►
From YouTube: AsyncAPI and Event API Products; a Match Made in Heaven - Tamimi Ahmad & Jesse Menning, Solace
Description
AsyncAPI Conference 2022 - Day 2
4th November 2022
Event-driven architecture (EDA) is all around us, and we may interact with EDA-based systems daily without even knowing it. It is the architectural backbone of capital markets, many retail banks, e-commerce platforms, and airlines. With hundreds, and even thousands, of applications in an EDA system, there can be a lot of challenges – including defining applications in a standardized specification and the distribution of asynchronous APIs to other stakeholders. The first challenge is tackled by the AsyncAPI spec and the second by event API products. In this talk, Developer Advocate Tamimi and CTO Group Architect Jesse Menning will cover the fundamentals of event API products and the advantages of having a standardized way to share APIs with other users. The way asynchronous event APIs are managed in an event portal, defined in AsyncAPI specs, and distributed via event API products will remind developers/architects of how synchronous REST APIs are typically managed in a developer portal, defined in OpenAPI specs, and distributed via API products.
A
A
You
that's
great,
that's
great
I'm
excited
for
today's
talk.
I
will
be
talking
about
async,
API
and
event.
Api
products,
as
the
title
of
the
our
talk
reflects
so
I
will
go
ahead
and
share
my
screen.
So
the
the
title
for
today's
talk
is
async
API
and
event.
Api
products
match
made
in
in
heaven.
Jesse
are
you?
Are
you
ready
to
start
talking
about
this
and
I'm,
throwing
some
questions
at
you?
A
A
B
A
A
So
in
my
previous
talk
earlier
today
at
the
async
API
conference,
I
presented
an
idea
about
event-driven
architecture
and
how
I
compared
Eda
to
a
bowl
of
salad
and
now
there's
so
many
different
ingredients
in
this
bowl
of
salad
and
I
compared
it
to
you
know
when
approaching
event
driven
architecture
in
general,
there's
so
many
different
components.
Some
of
these
components
you
gotta
design
your
event,
driven
architecture.
A
It's
not
just
about
choosing
an
event
broker
or
a
an
intermediary
layer
to
transfer
events,
there's
so
many
different
components,
and
in
and
in
today's
talk
we're
going
to
particularly
choose
two
ingredients
in
in
this
bowl
of
salad,
which
is
the
sharing
and
exposing
the
event
apis
before
passing
it
to
you,
Jesse,
if
you're
presented
by
a
bowl
of
salad,
what
is
your
favorite
ingredients
in
this
whole?
Salad?
Well,.
B
Actually,
I
was
thinking
exactly
that,
as
we
were
talking,
and
not
only
that,
but
like
what
elements
would
share
and
expose
event
apis
be
in
that
salad
and
I
would
have
to
say
that
sharing
and
exposing
apis
I
would
say
is
the
bacon
bits
and
the
cheddar
cheese
of
salads.
That's
the
stuff
that
people
actually
really
like.
It
can
only
exist
in
the
salad,
because
you
have
a
baseline
of
like
arugula
or
healthy
things.
You
know
that
would
be
your
sort
of
your
Discovery
life
cycle
management.
B
These
are
the
things
that
you
build
the
side
of
the
pond,
but
the
stuff
that
people
focus
on
and
really
really
enjoy,
of
course
are
the
things
that
are
not
quite
as
healthy
for
you,
the
bacon
and
the
cheddar.
So
I
think
the
the
point
being
here
being
sort
of
a
labored
metaphor.
But
you
do
all
this
stuff
in
the
quest
to
deliver
business
value
and
the
more
boring
arugula
lifts
things
up
and
allows
you
to
do
the
really
cool
stuff
with
with
sharing
and
exposing
event
apis
and
I.
A
It
is,
it's
definitely
yeah
the
the
fun
the
fun
aspect
of
things,
because
that
really
kind
of
brings
your
event-driven
architecture
to
a
whole
new
level.
You
know
so
like
it's
just
like
adding
and
that's
there's
like
a
lot
of
creativity
in
this,
because
you
know
the
bowl
of
salad
is
is
a
piece
of
art
for
sure
you
could
have
a
lot
of
creativity
added
to
it,
and
this
is
where
the
sharing
and
exposing
of
event
apis
come
in
place.
So,
let's,
let's
solve
more
more
more
into
into
this
Jesse,
why?
A
Why
do
we
need
to
expose
apis
as
products?
So
just
in
general,
let's,
let's
step
back
a
little
bit
from
the
Eda
world,
let's
step
back
from
Eventing
and
asynchronous
apis
and
in
general
When
anybody
is
dealing
with
apis.
Let's
take
rest
apis
as
an
examples.
Why
do
we
need
to
expose
apis
as
products.
B
Or
things
things
of
that
nature,
otherwise
you're
not
going
to
Garner
the
attention
that
you
really
need
to
fully
Implement
a
technical
project.
So
again
you
know
moving
back
to
the
sales
metaphor.
If
you
want
this
to
move
forward,
you
need
to
have
some
bacon
and
some
cheddar
available
to
for
people
to
really
grasp
into
so
I.
Think
that
exposing
apis
is
products
really
sort
of
appeals
to
both
technical
people
and
to
business
people
and
and
helps
move
apis
forward
as
a
as
a
project
within
a
particular
Enterprise.
A
You
know
so
that
is
that
is
where
bundling
from
my
perspective,
bundling
apis
and
the
functionalities
of
apis
and
exposing
them
as
products
for
other
stakeholders
to
consume.
This
is
where
the
power
of
API
products
just
just
come
in
in
general,
so
you
know
we
talked
about
the
importance
of
API
products
from
an
industry
perspective
and
kind
of
a
a
business
operation
side
side
of
things,
let's
self-injure
the
technicalities
of
API
products
and
that
definition
of
an
API
product
by
itself.
What
is
an
API
product,
I.
B
Think
he
really
hit
upon
it
using
the
word.
Bundle
I
think
is
really
really
appropriate
where
you
have
and
speak
of
the
devil
of
a
slide
based
on
this,
so
I
think
the
key
really
is
the
bundle,
and
you
have
individual
apis
that
you
have
laid
out
across
there
on
the
top
API
one
two
and
three,
and
you
can
think
of
those,
as
maybe
more
of
a
business
business
style
API
that
they
accomplish
very
specific
things
within
the
business
and
then,
along
the
left
hand
side
there.
B
You
have
API
products,
and
so
the
creation
of
API
product
really
is
the
bundling
the
mixing
and
matching
of
lower
level
apis
into
a
higher
level.
Product
I
think
we
talked
a
little
bit
about
abstraction.
The
API
product
creates
a
higher
level
abstraction
away
from
what's
actually
implementing
the
apis
into
this
product.
That
may
take
something
from.
B
And
something
from
over
there,
shove
them
into
something
that
makes
sense
in
the
sort
of
accumulation
that
doesn't
necessarily
reflect
the
underlying
infrastructure.
So
I
think
there's
a
power
in
having
things
be
a
little
bit
more
abstract
and
combining
apis
into
combinations
that
make
sense
to
particularly
external
Partners.
B
A
Interesting
yeah-
and
you
know
you-
you
hit
the
nail
right
in
the
head
and
you
met
when
you
mentioned
kind
of
trying
to
bridge
the
gap
between
the
business
requirements
and
the
underlying
technical
implementation.
At
the
end
of
the
day,
the
stakeholders
they
just
want
to
have
kind
of
like
a
business
requirement.
B
A
Nice,
the
idea
of
API
products
in
in
the
rest
world
has
been
around
for
a
while,
and
you
know
due
to
the
popularity
of
rest
apis.
Over
the
past
years
and
years,
there
has
been
a
lot
of
tooling
on
top
of
rest
apis.
That
makes
working
with
rest
apis,
pretty
easy,
pretty
nice
and
makes
kind
of
DD
the
collaboration
process
and
moving
forward
for
either
Innovation
and
creativity
around
rest
apis
much
much
easily
now
on.
Let's
say.
B
A
I
am
on
one
exactly
yeah,
that
is,
that
is
like
a
a
a
a
very
important
thing,
because
working
with
apis,
if
there
aren't
a
lot
of
tooling
around
it,
it
would
be
pretty
boring.
But
if
there's
kind
of
like
a
lot
of
tooling
around
it-
and
you
start
working
with
bundling
these
apis
and
building
applications
on
top
of
those
exposed,
apis
things
start
to
get
much
more
fun.
B
A
Right
so
moving
on
to
kind
of
you
know,
the
the
next
thing
I
wanted
to
talk
about
funding
your
apis
as
API
products
is
is
is
is
is
cool
and
everything,
but
it
is
also
very
important
to
associate
specifications
and
documentation
around
these
apis.
So
when
it
comes
to
rest
apis,
you
know
bundling
them
and
exposing
them
as
API
products.
What
is
the
technology
and
the
tooling
behind
rest
apis?
That
would
enable
kind
of
the
distribution
of
this
bundled
API
product.
B
A
B
You
don't
have
a
common,
more
global
standard
that
you
can
write
to
that
interchange,
especially
between
Enterprises,
really
Falls,
by
the
wayside,
so
I
think
open
API
and
the
emergence
of
truly.
What
I
think
is
a
global
standard
has
really
driven
the
ability
to
to
expose
apis
at
a
much
greater
level,
and
then
they
start
getting
these
great
gains
from
trade.
A
Right,
I
I
cannot
agree
with
you
more
on
that
on
that
front,
so
you
know:
we've
we've
talked
about
rest
apis,
API
products,
the
tooling
around
rest
apis
and
the
specification
that
drives
that
kind
of
the
distribution
and
the
collaboration
after
the
pressed
apis-
and
you
know,
standards
such
as
open,
open
API.
But
how
does
this
relate
to
the
Eda
World
Jesse?
So
what
do
you
think?
How
does
this
relate?
You
know
we
talk
a
lot
about
rest
apis.
How
can
we
relate
this
to
to
eda1.
B
Certainly
it
would
be
pretty
awesome
if
we
could
accomplish
the
same
thing
within
the
Eda
and
I
think
that
would
both
helps
Eda
grow
and
the
growth
of
Eda
helps
prevent
API
products
become
more
prominent,
so
sort
of
virtuous
circle,
so
I
think
async
API
can
can
lead
the
way
and
I
I
think
that
the
synchronous
World
gives
us
a
nice
little
template
as
to
how
to
accomplish
it
and
like
we
were
talking
about
open.
Api,
serves
a
huge
role
in
terms
of
the
API
economy.
B
A
A
Over
there,
so
let's
call
it
a
day
then,
but
this
is
like
I
I,
really
like
your
kind
of
comparison
between
you
know
rest
and
Eventing,
because
any
movement
forwards
in
the
event
driven
architecture
World
took
some
kind
of
inspiration
from
what
has
been
done
with
the
rest.
So
talking
about
specifications,
so
we
started
with
specifying
rest
apis
with
open,
API
specs.
A
This
gave
the
birth
of
async
API
specifications
to
specify
asynchronous
events
in
the
events,
API
and
the
event
driven
architecture,
and
then
with
the
bundling
and
exposing
and
sharing
and
collaboration
aspects
of
rest
apis.
There
was
API
products,
and
now
we
kind
of
took
inspiration
from
the
API
products
and
created
what
we
called
an
event.
Api
products
and
that's
kind
of
the
parallel
between
you
know,
what's
happening
in
the
rest.
A
B
Sort
of
I'm
an
architect
I
do
a
lot
of
stuff
on
PowerPoint
I.
Do
a
lot
of
talk
in
the
conferences
you
are
down
in
the
trenches,
thinking
about
doing
stuff,
doing
real
stuff
type
behind
computers.
Programming,
so
take
me
through
you
know,
I
I
think
I
have
a
pretty
good
idea
about
a
high
level.
What
these
these
use
cases
are,
but,
what's
give
me,
give
me
the
real
the
real
deal.
How
would
you
do
this
as
a
as
a
devrel
guy
who
actually
does
stuff
for
a
living.
A
Well,
put
your
seatbelt
on
and
hop
on
this
Journey
that
I'm
going
to
take
you
on
how
we
can
take
things
from
PowerPoint
slides
to
put
it
in
a
real
world
use
cases
and
I
really
want
to
cover
a
particular
real
world
use
case
where
rest
apis
could
really
interact
hand
in
hand
with
event
driven
apis.
So
let's
assume
that
you
have
a
kind
of
this
this
use
case
and
you
are
an
e-commerce
platform.
You
have
customers,
interacting
with
your
order
management
system
by
arrest
apis
and
when
I
say
customers.
A
A
These
rest
apis
are
governed
by
open
API,
expect
their
specifications
documentations
around
these
rest
apis
and,
in
fact,
if
some
of
these
rest
apis
from
the
order
management
system
want
to
be
bundled
and
exposed
as
API
products,
they
could
be
done
so
and
kind
of
documented
specified
using
open
API.
So
this
is
where
kind
of
the
open
API
aspects
come
in
place
now
what's
happening
behind
the
scenes.
Is
you
know
your
order
management
system
there's
an
underlying
implementation
where
there's
different
microservices
or
different
things?
A
That
is
that
is
happening,
and
this
is
where
kind
of
asynchronous
Eda,
implementations
and
interaction
come
in
in
place.
Where
you
have
kind
of
an
inventory
system,
a
shipping
system,
a
CRM
system,
you
can
even
have
a
fraud
detection
system.
You
can
have
a
consumer
sentiment
system
where
in
real
time
it
publishes
events
and
subscribes
to
other
events
and
get
these
information
from
these
events
and
could
also
kind
of
sometimes
send
status
updates
to
your
consumer
customer
stakeholders.
A
Now
the
same
way,
we
said
that
open
API
is
a
specification,
is
used
to
specify
your
rest
apis
and
if
you
want
to
bundle
your
rest
apis,
you
bundle
them
as
API
products.
You
could
do
the
same
thing.
We
could
take
an
inspiration
from
how
this
is
done
in
the
rest
API
world
and
do
it
in
your
asynchronous
world,
where
you
have
other
stakeholders
who
are
also
interested
to
know
about
kind
of
the
different
inventory
systems.
A
Let's
say
that
you're
building
an
analytics
engine
by,
like
you,
know
a
third-party
stakeholder
who
wants
exposure
to
your
underlying
systems
and
wants
to
publish
events
about
their
analytics
into
your
own
system.
This
is
where
event
API
products
shine.
This
is
where
async
API
shines.
This
is
where
the
collaboration
exposure
exposure
of
business
capabilities
in
the
Eventing
World
also
come
come
to
come
to
place
in
a
very
interesting
use
case
and
again,
once
we
enable
different
stakeholders,
businesses,
organizations
to
use
event
API
products,
you
are
moving
forward
in
a
much
much
faster
process.
A
A
B
It's
really
important
to
point
out
that
it's
not
an
either
or
kind
of
situation
like
Rusty
apis
versus
async,
apis
I
can't
tell
you
the
number
of
clients
that
I've
been
talking
to
just
over
the
past
month.
Who
say
what
we
really
want
is
one
stop
shopping
for
both
internal
users
and
external
users
to
see
every
option
available,
both
synchronous,
apis
and
async
apis
in
one
place,
and
they
get
to
pick
which
API
makes
sense
for
them
in
the
particular
particular
use
case.
B
What
they
don't
want
is
a
sort
of
bifurcated
world
where
you
go
over
here
for
the
rest,
apis
you
go
over
here
for
your
async
apis.
They
want
it
all
in
one
place,
they
want
the
the
tooling.
You
know
the
Swagger
kind
of
thing
where
you
get
to
you
know,
do
a
sample
and
click
here
and
you
get
to
see
the
sample
reply
really
really
easily.
That's
the
kind
of
look
that
people
are
talking
about
and
I
think
that's
the
convergence
between
rest,
apis
and
async
apis
and
the
the
API
products.
B
A
Yeah
all
right,
so
we
get
the
point.
We
understand
that
event.
Api
products
are
important.
We
know
kind
of
what
are
what
are
the
benefits
of
event
kpi
products?
What
are
the
steps
that
we
need
to
create
many
API
products
and
we
kind
of
like
summarize
some
some
steps
needed
to
create
event,
API
products
and
from
our
perspective
you
know
the
the
journey
to
successful
creation
of
Eventbrite
API
products.
We
broke
them
down
into
five
different
steps.
Shall
we
go
over
them?
B
Yeah
I
would
say
this
is
sort
of
like
the
arugula
step
of
the
the
process,
because
you're
Gathering
system
of
events
either
you're
talking
with
people
and
discussing
like
hey.
This
is
what
events
we're
putting
out
onto
our
onto
our
broker
or
you're
running
some
sort
of
automated
program
that
detects
events
and
and
brings
them
into
some
sort
of
catalog.
This
is
the
boring,
hard
work
that,
unfortunately,
is
really
really
necessary
to,
as
we
build
up
the
value
chain
figure
out
what
we
can
actually
can
combine
so
level.
One
arugula.
A
B
So
I
think
you
also
you
can
have
this
big
pile
of
system
events,
slash
arugula,
but
if
you
like,
as
long
as
you
don't
sort
of
parse
out,
what's
what's
helpful,
what's
not
helpful!
This
is
sort
of
the
Sorting
of
oh.
This
is
delicious
arugula
leaf
that
will
be
nice
and
peppery
versus.
Oh.
This
has
been
seen
out
here.
This
arugula
is
useful
for
one
particular
purpose,
but
not
so
great
for
a
delicious
salad
that
I'm
building
so
two
again,
not
so
not
so
fun,
but
really
really
useful
in
in
the
Quest.
A
B
Yeah
and
I
think
this
is
slightly
more
fun,
and
this
is
a
little
bit
more
creative,
where
you
think
all
right.
These
are
really
important
things,
but
how
do
they
fit
together,
like
a
like
a
piece
of
a
puzzle,
so
I
think
here,
you're
figuring
out
what
kind
of
dressing
you're
gonna
pair
with
the
arugula
to
really
bringing
out
bring
out
that
that
freshness,
I
would
recommend
the
ranch,
because
I
always
recommend
Ranch,
no
matter
what?
But
your
your
preferences
may
may
be
different.
B
A
B
A
And
then,
finally,
we
got
the
manage
aspect
where
you
can
like
evolve
and
optimize.
This
is
where
you
know:
you've
done
the
discovery
of
your
underlying
system,
you've
curated.
What
are
the
events
that
you
want
to
bundle
and
expose
and
you've
actually
bundled
them
in
an
event
API
product
released
it
into
you
know
for
your
other
stakeholders
to
use.
And
finally
you
got
the
manage
aspect.
A
A
Totally
man
Jesse-
that
was
a
a
fruitful
conversation.
We've
had
around
event
API
products
about
solids.
It
was
a
very
delicious
conversation,
I'm
pretty
hungry
right
now,
it's
it's
great
I,
I,
really
hope
we
we
gave
our
audience
or
whoever
is
listening
to
to
this
talk
and
idea
on
the
importance
of
event
API
products
how
to
do
them.
What
are
the
different
steps
that
are
needed
behind?
Just
you
know,
working
with
event,
API
products
and
Jesse.
We
are
just
scratching
the
surface
on
how
things
are
being
done.
A
There's
there's
so
many
different
things
with
event:
API
products
I
know
what
we
have
with
with
our
with
our
tool:
the
pub
subplus
event
portal,
which
is
a
platform
to
help
people
manage
their
underlying
event,
driven
architecture.
We
have
a
way
to
work
with
events
API
products
that
we
didn't
even
delve
more
into
it.
But
again
this
was
kind
of
just
to
scratch.
A
The
surface
introduce
the
importance
of
event
API
products
and
how
async
API
fits
with
all
of
this,
so
throughout
the
whole
process
throughout
the
whole
Journey
async
API
is
a
passenger
seat.
In
this
event,
API
event
API
products,
Journey,
where
you
want
to
specify
you
want
to
communicate
what
your
event
apis
are
all
about
is
where
you
use
async,
API
to
specify
and
document,
and
you
know,
explain
what
are
the
things
behind
your
event.
Compare
problems.
A
B
The
movement
behind
sort
of
creating
a
worldwide
flow
of
events
throughout
different
Enterprises
and
I
think
seeing
us
expose
out
event.
Api
products
immediately
leads
to
questions
such
as
well.
How
do
we
find
these
event
API
products
and
so
I
think
that
leads
immediately
to
questions
about
discoverability
and.
A
B
Questions
about
we
can't
have
humans
going
and
deploying
infrastructure
to
support
these
events
that
are
coming
going
out
of
particular
Enterprises.
So
how
do
we
support
more
Universal?
Provisioning
rules
allow
people
to
get
access
to
their
event
apis
without
dropping
an
email
out
to
an
administrator.
Then,
five
days
later,
you
get
a
queue
deployed
for
you,
I
think
those
as
that
slide
sort
of
revealed
at
the
last
moment.
Speed
is
key,
I
think
speed
both
in
terms
of
creating
the
the
API
products,
but
also
discovering
them
implementing
them.
B
Tightening
up
that.
That
cycle
is
going
to
be
key
for
the
next
evolution
of
events,
API
products
and
I
think
there's
a
huge
role
for
standards
to
be
used
there
as
well,
both
probably
within
an
async
API
and
other
organizations
as
well,
but
in
general.
It's
a
I
feel
like
a
very,
very
interesting,
exciting
time
to
be
involved
with
both
basement
and.
A
A
Okay,
perfect
I
think
that
kind
of
brought
up
our
talk
for
for
today.
Jesse.
Thank
you
again
for
shedding
some
light
on
some
of
the
information
that
we
we
talked
about
for
anyone
listening
to
us
or
watching
us,
live
or
recorded
right
now.
If
you
want
more
information,
you're
going
to
continue
the
conversation,
please
join
us
on
this
community
at
Solace,
Tech
Community.
We
have
a
lot
of
people
talking
about
different
aspects
of
event,
driven
architecture
including
event,
API
products.
A
So
if
this
was
a
topic
of
your
interest
or
you
kind
of
learned
something
new
hop
on
the
Solace
Community
send
us
a
message.
Let
us
know
if
this
was
useful
or
not
or
if
you
kind
of
learned
some
new
things
about
this
you'll
find
myself
and
Jesse,
and
the
community
answering
to
answering
questions
and
chatting
with
with
people.
So
that's.