►
From YouTube: Design-First for Event Driven APIs with AsyncAPI
Description
This is a session given by Fran Méndez at Nordic APIs 2018 Platform Summit on October 24th, in Stockholm, Sweden.
A
Currently
I
am
working
on
a
sink
API
project
that
you
might
have
heard
about
it
or
may
not
that's
why
I'm
here
today,
so
first
of
all,
before
continuing
I
want
to
make
it
clear.
I
asked
the
organisation
a
few
days
ago
to
change
the
subject
a
little
bit
about
the
talk
today,
because
there
are
many
exciting
things
happening
in
the
async
API
specification
today,
I'm
not
gonna,
exactly
explain
how
we're
doing
async
API
at
New
Relic,
but
I
will
be
happy
to
answer
these
questions
so.
A
A
The
project
that
I
started
like
two
years
ago
is
exactly
about
documenting.
This
kind
of
API
is
I'm
sure
that
all
of
you
have
have
felt
the
pain
of
not
having
a
contract
for
all
your
messages
in
the
in
your
system,
like
you
know
that
we
have
Rommel,
we
have
open
API.
We
have
many
specification
languages
for
our
API
contracts,
but
we
often
forget
about
the
messaging
api's
contract
like,
and
this
is
especially
important
because
we
tend
to
push
messages
into
a
system
broker,
and
then
we
have
many
consumers.
A
What
happens
is
if
the
the
producer
of
the
message
suddenly
changes
the
structure
of
the
message,
something
that
sounds
like
obvious.
You
should
not
do
that
in
large
organizations.
It
happens
very
frequently
more
than
one
who
who
will
want
to
to
assume
right
so
before
before
we
go
deep
into
into
async
API.
What
I
did
was
to
create
the
specification
like
open
API,
especially
to
define
this
this
contract.
So
let's
go
to
the
rapidly
to
the
brief
example
of
the
async
API
specification.
So
we
know
what
we're
talking
about
I.
C
A
Is
it
enough
I
think
so
right?
So,
as
you
can
see
here,
what
I'm
demoing
here
today
is
it's
pretty
much
like
the
open,
API
editor,
the
swagger
swagger,
editor,
sorry
that
you
can
see
a
final
flying
online,
but
instead
of
open
API,
you
see
like
async
API
right.
So
this
is
a
document
basically
containing
information
about
your
API,
but
this
API
when
I
mean
API.
Sorry
when
I
say
API
I
mean
messaging
API,
not
REST,
API
or
HTTP
API.
A
You
have
servers
like
we
have
here,
for
instance,
and
in
this
case,
what
I'm
this
is
sample
is
about
an
ik
product
like,
for
instance,
a
strict
light
controller.
Imagine
that
we
have
a
an
IOT
project
and
we
want
to
control
all
the
street
lights
in
the
street
and
and
all
and
we
want
to
monitor
them.
So
this
is
an
example.
A
Exactly
doing
that,
like
we
have
an
MQTT
broker
with
a
port
here,
and
then
we
have
another
MQTT
broker
with
another
port,
because
it
is
for
security,
another
protocol,
and
then
you
have
topics
and,
for
instance,
you
have
topic
whose
familiar
here
with
the
concept
of
topic
is
in
MQTT
or
in
Kafka,
for
instance.
Okay.
So
for
those
who
are
not
familiar
with
that,
the
topic
can
be
like
the
name
of
a
channel.
When
you
have
a
system
where
you
can
publish
channels
sort
of
messages
to
two
channels,
you
have
to
name
them
right.
A
You
have
to
name
the
channel,
so
this
is
the
name
of
the
channel,
so
street
lights.
This
is
a
variable.
The
ID
of
the
street
light
lighting
measured.
So
here
we're
publishing.
It
says
that
we
as
a
street
light
as
a
consumer
of
this
API,
we
can
publish
the
current
lighting
conditions
that
the
street,
like
has
right.
So,
for
instance,
these
are
usually.
A
These
are
usually
lumens,
as
you
may
know,
and
it's
usually
measures
that
the
light
intensity
and
we
have
the
same
thing
like
as
a
street
light.
We
might
receive
a
command
from
the
control
center
to
dim
the
lights.
For
instance,
we
want
to
dim
the
light
until
I,
don't
know
20%.
So
here
you
have
in
components,
messages
you
have
dim
correct
and
it's
an
object
containing
percentage
and
a
timestamp
cool,
so
big,
without
going
too
deep
in
in
in
in
this
format.
I
just
wanted
you
to
know
what
are
we
talking
about
before
I?
A
This
is
pretty
much
like
open,
API
right.
Actually,
it
was
in
purpose.
What
I
did
in
the
beginning
was
literally
copy,
open,
API,
exactly
and
say:
okay,
we
need
to
change
paths
by
topics.
We
need
to
change
this
by
this
display
so
adapt
into
a
messaging
system,
because
many
people,
including
me,
were
in
the
need
to
have
this
kind
of
contracts
for
messaging
and
that
the
EOP
and
the
open
API
specification
was
not
going
to
be
implement
it.
So
with
that,
you
can
generate
this
kind
of
documentation.
A
For
instance,
like
you
can
generate
the
documentation,
you
can
generate
code
or
you
can
do
it.
The
other
way
around
like
I
was
like
I
was
proposing
in
the
in
the
previous
talk.
You
can
go
design
first,
you
design
your
API
like
in
the
in
the
left
side
and
then,
after
you
design
your
API,
you
embed
it
in
your
curl
like
every
time
you
receive
and
message,
you're
gonna
check
if
the
message
is
complies
with
with
the
payload
definition
that
you
have
there
all
the
headers
etc
right.
A
A
Go
so
now
now
that
we've
seen
an
example
of
facing
KPI
document,
what
is
async
API?
Actually,
so
we
have
a
tweet
here
from
API
handyman.
We
have.
We
have
him
here
in
the
in
the
room
which
I
think
it's
the
best
tweet
that
I've
found
since
two
years
ago.
That
best
defines
what
async
API
is
it's
funny.
It's
it's
been
like
more
than
two
years
and
and
I
think
it's
he's
the
only
one
that
was
able
to
define
it
properly.
In
a
few
words,
it's
exactly
what
it
is.
A
It's
open,
API,
an
open,
API
document,
but
for
messaging
correct
so
before
we
before
sorry
continuing
this
is
a
specification
I
want
to
make
it
clear
that
it's
not
a
software
or
anything.
This
is
a
specification
and
with
that
we
can
define
invent
driven
medical
services
or
message
driven
micro
services,
IOT
api's
and
pretty
much
anything,
that's
message,
space
right.
A
We
don't
enforce
any
particular
protocol,
but
we
keep
in
a
list
of
compatible
protocols
and
that's
due
to
the
many
different
approaches
in
the
messaging
world
on
how
to
how
things
work
like
some.
Some
of
them
has
have
hues.
Some
of
them
don't
have
cues
like
Kafka,
don't
have,
for
instance,
some
of
them
I,
don't
know
they
don't
even
have
a
broker.
They
just
beer
to
peers
like
WebSockets,
for
instance,
it's
not
a
broker,
but
you
have
brokers
that
have
WebSocket.
A
So
it's
not
the
library,
no
software,
but
as
a
way
for
you
to
get
started
with
a
with
the
specification,
we
provide
documentation,
generators
code
generators.
We
have
now
some
people
implementing
API,
wait
a
PA
gateways
and
API
management
tools,
pretty
much
like
what
you
have,
for
instance,
that
mule
soft
with
Dremel.
You
could
have
it
with
a
sync
API,
but
for
messaging.
A
A
Well,
maybe
that
would
be
the
right
case,
but
it
make
no
because
I
honestly
insert
I
honestly
created
this
technology
in
order
to
to
solve
a
problem
of
mine
that
I
had
on
in
a
previous
company
a
teach
at
API
changelog,
but
the
more
I
started
working
on
the
messaging
world
on
the
messaging
API
is
I
realized
that
this
is
a
huge
mess.
I
cannot
have
the
same
advantages
that
I
have
when
I
use
an
API
specification.
A
I'm
gonna
create
that
well,
I
must
be
since
you're
here.
The
first
thing
that
I
tried-
and
I
I've
heard
from
from
many
people
the
same
the
same
story.
The
first
thing
that
I
tried
was
to
adapt
open
API
for
messaging
like
hacking
in
a
way
like
the
path
is
a
name
of
the
topic
and,
and
then
I
mean
all
sorts
of
tricks
and
and
get
is
subscribed
and
post.
This
publish,
you
know
all
sorts
of
weird
stuff.
A
So
why
I
think
you
should
use
it?
It's
basically
because
the
more
I
work
it
on
that
and
the
more
I
were
I
speak
to
people.
The
more
I
realized
that
this
is.
This
is
very
useful
for
them.
So
I
think
you
should
give
it
a
try,
but
one
thing:
this
is
all
just
subjective
subjective
stuff
from
my
experience,
but
the
objective
stuff
is
like
we
as
a
as
an
industry.
We
need
to
common
language
right.
A
A
One
of
the
the
main
purposes
of
async
API
was
to
make
it
machine
readable
because
that
I
mean
that
was
the
whole
idea
right.
You
can
have
human
readable
documentation
which
might
be
very
nice
and
beautiful,
and
it
might
explain
things
in
a
nice
way,
but
that
cannot
be
parsed
by
machine
that
cannot
be
probably
shared
into
with
another
person
in
the
world
that
doesn't
speak
the
same
language,
for
instance,
so
we
need
something
that
can
be
exchanged
and
especially
between
machines,
but
at
the
same
time
we
wanted
to
keep
it
simple
for
humans.
A
Again,
coming
back
to
coming
back
to
to
the
API
definition,
I
want
to
reinforce
the
point
here
and
especially
because
we
are
at
Nordic
api's,
and
this
is
the
one
of
the
the
play
there.
The
place
is
the
conference
that
either
that
I,
like
the
most
and
actually
my
first,
my
first
conference
outside
Spain-
was
here
so
I'm
glad
to
be
here
again.
A
This
message
might
cause
or
might
not,
but
might
cause
something
in
your
system
or
in
your
applications
to
do
something.
So
you
are
programming
a
system
through
an
interface.
So
this
is
an
API
and
as
an
API,
we
need
to
take
control
of
the
whole
lifecycle
and
it
has
the
same
problems
of
REST,
API
or
HTTP
API,
your
graph
QL
api's.
It
has
the
same
problems.
You
have
to
take
care
of
the
design
you
have
to
take
care
of
the
documentation
code
generation.
A
A
So,
on
the
on
the
subject
of
why
you
should
use
it
and
I
think
this
is
a
good
reason
for
that
I
could
have
make
it
private
and
create
a
company
from
from
that
specification.
I
actually
had
the
offer
to
do
it,
but
I
wanted
to
keep
it
to
public
and
open
source
and
community
driven
I
want
I
wanted
to
be
the
standard
way
of
doing
it.
I
want
to
be
the
open
API
for
messaging.
A
Briefly
how
to
get
started.
I'm,
not
gonna,
say
here
how
to
get
started.
We
go
because
I
only
have
25
minutes
and
I
want
to
tell
you
more
things
more
stuff,
but
I
can
point
you
to
some
places
like
where
you
can
start.
For
instance,
the
the
code
editor
that
I
was
using
in
the
beginning
is
an
online
editor.
That's
in
editor
that
I
syncopated
orgy
and
in
the
github
organization,
you
have
much
more
stuff,
like
code
generator
documentation.
Generators
I
will
be
also
happy
to
help.
A
You
have
documentation.
We
have
now
a
team
of
people
helping
with
the
documentation
that
will
I
would
like
to
thank
kin.
Lane.
I
would
like
to
thank
James
Higginbotham
I
mean
many
people.
I
cannot
mention
all
of
them
here,
because
there
are
too
many,
but
thanks
to
them,
because
they
are
working
a
lot
on
the
new
documentation
on
blog
posting,
a
blog
post,
explaining
how
to
use
it
and
and
and
also
you'll,
always
have
the
slack
channel.
Where
I,
usually
reply
almost
immediately
and
and
yeah
we'll
be
happy
to
help.
A
So
and
now
it's
a
the
reason
why
I
changed
the
subject
of
the
talk.
Briefly,
it's
exactly
that
the
next
slide.
So
until
now
it's
been
a
side
project
of
mine,
while
I
was
working
at
each
or
at
New
Relic.
This
is
not
a
side
project
anymore.
This
is
a
full-time
project
now
I
I'm
glad
to
say
here
today,
for
the
first
time
that
I'm
gonna
create
a
foundation
in
the
next
month,
together
with
the
people
you
see
here:
Salesforce
Mule,
soft
sapa,
slack,
api,
evangelistic,
elaine
and
typical
for
now.
A
So
I
think
this
is
getting
interesting,
and
I'm
also
here
today
as
a
way
to
to
say.
Please
join
us
in
the
effort
of
standardizing
that
don't
worry
if,
whatever
company
you
see
there
is
a
competitor
of
yours,
because
we
actually-
and
I
don't
want
to
say
we-
I
want
to
actually
put
as
much
competitors
in
the
indirect
foundation
as
possible,
so
so
death,
so
that
specification
is
not
biased
to
one
or
the
other.
You
know
so
it's
fair
to
everyone
correct,
so
yeah
also
I
would
like
to.
A
I
would
like
to
know
that
we
are
looking
for
individual
contributors
we
need
for
now.
We
need
people
writing
stories
about
it.
Documentation
I
mean
code
generators.
Whatever
the
idea
you
have
I'm
you're
welcome
basically
you're.
Welcome
for
that,
because
I
mean
that
that's
a
lot
of
work
and
yeah.
So
thank
you
for
that.
A
A
Actually,
the
problem
is
that,
as
it
is
right
now
and
to
make
it
compatible
with
up
an
API
we're
using
this
sort
of
JSON
schema
for
for
the
for
the
payloads
and
and
all
the
data,
but
I'm
working
actually
right
now
on
the
version
two
and
one
of
the
features
is
to
support
multiple
schemas
like
you,
can
define
your
schema
with
Avro
proto
buffers,
whatever
you
want.
So
thanks
thank.
A
We
kept
it
simple
on
purpose.
We
only
pretend
to
define
not
pretend
I
think
this
is
a
false
friend
from
Spanish.
We
only
want
to
define
topics
and
and
messages,
because
these
are
common
in
almost
every
messaging
system.
We
don't
want
to
go
into
detailing
in
two
queues
or
or
in
two
stream
details,
because
these
are
very
vendor
specific
details.
A
However,
most
of
the
times
you
can
define
all
these
details
in
heathers
and
the
messages
can
have
headers,
so
you
can
also
define
the
the
headers
you
need
in
the
message.
Also
briefly,
we
are
also
working
on
the
on
the
version.
Two
on
the
feature
that
will
allow
you
to
have
specifics
for
every
vendor,
like
in
a
message
you
want
to
have
or
while
connecting
to
a
broker,
you
want
to
have
different
setups,
depending
depending
if
it's
rabbit
in
queue,
Kafka
or
whatever,
so
that
would
be
possible
as
well.
B
A
Okay,
so
briefly,
explain
there
is
a
document
in
the
repo
on
the
under
on
the
github
github
organization,
that
explains
in
a
strategy
for
versioning
messages
over
time
and
how
to
structure
the
name
of
the
topics.
So
the
version
is
on
the
topic.
This
is
pretty
much
the
same
strategy
as
putting
the
version
on
the
on
the
path
and
in
HTTP.
Api,
like
the
path
in
this
case
will
be
the
topic,
so
I
would
like
to
show
you
more
I
can
probably
share
later,
but
yeah
I
will
share
it
on
the
slack
Channel.
A
We
have
strategy
for
that,
but
this
is
separate
from
from
async
API.
It
has
nothing
to
do,
but
I
started
this
at
the
same
time
as
icing
KP
async
API,
because
I
figured
out
that
I
realize
about
the
problem
and
then
and
had
to
figure
out
the
solutions
so
yeah
we
have
a.
We
have
something
I
will
share
in
the
selection.
E
A
I
that's
right,
I,
never
thought
about
these,
these
foundations
or
groups.
To
be
honest,
the
first
thing
that
people
ask
me
always
is
why,
when
are
you
emerging
to
open
API
initiative?
This
is
I,
always
get
the
same
question
and
I.
Think
I
will
not
do
it
for
now.
For
the
same
reason,
because
we
need
speed
now
we
need
to
move
faster
and
this
will
block
development
and
that
will
be
blocked
by
something
we
don't
control.