►
Description
AsyncAPI Conference 2022 - Day 3
5th November 2022
Want to try out AsyncAPI for your brand new Websocket API? Sure, that’s a great fit! But have you ever thought about all the other use-cases where AsyncAPI could also shine? Reactive system design, microservices adoption, data lake ingestion, hybrid-cloud communication, even mainframe integration… all these use-cases may benefit from AsyncAPI adaptable structure and protocol bindings. And we’re not just talking about documenting stuff… but making all these Event Driven Architecture patterns faster and easier to deliver for development teams!
In this session, we will:
- Discuss all the places AsyncAPI can be used in complex organization Information System,
- Highlight the capabilities of AsyncAPI that make it rocks for the different jobs,
- Give an overview of Microcks for speeding-up and securing the delivery of EDA components described with AsyncAPI.
A
A
So,
first
a
little
bit
more
about
me.
My
name
is
Lauren
and
I'm
working
at
Google
on
daytime,
where
I
support
fintech
startups
scale-ups
in
their
in
making
their
application
design.
Quantity
I'm
also
involved
in
open
source
and
spare
time
being
a
member
of
the
async
API
TSC
and
the
leader
of
microsmore
heard
that
in
a
few
minutes
before
joining
editors
or
Cloud
providers
was
working
as
an
Enterprise
architect
in
financial
services.
So
I
think
I
have
a
very
pragmatic
background.
A
But,
throughout
my
experience
this
last
year,
I
also
come
to
to
a
somewhat
provocative
question.
When
discussing
with
customer
or
colleagues.
What
does
the
a
of
Eda
stands
for?
Of
course
everybody
knows
it's
for
architecture,
but
what
does
architecture
mean
to
you?
Is
it
technical
architecture?
Is
it
related
to
the
the
logic
of
interaction?
A
Is
it
the
architecture
of
your
information
system
or
the
the
organic
design
of
your
application
and
wouldn't
the
amine
application?
Sometimes
if
you
focus
on
interacting
with
the
user,
so
it
leads
to
the
question:
what's
an
application
if
you're
looking
for
a
user
perspective
or
lifecycle
perspective,
but
in
short,
those
questions
make
me
think
that
there
are
different
levels
where
Eda
can
make
sense.
A
It
was
not
that
considered
reliable,
remember
it
was
just
the
beginning
of
free
class
system
and
the
era
of
two
phase
commits
and
at
the
end
of
the
day,
people
tend
to
prefer
pure
web
services
or
batch
exchanges
that
were
way
easier
to
to
operate
at
that
time.
So
Eda
was
just
on
the
test
on
a
few
use
case,
mostly
one
usage,
exchanging
flows
with
Partners
or
Legacy
stem,
and
mostly
in
financial
services,
but
and
also
even
there
is
very
similar,
all
pigeons
or
or
EDS
Solutions.
A
A
It
also
allows
us
to
manage
what
we
see
new
industry,
iot
Edge
Computing
use
cases
at
the
application
Level
having
a
distributed
applications
with
a
central
herb
and
distributed
devices.
For
example.
It
allows
you
to
address
what
we
have
in
modern
application:
interaction
like
streaming
applications
having
an
API
that
stream
event
to
a
browser
or
a
mobile
phone,
and
yes,
it
also
helps
specify
complex
or
long-running
workflows,
like
loan
application,
like
mortgage
application
and
so
on.
So
you
see
that
it
can
apply
to
to
a
wall
range
of
use
cases
at
very
different
levels.
A
When
you
really
see
the
the
heavens
as
the
building
blocks
for
supporting
your
I.T
transformation
or
enabling
more
agility
into
the
into
the
business,
each
category
comes
with
its
own
victories
of
badges.
If
you
manage
it
as
a
progression,
but
don't
get
me
wrong,
I
I,
don't
necessarily
see
this
as
an
adoption
path.
It's
a
map
and,
in
my
experience,
I've
seen
people
that
were
really
well
addressing
the
path
on
the
right,
but
totally
neglecting
the
one
on
the
left.
A
So
the
latest
element
I
want
to
introduce
before
talking
about
recipes
is
this
microx
project
I'm
working
on
this
is
of
greatest
importance
as
I
truly
think
that
even
the
greatest
spec
needs,
pragmatic,
tooling,
to
unleashes
Value
to
a
reactor
on
the
life
cycle
and
in
a
few
words.
Microx
is
a
tool
that
help
to
help
simulation
and
testing
of
all
kinds
of
API,
including
the
the
even
driven
ones,
for
the
support
of
async
API.
A
Of
course,
how
we
are
doing
that,
and
we
are
doing
that
by
leveraging
the
power
of
contracts
an
example
contracts,
because
we
are
using
a
Sync
API
and
it
provides
all
the
syntactic
rules
in
it
and
examples,
because
examples
provide
illustrative
real
world
scenario
for
free
and
they
can
be
embedded
into
the
spec
as
well
most
of
the
time
in
development.
We
we
neglect
for
or
in
design
phases.
We.
We
neglect
the
importance
of
examples.
A
So
that's
a
few
words
on
my
Crocs
and
you'll
see
it
in
actions
in
a
few
in
a
few
in
a
few
minutes.
So
now
that
we
have
our
three
elements:
Eda
async,
API
and
microx,
we
can
deep
dive
into
recipes
and
I
specifically
choose
six
recipes,
but
I
think
are
the
the
most
common
ones
and
but
every
architect
every
every
practitioner
should
be
aware
of
foreign
as
I
try
to
make
them
a
bit
generic
to
to
Encompass
the
most
situation.
Possible.
A
So
my
first
recipe
is
the
the
examples
you
you
always
see
when
dealing
with
a
Sync
API,
it's
dedicated
to
user
interaction
and
how
Eda
and
async
API
can
help
enhance
the
the
user
or
the
the
customer
experience,
or
at
least
the
experience
of
the
developer.
That
is
developing
enhanced
user
or
customer
experience.
So
this
is
a
mini
receipt
to
to
set
up
the
structure.
That
would
be
the
same
for
each
one.
So
we'll
talk
about
the.
A
A
But
you
can
also
specify
user
LED
interactions
using
Eda
and
async
API.
Imagine
you
want
to
implement
a
chat
room
or
something
like
that,
and
this
time
you
have
to
Define
publish
operation
on
the
channel,
so
that
users
can
send
messages
and
because
a
Sync
API
this
notion
of
protocol
bindings
you'll
be
able
to
precisely
describe
the
one
you
choose.
A
It
can
be
a
simple
HTTP
for
server
side
events
for
notifications
or
it
could
be
AWS
a
simple
notification
system
for
for
mobile
or
even
web
sockets
in
the
case
of
a
chat,
so
a
Sync
API
is
very
flexible
for
that.
It
also
allows
you
to
handle
different
content
types
for
your
messages,
but
in
that
case,
you'll
probably
end
up
with
Json
encoding
messages.
A
How
can
microx
help
in
that?
Well,
let's
focus
on
a
simple
point
for
a
moment.
Microx
will
be
very
helpful,
allowing
you
to
to
speed
up
the
work
of
the
funded
team,
while
the
backend
team
is
developing
the
the
notification
system,
for
example,
so
we
are
going
to
to
see
how
microbes
can
bootstrap
your
async
API
demo
time
and
hope
the
Democrat
will
be
with
me
today.
A
So
let's
switch
to
to
the
micro.
So
my
this
is
the
the
UI,
the
dashboard
of
microx
presenting
you,
the
different
API
which
are
in
your
system
and
micros,
is
very
contract.
Trust
driven.
We
promote
contract
first
approach,
but
we
recently
developed
this
new
feature
to
allow
you
to
having
a
rapid
feedback
loop
on
a
new
API.
This
is
called
direct
API
direct
API
allows
you
to
choose
an
API
type
here.
We
are
going
to
choose
11
driven
API
and
we
are
going
to
publish
a
notification
API.
A
Simply
and
with
microx,
as
it
is
example
driven,
you
can
just
specify
one
example
that
is
the
the
reference
payload
but
will
be
used
to
produce
simulation
and
to
produce
your
async
API.
I
can
use
specific
notations
in
micros.
Here,
for
example,
I
want
to
generate
a
universal,
unique
identifier
for
my
for
each
event,
for
each
message-
and
here
I
want
some
Randomness,
generating
a
first
name
to
greet
the
the
newcomer
in
the
chat.
A
A
A
Hopefully
it
doesn't
work.
Oh
yes,
it
works,
so
you
can
see
with
my
books.
I
can
really
really
quickly
bootstrap
my
Eda
project
really
bootstrap.
My
async
API
project,
whether
for
web,
sockets
or
other
bindings
here,
for
example,
on
the
Kafka
bindings
I
will
talk
about
in
a
few
minutes,
so
this
I
have
some
endpoints
that
are
generated
for
me,
so
that
ux
team
can
start
working
on
and
I
have
also
a
basic
contract
that
has
been
generated
for
me
and
I
can
start
to
to
enrich
it
to
to
complete
my
use
case.
A
A
This
is
very
hot
topic
today,
as
most
traditional
companies
are
moving
to
the
cloud
and
they
are
trying
hard
to
to
lower
the
cost
due
to
the
current
context-
and
this
is
where
Eda
can
be
used
at
an
application
Level
as
a
new
as
new
programming
patterns
emerge.
So
we
are
talking
a
lot
these
days
about
reactive
programming,
that
is
using
techniques
like
non-blocking
IO
when
talking
to
databases
and
dependencies,
but
reactive
also
introduces
a
lot
of
asynchronous
structures
to
avoid
adding
threads
waiting
for
processors
in
the
in
the
chain
of
invocation.
A
So
in
this
type
of
design,
each
processor
you
can
see
in
the
chain
will
benefit
from
clearly
defining
its
interface
through
an
async
API
publish
operation.
Of
course,
you
will
have
to
prove
to
proceed
in
reverse
order.
Last
processor
publish
its
interface
and
so
on
reverting
the
the
chain,
and
in
the
case
you
were
implementing
the
request
response
parading
on
this
way.
This
is
something
we
we
used
to
call
stage
event
driven
architecture
when
using
queuing
technology
in
the
past.
A
A
Sync
API
also
allows
you
to
clearly
Define
a
correlate
correlation
identifier,
but
may
be
used
to
to
match
the
outgoing
response
from
a
subscribe
operation.
This
time
for
this
type
of
situation,
you
may
want
to
to
choose
some
kind
of
traditional
broker
like
rabbit
and
Q
or
imqp,
as
those
patterns
may
require
durability,
but
not
the
long-term
Persistence
of
messages
so
also
on
the
side
of
message:
content
type,
A,
Sync
API
as
also
first
class
support,
forever
messages
that
are
binary
encoded.
A
A
Regarding
my
clock's
usage
in
that
case,
you
can
easily
use
it
for
testing
different
processors
in
in
isolation
to
to
each
other.
Therefore,
it
becomes
a
straightforward
to
define
a
set
of
example,
message
corresponding
to
expected
input
and
output
and
using
microx
testing
features.
You
can
really
spot
buggy
processors
in
your
chain.
So
let's
see
that
in
action
with
with
our
use
cases,
so
as
a
developer
of
a
processor,
I
can
easily
get
incoming
messages
without
having
to
wait
for
the
previous
processor
to
be
to
be
ready.
A
So,
if
I
go
back
to
my
notification,
API
I've
used
previously
I
can,
for
example,
see
that
there
is
also
a
Kafka
binding
that
has
been
provided
and
I
can
easily
start
to
browse
the
Kafka
topic
that
was
created
and
managed
by
micro.
So
as
an
example
here,
I
can
just
here
using
the
the
kcat
here
is
the
KitKat
tool
to
see
that
I
start
receiving
messages
and
I
get
start
developing
my
processor
so
very,
very
easy.
A
A
It
is
a
producer
and
it
produces
messages
and
on
my
topic
on
a
local
topic,
called
user
signed
UPS,
you
can
see
here
an
outgoing
messages
and
using
micros
I
can
easily
test
it
out.
So,
for
example,
I
can
launch
a
new
test
specifying
a
Kafka,
a
kafkind
point
here.
The
endpoint
that
is
used
by
my
application.
A
The
message
is
confirmed
to
the
schema,
and
here
you
can
see
that
my
processor
is
correct,
because
the
messages
that
he
is
sending
to
the
to
the
broker
are
conformant
to
the
schema.
So
it's
very
easy
to
spot
the
the
buggy
processor
to
to
check
here
that
everything
that
your
produce
are
confirmed
to
your
API
and
interfaces
you
you
define
so
really
easy
to
to
test
in
isolation.
A
A
You
remember
it
was
all
the
mq
series,
Webster
and
Q
Brokers
that
allow
access
to
your
Mainframe.
This
is
what
I'm
talking
about
and
I
see
a
lot
of
people,
retro
engineering,
those
chains
to
take
advantage
of
formal
description
and
tooling
acceleration
that
may
that
we,
they
may
have
with
a
Sync
API
eterogeneous.
A
Api
is
really
big
thing,
as
we
are
able
to
support
things
such
as
IBM,
Q,
amqp
or
mqtt
protocol
bindings
on
the
message:
content
type
side
of
things,
the
XML
is
still
a
big
thing
regarding
those
Legacy
systems
and
a
Sync
API
can
handle
a
XML
message
as
well
and,
of
course,
Json
rises
in
many
hatch
cases
where
the
interoperability
between
different
devices
or
different
device.
Vendors
is
the
key.
A
One
thing
that
I
really
wanted
to
highlight
today
is
the
usage
I,
see
of
micro
simulation
capabilities
on
the
field.
Having
issues
with
the
cost
and
availability
of
Mainframe
partitions
for
testing
having
concern
about
the
availability
of
remote
devices,
all
this
can
be
easily
simulated
using
a
Sync
API
example
supports
in
microx.
A
We
see
many
people
be
building
a
complete
partner,
sandboxes
using
simple
but
significant
mocks
with
micros,
for
example,
in
the
the
banking
World.
A
lot
of
Bank
are
providing
open
banking
sandboxes
to
allow
their
partners
and
their
users
to
to
play
with
their
apis
and
instead
of
connecting
those
sandboxes
to
existing
services
on
Mainframe.
Some
of
them
are
have
replaced
the
these
expensive
sandbox
environments
by
just
mocks
that
are
served
by
Michael,
so
really
really
a
cost-casting
costing
solution.
A
A
One
nice
thing
about
event
driven
is
that
it
allows
you
to
to
decouple
the
place
where
events
are
consumed
from
the
place
where
they
are
produced.
So
if
you
have
introduced
events
between
services
and
modules,
you
can
transparently
extract
the
modules
and
still
have
them
consume
events,
and
it's
then
very
easy
to
retire
existing
modules
in
a
in
a
very
Progressive
Way
other
side
effects.
Please
note
that
events
may
also
be
useful
in
microservices
work
to
to
break
the
dependencies
to
improve
the
uptime
and
the
resilience
of
an
application.
A
This
may
be
judges
of
The
Kill,
but
it's
really
help
anticipating
the
the
scale
up
of
your
application.
The
scale
up
of
your
of
your
traffic
as
you
refactor
into
micro
services,
so
really
nice
thing
of
a
Sync
API,
is
that
it
will
allow
you
to
to
to
precisely
describe
your
orchestration
and
your
composition
process.
You,
you
may
Implement
using
Saga.
A
Embedded
into
your
Sync,
API
spec
may
be
totally
appropriated
for
that
and
you
can
see
utilize
you
can
use
bindings
like
rabbit
and
Q
or
or
not,
if
you're,
very
Cloud
native
you
still,
you
probably
don't
need
long
Persistence
of
messages.
In
that
case
too,
on
the
micro
side,
we
can
specify
that
we
tend
to
see
more
and
more
the
need
to
use
local
development
laptop
situation
that.
A
A
developer
that
can't
or
doesn't
want
to
be
connected
to
True
complex
systems,
for
example
a
case
of
Mobility
or
offline
situation,
and
for
that
we
we
have
also
developed
a
Docker
extension
for
that.
So
just
to
to
give
you
a
brief
overview,
you
can
install
micros
in
a
centralized
way
so
that
the
same
instance
can
be
used
by
different
developers,
or
you
can
easily
use
the
docker
desktop
tool
and
browse
the
different
extensions
in
the
marketplace
and
install
the
microxim
tension.
A
That
way,
you
have
a
ready
to
launch
micros
and
it's
just
as
easy
as
eating
the
the
launch
button,
and
just
after
that,
you've
got
your
your
locally
running
instance
ready
to
be
filled
with
any
mock.
You
need
for
your
local
development
experience
so
very
handy
to
have
this
new
way
of
deploying
and
using
micros
recipe.
Number
five
is
all
about
pursuing
this
modularization,
but
scaling
it
to
the
organizational
level
by
adopting
some
kind
of
domain
or
product
driven
orientation.
A
The
usage
of
Eda
and
events
tend
to
be
generalized
as
the
de
facto
pattern
for
East-West
Communications
once
you
cross
the
boundary
of
a
domain.
Okay,
I'm
really
talking
about
cross-domained
boundaries,
and
this
usually
goes
hand
to
end
with
the
adoption
of
choreography
as
the
way
to
to
assemble
multi-domains
processes
in
the
organization.
And
here
again
there
is
a
lot
of
interesting
things
in
the
pattern
called
Saria
choreography.
A
So
I
really
really
encourage
you
to
to
have
a
look
at
this
also
to
to
notice
a
great
approach
that
we
have
foreseen
organization
is
the
definition
of
all
the
the
capabilities
of
a
domain
through
manage
API.
Could
it
be
for
a
classical
rest,
API
for
the
command
or
graphql
API
for
the
queries
or
a
Sync
API
for
all
the
things
relating
to
access
of
unit
or
data
in
unit
chunks
or
in
a
streaming
mode?
A
Most
of
the
time
we
see
that
the
data
related
capabilities
are
provided
by
Common
infrastructure,
common
Services,
common
team
of
attenders
ingestion,
cleaning,
anonymization
and
so
on,
and
I
really
think
it's
also
a
great
fit
for
a
Sync
API.
A
search
service
provider
can
easily
describe
publish
operations
contracts
that
can
be
simply
reused
by
all
the
domains
that
want
to
consume
these
centralized
services.
A
On
the
protocol
side
of
things,
the
async
API
can
support
Kafka
bindings,
as
we
already
see.
It
fits
particularly
well
with
the
injection
and
streaming
use
cases,
but
please
note
that
for
this
use
case,
the
deployment
of
a
schema
registry
with
either
a
Json
or
Avro
looks
like
like
a
mandatory
step,
as
schemas
must
be
available
and
governed
across
the
organization.
A
We
specifically
added
the
schema
registry
support
for
Kafka
in
the
latest
async
API
release,
that
is
the
2.5
release
of
the
spec.
So
you
should
really
have
a
have
a
look
at
it.
How
can
microbes
can
help
you
with
that?
It
can
help
a
lot
because
of
its
multi-protocol
support.
We
mentioned
Kafka
in
that
case,
but
where
socket
is
also
of
interest,
if
you
need
to
to
expose
some
data
to
to
the
outside
of
the
organization,
because
please
don't
provide
external
access
to
your
Kafka
broker.
A
Use
web
sockets
instead,
for
example,
and
as
micro
supports,
both
really
really
easy.
It
really
is
the
pain
testing.
The
different
Exposition,
but
microbes
can
also
help
with
the
schema
registry
integration,
as
it
is
able
to
to
connect
to
the
central
registry
for
automation,
of
the
the
publication
of
the
schema
updates,
and
it
can
also
connect
to
distributed
registry
to
to
test
that
the
records
read
from
different
Brokers
can
be
correctly
deserialized
using
a
corresponding
schema.
A
Okay,
so
you
can
see
there
is
a
an
async
API
spec
and
there
is
a
network
schema
that
is
attached
to
this.
Spec
here
is
the
schema,
so
microcs
can
publish
mocks
message
from
now.
They
are
disabled
and
you
will
see
there
that
as
soon
as
I
enable
the
publication
of
mock
message,
it
will
also
handle
the
synchronization
of
the
schema
registry
with
the
corresponding
schema.
So,
let's,
let's
check
with
the
property
Edition
I
can
now
enable
the
mocking
just
save
here.
A
So
it
should
start
mocking
sending
new
messages
and
as
soon
as
it
has
started,
mocking
if
everything-
okay,
yes,
it
has
a
synced
registry
with
new
schema
that
is
attached
to
the
Sync
API
specification.
So
it's
very
handy
to
ensure
the
propagation
of
your
schema
on
the
registry
and
as
microx
can
be
also
connected
to
your
git
repository.
As
soon
as
you
have
updated,
your
your
async
API
file
into
your
source
of
Truth
git
Repository.
A
You
can
be
sure
that
it
will
be
propagated
to
your
schema
registry
as
well,
and
here
we
are
finally
on
recipe
number
six
and
has
a
cherry
on
the
cake.
I
wanted
to
finish
with
this
one
talking
about
how
PDA
can
be
used
in
large
scale
to
provide
some
help
in
a
move
to
Cloud
transformation,
because
in
move
to
Cloud
there's,
usually
this
problem
of
data
gravity.
A
You
want
to
start
with
the
easy
part
moving
one
application
to
the
cloud.
The
data
is
still
on
premises
used
and
produced
by
so
many
hover
apps.
So,
as
said
before,
one
nice
thing
about
events
is
that
they
are
easy
to
replicate
and
you
can
decoupage
where
the
data
is
produced
from
where
it
is
consumed.
A
A
Then
you
can
move
adapted
consumer
B
on
the
cloud
before
retiring
it
from
the
on-premise
and
when,
finally,
you
are
ready
or
you
want
to
move
the
service
that
is
on
the
top,
you
just
have
to
to
move
it
and
to
revert
the
replication
okay.
Now
the
master
is
the
cloud
environment
and
events
are
replicated
to
the
on-premise
environments.
A
Interoperability
of
your
home
events
with
the
one
of
your
Cloud
platforms
you
chose,
and
luckily
async
API
is
also
compatible
with
Cloud
events
as
I
describe
it
extensively
in
a
previous
talk
last
year.
So
you
may
may
have
a
quick
search
on
YouTube
search
for
my
name
and
the
cloud
events
or
a
Sync
API,
and
you
will
probably
find
this
this
detailed
video
showing
how
they
can
be
combined
to
yes
to
to
provide
great
power
and
great
interoperability.
A
Finally,
where
to
use
the
microx
in
this
picture
and
I
would
say
everywhere,
of
course,
because
it
also
supports
the
different
bindings
and
it's
for
cloud-based
broker.
So
it
could
be
of
great
help
for
anticipating
and
preparing
migrations,
as
well
as
ensuring
there
is
no
regression
once
you,
you've
started
moving
components
or
revert
replications,
for
example.
A
From
purely
tactical
to
more
strategic
approaches
are
said
in
the
introduction.
I
chose
today
to
have
a
very
Progressive
approach,
but
this
is
not
necessarily
a
path.
This
was
easier
to
have
this
Progressive
approach
to
to
introduce
concept
one
by
one,
but
you
can
really
start
from
the
right
and
then
also
consider
recipes
on
the
left
starts
having
a
global
approach
and
then
a
local
optimization
approach.
A
How
going
the
other
way?
It's
really
up
to
you
to
let's
say
to
be
your
home
menu,
depending
on
your
on
your
scope
of
action,
depending
on
the
maturity
of
your
organization
and
and
a
lot
of
event,
Criterion
that
that
matters
for
you
just
finer
words
of
microbes.
We
are
open.
We
welcome
everyone
to
come
to
share
ideas
and
to
contribute.
The
project
is
purely
community
and
user
driven.
A
So
this
last
month
we
implemented
a
lot
of
stuff
regarding
users
requests
regarding
the
supports
of
new
broker
the
supports
of
new
approaches
of
test
time
testing
approaches.
So
it's
really
up
to
you
to
to
come
and
join
the
the
community,
try
it
and
give
us
feedback-
and
this
is
final
words-
many
thanks
for
for
attending
this
session.