►
From YouTube: AsyncAPI SIG meeting 34 (October 27, 2020)
Description
This is the recording for the AsyncAPI Special Interest Group (SIG) meeting #34.
Attendees:
- Fran Mendez
- Laurent Broudoux
Agenda & Notes: https://github.com/asyncapi/asyncapi/issues/455
Chat:
(no chat this time)
A
Hello,
hello,
so
we
are
for
those
watching
the
recording.
We
are
lorraine-
and
I
here
today
on
the
on
the
sick
meeting
and
so
lauren
had
a
really
good
update
from
my
crux
to
give
us
today.
So
so
yeah,
please
smith,
introduce
what
you
have.
B
Thanks
very
much
friend
hi
everyone
thanks
for
for
watching
the
the
recall,
so
just
tell
you
a
few
words
about
me
to
introduce
myself,
so
my
name
is
lauren
produ
and
I'm
the
the
founder
of
the
microx
dot
io
project.
This
is
a
an
open
source
project
dedicated
to
to
api
mocking
and
testing
a
few
words.
On
my
background.
I
work
as
a
solution
architect
at
red
hat
on
daytime
on
nighttime.
B
B
Okay,
so
looking
how
to
share
my
wall
screen
because,
right
now,
I
can
only
select
a.
B
B
Okay,
so
now
you
should
see
my
chrome
browser
right
now:
okay,
so
a
few
words
on
the
micro.
So,
as
I
said
before,
it's
it's
an
open
source.
Tooling,
it
is
based.
It
is
all
related
to
kubernetes
and
dedicated
to
api
marking
and
testing,
and
we
just
launched
it
was
during
august
the
1.0
release.
Okay
and
there's
two
big
features
around
the
microx.
The
first
one
is
obviously
around
the
mocking.
B
So
basically
microx
allows
you
to
turn
the
any
api
specification,
any
api
contract,
whether
it's
a
postman
collection,
an
open
api
specification
and,
of
course,
on
a
sync
api
specification.
It
allows
you
to
turn
that
into
live
marks
in
seconds
so
that
the
consumers
of
your
api
may
start
working
immediately.
B
B
The
second
one
is
about
testing,
so
we
are
able,
in
my
clocks
to
reuse
your
api
specification,
your
postman
collection
and
then
use
it
as
some
test
definitions.
So
that,
once
you
have
developed
once
you
have
deployed
your
api
implementation,
microx
is
able
to
check
that
this
implementation
is
compliant
with
your
specification,
okay
and
we
provide
different
plugins
different
cli
tools
so
that
you
can
integrate
these
checks
into
your
automated
cicd
pipeline.
Okay,
so
we
provide,
for
example,
jenkins
plugin,
and
we
provide
some
simple
cli
and
also
a
tecton
task.
B
Tecton
is
the
new
clam
native
cicd
technology
right
now,
okay,
so,
as
I
said
before,
we
announced
the
support
of
a
sync
api.
It
was
during
this
summer
on
august,
and
now
we
we
should
have
it.
It
will
be
for
the
end
of
this
week.
We
should
have
the
1.1
version
that
com
event
brings
some
new
features
around
this
thing,
kpi,
so
basically
for
the
1.0.
B
B
Microx
installation
onto
my
kubernetes
cluster
so
right
now
this
is
an
openshift
cluster,
but
basically
it
works
on
any
kubernetes
distribution.
Okay
and
microx
is
just
a
set
of
micro
services.
So,
depending
on
the
features
you
want
to
enable
to
disable,
you
will
have
different,
deploying
microservices
for
for
micros
and,
if
I'm
connecting
to
the
application.
B
This
is
the
this
is
the
the
home
screen.
This
is
the
dashboard
okay,
when
I
can
easily
have
a
look
on
my
api
and
services
repository.
So
this
is
the
the
the
number
and
the
different
kind
of
api
I
have
in
my
registry
right
now.
B
B
B
One
is
about
the
registration
of
a
user
and
another
is
about.
It
is
in
a
sync
api,
of
course,
and
it
is
about
the
signed
up
event
that
we
may
send
when
a
new
user
is
registered.
For
example,
once
these
api
are
imported,
they
appear
in
the
registry
right
here.
So
you've
got
these
nice
pictures
here
and
different
colors
telling
you.
This
is
a
rest
api,
and
this
is
a
an
event-based
api,
so
you
can
use
labels
so
that
you
can
have
your
own
taxonomy
to
easily
classify
and
then
retrieve
your
different
set
of
apis.
B
Okay.
So
when
I
go
to
an
api
user
signed
api,
okay,
I've
got
the
basic
informations
right
here
with
the
contract
of
this
api,
and
you
can
see
that
it
has
discovered
the
different
operations
here.
There's
just
one
operation,
okay,
and
because
I
have
enabled
all
the
asynchronous
api
support
in
microx.
B
B
Specification
was
defining
two
examples
here
and
as
soon
as
this
api
specification
is
imported
into
microx,
it
starts
publishing
example
messages
on
the
endpoint
every
10
seconds,
so
this
is
the
default
frequency
you
can
tune
it.
Of
course,
the
different
messages
will
be
published
on
a
specific
topic
that
is
created
by
microx
at
the
api
import.
B
So
the
first
thing
is
that
I
can
check
that
everything
is
now
okay.
I
have
to
share
up
my
terminal.
Okay
and
now
you
can
see
my
terminal
right
here
so
just
using
a
simple,
node.js
consumer,
I
can
see
that
each
and
every
10
seconds
the
microserver,
is
publishing
new
messages
from
the
examples
that
were
found
into
the
specification.
B
Okay.
So
basically
that
was
the
the
feature
that
the
1.0
really
bring,
and
now
we
have
added
some
new
feature
around
the
the
tests.
Of
course,
some
right
here
you
can
see,
there's
a
little
diagram
here,
giving
you
some
results
of
the
the
last
test.
A
B
Right
here
you
can
see
there
is
the
this
little
diagram
here
and
the
nice
thing
about
the
the
next
coming
version
is
now.
I
have
the
ability
to
launch
test
to
connect
to
a
real
kafka
endpoint
somewhere
in
the
organization,
and
to
check
that
the
different
messages
that
are
published
on
a
topic
are
compliant
with
the
schema
information
that
were
provided
into
the
async
api
document.
B
B
B
B
Just
have
the
the
payload
of
the
message
that
was
received
and
the
validation
error
regarding
the
schema
so
right
now
there
is
a
problem
because
we
find
an
integer
here
and
we
were
expecting
a
string
for
this,
this
property
okay.
So
it's
normal.
We
have
a
test
failure,
so
just
switching
my
window
just.
B
B
A
So
this
where's,
this
data
coming
from
this
data,
is
coming
from
the
mocking
right,
so
they.
A
A
B
I
have
developed
an
application
that
published
by
should
published
this
event
with
microx.
I
can
listen
to
the
to
the
topic
this
application
is
connected
to
and
then
I
will
check
that
the
the
events
sent
by
this
application
are
correct.
So
these
are.
This
is
real
data
coming
from
the
the
real
application.
B
B
So
basically,
this
is
how
we
can
easily
test
application
that
should
produce
or
consume
events
using
microx
and
all
the
information
present
into
the
dsync
api
contract.
A
That's
that
that's
really
cool
man,
so
I
just
have
one
question
here:
yeah
that
comes
to
my
mind
is
I
guess
this
is
for
testing
environments
and
not
for
production,
maybe
because
I'm
thinking
so
the
reason
I'm
asking
this
is
under
huge
loads.
Let's
say
of
messages:
when
you
have
a
lot
of
messages
in
production,
then
you
will
also
have
to
scale
microx
to
handle
this
amount
of
messages
right,
yeah
right.
A
B
Yeah,
so
obviously
it
should
be
done
as
early
as
possible
into
the
the
development
process,
so
we
recommend
plugging
microx,
starting
from
the
the
dev
environment,
but
there
is
nothing
that
prevent
to
use
this
with
the
production
test
as
soon
as
we
are
able
to
connect
to
the
remote
endpoint,
and
we
can
easily
manage
that
using
this,
this
ability
here
to
specify
some
secrets
so
that
I
can
reuse
credentials.
I
can
reuse
certificates
to
connect
to
each
and
every
broker
into
the
the
organization.
B
B
So,
basically,
what
we
have
planned
is
if
we,
if
your
own
station,
is
tending
to
have
more
and
more
tests
in
parallel
to
starting
to
listen
to
more
and
more
different
endpoints,
the
operators
will
be
able
to
scale
the
number
of
components
scale,
the
number
of
consumers
within
the
the
microx
installation,
so
that
it
should
not
be
an
issue.
A
So
so,
then,
I'm
not
a
cure,
not
just
expert
actually
like
I'm
new
at
almost
new
at
kubernetes,
so
so
the
way
you've
seen
this
is
to
have
microax
like
in
a
central
place,
centralized
place
where
all
your
micro
services
are
going
to
publish
or
subscribe
from
to
well
actually
fabulous
in
this
case
only
right.
So
it's
it's
is
this
the
the
let's
say
the
architecture
design
that
you
are.
I
don't
know
how
to
it's,
not
that
yeah
you're.
A
This
is
the
the
way
it's
it
will
work
or
it's
right
working
right
now,
at
least.
B
B
I've
tried
this
before
and
I
see
many
many
customers
trying
this.
This
approach
is
not
very
scalable
when
you
try
to
when
you're
starting
to
have
dozens
and
or
hundreds
of
services
and
apis.
This
does
not
skate,
because
you
always
have
some
issues
around
the
synchronization
and
keeping
everything
up
to
date.
So
you
ended
up
having
different
developers
working
with
different
mock
definitions
and
that's
lead
to
chaos.
B
Obviously,
so
the
first
opinion
with
microx
was
to
providing
some
kind
of
a
platform
so
that
developers
different
teams
do
not
have
to
worry
about
running
their
own
mocks.
They
can
rely
on
the
microx
installation
that
is
shared.
That
is
always
up
to
date,
and
this
is
because
it's
this
way
it
is
important
to
be
connected
to
the
git
repository
and
it
provides
a
marks
and
the
same
mocks
for
for
everybody.
A
B
We
are
starting
to
see
customers
having
starting
with
one
instance
for
all
the
needs
related
to
development,
and
then
they
start
popping
new
new
installations
for,
for
example,
creating
a
new
sandbox
for
partners
or
creating
a
new
sandbox
to
use
during
performance
testing
so
that
they
can
simulate
a
different
response
time
of
your
own,
their
api
using
microx,
and
then
they
are
using
some
so
some
features.
We
have
some
abilities
around
the
exporting
and
reimporting
mox
definition
between
different
microx
setups.
So
actually
it's
definitely
micros
definitely
built
as
a
platform.
A
B
A
On
the
top
on
the
on
the
browser
tab,
you
have
it
there,
it's
a
topology
right
yeah,
so
I
was
meaning
the
topology.
I
couldn't
find
the
word
so
yeah
and
then
again,
I'm
like
pretty
new
to
kubernetes.
So
have
you
thought
about
having
this
as
a?
I
think?
It's
a
it's
called
sidecar
like
having
like
each
service,
have
to
have
a
micro
instance
mini
micro
instance,
obviously
as
a
zip
car,
and
then
the
information
is
somehow
centralized
in
some
place.
A
So
I'm
saying
this
because
in
case
in
case
of
scaling
in
case
you
want
to
scale
this,
and
one
service
is
behaving
like
like
a
beast
and
it's
promising
a
lot,
then
only
this
micro
instance
is
going
to
be
affected
right
and
the
rest
are
going
to
be
fine
just
from
time
to
time
this
instance
will
have
to
to
update
the
results,
let's
say,
of,
of
the
minecraft
tests
and
and
and
marks
as
well
on
the
central
place.
B
No,
no,
no,
the
the
sidecar
based
architecture
is
really
interesting.
It
opens
the
it
opens
the
door
to
many
many
use
cases.
So
currently
we
are
explorating
some
some
usage
of
the
the
sidecar
pattern
with
with
service
mesh,
for
example,
because
there
is
so
when
you
want
to
use
some
of
the
features
in
service
mesh
like,
for
example,
a
b
testing
like
mirroring
the
different
the
traffic
like,
for
example,
during
a
canary
release.
B
You
can
easily
imagine
how
my
crocs
can
be
used
to
to
to
gather
the
the
real,
the
real
traffic
of
an
application
or
to
be
used
as
a
placeholder
waiting
for
a
new
feature
to
be
developed.
For
example,
you
may
introduce
the
new
version,
even
if
it
is
not
yet
deployed
developed,
the
sidecar
will
use
the
mock
provided
by
microx,
for
example.
So
definitely
this
is
something
where
we
are
explorating.
A
I'm
saying
because
I'm
saying
because
of
this
like
it
would
be
great
to
have
like,
for
instance,
every
team,
because
the
whole
thing
about
microservices-
it's
not
so
much
the
technology,
but
it's
more
about
how
people
work
right.
How
people
can
yeah
manage
their
own
work
from
from
design
to
to
production
right
the
whole
the
whole
way
right
from
from
idea
to
production.
If
you
want.
A
So
so
I
was
thinking
that
maybe
and
and
one
of
these
one
of
these
parts
is
actually
the
evolution
of
the
service
like
you
were.
You
were
saying
before
that
this.
This
would
allow
people
to,
for
instance,
work
on
version
two
of
their
service
version.
Three
write
the
next
version,
and
before
and
and
update
they
their
their
sidecar
or
their
microx
instance
running
in
their
sidecar
that
they
manage
right.
B
A
And
that
will
allow
them
to
to
start
like
already
in
production.
You
know
generating
bugs
and
generating
tests
before
it's
actually
done
before.
It's
actually
like
you
said,
like
it's
actually
implemented
like
we,
this
micro
service,
it's
still
in
version
one,
but
you
already
have
the
marks
and
the
tests
in
your
instance.
So
whatever
you
want
to
develop,
you
already
have
the
information
there,
yeah
or
even
even
better
other
people,
relying
on
your
next
version
of
the
service.
A
A
And
also
the
reason
I
was
saying
that
is
so
we
are.
Can
one
of
our
plans
that
I
think
api
is
to
have
something
that
well
there's.
There
is
a
a
bit
of
confusion
with
the
name,
but
so
the
current
18kp
I
have
it's
going
to
be
renamed
to
async
studio
right.
So
that's
that's
one
thing,
that's
one
part
and
then
we're
going
to
create
something
which
is
probably
going
to
be
called
async.
A
I
have-
and
it's
probably
something
like
this,
something
like
what
with
what
we
were
saying:
it's
a
piece
that
you
can
install
on
your
side,
car
or
in
your
or
actually
as
a
center
as
a
centralized
service
in
your
architecture
right
and
that
will
allow
you
to
validate
messages
before
they
go.
A
A
So
so
nobody
has
to
know
the
the
secrets
to
encrypt
and
decrypt
messages,
because
because
yeah,
only
only
the
security
team
will
be
in
charge
of
going
to
your
sidecar
and
updating
the
the
the
secrets
right
to
encrypt
and
decrypt
your
messages
yeah.
So
you
don't
you
will
not
at
development,
you
will
not
have
to
worry
about
it.
A
Only
only
people
only
devops,
if
you
want
our
security
people
will
need
to
know
and
or
for
instance,
also
a
transformation
like,
for
instance,
you
want
to
make
sure
that
every
message
has
a
sent
at
field,
and
if
it's
not
there
use
will
be.
A
You
should
be
adding
this
sent
at
with
the
current
date,
with
the
current
timestamp
for
instance.
So
things
like
this,
like
can
be
like,
can
be
stupid.
Things
like
this
or
can
be
transformations
in
the
sense
of
we're
going
to
start,
transforming
all
the
messages
from
version
one
to
version
1.1,
yeah.
B
A
Or
version
two,
so
you
do
the
transformation
on
the
sidecar
first
and
then
so
you
so
the
other
services
can
adapt
and
then
people
can
update
their
code
right,
which
this
part
is
a
little
bit
tricky,
because
that
will
that
that
reminds
me
a
lot
to
what
you
know.
What
was
the
name?
A
B
A
There
you
will
have
a
little
bit
of
smart
pipes
a
little
bit
as
well,
so
so
yeah
we're
still
figuring
out
like
if,
but
I
mean
that's
in
our
case,
that
has
to
be
unopinionated
like
it's
not
a
product.
It's
just
a
technology
piece.
You
use
it
as
you
as
you
want,
because
you
might
not
be
doing
microservices
at
all
yeah,
so
so
yeah
yeah.
B
For
sure
yeah
we
are,
we
are
seeing
users
of
microx
using
it
not
for
rest.
Api
is
not
for
async
apis,
but
for
legacy
software
services,
because
we
are
also
able
to
to
mock
and
test
software,
stop
web
services,
so
people
use
microx,
for
example,
during
a
technical
migration,
they
are
changing
their
their
esb.
A
B
A
What
are
the
other
other,
let's
say,
kind
of
architecture
that
people
tend
to
use
with
async
api?
Is
it's
test
queues
right
so.
B
A
Start
queueing
tasks
in,
for
instance,
in
rather
than
cure,
for
instance,
right.
That's
very
common,
like
people.
One
common
example
is
curing
emails
right
like
not
just
emails,
but
for
instance,
you
queue
a
welcome
email
or
you
queue
a
an
email
saying
like
hey,
you
registered
you
signed
up,
but
you
didn't
complete
step
one
or
two
or
three,
whatever
you
have
to
give
some
time
to
people
right,
that's
why
you
view
it
there,
and
so
this.
This
kind
of
things
are
also
in
synchronous.
A
Let's
say
operations
right
with
amqp
or
sequence,
apis
or
events.
If
you
want,
but
but
yeah,
they
are
not
microservices
at
all
like
this
can
probably
a
monolith
with
just
a
queue
right,
and
I'm
saying
because
I
did
it
in
the
past,
I've
been
working
with
this
architecture
in
the
past,
like
a
monolith
and
a
queue.
Thank
you
yeah,
so
yeah,
okay,.
B
That's
cool!
Thank
you!
Thank
you
for
the
transition
and
here's
the
the
last
piece
of
the
demonstration.
So
right
now
imagine
you
have
this
kind
of
maybe
monolithic
application
regarding
user
registration.
Okay,
so
it
is
deployed
here
into
my
kubernetes
cluster
and
it
has
its
own
kafka
broker.
This
is
not
the
kafka
broker
used
by
microx
internally.
B
This
is
another
kafka
broker,
and
this
application
right
here
just
exposed
two
apis,
the
first
one
being
the
rest
api,
allowing
a
user
to
register
okay
and
the
second
one
being
the
user
signed
up
api
because
the
the
business
rule
is
when
you
have
registered
a
new
user.
You
should
published
an
event
to
say
this
user
has
been
signed
in
and,
as
you
say,
to
send
to
send
him
an
email
to
compute
some
discount
advantages
or
whatever,
okay
and
one
nice
thing
with.
B
My
crux-
is
that
you
can
all
the
tests
we
have
done
before
we,
you
will
be
able
to
automate
this
from
your
delivery
pipelines.
So,
for
example,
right
here
for
this
application,
imagine
I
can
write
some
kind
of
pipeline
like
this
okay.
So
this
is
a
tecton
pipeline
and
basically
it
has
two
yeah.
It
has
two
two
branches,
so
I
start
with
building
the
app
deploying
the
application,
and
then
I
will
have
a
first
branch
that
will
take
care
of
testing
the
open
api
rest
api,
the
the
registration
api.
B
I
can
test
it
in
version,
one
in
version
two
and
then
I
have
a
parallel
branch
that
is
taking
care
of
gathering
the
messages
and
testing
the
async
api
specification
and
then,
if
the
two
branches
are
okay,
I
can
say:
okay,
this
application
is
implementing
the
two
apis
correctly
and
I
can't
promote
it.
So
if
you
have
a
look
sorry,
it's
a.
B
I
start,
hating
eml,
but
if
you
have
a
look
at
the
at
this
dcml
pipeline
right
here,
this
you've
got
this
task
here.
That
is
my
cox
test.
So
here
I
can
specify
the
test
endpoint.
I
can
specify
my
broker
that
is
used.
I
can
specify
the
the
the
secret
that
is
used
to
connect
to
the
remote
endpoint
and
actually
the
different
test
steps
here
are
all
microx
tests.
B
A
That's
that's
really
cool,
so
that's
I.
I
assume
that
when
you
launch
a
test
before
promoting
the
app,
let's
say
when
you
launch
a
test,
it
has
to
wait
for
for
the
data
to
come
right
like,
for
instance,
yeah
this.
This
data,
this
the
data
that
you're
feeding
into
the
test
is
real
data
like
it's
coming
from
the
real
application
yeah.
If
that's
the
case,
what
if
no
messages
are
coming
like,
for
instance,
there
are
there?
Are
there.
A
There
are
some
kind
of
applications
that
are
not
data
intensive,
like,
for
instance,
they
get
some
some
messages
every
day,
not
not
every
minute
right
like
every
day.
So
what
what
about
them?
Like.
B
Yeah
about
this
case,
of
course,
if
there
is
no
data,
is
coming,
the
the
taste
is
failing,
but
right
here
indeed,
because
in
parallel
we
are
invoking
the
rest
api.
B
A
B
B
B
You're
using
the
combination
of
delivery
pipeline
cd
pipeline,
so
whether
it
is
tecton
or
jenkins
whatever
and
parallel
branching
and
microstrips.
You
have
a
wonderful
mean
of
actually
testing
that
the
the
the
interface
of
your
api
are
correctly
implemented,
but
also
that
the
behavior
of
the
application
is
is
correct
because
you
can
test
in
parallel.
The
the
synchronous
part
and
the
asynchronous
part,
making
a
condition
that
both
parts
will
join
before
promoting
the
app.
A
B
B
You
have
to
yeah,
you
have
to
set
some
yes,
some
some
coherent
timeout,
because
if
you,
if
you
are
just
waiting
on
this
sync
api
branch
for
two
seconds
and
your
your
application,
has
a
some
kind
of
warm-up
timeout
before
actually
publishing
message,
it
will
fail
but
yeah.
Just
during
the
the
timeout,
we
is
a
okay.
A
I
guess
I
guess
that's
tactile
related
right,
so
it's
not
really
microbes
so
to
define
these
these
details.
A
B
No,
this
is
microx
because
on
the
on
the
different
plugins
and
tasks
we
are
providing.
Oh
sorry,
let
me
go
to
the
pipelines
on
the
different
tasks
we
are
providing.
There
is
the
up
there.
Is
this
specific
attribute?
Wait
for
and
indeed
yes,
the
async
part
is
waiting
longer
and
20
seconds
and
the
open
api
the
exactly
eight
seconds
yeah.
So
you
have
just
to
tune
the
things
like
that
to
to
be
sure
to
to
wait
the
correct
amount
of
time.
B
A
Guess
it's
waiting
like
20
seconds
at
most
right,
like
yeah.
If,
if
it
happens
before
it
will
just
continue
right
like
he
doesn't.
B
A
It
for
the
demo-
that's
not
that's,
really,
that's
really
impressive
and
you're
doing
a
great
job
here.
It's
really.
It's
really
moving
forward
the
mocking
and
testing
of
even
driven
architectures-
and
this
is-
and
this
is
super
interesting
because
I
mean
there's
nothing
and
you
know
it
like-
there's
nothing
about
it.
There's
nothing!
A
There's
nothing
yet
to
test
and
mock
aside
from
microbes
right,
there's,
nothing
else
to
test
even
driven
architectures
and
that's
super
important
step
if
we
want
to
make
even
driven
architectures
as
as
mature
as
stressed
apis
and
and
let's
say,
microservices
architecture
based
on
based
on
service
mesh
or
well
yeah
yeah,
but
like
in
a
similar
like
material
in
a
similar
way.
Right.
A
That's
that's
my
point
so
right
now
we
have
lots
of
tools
for
rest
apis
for
several
messages,
for
for
many
things,
yeah
for
many
synchronous
things,
let's
say,
but
for
asynchronous
stuff
we
have
almost
nothing
right,
like
people
were
historically
trying
to
avoid
these
kind
of
architectures
because
it
is
complex
and
it
looks
complex
to
to
reason
about
and
to
and
to
implement
and
with
these
tools,
we're
actually
making
it
easier
to
to
succeed
on
events.
B
A
I-
and
I
got
a
note
on
what
you
said
before,
and
I
think
this
is
really
important
and
people
are
not
yet
exploring
this
area.
So
much
is
about
offering
like
a
sandbox
for
your
partners.
A
B
Something
happens
and-
and
also
you
do
not
have
to
to
maintain
expensive
environments
for
your
partner.
I
made
quite
a
quite
a
few
customers
that
were
starting
evaluating
my
crooks,
and
I
was
very
surprised
when
they
told
me
that
they
were
having
a
full
representative
environment
from
for
staffs
like
open
banking,
for
example,
the
some
bank
are
providing
open
banking
services
and
they
are
dedicating
a
world
environment
to
the
the
sandbox
they
provide
to
partners,
and
they
say
that
it's
really
expensive
because
they
have
to
maintain
all
of
this.
A
That's
true,
and
but
I
I'm
like
you
know,
cost
is,
is
an
important
thing
here,
but
I'm
I'm
more
interested
in
the
in
the
business
facts.
Let's
say
the
in
the
like
right
now.
The
way
we
implement
this
with
partners
or
consumers
are
our
external
consumers
in
rest.
Apis,
it's
clear:
it's
like
you
give
people
you.
You
have
all
what
two,
for
instance,
for
people
to
authenticate
and
consume
your
data,
your
real,
your
real
data
and
that's
on
demand.
A
So
when
the
user
needs
it
reply
and
then
you
have,
of
course
you
have
to
apply
limits
rate
limiting
and
all
this
stuff,
but
we
we
found-
or
I
found
in
the
past
many
times
that
I
wanted
to.
I
wanted
a
higher
limit
rate
limit
because
I
had
to
ping
the
api
very
constantly
like
because
it
it
was.
It
was
impossible
for
me
to
to
wait
more
because
I
wanted
something
more
real-time,
but
I
couldn't
because
yeah
the
api
wasn't
offering
this
to
me.
We
now
have.
A
We
now
have
some
what
now
not
now,
but
we
started
to
have
this
web
hooks
architecture
right.
So
it's
it's
actually
the
company
or
the
the
api
you're
consuming
is
actually
calling
you
right
so,
which
is
it's
a
step
right?
It's
it's
a
it's
now
a
a
a
step
towards
asynchronous
or
operations.
A
Let's
say
if
you
want
so,
but
that's
that's
cool,
because
let's
say
this
is
that's
cool
because
you
don't
have
to
ping
the
api
all
the
time,
but
it's
out
of
band
and
and
what's
happening
here
is
that
if,
of
course,
there
are
retries
if
you
miss
if
your
services
are
down
for
whatever
reason
and
the
webhook
is
calling
you
many
times
after
certain
number
of
retries
you're
gonna
miss
this
data
right
yeah.
Of
course
you
shouldn't.
Have
your
services
down.
That's.
B
A
It
for
granted,
but
these
things
happen
so
so
so
my
opinion
is,
if
we
can
cue,
let's
say
if
you
can
queue
this
data
somewhere
like
in
kafka
or.
B
A
Or
in
a
routing
queue
or
something
like
this,
and
then
it's
it's
actually
myself,
where
I'm
gonna
go
there
to
the
queue
and
consume
the
data
whenever
I'm
ready
right
whenever
I'm
up
and
ready
or
even
in
the
case
of
kafka,
I
want
to
go
back
to
the
history
of
data
and
replay
for
whatever
reasons,
because
I
want
to
do
it.
A
B
A
B
B
B
Issue
when,
when
you
start
talking
with
partners
about
asynchronous
integration,
is
usually
there,
there
is
two
two
main
problems.
I
see,
what
is
the?
What
is
the
protocol,
and
do
you
have
some
kind
of
industry
standard
protocol
that
offers
a
loose
coupling?
B
So
kafka
is
now
the
de
facto
standard,
but
some
other
players
like
imqp,
are
really
portable
protocols
and
the
the
other
issue
I
usually
see
is
around
how
to
specify
how
to
describe
the
contract,
and
this
is
where
a
sync
api
specification
should
have
easy
its
role
to
play.
So
I
think
right
now,
we
we
do
have
the
the
tools
to
make
asynchronous
integration
rise.
A
B
B
A
B
Yeah
right,
it's
also
a
mindset
and
all
the
things
around
the
cicd
helps
a
lot,
because
people
start
to
think
start
to
to
ask
them
how
to
to
do
things
in
a
more
agile
way
or
to
to
deliver
software
more
fluid
in
a
more
fluid
way,
so
yeah.
So
it's
the
good
time.
A
Cool
thanks
hello,
so
I
hope
I'm
pronouncing
well
good
night.
A
Lorenzo
here
in
spain,
cool
man,
so
thanks
for
for
joining
us
today
and
giving
us
this
cool
demo,
this
microx
thing
is:
I
think
it's
going
to
have
a
a
great
feature,
but
I
hope
it's
going
to
have
a
great
feature
and
yeah
always
happy
to
have
you
absolutely.
A
Thank
you,
you're
welcome,
okay,
so
I'm
just
closing
the
recording
right
now
and
for
those
who
don't
know,
we
are
having
this
meeting
every
two
weeks
so
in
into
but
we're
alternating
times.
So
in
two
weeks
we'll
have
the
the
meeting
at.
Let
me
see
if
I
can
see
it.
If
I
can
say
it
correctly,
so
next
meeting
is
going
to
be
at
4,
00
p.m,
utc,
so
it's
actually
5
p.m
in
central
europe
time.
A
So
this
is
more
american
friendly.
If
you
want
and
and
then
in
two
weeks
later,
we'll
have
the
meeting
at
this
time
again,
which
is
at
8
a.m.
Utc-
and
this
is
more
asia,
new
zealand,
australia
friendly
today.
I
think
what
was
the
name
again.
It's
apec
right.