►
From YouTube: Using the AsyncAPI Ecosystem for your Event-Driven Architecture - Hugo Guerrero, Red Hat
Description
AsyncAPI Conference 2022 - Day 2
4th November 2022
In the past, working with event-driven architecture (EDA) meant you had to struggle with information about endpoints and the type of event payloads available for consumers or required by producers. With AsyncAPI, we can easily describe how those servers, endpoints, and payloads compose our EDA. The AsyncAPI Initiative is not only in charge of the specification but has created open source projects to make it easier for developers to work with the specification documents. Besides the AsyncAPI team, other EDA providers have contributed projects to the ecosystem to power the usage of AscyncAPI at different levels. In this session, we will go from discovering events in current brokers to designing, testing, and mocking projects that help server implementations and consumer and producer generators. We will review the open source projects, generators, and other components of the expanded ecosystem related to EDA.
A
Hi,
hello,
everyone
and
welcome
to
this
session.
I
really
hope
that
you
are
enjoying
the
conference
so
far
and
that
you
can
stay
with
me
the
following
minutes.
So
we
can
go
over
this
interesting
topic.
This
session
is
from
Discovery
to
implementation,
using
the
async
API
ecosystem
in
the
following
minutes.
As
I
was
telling
you,
we
are
going
to
go
over
the
different
elements
of
an
Eda
that
can
be
helped
of
help
from
the
async
API
initiative,
with
their
tooling
and
with
their
ecosystem.
A
So
let's
get
started
okay.
First,
let's
do
some
introductions.
My
name
is
Hugo
I'm
part
of
the
developer,
advocacy
team
in
red
hat
and
I'm
specializing
apis
and
messaging
I
do
like
to
travel
I
like
travel
to
get
some
very
interesting
food
history
about
the
place
where
I'm
traveling
and
such
so
I
will
have
loved
to
be
able
to
join
audio
in
Barcelona,
but
well
I
hope.
Next
year
we
can
do
it.
I'm
a
Mexican
currently
based
in
Massachusetts
in
the
United
States,
and
here
is
some
information
about
my
Twitter
account.
A
Let's
talk
about
the
first
interesting
talk,
so
the
thing
we're
gonna
be
coming
today
is
Eda
or
even
driven
architecture,
and
the
interesting
thing
here
is
that
we
have
been
doing
Eva
for
a
very
long
long
time.
It's
now
on
Race
because
of
the
new
distributed
architecture
and
microservices
that
are
be
in
the
norm
in
the
cloud
computing,
but
we
have
been
doing
Eda
for
a
long
time.
A
So
since
the
beginning,
when
we
are,
we
were
just
working
with
with
the
mechanical
computers,
there
was
interruptions,
and
those
were
events
that
need
to
be
captured,
be
able
to
respond
up
on
that.
So
this
is
basically
the
the
core
Center
of
what
Eda
is,
and
we
can
see
this
in
this
diagram.
So
we
have
a
consumer
and
a
producer
each
one
of
those
needs
to
be
able
to
change
information
or
exchange
data
events,
messages
from
the
producer,
that
is,
you
know,
sending
the
information
as
well
as
the
consumer.
A
That
is
supposed
to
be
the
Target
that
we'll
be
receiving
the
the
information.
So
there's
one
of
the
challenges
that
we
have
with
the
traditional
ARS
apis
is
that
both
the
producer
and
the
consumer
or
the
client
and
the
server
need
to
be
online
at
the
same
time
and
being
able
to
then
communicate,
establish
a
connection
communicate
in
exchange
information.
A
However,
there's
some
limitations,
it's
like
okay,
what
happens
if
you
know
I
don't
have
connectivity
or
if
I
just
need
to
be
able
to
send
information
later
and
so
on,
and
this
is
where
the
pattern
of
storm
forward
becomes
very
useful
and
implement
this
pattern
of
story
forward.
We
need
this
middle
piece
of
the
architecture
that
allows
us
to
delegate
the
delivery
of
the
message
or
the
event
from
the
producer
to
consume.
A
So
basically,
we
have
a
singles
communication
between
the
publisher
and
the
message
broker
where
they
send
the
information,
and
then
the
message
probably
takes
ownership
of
the
message
and
then
it's
in
charge
of
delivering
that
event,
that
message
to
the
different
consumers
that
will
be
listening
or
they
will
be
interested
in
receiving
those
messages,
but
there's
a
lot
of
different
type
of
consumption
patterns
for
the
messages.
When
you
have
you
know,
bands
that
can
be
discarded
events
that
needs
to
be
delivered
to
a
specific
consumer
events
that
need
to
be.
A
That
needs
to
be
able
to
stay
for
a
longer
time
case
that
the
consumer
wants
to
replay
them,
wants
to
reread
them
or
receive
those
and
and
such
but
the
the
basics.
The
basic
is
still
there.
We
have
this
middle
element
in
the
architecture
that
it's
a
broker
or
the
bus
that
takes
ownership
of
managing
and
delivering
those
messages
to
you,
one
consumer,
multiple
consumers
and
and
such
and
this
interesting
this
piece.
It's
also
interesting
because
there's
a
different
type
of
pieces
that
implement
this
pattern.
A
So
if
you
have
been
doing
Mainframe,
you
have
been
doing
other
type
of
or
architecture.
You
certainly
have
been
facing
the
concept
of
cues
and
the
concept
of
topics
available
in
all
these
programs
right
from
Kafka.
That's
the
the
the
honor
topic
or
playable
events,
IBM
and
Q
has
been
forever
active
into
rapid
Solace.
Has
a
lot
of
work
been
doing
on
Pub
sub,
as
well
as
Google?
Not
ready.
Originally
was
more
on
the
cache
side,
it's
also
Implement
events
and
and
so
on.
A
So
on
you,
you
can't
find
a
lot
of
different
software
that
it's
implementing
this
concept
of
the
broker
or
the
boss,
and
this
is
important
because
there's
different
type
of
protocols
there's
also
different
type
of
implementations
on
how
to
handle
this
pattern,
and
this
makes
it
a
little
bit
more
complicated
than
just
you
know,
having
an
HTTP
connection,
but
let's
go
a
little
bit
more
on
down
with
the
history.
So
in
the
beginning,
as
I
was
saying,
we're
doing
Eda
for
a
long
time.
A
Those
accused
topics
was,
you
know
something
easy
in
there,
but
then,
in
the
other
side
and
in
the
Next
Room,
you
know
people
were
doing
rest
apis.
They
start
to
be
able
to
use
them
externally
and
to
show
with
partners
and
API
economy
started,
and
we
have
learned
that
with
them
being
able
to
expose
our
apis
publicly
and
be
able
to
socialize
them
to
be
able
to
get
information
and
feedback
around
it.
A
A
You
know
in
the
broader
scope,
so
that's
why
we
started
to
work
on
something
like
the
async
API
initiative
that
we'll
be
trying
to
address
the
ecosystem
around
apis,
on
on
and
and
on
Eda
and
even
driven,
and
this
is
how
the
initiative
started
with
the
specification.
So
the
specification
started
to
basically
be
a
way
to
implement
something
similar
to
the
open,
API
specification,
but
for
even
driven
architecture.
So
you,
if
you're
coming
from
from
race
AP
award,
you
will
certainly
see
that
the
specification
is
very
similar.
A
It's
sharing
a
lot
of
information
regarding
service
servers,
security,
pads
consumption
and
payload,
for
example.
It's
very
clear
that
the
the
payload
is
one
of
the
interesting
and
most
important
things
about
about
our
API,
so
the
initiatives
started
with
the
specification
and
how
to
be
able
to
implement
that
and
create
that.
A
But
you
know
when
working
with
things
like
a
specification
and
schemas
things
like
that,
you
certainly
need
a
way
to
be
able
to
validate
them
to
work
around
them,
and
this
is
where
the
the
initiative
start
to
switch
just
not
just
from
the
specification
as
a
document,
but
also
around
the
tooling.
That
will
help
us
to
manage,
interact
and
work
with
that
specification.
So
the
initiative
went
broader
and
start
to
work
on
this
tooling
from
editor
parses
generators
and
things
like
that.
A
So
the
idea
is
that
all
this
ecosystem
and
all
these
toolings,
within
the
specification
initiative,
or
from
other
vendors
or
from
other
open
source
projects
cambrother
and
can
help
you
to
deal
with
your
apis,
and
this
is
why
we
have
the
API
fly
cycle.
You
know
that
when
you
are
working
with
specification,
where
you're
working
with
apis,
we
have
this.
This
infinitive
Loop
that
tell
us
that
we
need
to
go
from
from
a
a
certain,
a
Continuum
of
delivering
our
apis
being
able
to
consume
them
and
such
so.
A
It's
basically
a
life
cycle,
a
process
for
that
in
the
rest,
API
it's
a
little
bit
more
more
mature.
The
Eda
side
is
perhaps
a
little
bit
more
compact
within
what
we
can
do
right
now
with
the
current
state
of
the
art.
So
we
still
are
able
to
do
design
of
your
your
API.
You
can
still
do
things
like
mocking
or
testing
of
your
API.
A
You
can
then
Implement
the
server
side
for
a
certain
kind
of
of
bindings
or
certain
kind
of
of
elements
of
the
broker
that
allows
you
to
you
know,
Implement
how
you're
going
to
be
handling
the
interaction
with
your
consumers
and
producers,
but
also
there's
for
the
part
of
the
socialization
of
your
API.
So
you
how
you
do
the
discovery,
how
you
do
socialization
of
your
apis?
A
How
do
you
implement
a
developer
portal
and
such
in
a
way
that
then
you
can
enable
other
developers
and
other
applications
to
be
able
to
consume
during
so
we
will
be
able
to
then
take
these
different
stages
and
phases
of
the
API
apply
circle
from
design
mob
testing
limitation
all
the
way
to
to
the
consumption
of
your
API.
So
let's
start
with
some
of
the
examples.
So
if
you
are
doing
the
design,
there
are
different
ways
to
get
started
right.
A
So
when
we're
talking
about
the
design
and
contract
first
approach,
we
said:
okay,
we
will
first
create
the
contract
Define.
What
is
the
spec?
The
expected
workload,
the
expected
point,
but
don't
want
single
line
of
code-
needs
to
be
written
at
this
time
and
for
that
there
are
different
tooling,
for
that
can
help
us
with
that.
So
there's
things
like
the
Sync
API
Studio,
this
part
of
the
initiative.
There
are
other
open
source
Solutions,
like
epicurio,
a
studio
that
also
have
the
opportunity
to
be
able
to
design
your
API
following
a
form
based
approach.
A
Stronger
Hub
also
has
support
for
a
Sync
API,
and
this
is
when
you're
doing
like
I
was
saying
the
design
first
approach,
but
in
the
case
that
you
are
already
trying
to
grab
your
event
driven
API
from
a
chronic
system.
Instance,
for
example,
you
already
have
a
Kafka
broker
that
is
receiving
and
sending
events.
Then
you
can
use
things
like
the
Solace,
even
agent,
that
can
be.
It
can
be
used
to
get
a
discovery
of
the
different
topics
that
are
available
on
your
Kafka
cluster.
A
Also,
the
kind
of
events
that
are
flowing
through
those
topics
and
then
being
able
to
Auto
generate
an
a
Sync
API
document
from
that
information,
and
then
so
you
can
get
the
definition
of
that.
So
there's
other
different
type
of
tools.
This
is
just
an
example.
You
can
certainly
explore
the
importancy
how
they
can
be
if
you're
doing
either
design
first
approach
or
code
first
approach,
where
you
just
want
some
annotations
on
your
code
and
being
able
to
generate
the
the
the
specification
as
I
was
saying.
A
If
you're
starting
from
code,
you
can
go
with
the
go
Java
Sync
API,
because
it
example
you
can
just
you
know,
add
annotations
to
your
code
and
then
the
plugin
can
read
those
annotations
and
then
be
able
to
autogen
automatically
generate
the
specifications
you
can
expose
that
spring
wall
even
preach.
Atlas
also
allows
you
to
do
the
same
for
AWS,
even
Bridge.
So
there
are,
there
are
more
of
those
that
allows
you
to
get
an
existing
code
and
implementation
and
then
being
able
to
and
generate
the
specification
for
for
you.
A
If
we
are
talking
about
mocking
and
testing
well,
there
are
other
different
tools
that
also
benefit
from
the
async
API
specification.
When
you
define
examples
in
in
the
specification
and
then
you
are
able
to
mock
this,
create
these
mock
servers
that
will
be
automatically
generating
payloads.
So
you
can
try
your
consumers
and
be
able
to
receive
that
information.
So
you
have
things
like
macros
and
also
you
have
virtual
land,
multi-a
API
converter
Spectra
also
helps
you
to
do
testing
Microsoft,
so
do
a
little
bit
of
testing
based
on
the
contract.
A
So
you
can
check
if
the
a
specific
if
the
generated
event
or
from
your
producer
is
really
in
sync
or
in
line
with
the
with
the
expected
schema
and
specification
from
your
from
your
async
API.
So
there's
a
way
to
then
be
able
to
parallelize
being
able
to
mark
your
apis.
While
your
teams
working
on
the
implementation,
your
consumers
are
going
to
start
to
work
with
those
and
see
how
they're
receiving
events
through
all
the
different
bindings
and
and
such
for
testing.
A
You
can
also
do
on
the
not
only
testing
of
the
action
and
the
actual
topic,
but
also
your
topic
or
queue
or
or
input.
Also,
you
can
do
some
kind
of
testing
of
the
of
the
async
API
like
doing
some
Landing.
So
spectral
is
one
of
the
those
I'll
help
you
to
validate
that
your
Sync
API
generated
was
it
is
it
has
been
tested
along
some
certain
rules
and
validate
that
everything
needs
it's
according
to
what
is
expected
from
from
that
async
API.
A
So
when
we
talk
about
socialization,
there's
different
ways
to
share
your
API,
so
you
can
go
to
public
directories
like
a
apis
guru
or
API
tracker
there,
or
you
can
submit
your
information
and
you
can
see
what
available
airports
or
specifications
are
already
available.
These
are
not,
as
you
know,
as
as
common
or
popular
or
popular
as
some
other
rest
API
directories,
but
well.
This
is
a
way
to
the
start.
This
is
only
if
you
want
to
go
public
and
you
really
want
to
expose
or
consume.
A
You
know
somebody
else's
documents,
but
also
you
can
go
internally
and
if
you
want
to
just
socialize
and
share
your
apis
with
our
members
on
within
the
same
organization,
you
can
deploy
on-premise
tools
like
the
application
registry
or
your
own
developer
portal,
where
you
can
then
publish
the
the
Sync
API
specification
and
then
being
able
to
use
some
tools
to
automatically
download
and
generate
you
know,
stops
or
or
source
code
from
from
those
apis.
So
you
can
also
do
internal
or
external
type
of
socialization
of
your
API.
A
Now,
let's
talk
about
consuming-
and
this
is
perhaps
where
you
will
be
spending
most
of
the
time
or
where
you
have
been.
You
know
seeing
a
lot
when
talking
about
the
ecosystem,
for
a
Sync
API
most
of
the
times.
It
is
because
you
already
are
being
provided
by
us
with
an
async
API
specification
document,
and
then
you
want
to
consume,
or
you
want
to
connect
to
the
service
and
being
able
to
start
interacting
with
that,
and
so
that's
why
most
of
the
times
you
will
be
hearing
about
this.
A
A
So
the
first
one
is
part
of
the
async
API
token
is
the
generator
there's
an
option
to
be
able
to
run
a
an
application
that
will
take
the
specification
analyze,
the
different
content
that
is
available
on
the
notification
and
then
generate
to
play
the
stop
or
some
basically
sample
code
that
allows
you
to
get
started
with
your
business
logic.
So,
basically,
as
the
library
is
required
for
your
application,
it
starts
the
code
set
up
the
connection.
A
Perhaps
the
configuration
for
for
the
connectors
that
you
will
be
using,
depending
on
the
language,
depending
on
the
different
libraries
that
you
are
using,
and
this
is
where
there's
a
lot
of
of
work
being
been
happening.
Obviously,
there's
other
vendors
that
are
also
implementing
something
similar
to
generate
code
from
different
applications,
and
some
of
them
are,
for
example,
for
a
specific
Solutions
like
node
red
plugin.
A
That
allows
you
to
take
a
specification
and
being
able
to
start
crafting
on
a
more
visual
visual
way,
so
multi-api
generator
there's
another
option
that
allows
you
to
generate
your
your
code
and,
if
you're,
going
to
develop
for
a
specific
type
of
languages
like
C,
plus
plus,
there's
also
generators
that
allows
you
to
do
that.
So
there's
you
will
find
a
lot
of
information.
A
Okay,
so
we
went
over
the
different
concepts
of
the
of
the
ecosystem
of
the
API
life
cycle
of
what
is
an
ETA.
The
important
thing
here
this
is
what
I
really
want
you
to
to
have
as
a
takeaway
is
the
even
though
we
think
about
sync
kpi,
as
just
the
specification
or
just
the
contract,
or
just
the
definition
of
of
how
we
are
going
to
be
and
documenting
our
or
even
ribbon
apis.
It
is
more
than
that.
A
A
A
Thank
you
very
much.
For
this
time.
I
know
we
covered
a
lot
of
ground,
there's
a
lot
of
things
from
the
definition
of
Eda
all
the
way
to
the
API
lifecycle,
the
different
steps
and
different
tools.
So
I
invite
you
to
go
again
visit
the
Sync
API
site
go
under
different
tools,
so
you
will
be
able
to
check.
What's
going
on,
it's
always
been
updated.
If
not
here's
again
my
Twitter
account.
A
You
can
certainly
follow
us,
follow
up
us
and
be
able
to
see
what
we
are
publishing,
what
we
are
sharing
or
just
you
know
you
can
with
track
the
conversation
over
there
so
again.
Thank
you
very
much.
I
really
appreciate
the
time
you
spend
with
me
and
I
hope
you
can
enjoy.
I
continue
enjoying
the
the
rest
of
the
conference
and
if
everything
was
good,
just
stay
safe
and
see
you
next
time
again.
Thank
you.