►
From YouTube: LiveCast: Leveraging AsyncAPI
Description
AsyncAPI is a new standard specification for describing asynchronous and event-driven architectures. Here’s an introduction to the initiative around AsyncAPI.
Asynchronous and event-driven architectures are rising styles. AsyncAPI answers this trend, as a standard specification for describing these communication scenarios. We’ve been following the AsyncAPI Initiative for years now and are excited to finally dedicate an event to AsyncAPI!
At this event, Fran Méndez, Project Director, AsyncAPI will give us an introduction to AsyncAPI and the surrounding community initiative. Ben Gamble, Head of DevRel at Ably Realtime, will follow with some real-world examples of how AsyncAPI has been implemented in production and the benefits of use.
https://nordicapis.com/events/leveraging-asyncapi/
A
A
In
this
event,
we'll
be
exploring
the
async
api
specification
and
learning
from
the
experts
about
how
to
best
leverage
it
to
guide
asynchronous
development.
Asynchronous
and
event-driven
architecture
has
really
been
on
the
rise
lately.
So
I
think
this
is
a
great
time
to
meet
with
some
of
the
key
figures
propelling
this
field
forward.
A
We
also
ran
a
poll
recently
and
by
a
landslide.
This
topic
was
our
most
voted
one
by
our
followers.
So
I
think
that
just
demonstrates
the
interest
in
async
styles
right
now,
so
for
those
of
you
who
are
maybe
a
bit
unfamiliar
async
api
is
a
newish
standard
specification
for
describing
asynchronous
apis.
A
The
open
source
api
definition
is
backed
by
the
async
api
initiative
and
by
using
async
api,
you
can
define
your
async
apis
in
json
and
yaml
to
create
a
machine,
readable
format
now
hosted
by
the
linux
foundation.
As
of
early
2021
async,
api
is
billed
as
kind
of
an
alternative
to
open
api
specification
as
it
caters
to
different
protocols
like
amqp,
mqtt,
websocket
kafka
and
others.
A
On
that
note,
one
benefit
of
working
with
any
open
standard
definition
is
that
you
can
utilize
all
the
compatible
tools
in
the
ecosystem.
So
if
you
have
an
async
api
definition,
for
example,
you
could
easily
generate
human
readable
documentation
for
the
service
or
you
could
incorporate
your
definition
into
trigger-based
development
with
github
actions
or
async.
Api
could
even
help
a
specification
and
design
first
development
strategy.
A
So
that's
kind
of
a
very
high
level
overview
of
what
async
api
is
and
to
dive
deeper
into
this
subject.
We
are
honored
to
welcome
two
expert
speakers
today.
First
up
is
none
other
than
founder
of
async
api
initiative
and
someone
we
featured
through
nordic
apis.
Quite
a
bit
director
of
engineering
at
postman,
fran
mendez
fran
will
be
giving
us
an
introduction
to
async
api
and
the
surrounding
community
initiative
and
exploring
the
future
of
api
specifications.
A
A
B
Nobody
is
doing
event
driven
architectures
a
lot
nobody's
been
dressed
api
as
long
nobody's
doing
graphql
api
so
long.
So
we
all
work
with
different
styles
of
apis
and
I
would
love
to
explore
what
the
future
of
api
specifications
could
look
like
if
we
make
it
happen,
so
it
all
depends
on
us.
You
included
not
just
the
ones
that
are
working
currently
on
the
specs
right.
B
So
let
me
tell
you
this.
Let
me
explain
what
I'm
what
I'm,
what
I'm
thinking,
what
I
think
it's
the
future
of
api
specifications
as
a
story
right.
So
this
is
a
beautiful
stockholm.
So
I
think
bill
is
familiar
with
this
picture,
maybe
and
and
yeah.
So
I
I
was
invited
at
nordic
api
stockholm
in
2018,
and
I
was
like,
like
I
said
I
was,
I
was
honored
to
be
there.
B
Actually,
I
think
it
was
a
keynote,
so
I
was
even
like
I
was
you
know,
super
freaking
out
and
nervous
right,
because
I
I
came
there
to
announce
that
I
was
dedicating
full-time
to
async
api
and
that
it
was
for
the
first
time
in
history
for
async
api.
It
was
backed
by
companies
right
by
other
companies,
so
it
was
sustainable
and
at
the
end
of
the
update
of
talk
in
the
usual
questions
and
answer
section,
a
guy
raised
his
hand
and
asked
about.
B
Is
it
like
average
schema
or
is
it
the
replacement
for
average
schema
and-
and
I
was
like
well
no
it's
a
you
know.
Average
schema
is
to
define
the
data
and
of
the
message,
and
this
is
more
for
the
api
itself
right.
Like
how
you
send
and
receive
message
and
where
to
connect,
to
receive
message
and
all
at
all
right
and
like
after
the
question
and
answer
section
out
of
the
talk
already
offline,
two
guys
came
to
me
to
talk
and
it
was
funny
to
see
it
to
me.
B
It
was
funny
to
me
that
what
happened
at
that
time
was
right,
one
right
after
the
other.
They
both
asked
the
same
question,
which
is
very
unlikely
and-
and
they
were
both
asking,
have
you
thought
of
merging
with
open
api,
so
async
api
and
open
api
can
be
a
single
spec
and
I
said
like
well
yeah.
We
thought
about
it.
B
We
discussed
about
it
and
we
decided
not
to
do
it
for
reasons
being
the
majority
of
the
reasons
where
not
to
put
too
much
pressure
on
the
tooling
vendors
right,
because
it's
already
complicated
to
provide
full
support
for
open
api
or
full
support
for
async
api.
So
if
we
have
to
provide,
if
someone
has
to
provide
full
support
for
open
api
processing
kpi,
then
it's
like
this
is
a
mess.
It's
too
much
right.
So
we
decided
not
to
go
this
way,
but
we
kept
collaborating
open
api
and
zinke
bay.
B
B
I
was
invited
to
go
to
api
days
paris
same
year,
and
this
is
this
was
the
the
my
first
fbi
days
in
paris,
and
luckily
I
mean
I
was
lost
there
like.
I
almost
knew
no
one,
but
luckily
king
was
king.
Lane
was
there
to
lend
me
a
hand,
and
I'm
always
super
happy
to
to.
You
know
that
that
I
met
him
at
least
so
we
I
could.
I
could
get
introduced
to
somewhere
right.
B
B
B
B
I
want
you
to
think
about
it
for
a
moment
like
and
like
I
did
at
the
time
like
so
this
question
has
been
bugging
me
for
years
for
a
lot
of
years
now
like
why
people
want
us
to
merge
with
open
api.
Like
is
it
I
don't
know
it's
not
it
can
it
can
be
interest,
it
can
be
any
other
under
other
obscure,
let's
say
or
dark
thoughts
or
anything,
because
some
people
are
just
like
users
and
they
don't
care
about
open
apis
and
kpi
or
any
spec.
B
C
B
Gonna
answer
this
question
now
I
just
want
to
look
you.
I
just
want
you
to
look
at
this,
so
this
is
the
current.
Let's
say
the
the
current
ecosystem
of
specs
and
api
styles,
so
you
have
rest
graphql,
grpc
or
rpc
messaging
and
so
right
and
then
you
have
a
bunch
of
api
specifications.
These
are
not
all
the
specifications
that
exist,
but
these
are,
let's
say
the
primary
ones
for
each
of
the
of
the
api
styles.
B
B
A
B
Some
people
think
it
doesn't
exist
anymore,
but
it's
still
there
so
still
there
for
a
long
time.
I
guess
so,
then
you
have
to
use
either.
I
don't
even
know
how
to
pronounce
this
correctly.
I
always
call
this
whistle
because
I
think
it
sounds
cool
or
you
have
to
use
xsd
right,
not
or,
and
you
have
to
use
xst
right
to
define
the
data
model.
So
so
again,
if
this.
B
B
So
then
probably
people
want
to
want
us
to
merge
with
open
api
and
and
then
what
and
then
we'll
have
to
merge
with
grpc
and
with
graphql
or
how
is
it
going
to
happen
right
more
than
how
it
is
going
to
happen,
I'm
more
interested
in
the.
Why
right,
so
so
why
people
are
again
asking
us
this,
so
let
me
just
get
back
to
this.
So
do
you
really
think
that
people
want
a
single
spec
with
all
these,
with
all
this
ecosystem.
C
B
B
I
mean
could
be,
but
aps
specifications
are
often
composed
by
multiple
files.
You,
you
divide
the
spec
in
multiple
files,
so
I
don't
think
it's
happening
in
multiple,
a
single
file
and
so
the
the
conclusion
that
I
can
that
I
came
with
is,
in
my
humble
opinion,
I
think
people
are
just
looking
for
the
one
tool,
the
one
process,
the
one
workflow,
if
you
want,
so
you
just
do
one
thing
and
it's
the
same
for
any
kind
of
api
right,
any
kind
of
if
it's
rest,
graphql
jrpc
and
they
don't
care.
B
B
B
Don't
tell
me
you're,
like
don't
tell
me
your
problems,
and
it's
just
give
me
a
solution
right
like
I
was
saying
before
they
were
like
okay,
I
understand,
but
I
don't
care
right.
So
I
think
it's
just
like
one.
One
single
process,
one
workflow
and
then
just
do
something
for
rest,
and
then
you
do
the
same
for
graphql
and
jrpc
and
messaging,
and
so
and
it
works,
and
you
don't
have
to
be
installing
different
tools
and
then
that
are
in
this
tool.
You
do
this
like
this
and
these
other
tools.
B
You
do
this
things
differently
and
then
nothing
is
compatible
with
each
other.
So
I
think
that's
that's
that's
the
key
thing,
and
and
also
because
we
tend
to
we
like
api
practitioners.
I
would
call
myself
for
ourselves
api
experts-
maybe
some
someone
is
but
but
the
api
practitioners,
those
who
are
a
little
bit
more
than
the
average
interested
in
apis
they're
cool
with
this,
because
it's
like,
oh,
this
is
like
a
game
right.
I
need
to
learn
this
new
language,
these
new
tools.
B
B
Or,
or
or
or
orms
right,
so
you
have
sql
and
no
sql
and
nosql,
but
you
have
all
orms
that
can
handle
this
for
you.
So
you
don't
have
to
rewrite
your
queries.
It
will
do
it
for
you,
depending
on
the
end
that
you
have
right
for
deployment.
There
are
many
systems,
and
now,
with
kubernetes
and
many
other
systems,
this
is
becoming
even
more
famous,
let's
say
right
and
mainstream
and
security
same
way,
so
so
for
apis.
B
We're
still
asking
developers
with
non-specific
interest
in
apis
to
learn
all
these
things
just
to
be
able
to
provide
a
good
api
experience,
good
api
development
experience
and
I
think
the
experience
there
needs
to
be
seamless
right,
not,
as
is
as
it
is
right
now.
So
how
do
we
solve
this
problem
without
merging
into
a
single
space?
B
B
So
I
think
I
took
the
time
to
evaluate
how
it
is
the
state
of
the
api
is
seeing
right
now
and-
and
you
know
evaluating
as
in
realizing,
which
ones
are
in
the
good
direction.
My
opinion
in
a
good
direction,
which
ones
are
not
in
a
good
direction
or
non-existent
or
and
and
also
which
ones
are.
You
know
like
kind
of
there,
but
still
need
some
work.
B
So,
as
you
can
imagine,
green
is
for
it's
for
those
who
are-
or
I
would
say
doing
well,
these
parts
of
the
the
spec
that
the
space,
the
aps
quests
that
are
doing
well
red,
is
none
and
yellow
is
kind
of
right.
So
so
I
divided
this
by
specs
and
tools
right,
so
we
have
different
specs,
but
then
we
have
tools
to
work
with
the
specs
and-
and
I
would
say
that
specs
you
have
everything
listed
there
like,
I
think,
multiple
schema
definition,
languages
paradigms
and
protocols.
B
This
is
really
possible,
at
least
without
with
decent
kpi.
It
is
possible,
so
you
can
have
different
like
client
server
and
broker
based
architectures
defined
with
async
api,
and
you
can
have
multiple
protocols
and
you
can
have
multiple
schema
definition.
Languages
like
avro,
like
json,
schema
right,
so
it
is
like
removal,
data
types
it
is
already
possible.
So
that's
that's
cool,
then
on
spec
side
as
well,
most
of
them
are
extensible,
so
I
will
say
that
I
think
roughql
and
jrpc
are
the
only
ones
who
are
not
providing
an
extension
mechanism.
B
I'm
not
sure
though,
but
this
is
kind
of
there
right
and
then
I
think
specs
need
to
become
composable.
What
do
I
mean
by
composable?
So
if
you
have,
if
you
have
a
spec
like,
for
instance,
we
do
in
async
api,
we
have
the
possibility
to
use
the
http
protocol
and,
if
you're
gonna
use
the
http
protocol
and
you're
gonna
interact
with
an
http
endpoint,
then
why
should
we
be
defining
this
amazing
kpi?
B
Why
can't
we
leverage
open
api
to
do
that,
like
open
api
is
already
defining
and
giving
you
the
opportunity
to
define
how
to
how
to
interact
with
an
http
endpoint
right?
So
let's
leverage
that
so
that's
mbev,
open
api
or
a
part
of
open
api
inside
and
sync
api
that
wouldn't
be
new
because
remember,
like
I
said
before,
json
schema
is
already
embedded
inside
open
api
and
snk
api.
So
it's
not
something
new
and
we're
also
using
urls,
which
are
urls.
B
B
A
B
B
I
divided
everything
by
specs
and
tools,
but
there's
another
dimension,
which
is
people
and
I
think
we're
failing.
We
all
are
failing
here.
So
we
are.
Some
of
us
are
running
everything
with
transparency.
We
try
to
be
as
transparent
as
possible
on
on
a
sink
api,
but
not
none.
Not
all
the
organizations
behind
the
specs
are
being
transparent
and
that's
something
that
which
will
change
and
that's
something
that
that
we
should
be
calling
out
ourselves,
not
just
ourselves
working
inspect,
but
you,
the
users
as
well,
will
be
calling
out.
B
B
We
are
at
the
same
kpi
as
you
can
imagine.
This
is
it's.
This
talk
is
about
the
future
of
abs
specifications,
so
this
could
be
giving
you
some
hints
of
what
are
what
is
the
future
of
facing
kpi
as
well
right.
So
if
we
think
that
this
is
a
future
of
api
specification,
we're
always
gonna
bet
in
this
direction.
Of
course,
so
so
yeah
we're
gonna
be
betting
on
specs
becoming
composable
and
extensible,
and
I
hope
we
are
not
the
only
ones.
Betting
on
this
and
tools
should
be
facilitating
evolution.
B
Nothing
because
like
why
do
you
want
to
have
a
spec?
If
you
don't
have
tools
to
use
it
and
spec
authors
must
collaborate
with
users
and
not
not
only
with
users
but
between
them
for
the
benefit
of
the
user
and
to
make
it
clear,
like
the
users
will
be
in
the
center
always-
and
this
is
just
I
call
out
two
other-
a
call
to
other
spec
maintainers.
A
C
A
The
specification
is
being
received
really
shows
the
power
of
people
to
really
drive
home.
A
single
nagging
idea-
and
this
is
that-
was
something
I've
been
asked
at
conferences
too,
and
I
didn't
have
a
great
question
or
response
to
that
question
so
that
this
helps
tremendously
yeah.
I
think
it's
great
to
be
thinking
from
the
user's
perspective.
A
Like
you're
saying
you
know,
we
get
so
often
just
trapped
in
our
own
vision
of
whatever
we're
working
on
when
in
reality,
this
is,
like
you
said
just
part
of
the
larger
puzzle,
there's
so
much
more
to
dive
into
everyone.
Who's
listening
in
real
time
feel
free
to
you
know,
drop
your
questions
and
we'll
get
to
it
in
the
in
the
chat
after
ben's
session
here
just
to
mess
with
fran.
I
dare
a
listener
to
ask
why
we
shouldn't
merge
async
with
open
api,
so
I'll
just
throw
that
out.
There.
C
C
So
let's
continue
so,
who
am
I,
I
suppose
so,
whereas
fran
is
quite
well
known
in
the
space
already,
I
think
probably
the
only
person
who
here,
who
actually
knows
me
is
fran,
so
my
name
is
ben
gamble.
I
work
at
abele
real
time
as
head
of
devrel.
I'm
sort
of
person
who
makes
people
read
the
phoenix
project
by
literally
giving
them
physical
copies
until
they
do
get
decided
by
cool
things.
C
So
let's
talk
about
a
little
bit
about
abel
before
we
move
on
to
the
kind
of
key
thing
so
abele,
real-time
communication
platform,
we
empower
digital
experiences,
lots
of
connectivities,
huge
wall
of
logos,
but
you
don't
want
to
read
that.
So
what
we
really
are
is
a
highly
available
pub
subs
message
broker
right,
we
built
scale
out,
think
kafka
that
goes
from
your
data
center
to
your
phone,
except
you
can
have
unlimited
topics
at
any
time.
C
You,
like
that's
sort
of
what
abele
is
with
a
lot
of
websockets
connected,
and
it's
kind
of
important
to
set
the
stage
with
this,
because
this
is
kind
of
like
what
we
do.
What
I
do
and
therefore
where
this
is
all
coming
from,
so
let's
start
with
about
asynchronous
systems,
because
it's
not
really
worth
talking
about
asynchronous
communications
until
we
know
what
is
asynchronous,
so
this
is
going
to
be
a
bunch
of
euclidean
assumptions,
so
these
are
the
things
I'm
going
to
try
and
validate
or
prove
today.
C
These
are
just
the
kind
of
statements
almost
so
when
you
do
the
complex
stuff.
Like
anything
I
mean
significantly
complex,
I
don't
mean
math
operations
I
mean
discs,
I
mean
network
and
the
rest
of
it.
You
kind
of
have
to
wait
for
it
to
happen,
and
it
nearly
always
happens,
often
off
the
main
thread.
So
you
know
you
press
go.
You
want
to
keep
pressing
while
something
is
happening
and
users
are,
should
we
simply
say
very
impatient,
and
so
what
happens
then?
C
Is
you
return
control
to
wherever
you
were
and
until
the
thing
comes
back
you
come
back
and
then,
when
the
thing
returns,
a
promise
would
be
an
example
of
this.
A
future
will
be
an
example
of
this.
There
are
various
ways
of
basically
wrapping
up
an
interrupt
loop,
which
is
still
going
round
and
round
and
round
and
round
in
a
rapid
polling
thing.
When
you
wrap
it
unwrap
it
all
the
way
down,
nothing
is
really
asynchronous.
C
Instead,
things
are
just
constantly
checking.
Asynchronicity
is
important,
because
it's
about
efficiency,
it's
not
totally
more
efficient
than
truly
synchronous
code.
However,
it
gives
a
much
better
impression
of
efficiency.
It
also
makes
the
most
of
when
things
can't
be
done,
because
you're
waiting
for
an
external
resource
now,
the
classic
analogy
I
always
like,
is:
are
you
watching
a
pop
boil
or
you
put
the
kettle
on
away
for
a
sound?
C
It's
it
literally
is
the
computing
equivalent
of
this,
because
you
know
the
the
line
is
you'll,
never
watch
a
pot
boil
or
even
watch
the
file
handler
complete
on
windows.
With
that
little
thing
ticking
across
telling
you
it'll
be
three
days,
10
minutes
or
six
weeks.
It's
one
of
those
kind
of
examples.
You
don't
want
to
be
stuck
there.
Instead,
you
want
to
press,
go,
do
something
else
and
when
it
comes
back
it'll
ping
and
tell
you
and
that's
what
your
computer
really
wants
to
do,
so
you
don't
get
a
horrible
user
experience.
C
C
So
it's
one
of
those
things
where
the
network
itself
is
often
your
enemy,
but
also
your
cpu
doesn't
want
to
wait
for
that
hundred
and
something
milliseconds
in
one
direction:
100
something
milliseconds
in
the
other
direction.
So
what
happens?
Is
you
fire
the
request
and
we'll
do
something
else,
while
it's
going
on
and
the
key
thing
here
is
that
you
don't
even
know
if
you
should
be
receiving
messages
most
of
the
time
like
you
literally
have
an
open
port
somewhere
waiting
and
your
os
is
going.
Is
it
there
is
it
there?
Is
it
there?
C
Is
it
there?
Is
it
there
and
with
the
message,
will
turn
up
or
not
it's
something
you
don't
know
as
the
user
most
of
the
time,
which
is
where
this
kind
of
thing
comes
from
so
like
this
is
what
we
get
down
to
kind
of
synchronous
versus
asynchronous
communication.
So
one
is
literally
hi.
I'm
talking
wait
for
a
response
and
the
other
is
classically
like
the
kind
of
the
post
room
model
where
you
send
a
whole
bunch
of
requests,
someone
something
else
gets
them
back,
and
this
is
where
I'm
going
to
define.
C
One
of
my
things
about
asynchronous
communication
is
asynchronous.
Communication
does
not
rely
on
the
receiver,
acknowledging
the
sender
directly
to
continue,
so
the
sender
can
continue
while
the
receiver
is
receiving
acknowledgements
may
happen,
but
it's
not
in
the
same
protocol
layer.
So
even
if
it's
a
tcp
connection-
and
there
are
literal-
you
know
ip
frame
acknowledgements
coming
back,
it
can
be
asynchronous
because
the
high
level
you're
at
let's
say
it's
levels,
layer,
seven,
you
can
asynchronously
keep
communicating,
even
though
at
layer
four
there
at
every
single
packet
is
in
fact
synchronous.
C
The
key
thing
here
is
that,
like
http
started
off
life
as
like
a
way
to
get
stuff
on
screens
over
the
web,
what
it
became
is
the
de
facto
way
computers
talk
right
and
by
computers
I
mean
any
device
which
is
can
do
computation.
I
mean
your
phone,
your
desktop
hell
load
of
iot
devices
still
speak
http
because
it's
the
most
common
thing.
Work
has
been
done
to
make
http
work
at
scale
and
the
one
thing
we
do
like
as
programmers
is
not
doing
the
work
ourselves.
C
So
if
there's
a
way
to
make
it
work,
you'll
use
it
and
http
it
damn
well
works
and,
as
we
continue
like,
we
get
to
kind
of
understand,
what's
actually
going
on
in
http,
which
is,
let's
start
with
http
one
point
x,
I'm
gonna
say
one
point
x,
because
one
point
one
is
not
is
still
bizarrely
as
unsupported
if
you
dig
deep
into
the
web
but
http.
One
point
x
is
very
synchronous,
there's
a
maximum
number
of
in-flight
requests.
You
can
do
things
like
domain
sharding
and
pipelining,
but
it
doesn't
really
solve
the
problem
right.
C
You
know.
Persistent
connections
within
the
actual
kind
of
live
spec
actually
make
things
faster,
but
they
don't
solve
the
actual
synchronicity
of
stuff
websockets
sort
of
do,
but
they
are
persistent
and
need
to
be
maintained
and
they
are
more
complex
than
a
lot
of
people
want
to
deal
with.
Hence
why
they
come
to
us
enabling
but
irrelevant
for
this
bit.
The
next
thing
that
happened,
of
course,
is
http
2.
now
http
2
is
what
grpc
is
built
on
top
of
it's
part
of
a
google
protocol
called
spdy.
C
C
Now
this
is
really
important
because
something
like
grpc
is
you
don't
know
how
long
an
rpc
is
going
to
take.
So
I
want
to
be
able
to
send
20
rpcs
off
to
a
server
one
might
take
an
hour.
One
might
take
15
milliseconds.
I
need
to
be
able
to
get
16
milliseconds
back
afterwards
and
not
wait
the
one
hour
for
the
first
one
and
that
is
really
important
and
when
we
get
to
http
3
things
get
spicy
and
we're
in
udp
territory.
C
C
But
to
be
honest,
it
would
also
require
a
lot
of
hardware
to
change.
There
is
literal
hardware
problems
in
implementing
http
3,
because
there
are
various
networks
that
physically
block
udp
packets,
because
they
are
inherently
unreliable,
though
they
can
be
made
reliable.
It's
simply
the
fact
that,
because
it
was
unfavorable
for
such
a
long
time
that
people
like
cisco,
have
made
decisions
to
make
it
really
hard
to
make
something
like
http
3
everywhere.
That
said,
it's
absolutely
amazing
what
you
can
do
with
it,
if
only
it
wasn't
so
difficult
to
find
support.
C
C
The
idea
here
is:
we
have
a
broker
in
the
middle,
which
is
some
machines
and
it
is
some
machines,
but
it
could
literally
be
a
process
in
your
computer
or
it
could
literally
just
be
a
buffer
in
ram
somewhere,
because
the
pub
sub
applies
from
the
your
own
machine.
All
the
way
up
to
multiple
layers
of
distributed
systems,
and
the
key
thing
here
is
inputs,
go
in
one
end:
something
does
some
processing
and
routing
and
receivers
are
at
the
other
end
and
there's
a
disconnect
between
these
things.
C
So
the
famous
examples
these
days
would
be
rabbit,
mq,
kafka,
nats
and
mqtt.
Now
the
key
thing
here
is
that
they
all
do
this
very
differently.
Nats
tries
to
do
a
bit
of
all
the
above,
but
the
key
thing
here
is
that,
like
they
all,
do
they
all
they're
all
existing
for
specific
use
cases,
but
they
implement
this
pattern
and
the
pattern
is
the
power
full
bit.
The
actual
implementation
is
about
a
use
case
nearly
always,
but
it
also
means
it
trends
towards
activity
in
various
regions.
C
Kafka
came
around
from
linkedin
where
they
wanted
to
do
logs
gathering
in
one
place.
They
wanted
to
have
a
known
set
of
good
information
to
work
from
to
optimize
their
website,
to
have
events
gathered
in
one
place
or
had
to
write
disk.
It's
also
optimized
for
spinning
platters,
which
is
why
I
occasionally
look
at
cafe
going.
This
is
really
strange,
but
when
you
realize
it
was
all
built
against
mechanical
hard
drives,
all
the
decisions
are
really
smart.
C
Rabbitmq
is
much
older
from
jp
morgan
of
all
people
and
it
was
about
trying
to
just
root
messages
around
a
bank
with
a
really
clever
protocol,
and
that's
why
it's
amqp
under
the
hood,
rabbit
is
just
an
implementation
of
amqp.
Mqpp
is
the
is
a
is
the
advanced
message,
queueing
protocol
and
it
is
unbelievably
advanced
and
things
like
active
mq
and
all
the
other
mqs
you've
heard
of
are
actually
bizarrely
similar
to
rabbit
just
subtly
different
in
what
they
implement.
C
Nats
is
effectively
trying
to
be
kafka,
but
but
more
friendly
is
the
best
way
I
can
describe
it,
but
it's
such
a
broad
protocol
that
it's
really
hard
to
define
and
anything
beyond
that
mqtt
is
the
de
facto
by
popularity
iot
protocol.
Is
it
the
actual
most
popular
iot
protocol?
No
one
knows
most
iot
things
get
very
proprietary
after
a
point,
and
it's
very
hard
to
actually
tell
what's
going
on
things
like
lightweight
m2m
are
massively
kind
of
moving
in
on
this
territory,
because
it
involves
more
than
just
data.
C
All
the
ones
I've
listed
here
are
tcp
based
right.
Mqtt
is
about
trying
to
minimize
the
amount
of
data
into
one
into
in
a
in
a
chunk,
so
you
can
keep
throwing
them
over
the
wire
and
deal
with
failures.
Very
cleanly
rabbit
is
about
just
being
able
to
route
things
into
good
cues
to
consume
from
to
make
patterns
which
allow
for
very
strict.
I
have
done
this
exactly
once
consumption
models.
Kafka
is
about
storing
messages
in
the
most
resilient
possible
fashion.
C
Anyone
tells
you
otherwise
doesn't
is
not
really
talking
about
what
actually
capture
is
best
at,
which
is
the
resilience
factor.
Kafka
is
used
because
it
is
the
most
reliable
part
of
a
network,
and
that's
what
it's
best
at
the
fact
that
it
processes
streams.
Great
is
a
wonderful
side
effect
of
the
reliability
you
get
and
nats
is
sort
of
there,
because
people
wanted
something
better
than
all
the
above,
which
means
it
has
a
bit
of
this
kind
of
mixed
message
about
it.
C
But,
quite
frankly,
I'm
really
excited
to
see
where
it
goes
next,
so
they
exist
to
provide
these
loose
coupling,
regardless
of
which
of
those
I've
mentioned.
Everything
is
all
about
trying
to
encourage
decoupling
things,
so
you
use
kafka
because
you
don't
want
your
producers,
who
are
spooling
a
million
messages
per
second
to
have
to
overwhelm
anything
at
the
other
end.
You
also
want
to
be
able
to
scale
that
middle
layer.
C
You
know
in
the
case
of
rabbit,
saying
I
have
tons
and
tons
of
work
cues
that
all
need
to
be
consumed
exactly
once,
but
I
don't
want
to
have
to
worry
about
my
workers
being
able
to
actually
hold
the
stuff
in
memory
so
instead
can
scale
rabbit
in
between.
I
want
the
pace
to
go
any
way
they
like
so
particularly
mqtt.
Your
literal
sender
might
only
be
able
to
send
one
message
every
minute,
because
the
cpu
is
that
slow
on
a
literal
hardware
clock.
So
what
happens
then?
Is
you
need
to
have
something?
C
On
the
other
end,
it
can
consume
really
rapidly
from
a
billion
of
those
devices,
and
the
other
thing
you
get,
which
is
fun,
is
strong
guarantees,
because
you
can
actually
do
this
decoupling,
the
speed
decoupling.
You
can
make
stronger
acknowledgements
happen
between
two
systems
without
ever
trying
to
truly
impede
the
full
end
to
end
throughput
of
your
system.
C
So
you
can
do
things
like
pass
a
packet
in
start
pressing.
It
onwards
act
it
back
once
it's
on
disk,
while
it
might
even
reach
the
other
end
of
the
phone.
The
first
act
has
got
back
because
these
things
can
be
fully
decoupled.
There
is
nothing
to
say
you
can't
always
process
a
message
before
it's
act.
C
It
just
means
that
when
the
person
receives
the
act
at
the
other
end
and
says
this
has
definitely
happened,
got
a
strong
guarantee
it
might
have
completed,
but
they
know
for
a
fact
with
the
guarantee
which
takes
time
has
happened
now.
This
is
where
asynchronicity
comes
in,
because
you
need
to
decouple
these
systems
to
allow
this
to
happen
at
any
level
of
performance.
C
So,
what's
the
issue
with
all
this,
surely
this
is
all
kind
of
plug
and
play
right.
You
know
you've
got
all
these
systems
they're
all
off
the
shelf.
Most
of
them
are
at
least
10
years
old.
Well,
they
don't
plug
and
play
right
loose.
Coupling
involves
service
discovery.
Each
of
these
things
speaks
a
magical
binary
protocol,
rather
than
just
json
or
or
plain
text
like
http
http's
magical
source
is
the
fact
that
it
is
plain
text.
C
So
what
happens
now?
Is
you
have
all
these
protocols
right,
which
all
speak
subtly
different
languages,
and
now
you
have
to
manage
like
a
system
with
n
different
things
inside
them,
and
you
just
do
not
know
what
you're
actually
up
to
sometimes
because
you're
saying
right,
I'm
consuming
a
rabbit.
What
does
that
mean?
What
do
I
need
to
do,
and
so
you
need
a
contract,
and
this
is
where
we
get
the
async
api
stuff
right.
You
need
nouns
and
verbs
on
this
on
this
api
contract.
That
makes
sense.
The
machine
needs
to
agree.
C
Outputs
need
to
verify
success
right,
and
it's
very
important
that
you
can
do
all
these
things
as
somewhere
in
your
system,
because
otherwise,
like
how
are
you
supposed
to
have
a
reliable
system
that
does
a
bank
transaction?
If
you
can't
guarantee
the
machine
side
that
you
receive
verifiable
data,
how
can
how
is
it
easy
to
build
with
a
big
team?
If
you
can't
agree
what
is
a
producer
and
what
is
consumer
as
a
friend
will
happily
tell
you
that
this
kind
of
language
is
hard
to
get
right?
C
What
is
a
server
is
even
something
hard
to
agree
at
times,
and
your
expectations
from
the
data
are
important
as
well
like
you
have
to
be
able
to
read
it.
You
know,
there's
often
a
time
criticality
to
things
and
it's
gonna
fit
like
these.
Aren't
this
isn't
kind
of
loosely
typed
stuff
at
the
end
of
the
day,
this
could
literally
be
like
a
medical
record.
You
can't
misinterpret
that
and
miss
bites
off.
It's
not
acceptable
and
many
of
these
systems,
which
is
reliable,
reliability
comes
in
in
a
big
way.
C
We
can
basically
feed
an
async
api
spec
to
a
machine.
It
will
generate
the
actual
against
the
sdk
which
it
knows
about.
It
will
generate
a
way
to
get
the
data
out
and
verify
it,
and
this
is
why
async
api
is
quite
powerful
and
why
I'm
quite
a
big
fan
of
it,
having
a
big
a
having
an
actual
async
api
as
my
day,
job,
which
is
ably
and
it's
magical
because
it
means
I
can
talk
to
other
services
as
well.
C
I
can
convert
from
one
to
one
to
one
without
ever
losing
what
the
magic
of
each
of
the
ones
are.
So
kafka
is
lovely
for
this
data.
That
needs
to
be
there
every
damn
time,
but
it's
terrible
for
trying
to
get
one
person
to
get
that
data
out
of
a
million
people,
and
it
means
I
can
do
things
like
verify.
The
data
came
off,
do
some
information
to
it
and
then
republish
that
on
someone
else
who
understands
how
to
get
it
again
with
the
same
schema
with
the
same
data
layout
and
with
the
same
guarantees.
C
C
Why
now
thing
is
devices
are
everywhere
like
the
growth
of
internet
usage
is
kind
of
insane
in
2019
it
was
51
of
the
world's
population,
and
now
it's
about
61
right
and,
if
you
think
about
what
that
is
in
in
population
terms,
it's
about
700
million
new
internet
users
right
and
there
are
more
data,
there's
more
data.
Now
there
are
more
spikes
in
data
because
there's
one
thing:
people
like
doing
it's
the
same
thing
as
the
person
standing
next
to
them
right.
So
now
you
have
bigger
spikes
in
usage.
C
You
have
bigger
spikes
in
data
and
much
higher
expectancy
because
of
the
fact
that
everything
has
gotten
faster
now,
there's
nothing
worse
than
user
experience
than
loading
bars
and
or
just
waiting
for
stuff
to
happen
for
no
good
reason,
we've
gotten
pretty
good
with
asynchronous
uis,
but
as
data
becomes
the
key
commodity.
Here,
it's
really
worrying
when
you
press
go
on
a
transaction
payment
and
there's
no
return
to
know
that
the
data
even
got
to
the
bank
and
there's
no
way
to
know
it's
being
processed
or
what's
actually
going
on,
because
it's
a
synchronous
request.
C
If
I
missed
one
just
do
that,
one
again,
don't
do
the
whole
thing
again
right,
don't
block
on
the
one
somewhere
in
the
middle,
and
the
problem
here
is
that,
like
particularly
as
things
become
more
connected,
things
become
faster
and
the
change
in
tech
comes.
Faster.
Loyalty
requires
reliability
and
it
requires
an
experience
that
matters.
C
So
you
can't
really
mess
around
anymore
here,
like
in
the
early
days
of
the
web.
You
could
do
almost
anything
and
people
just
go
yeah,
it's
new
and
these
days
it's
a
commodity
like
commodities
can't
fail.
It's
not
allowed
it's
a
building
block
of
people's
lives
like
I
don't
really
carry
cash.
I
barely
carry
a
card.
I
literally
use
my
phone
for
everything.
C
So
if
that
stops
working,
I'm
in
a
bad
situation-
and
this
is
way
of
less
room
for
failure
and
I've
sort
of
already
talked
about
this,
but
people
hate
waiting,
they
really
do
so.
You
can't
really
rely
on
a
synchro's
communication
anymore.
So
the
next
question
is
what
next,
what
is
the
future
here
now?
C
The
thing
is,
like
everyone
is
saying
you
know,
5g
lower
latency
up
bandwidth
than
the
rest
of
it,
and
you
know
for
things
like
self-driving
cars
and
bigger
connected
devices
dry,
all
this
extra
stuff.
You
think,
what's
going
to
change
what
thing
and
it's
all
the
same
right
all
you've
achieved
is
fatter
shorter
pipes,
which
means
you
still
need
to
have
asynchronous
communication.
Otherwise
it
still
is
a
bad
situation.
C
It
doesn't
matter
because
the
server
you're
working
on
it
has
a
life
span
of
five
years
and
its
disk
write.
Speed,
hasn't
changed
so
uploading
a
file
might
take
a
little
less
time,
but
you're
still
gonna
run
into
some
walls
and
as
expectations
rise,
so
does
performance.
So
it
still
matters
to
decouple
things.
It
still
really
matters
to
make
things
asynchronous
and
though
this
is
a
bit
facetious,
we
can
do
it
better.
C
Very
few
people
speak
websocket,
even
fewest
became
qtt
and
no
one
speaks
kafka
except
internally.
So
suddenly
it's
like
how
do
I
make
it
that
everything
like
this
could
talk
because
right
we're
building
an
internet
of
everything.
It's
not.
Instead
of
things,
it's
an
internet
of
everything
and
at
a
certain
point
90
something
of
it
will
need
to
be
asynchronous
because
we
are
not
we're
not
programmed
to
as
humans
wait
very
well.
We
just
want
stuff
to
happen,
and
that
means
you
don't
know
when
a
connection
is
an
account.
A
Hey
ben
awesome
presentation.
Thank
you
so
much
yeah
really
great
overview
of
like
the
end
business
benefits
of
the
whole
asynchronous
trend.
I
mean
I'm
really
glad
you're
talking
about
like
increasing
end
user
experiences
and
just
like
the
rising
tide.
Behind
that
I
mean
I
recently
covered
a
report
saying
about
85
percent
of
people
say.
Applications
and
digital
services
are
now
like
intrinsic
to
their
daily
lives,
and
most
of
them
are
just
going
to
throw
an
app
away.
If,
if
it's
not
performing
correctly,
I
mean
the
whole
like
site.
A
Reliability,
engineering
role
has
gotten
so
much
interest.
Lately,
you
know
so
like
ensuring
awesome
integrations
is
just
part
of
that.
It
seems
yeah
thanks
for
like
having
a
great
overview
of
all
the
protocols
too.
I
think
that's
something
that
I
want
to
dig
into
more
with
nordic
apis
and
kind
of
the
need
for
a
common
specification.
A
I'm
curious,
though
you
say
like
one
of
the
best
benefit
of
using
something
like
async
api
is
because
it's
magical
you
know,
like
you
said
you
can
have
these
different
services
talking
to
one
another.
How
common
is
it
to
have
so
many
different
competing
protocols
like
within
the
same
project
I
mean?
Is
that,
like
a
a
common
scenario,.
C
I
wish
it
was
less
common.
I
wish
it
was
less
common,
so
I'll
answer
a
bit
first
because,
like
let's
so
so
classically
like
service,
we
provide
can
be
spoken
to
as
rest
as
our
websocket
protocol,
which
is
custom
just
because
you
can
talk
to
as
a
websocket.
It's
difficult
as
fran
will
tell
you
for
no
good
reason.
C
You
can
also
speak
mqtt,
ssc
and
a
few
others
and
like
that's
a
lot
of
different
things
for
just
the
single
service,
but
we're
spoken
to
as
if
we
are
kafka
as
if
we
are
a
mqp
and
a
few
others
as
well.
So
suddenly
it's
like
as
one
service
I
have
12
protocols.
I
think
at
last
count
and
my
customers
nearly
always
have
the
same
number
but
they're
all
different
again.
B
B
B
A
Dang
I've
heard
on
on
this
call
alone.
You
know
some
specific
areas
where
we're
seeing
a
lot
of
this
async.
You
know
development,
like
I
think
both
of
you
mentioned
financial
services,
banking,
health
care,
geolocation
iot
are:
do
you
see
these
as
like
common
kind
of
the
the
common
areas
where
you're
seeing
a
lot
of
this
being
applied?
Or
would
you
identify
some,
like
other
other
use
cases
as
well.
C
I
think
so
I
think
what
you've
described
is
where
it
really
is
started
and
exploded,
but
it's
sort
of
spreading
outwards
and
it's
like
you
know,
because,
like
inevitably
where
the
money
is
or
where
criticality
is,
is
when
it's
going
to
really
fight.
So
financial
services
is
the
obvious
one
and
then
healthcare
on
the
other
side.
But
as
soon
as
you
know,
once
the
tech
is
commonplace,
every
single
consumer
app
is
like.
If
I
be
20
faster,
my
app
store
rating
goes
up
and
you
know
that's
all.
C
B
B
C
A
C
A
Cool
yeah,
okay,
so
something
that
ben
mentioned
and
I
feel
like
it
relates
to
what
fran
saying
pretty.
Well,
you
know
it's
like
you're
trying
to
dig
into
the
actual
implementation
behind
iot
devices,
but
you're
finding
like
there's
a
lot
of
proprietary
stuff
here,
and
you
know
it's
it's
hard
to
know
what
actually
is
being
used
under
the
hood
so
like,
but
france
saying
you
know,
we
need
to
increase
interoperability,
have
the
specs
working
together
a
little
bit
more.
A
B
B
A
B
B
Not
a
technical
difficulty
or
anything,
it's
not
a
challenge
for
in
the
technical
side,
it's
more
about
people
you
know
and
when
you
have
to
deal
with
different
interests,
egos
business
interest.
Things
like
this
you
have
to
when
you
have
to
fight
against
this.
You
probably
are
gonna
fail
miserably
because
yeah,
if
you
have
a,
if
you
want
everything
to
align,
let's
say
and
come
up
and
work
in
the
same
direction.
The
very
moment
you
have
just
one
of
them
not
wanting
to
go
in
the
same
direction.
B
It's
gonna
fail.
So
so
yeah,
it's
hard.
It's
it's
hard
because
of
people
not
because
of
technology,
so
so
yeah
and-
and
we
see,
for
instance,
also
business
interest
being
part
of
it
like,
for
instance,
graphql
is
part
of
facebook
or
is
or
started
as
facebook,
at
least,
and
that
grpc
is
on
by
google.
So
I
mean
I'm
not
saying
that
they
are
not
in
the
mood
to
align
the
let's
say
the
direction
with
the
rest
of
the
specs.
B
B
C
So
you
look
at
the
open
firmware
movement.
It's
kind
of
I
see
a
lot
of
mirrors
here
because,
like
you
know
like
intel
and
such
don't
often
want
to
publish
what
their
firmware
is
doing
for
all
kinds
of
both
good
and
strange,
we'll
say
reasons
and
like
eventually
it
becomes
a
point
where
either
it's
in
their
commercial
interest
to
share
it,
because
they're
going
to
lose
out
on
a
big
opportunity,
which
is,
I
think,
what's
going
to
happen
and
it'll
become
open
because
it'll
be
a
commercial
risk
not
to
be
open
right
versus.
A
A
Yeah
I
I
kind
of
okay.
When
I
first
started,
you
know
getting
interested
in
apis.
I
did
notice
like
a
little
bit
more
open
developer
programs
around
hardware
stuff
like
iot,
and
you
know
smart
home,
smart
city
devices-
I
I
I
don't
know
if
it's
just
me,
but
I've
seen
like
a
little
less
excitement
around
that
is.
Has
it
become
more
proprietary
or
does
that
stuff,
like
still
exist,
you
know,
is.
C
C
It
was
like
the
internet
of
thing,
it
was
on
the
rise
again.
It
was
the
internet
connected
toaster
joke
was
the
one
that
kept
coming
round
and
round
and
round
the
toaster
on
the
internet.
Yes-
and
I
remember
the
partner
in
charge
of
the
project
was
saying-
I
did
that
in
the
90s.
It
was
a
good
joke
then
as
well.
C
C
A
A
C
Okay,
so
from
my
perspective,
it
doesn't
need
to
right,
like
they
both
have
a
domain
specific
use
case
and,
quite
honestly,
open
a
like
trying
to
get
an
organization
to
adopt
open
api
alone
is
a
challenge
right.
Getting
to
do
it
right
is
another
challenge
and
on
most
cases
your
the
asynchronous
part
of
your
api
does
not.
C
But
there's
need
to
alignment
because,
to
be
honest,
the
close
to
their
aligned,
but
subtly
different,
even
if
it's
just
name
alone,
is
the
best
answer.
But,
and
it
also
means
we
can
maintain
tools
more
easily.
The
tooling
alone
is
what
makes
these
specs
worthwhile
right.
Having
a
specification
that
people
have
to
follow
manually
is
rubbish
right,
like
they're
there
to
stop
people
making
mistakes,
not
to
add
another
vector
for
mistakes
to
be
made
like.
C
I
don't
need
more,
and
it
just
means
that
like
just
because
I
have
just
because
I
want
to
have
two
different,
because
we
have
two
different
specs
having
them
on
the
same
page
doesn't
mean
anything
and
like
having
them
on
the
same.
Tooling
is
actually
worse,
because
now
that
tooling
cycle
is
even
slower,
and
now
I
need
more
people
to
maintain
it.
B
A
B
Api
key,
which
is
different
than
api
key
and
all
those
two
common
flows
right,
open
id
and
sizzle.
So
http
authentication
here
you
have,
you
have
different
approaches.
Actually,
no
yeah!
That's!
No!
That's!
That's!
Okay!
It's
not
http
api
authentication,
it's
all
all
too!
So
it's
here.
So
there
are,
as
you
can
see,
there
are
many
why,
because
to
send
a
message
to
a
broker
or
to
receive
or
to
connect
to
a
broker.
B
The
the
broker
itself
might
be
exposing
an
http
interface
that
then
it
will
upgrade
to
something
different
or
that
will
give
you
a
temporary
password
to
access
via
user
password
to
their
router
to
their
broker.
So
there
are.
There
are
many.
Let
me
just
share
this
here
with
you,
so
you
all
can
have
it.
So
this
is
the
link
that
I
was
sharing
so.
A
C
It's
kind
of
fascinating,
because
the
problem
of
all
the
things
we're
actually
defining
kind
of
usage
of
is
they
all
have
their
own
security
measures
and
access
control
lists
and
all
the
rest
of
it,
and
like
the
fact
that
the
the
kind
of
the
key
thing
in
acbi
is
flexibility.
All
right.
We've
accepted
the
fact
that
we're
talking
synchronously
we've
accepted
the
fact
that
the
schema
could
be
quite
different
and
we
can
link
to
other
types
of
schema,
which
is
possibly
the
most
powerful
thing
it
does.
It's
not
really
about
just
being
the
spec.
C
You
use
it's
about
being
the
straight.
You
know
the
canonical
reference
where
all
the
bits
of
the
specs
live
right.
So
it
means
that,
like
for
security,
you
know
things
like
this.
Access
is
great
for,
like
tokens
we
generate
for
our
used
threshold
or
our
product.
Is
we
actually
use
the
spec
itself
because
it
defines
the
topics
and
then
you
can
simply
say
for
a
topic
subset,
which
is
defined
in
the
spec.
Generate
that
token,
with
access,
so
the
cool
thing
is
is
like.
C
A
B
Yes,
so
let
me
put
it
that
way,
so
message
brokers
usually
expose
a
single
protocol
interface.
In
most
cases
like
amqp
routing
queue,
for
instance,
expose
an
mq,
amqp
interface
and
the
amqp
authentication
is
very,
let's
say
simple:
it's
most
of
the
times
is
user
and
password.
So
because
it's
not
meant
to
be
public,
it's
meant
to
be
something
internal,
so
so
they
what
they
do
is
they
expose
the
authentication
as
user
and
password.
B
But
some
companies
are
exposing
the
broker
externally
for
users
to
connect,
and
you
can't
give
every
user,
the
user
and
password
because
then
you
will
have
problems
right
exactly
people
will
people
will
try
to
do
bad
things
on
your
broker
right
and
so
what
they
do
instead.
Is
they
give
you
an
api
key
that
they
generate
out
of
band
and
and
they
create
a
user
for
you,
so
they
create
a
user
and
the
password?
B
Is
this
api
key
or
they
simply
do
something?
Which
is
I
give
you
this
api
key,
and
this
is
your
username
and
leave
the
password
empty
right
or
leave
the
user
empty
and
put
the
api
key
as
a
password.
So
these
are
tricks
right.
This
is
these:
are
tricks
that
they're
hacks
they're
using
to
give
you
the
the
ability
to
have
api
keys
on
servers
or
brokers.
C
A
Agree
with
the
different
things
yeah
thanks
for
helping
to
clarify
that
all
right,
everybody,
I
think
we've
gone
a
little
bit
over
the
time,
so
I
think
we'll
we'll
end
it
there
thanks
fran.
Thank
you
ben
great
talks,
great
discussion
and
we'll
be
posting
the
recording
soon
yeah,
thanks
for
tuning
in
with
us,
everyone
yeah,
of
course
thanks
for
coming
in
thanks.
A
A
So
yeah
thanks
so
much
to
our
speakers
and
thanks
to
everyone
who
tuned
in,
live
and
helped
generate
some
discussion.
First
off
just
some
quick
updates
before
we
leave
here,
we
recently
put
out
a
new
ebook
api
is
a
product.
This
one
is
great
if
you
are
working
on
a
specific
api,
centric
software
as
a
service
and
trying
to
monetize
it
as
an
api
product
like
all
of
our
ebooks,
it's
completely
free
to
download
without
an
email
gate.
You
can
just
go
to
our
nordicapis.com
ebooks
page
for
to
pick
that
one
up.
A
Maybe
we
should
do
one
of
these
on
async
api
in
the
future.
If
you
want
that,
let
us
know,
maybe
we
can
do
some
collabs
there
fran
and
just
putting
it
out
there
if
you're
a
listener,
and
you
love
apis,
and
you
want
to
share
your
story
with
our
community.
Our
blog
is
always
open
for
those
sort
of
contributions,
as
long
as
they
meet
certain.
A
A
For
this
kind
of
knowledge
and
our
next
live
cast,
I'm
happy
to
announce
is
going
to
be
at
the
end
of
next
month
we're
going
to
be
investigating
the
new
intersection
between
apis
and
the
emerging
low
code
trend,
so
low
code,
no
code
saw
a
major
uptick
throughout
the
pandemic
and
we're
going
to
be
exploring
what
effect
that
shift
is
having
on
the
api
economy
and
maybe
how
to
bridge
the
pro
code.
No
code
and
divide
so
that'll
be
super
interesting.
A
We've
got
some
good
speakers
lined
up
for
that
one,
and
we
do
have
an
ongoing
call
for
speakers.
We
are
going
to
be
announcing
some
physical
events
soon,
so
that's
that's
up
and
coming
stay
tuned
for
that
and,
as
usual,
thank
you
to
our
sponsor
security.
You
can
learn
more
about
their
oauth
server
and
identity,
driven
api
security
solutions
at
curie.io.