►
Description
AsyncAPI Conference 2021 - Day 2
17th November 2021
During this session Rolando and Leonardo will explain how can you apply AsyncAPI for your projects from the point of view of the API-First approach. The API-first approach is a key part of the API Design and Development life-cycle, but when it comes to scenarios where an Event Driven Architecture gets introduced, and we do not have traditional REST API interactions, is difficult to apply it. It is difficult to mock it and get the benefits of the API First approach. We normally just describe the interactions and the events that will occur, and mention the type of technology that it will be used, but there is no spec to describe it. Part of the success for the API-first approach is to describe and share the capabilities of the API and actually test it. But when it comes to events, how do you do that? How do you spec them? There is where AsyncAPI comes to play. And there is where you can get the value of the API FIrst Approach when your architecture is based on events. Rolando & Leonardo will share their real life experiences on Event Driven Architectures and how you can apply AyncAPI into them.
A
A
A
A
We
are
both
part
of
sps
solutions,
as
I
already
mentioned.
It's
a
consulting
firm.
We
are
focused
on
api
development
and
design
and
other
things
using
different
technologies
such
as
mulesoft
oracle
and
some
others,
and
if
you
want
to
contact
us
in
the
future,
because
you
like
this
session
or
you
have
any
questions
around
it,
these
are
the
right
channels
where
you
can
find
us
either
linkedin,
email
or
twitter
all
right.
So
this
is
a
brief
summary
about
my
career.
A
I
studied
in
lycos.com
back
in
2000.
You
can
remember
like
us
as
one
of
the
first
search
engine
search
engines
in
the
web,
then
I
joined
hewlett,
packard
back
in
2001
and
actually
in
hewlett-packard.
I
started
my
career
in
terms
of
integration
technologies
and
then
I
moved
to
oracle
in
2002
and
continued
with
that
integration,
technologies
and
and
soa,
and
all
those
things
back
in
in
the
2000s
and
then
at
the
end
of
the
2000
2009
2010.
A
I
started
my
my
own
company
sps
and
we
are
focused
mainly
in
integration
platforms
and
api
technologies
and
modern
architectures
in
general,
and
I
like,
as
my
hobbies
to
to
collect
old-fashioned
video
games
and
also,
I
run
a
brick
and
mortar
store
here
in
mexico
city.
It
is
a
pop
store.
We
sell
vinyl
toys
so
so
pretty
much.
That's
that's
myself!
So
leo.
B
Yeah,
thank
you
roy.
So
thank
you
for
for
being
here
this
session.
So
some
of
my
technical
background,
I
started
programming
java
back
in
2003,
I
used
the
you
know,
javascripts,
hibernate
and
and
so
on.
I
also
designed
some
stuff
using
uml
and
then
I
jumped
into
the
integration
world.
I
moved
into
integration,
architectures
and
some
back-end
stuff
web
services
and
finally
apis.
B
I
use
the
soap,
of
course,
now
rest
services
and
different
technologies,
such
as
oracle,
soy
suite
now
more
modern
technologies
such
as
docker
containers,
mulesoft,
api,
led
connectivity,
application
networks
and,
and
so
on,
I'm
an
enthusiastic
of
a
craft
of
craft
beer.
So
I
I
opened
my
own
bottle
shop
and
I'm
running
right
now
a
tasting
room
here
in
mexico
city.
So
if
you
are
around
the
city,
just
contact
me-
and
you
are
very
welcome
to
this
place-.
A
Good
so,
let's
get
started.
This
is
our
first
slide
and
we
want
to
start
with
it,
and
we've
been
starting
our
presentation
in
the
past
years
with
this
very
same
slide,
because
we
highlight
the
relevance
of
the
apis
in
the
digital
transformation
era,
and
we
say
that
the
digital
transformation
turned
us
speechless
and
we
are
thanking
the
apis
for
that.
A
And
we
are
saying
that
because,
if
you
think
about
different
activities
that
you
used
to
do
in
the
past-
and
you
compare
it
on
how
you
are
doing
it
now,
for
example,
a
web
check-in
for
a
hotel
or
an
airline
or
asking
for
a
uber
ride.
For
example,
you
you
will
find
a
lot
of
differences
and
you
can
do
all
those
activities
without
the
need
of
talking
with
someone
without
having
a
conversation
with
a
person.
A
That's
what
I'm
trying
to
say
because
of
the
way
those
applications
are
built
and
part
of
the
success
of
those
applications
is
because
they
are
somehow
driven
by
apis
you
as
a
user.
You
are
not
aware
that
you
are
calling
on
a
specific
api
every
time
that
you
do
a
check-in
to
your
hotel
or
for
an
airline,
but
at
the
end
of
the
day
or
behind
the
scenes.
A
Most
of
those
applications
are
interacting
with
api,
so
I
think
we
are
surrounded
by
apis
and
those
apis
are
enabling
us
to
do
activities
in
such
a
way
that
we,
we
probably
don't
need
to
talk
with
someone,
and
I
am
not
highlighting
that
that
we
don't
have
conversation
with
persons,
but
what
I'm
not
highlighting
is
the
impact
that
those
apis
have.
So
so
that's
the
point.
B
Yeah
and
the
question
that
comes
to
my
mind
is
if
you
we
are
living
in
a
happy
world
in
a
world
that
are
surrounded
by
apis,
and
if
we
take
a
look
on
some
websites.
These
are
some
cool
websites.
The
first
one
is
the
programmable
web.
It's
an
api
directory
here
you
can
search
over
the
24
000
apis
public
apis
and
much
more
some
news
about
the
apis,
and
so
on
this
morning
I
received
this
report
from
postman
about
the
apis,
and-
and
I
it's
it's
funny,
because
we
are
going
to
talk
about
the
apis.
B
B
B
The
companies
are
investing
more
money
on
the
development
of
the
apis,
and
the
quality
is
the
top
priority
for
the
when
we
are
talking
about
when
we
are
thinking
of
of
apis
and
more
companies
are
embracing
the
api
first
philosophy,
which
is
a
thing
that
we
are
going
to
to
cover
in
this
session.
It's
a
cool
thing,
and
the
second
thing
is
that
being
api
first
pays
off,
so
it's
worth
it.
So
we
need
to
spend
more
time,
designing,
apis
and
and
and
thinking
in
aps.
What
do
you
think
rolando.
A
Yeah,
it's
it's
very
good
information.
What
you
just
share
leo
and
also
we
can
highlight
that
the
relevance
of
the
apis
in
the
world
in
the
economy
itself,
with
some
very
specific
examples.
So
if
you
think
about
top
10
fintechs
in
the
us,
for
example,
this
is
a
report
from
forbes
and
I
would
like
to
highlight
two
things.
The
first
one
is
that,
for
example,
these
fintechs
companies
are
api,
driven
companies
so
most
of
the
times
they
are
using
apis
from
third
parties,
and
they
also
offers
apis
for
for
their
for
their
customers.
A
So
so
they
are
api
driven
companies
and
if
you
see
that's,
the
first
thing
that
I
would
like
to
highlight
is
the
value
of
those
companies
strive,
for
example,
is
a
95
billion
us
dollars
company?
So
that's
that's
a
lot
of
money.
That's
a
lot
of
value,
and
the
other
thing
that
I
would
like
to
highlight
is
that
they
are
run.
They
are
run
by
very
young
people.
So
you
take
a
look
to
the
ceos
of
those
companies.
A
B
And
what
about
apis
when
we
think
in
an
event
ribbon
architecture?
So
probably
you
wonder
if
you
can
describe
apis
that
support
this
type
of
architecture,
and
the
answer
is
yes,
there
is
a
thing
called
async
api
where
a
that
you
can
use
to
describe
this
type
of
apis
over
this
type
of
architecture.
So
we
are
going
to
cover
this
this,
this
syntax
or
this
specification
more
in
detail.
But,
yes,
the
answer
is
yes,
you
can
define
apis,
even
if
you
are
using
this
type
of
architectures.
A
So
you
may
be
wondering
that,
obviously
we
are
here
in
the
async
api
conference,
and
that
is
the
answer
for
that,
but
previously
before
async
api,
the
question
is:
can
we
describe
it
because
we
normally
think
about
apis
with
normal
http
synchronous
calls
etc,
and
it
is
pretty
easy
to
identify.
How
can
we
describe
them,
but
what
about
events?
A
Okay,
it
can
be
challenging
definitely,
and
the
challenge
is
because
we
have
a
diversity
of
messaging
systems,
so
it
is
very
common
to
have
kafka
or
rabid,
mq,
jms,
aws,
sqs
and
so
on
in
order
to
communicate
our
systems
in
order
to
produce
events.
So
that's
the
challenge
that
we
have
a
very
large
diversity
of
messaging
systems.
B
For
example,
if
we
take
a
look
at
this
picture,
we
can
see
that
we
are
using
for
this
architecture,
a
kafka
broker,
and
we
start
thinking
how
to
connect
with
that
kafka
broker,
how
to
send
a
message
to
that
broker.
How
to
retrieve
a
message
from
that
broker.
What
is
the
bootstrap?
We
need
to
use?
What
about
the
transactions?
Can
we
use
a
single
transaction?
Should
we
use
a
single
transaction
or
not
that
that
are
the
first
things
that
comes
to
our
minds
in
this
type
of
architectures?
A
Yes,
and
as
you
mentioned
leo,
we
will
normally
ask
for
the
sdks.
That
will
be
our
first
speech
if
you
will
about
having
these
type
of
diagrams,
and
we
are.
Let's
imagine
that
we
are
a
group
of
developers
and
we
need
to
solve
the
situation
that
you
just
described
in
the
previous
image.
The
first
question,
maybe
will
be
okay,
so
I
am
going
to
use
a
consumer
which
is
based
on
java.
So
what
is
the?
What
is
my
sdk
in
order
to
consume
that
message,
so
we.
A
Into
that
direction
before
thinking
in
the
specification
itself,
so
what
we
are
trying
to
do
in
this
session
is
to
take
you
to
this
scenario,
about
the
relevance
of
having
that
specification
and
the
relevance
of
writing
that
specification
before
anything.
So
as
with
any
other
architecture,
like
I
mean
technology
or
any
other
type
of
architecture,
we
need
a
way
to
design
okay,
what
we
are
going
to
build,
so
we
need
to
represent
what
we
are
going
to
build
and
it
is
oh,
it
is
better
to
have
it
first.
A
B
So
the
here
the
the
idea
is
that
we
need
to
create
the
specification
first,
which
is
the
api
first
approach
and
then
code,
something
so.
First
of
all,
we
need
to
create
a
specification
that
will
be
solid
and
that
will
remain
useful
for
the
developers
over
time,
so
not
only
today
or
tomorrow
or
in
the
next
month,
but
over
the
time.
So
so
that
is
when
the
api
first
approach
comes
to
the
rescue.
And
what
exactly
is
this
thing?
B
A
Yeah
so
before
getting
into
those
details
about
how
to
connect
to
the
messaging
system,
it
is
better
to
describe
those
events
that
are
going
to
be
happening
within
your
architecture,
so
just
think
about
it
for
a
minute.
So
if
you
first
describe
that
something
is
going
to
create
an
event
now,
whoever
is
going
to
produce
that
event
is
going
to
know
the
event.
That
is
how
the
event
that
it
is
described
and
and
the
persons
or
the
the
application
that
needs
to
consume
that
event.
The
message
of
that
event.
A
B
A
Yes,
this
is
the
value
we
try
to
summarize
some
of
the
values
for
for
doing
that
mix
of
of
visions.
The
the
api
first
approach
and
the
async
api
specification
and
modern
architectures
and
motor
development
are
driven
by
events,
so
it
is
pretty
normal
to
have
events
in
our
application.
So
if
you
don't
use
async
api
to
describe
your
specification,
then
you
are
going
to
struggle
a
little
bit
to
to
share
what
your
component
is
going
to
publish
and
then
to
share
what
others
needs
to
use
in
order
to
consume
those
events.
A
So
the
the
value
for
that
is
what
I'm,
what
we
are
trying
to
to
highlight
here,
and
it
doesn't
matter
if
these
events
or
they
are
not
based
on
events.
The
api
itself
has
has
this
essence
of
describing
what
you
are
going
to
build,
so
it
doesn't
matter.
What
I'm
trying
to
say
is
that
you
can
keep
doing
what
you
are
already
used
to
do
in
order
to
describe
your
normal
rest
apis,
but
now
think
about
it
with
the
event-driven
architecture.
A
B
B
What
are
the
operations?
Are
we
going
to
publish
messages,
or
are
we
going
to
subscribe
an
application
to
a
to
a
queue
or
to
a
topic
and
so
on?
What
are
the
the
structures
of
the
messages
that
we
are
going
to
interchange
in
this
this
architecture?
So
all
those
things
are
available
in
async
api
and
you
can
describe
different
servers,
different
protocols,
different
channels,
different
type
of
operations
and
different
message,
structure
structures.
All
those
things
are
available
in
the
async
api
specification
to
create
our
particular
apis.
A
In
order
to
to
get
to
know
how
well,
the
business
is
running
in
the
different
branches
of
this
pawn
shop.
So,
as
you
can
see,
there
is,
there
is
an
event
that
needs
to
get
produced
in
within
that
transaction,
and
there
are
other
applications
that
are
interested
on
that
event.
So
it
seems
to
be
a
very
or
a
very
straightforward
scenario
for
us
right,
the
infrastructure
or
from
the
infrastructure
point
of
view.
A
We
have
rabid
mq
for
the
message
broker,
the
the
pound
application
or
the
pawnshop,
sorry,
the
pawnshop
application
or
the
pos
it
is
based.
In
java,
we
have
a
risk
management
solution
which
is
based
in
oracle
vpn
suite.
We
also
have
the
scoring
system,
which
is
a
java
based
system.
Accountingist.Net
crm
is
salesfor
and
the
real-time
dashboard
is
based
on
react
and
with
a
node.js
backend.
So
we
have
a
diversity
of
technologies.
B
Yeah
yeah
in
this
in
this
example
in
this
real
life
examples
we
need
to
describe,
or
we
need
to
identify
and
describe
some
elements
for
our
apis.
So
these
are
the
elements
that
we
already
identified
for
that
real
life
examples
for,
for
example,
we
have
one
event
to
get
described,
the
good
which
was
accepted
but
the
pound
shop,
and
then
we
need
to
produce
a
message
who
is
going
to
produce
that
message?
B
Well,
the
the
pos
application
will
produce
a
message
once
the
good
is
accepted
to
the
a
particular
channel
that
will
make
available
that
information
for
the
interested
system.
So
we
already
identified
these
elements,
we
need.
What
do
we
need
to
to
interchange,
which
is
the
good
or
the
information
about
the
good
who
is
going
to
produce
the
event
and
who
is
going
to
consume
the
event?
So
in
this
case,
for
example,
the
application
interested
in
this
type
of
event
are
the
the
the
crm,
the
risk
management
systems,
the
scoring
systems
and
so
on.
B
All
the
systems
we
mentioned
before
are
the
applications
that
are
interested
in
this
type
of
application.
So,
let's
identify
some
differences
from
the
point
of
view
of
using
an
idea,
eda
or
not
using
an
eda
in
this
case.
In
this
case,
what
happened
if
we
don't
use
an
architecture
of
this
type,
a
rolando.
A
Yes,
let's
imagine
that
we
don't
use
cda
for
this,
because
it
is
very
clear:
the
pos
is
going
to
create
an
event
and
then
we
have
multiple
applications
interested
on
that
event,
because
they
need
to
process
that
information
right.
But
just
let's
imagine
that
we
don't
produce
event
and
we
don't
use
a
message
broker
for
that
and
the
pos
directly
needs
to
deliver
the
message
to
those
different
systems.
A
So
probably
the
owners
of
those
different
systems
are
going
to
describe
different
apis,
so
the
pos
can
connect
to
them
right.
So,
at
least
in
this
case
we
have
five
different
apis
that
we
need
to
describe
and
we
need
to
to
develop,
which
is
not
bad,
we're
just
talking
about
five
different
apis
and
probably
a
very
small
group
of
operations
for
this
very
use
case.
Yes,
but
let's
imagine
that
you
need
to
add
an
additional
system.
A
B
For
example,
every
time
you
change
your
specification
here
on
the
left
of
the
of
the
screen,
the
a
playground
will
auto
generate
the
documentation
for
that
api.
So
you,
you
will
see,
reflected
the
documentation
updated
in
the
right
side
of
the
screen.
So
that
is
a
cool
thing.
It's
a
visual
way
to
to
to
see
what
are
the
parts
of
your
api
specifications.
So
when
you
open
this
thing,
you
async
api
playground
will
provide
you
with
a
sample
api
which
in
this
case
is
the
streetlights
api,
but
we
already
write
our
api
using
this
syntax.
B
This
is
based
on
jamal.
So
it's
easy
to
read.
It's
easy
to
write
is
easy
to
start
describing
your
api.
For
example,
in
the
first
section
we
have
the
information,
the
general
information
about
our
api.
This
is
a
phone
shop
service.
This
is
the
version
1.0.0,
and
we
have
a
description
here
about
what
the
api
is
going
to
to
to
deliver
to
the
developers
that
are
going
to
use
this
api.
Okay,
we
have
some
channels.
In
this
case
we
have
a
channel
called
goods
evaluated.
B
This
channel
is
to
use
you
are
going
to
use
this
challenge
when
you
need
to
interact
with
the
evaluated
goods,
as
we
mentioned
before.
In
the
real
case
scenario,
if
you
need
to
process
some
information
about
the
evaluated
goods,
you
are
going
to
use
the
subscribe
operation.
If
you
need
to
to
publish
or
to
produce
some
messages
about
goods
that
has
been
evaluated,
you
are
going
to
use
the
publish
operation.
All
that
documentation
is
reflected
here
in
the
right
side
of
the
screen.
B
In
this
case,
we
have
the
subscribe
operation
and
we
have
the
structure
of
the
message
that
we
are
going
to
interchange
or
that
we
are
going
to
push
to
to
to
that
channel.
Okay
in
the
documentation,
we
can
see
that
we
have
information
about
the
customer,
in
this
case
the
number
id
and
the
full
name.
We
have
information
about
the
the
branch,
the
branch
id,
the
name
and
the
city,
and
we
have
information
about
the
the
the
items
or
the
goods
that
this
is
is
going
to
be
evaluated.
B
In
this
case,
we
have
the
name
of
the
good
and
the
description
of
the.
And
finally,
we
have
the
total
amount
of
the
loan
that
we
that
represent
the
value
of
all
these
goods
that
are
received
that
the
pawnshop
received
in
the
pos.
So
we
can
describe
everything
here
and
we
will
see
the
documentation
here.
It's
a
fun
thing
to
start
playing
with
the
async
api
and
to
describe
this
type
of
architectures.
A
A
A
Using
the
very
same
api
and
incorporate
as
much
consumers
as
you
need,
if
you
change
the
message
for
some
reason,
then
all
the
systems
are
going
to
get
impacted,
but
probably
they
can
beforehand
know
that
those
changes
are
going
to
happen
because
of
the
description
in
the
api.
So
it
is,
it
has
a
lot
of
value,
and
hopefully
we
are
transmitting
this
message
for
you
and,
as
I
mentioned,
if
a
new
system
is
integrated,
then
the
specification
remains
valid.
Okay,
no
one
needs
to
make
any
type
of
change.
B
A
Yes,
thank
you
leo.
So,
if
you
have
any
questions,
we
can
answer
them.
If
you
want
to
contact
us,
we
already
share
with
you
our
direct
channels
to
either
linkedin
or
email.
So,
as
we
started
with
this
session,
we
are
very
happy
to
be
here,
we're
very
pleased
to
be
or
to
be
part
of
this
agenda
of
the
async
api
conference,
and-
and
thank
you,
thank
you
very
much.
Thank
you
guys.