►
Description
AsyncAPI Conference 2021 - Day 2
17th November 2021
Slides: https://dedouss.is/talks/asyncapi-conf/
Asynction: https://github.com/dedoussis/asynction
0:00 Introduction
2:17 Setting the scene
6:12 What is Socket.IO?
12:06 Modelling the Socket.IO protocol using AsyncAPI
23:20 Minimal chat application
32:50 Asynction
Socket.IO has evolved from a JavaScript library for realtime web applications to a language agnostic protocol enabling duplex, event-driven communication. In spite of its maturity and wide adoption across the industry, the Socket.IO ecosystem is still lacking support for documenting APIs in a standardised manner. The rise of the AsyncAPI specification presents itself as a great opportunity to finally tackle this problem. In this talk, Dimitrios is going to showcase how the Socket.IO protocol can be modelled through AsyncAPI, followed by a step-by-step tutorial involving the creation of a specification YAML file, given an existing Socket.IO API. The final part of this talk will be dedicated to Asynction, a Socket.IO micro-framework written in Python, that is entirely driven by the AsyncAPI specification. Even though this presentation focuses on Socket.IO, it serves as an example of how one could express any event-driven protocol using AsyncAPI.
A
So
this
is
going
to
be
one
of
the
long
sessions
of
this
conference,
so
I
think
it
would
be
wise
to
briefly
outline
some
agenda.
First,
I'm
going
to
start
with
quickly
introducing
myself
and
then
telling
a
story
from
real
life,
on
how
I
discovered
the
sync
api
and
how
I
got
motivated
to
combine
it
with
socket
io.
Then
I'm
going
to
talk
about
what
socket
io
actually
is
and
how
we
can
model
this
protocol
using
the
async
api
specification
towards
the
latter
stages
of
the
talk.
A
Finally,
we're
going
to
talk
about
a
section,
a
framework
combining
both
socket
io
and
the
sync
api,
and
hopefully
we're
going
to
get
some
time
for
q
a
towards
the
end
of
the
session.
I'm
now
going
to
share
a
link
at
the
slides
in
the
chat
so
that
you
can
navigate
through
the
content
at
your
own
convenience.
A
A
We,
our
mission,
is
to
deliver
an
affordable
and
accessible
healthcare
service
to
the
hands
of
every
human
on
earth.
I
am
a
senior
software
engineer
in
the
ai
chatbot
team
of
babylon
and
throughout
my
career,
I've
been
building
distributed
systems
and
cloud
native
workloads,
mainly
in
python
and
in
node.js.
A
I
do
have
a
passion
for
open
source
and
big
data
applications.
If
you're
interested
in
what
I'm
working
on
my
free
time,
you
can
check
my
github
profile
and
my
twitter
account
using
cataduces
handler.
I've
also
recently
started
blogging
in
my
personal
website,
and
this
blog
includes
articles
about
this
exact
topic
of
async
api
and
socket
io.
So
if
you're
interested
about
them,
you
can
certainly
check
this
out.
A
I'm
also
the
author
and
the
maintainer
of
ascension,
which
is
a
socket
io
python
framework
driven
by
the
async
api
specification.
We're
going
to
talk
about
the
sanction
in
detail
towards
the
end
of
the
talk.
So
for
now
you
can
just
start
gazip
on
github,
so
how
it
all
started.
So
my
adventures
with
sync
api
date
back
to
the
early
2021,
where
in
the
chatbot
team
of
babylon,
we
wanted
to
extend
our
chat
platform
with
human
in
the
loop
capabilities.
A
So
long
meetings
would
soon
follow
about
the
design,
so
whether
we
should
pick
a
framework
x
or
framework
y
or
whether
we
should
go
serverless
or
not,
eventually,
the
the
stack
of
the
team,
which
is
a
python
flask
and
kubernetes,
pointed
us
in
the
direction
of
flask
socratio,
making
socket
io
the
protocol
of
choice.
So
this
felt
a
rather
unorthodox
design
process.
A
A
A
So,
as
we
moved
onwards
towards
the
development
phase
of
this
project,
I
I
started
looking
into
how
we
can
document
our
application
before
actually
developing
it.
So
the
purpose
of
of
this
thought
was
that
we
could
share
a
contract
with
the
frontend
team
and
they
can
start
developing
their
stuff
independently
to
us.
So
I
started
looking
online
on
how
one
could
document
the
secretary
api
and,
to
my
disappointment,
I
couldn't
find
any
resource
on
the
topic.
A
I
tried
to
zoom
out
a
bit
and
started
searching
about
how
one
could
document
a
websocket
api
still
didn't
find
did
find
many
resources.
I
found
a
few
but
no
standardized
or
widely
adopted
solution,
so
it
was
at
this
point
when
I
realized
that
documented
event-driven
apis
is
treated
as
a
niche
area
of
the
industry,
which
is
kind
of
kind
of
absurd,
because
the
actual
event-driven
architectures
themselves
are
pretty
popular,
especially
throughout
the
last
decade.
A
So
this
left
me
rather
disempowering
than
rather
disappointed,
especially
because
I
come
from
a
resident
graphql
world.
So,
for
example,
in
the
rest
api
we
have
the
open
api
initiative
as
the
de
facto
standard
and
also
in
the
graphql
or
grpc
protocols.
Everything
is
strictly
typed
and
contract
driven.
So
it
feels
that
this
kind
of
apis
have
managed
to
solve
this
problem
for
quite
some
time
now
and
that
the
event
driven
apis
have
lagged
a
bit
behind.
A
So
I
skimmed
through
the
sync
api
specification,
and
I
figured
out
that
this
is
a
tool
that
I
could
use
for
my
own
problem
to
document
the
socket
io
api.
So
I
started
looking
into
how
one
can
document
the
circuit
io
api,
using
the
single
api
specification,
the
only
single
research
I
managed
to
find
online
was
this
stack
overflow
question,
which
is
a
very
old
one
and
also
an
arcade
one.
So
in
the
title
it
says,
recommendation
on
how
document
websocket
api
is,
but
the
actual
content
of
the
question
is
about
socket
io
apis.
A
So
this
question
has
had
only
a
single
answer,
suggesting
the
use
of
sync
api
version,
one
and
also
suggesting
it
to
use
in
a
not
very
correct
manner.
So
at
that
point
I
realized
that
no
one
has
really
attempted
to
document
the
social
api
with
async
api,
so
I
decided
to
take
on
this
challenge
and
if
successful,
write
a
blog
post
about
it
or
give
a
talk
about
it.
So
here
we
are.
A
Many
would
argue
that
socket
io
is
a
javascript
library
for
real-time
web
applications,
and
I
wouldn't
blame
them,
because
this
is
what
the
wikipedia
article
actually
states.
However,
I
do
regard
this
as
an
outdated
definition.
I
see
socket
io
as
a
protocol
of
its
own
with
a
javascript
library
just
being
the
reference
implementation.
A
It
is
a
protocol
enabling
event-driven
communication.
It
is
a
protocol
enabling
low
latency
duplex
communication,
and
it
is
a
protocol
supported
by
the
underlying
mechanisms
of
websockets
and
http
long
polling
to
reinforce
the
fact
that
socket
io
is
a
protocol.
There
is
an
official
specific
protocol
specification
sitting
under
this
repository
in
github,
and
also
this
protocol
is
implemented
in
various
other
languages
other
than
javascript,
for
example,
java,
python
c,
plus,
plus
and
trust
and
many
others.
A
So
one
would
ask
why
use
socket
io
instead
of
vanilla,
websockets-
and
there
are
plenty
of
reasons
for
that
secretary-
is
more
reliable
than
web
sockets
and
the
reason
for
that
is
that
whenever
socket
websocket
connectivity
cannot
be
achieved
because
of
an
old
browser
version
of
because
there
is
a
reverse
proxion
or
a
firewall
between
the
client
and
the
server.
Then
socket
io
falls
back
to
http
loan
polling.
A
So
the
caveat
is
that
a
socket,
io,
user,
client
or
server
should
never
interact
with
the
protocol
directly
and
they
should
never
interact
with
the
actual.
They
should
never
care
whether
it
is
web,
sockets
or
http
polling
under
the
hood.
The
user
of
circuitrio
should
only
interact
with
the
socket
class
api
of
the
respective
implementation
library.
This
socket
class
api
implements
the
following,
symmetrical
interface
that
you
see
here,
and
I
describe
it
as
symmetrical
because
it
is
the
same.
Api
is
implemented
by
both
the
server
circuit
class
and
the
client
circuit
class.
A
A
So
again,
the
on
function
of
the
socket
class
api
registers,
a
new
handler
for
a
given
event.
It
implements
a
subscribing
operation
and
the
callback
could
potentially
return
a
value
that
will
be
sent
to
the
center
party
as
an
acknowledgement.
Implementing
this
acknowledgment
feature
that
we
already
mentioned
the
emit
function
of
the
socket
class
api
emits
an
event
to
the
receiver
party,
implements
a
publishing
operation
and
if
an
acknowledgement
is
returned
by
the
receiver,
then
the
acknowledge
acknowledgement.
Callback
that
you
see
here,
as
the
third
argument
of
the
function
is
invoked
with
that.
A
With
that
data,
a
more
advanced
concept
of
soccer,
I
o
is
the
namespace
which
essentially,
it
enables
multiplexing
capabilities.
A
namespace
has
its
own
event,
handlers
and
potentially
its
own
dedicated
connection
by
default.
Socket
io
uses
this
single
character,
slash
and
namespace,
but
it
is
possible
for
a
circuit
io
server
to
support
to
set
up
multiple
namespaces
and
also
to
a
societal
client
to
connect
to
multiple
same
namespaces
simultaneously.
A
So
at
this
point,
where
we
have
only
covered
the
very
basics
of
socket
io,
one
would
dance
one
would
ask.
Why
would
we
want
to
document
such
an
api?
And
I
think
the
answer
to
that
is
pretty
clear
even
by
that,
even
by
now.
So
here
we
have
a
very
simple,
socket
io
server,
which,
in
the
connection
handler,
we
can
see
that
the
server
emits
a
few
events
and
also
listens
to
some
other
events.
A
So
on
line
four
and
line
five,
we
have
the
server
emitting
the
hello
event
and
on
line
five,
we
have
the
server
and
meeting
the
great
experience,
which
is
also
accompanied
by
some
arguments.
The
first
argument
here
is
just
a
string
and
the
second
argument
is
an
object
which
could
be
a
structured
object
or
it
could
be
like
a
free
dictionary
and
then
on
line
7
9
11
respectively.
A
We
have
the
server
listening
to
the
message
event,
which
expects
some
data
as
well,
and
the
server
listening
on
the
salutation
events,
which
accept
expects
an
array,
a
tuple
of
three
elements
of
data.
So
imagine
the
client
of
this
circuit
io
server
being
developed
by
a
completely
separate
organization.
A
We
would
need
the
backend
team
to
communicate
with
a
frontend
team
and
let
them
know
about
what
events
does
the
server
supports?
What
the
server?
What
events
does
the
server
listen
to?
So
I
wouldn't
want
to
live
in
a
world
where
the
answer
is
to
all
these
questions
would
be
agreed
verbally
through
some
zoom
meeting.
A
A
So
I
started
with
the
root
document:
object
the
sync
api
object,
which
has
four
fields
that
are
of
interest
to
us,
a
sync
api,
which
is
the
pinning
of
the
spec
version,
that's
being
used.
We
have
channels
which
are
all
the
available
channels
and
messages
for
the
api.
We
have
servers
which
provides
connection
details
for
all
the
server
instances
of
verification,
and
we
have
components
which
is
essentially
a
library
of
reusable
elements
that
we
can
reference
across
our
spec
file.
A
So
going
one
layer
deeper,
we
can
see
the
channels
object,
which
is
a
mapping
of
channel
names
to
channel
item
object.
The
specification
states
that
the
channel
is
an
addressable
components
where
messages
or
events
flow
through
it
enables
an
application
to
separate
its
concerns.
To
me,
this
sounds
very
much
like
a
socket
ion
name
space.
So
there
we
have
our
first
relationship
between
a
sync
api
and
socket
io,
which
is
a
secretary
of
name.
Phrase
is
essentially
a
single
api
channel
going
one
another
layer
deeper.
A
We
have
the
channel
item
object,
which
is
essentially
the
values
within
the
channels.
Mapping.
The
channel
item
object
describes
the
definition
of
a
societal
name
space
in
socket
io,
a
connection
can
be
established
in
the
namespace
level,
so
the
channel
item
object
is
the
only
place
in
the
specification
where
we
can
define
bindings
and
bindings
are
essentially
protocol.
Specific
information
for
the
server
in
the
case
of
socket
io,
the
bindings
describe
the
handset
context
on
the
connection
request.
A
So
in
this
case
we
have
a
websocket
binding
defined
for
the
default
channel
for
the
main
channel,
where
it
specifies
a
schema
for
the
query
params.
This
means
that
whenever
a
client
wants
to
connect
to
them
that
main
that
main
namespace,
they
need
to
provide
this
token
property
as
part
of
the
query,
param
object
and
this
token
property
should
be
of
type
string,
and
this
is
how
it
actually
happens
on
the
following
implementation.
Snippet
below,
where
the
socket
io
client
establishes
a
connection.
Passing
this
query.
A
Param
there
are
a
few
conventions
with
regards
to
bindings,
which
I
mainly
came
up
with
one
is
that
one
we
can
include
bindings
under
the
main
namespaces
under
the
main
namespace,
but
also
we
can
omit
them
under
the
custom
ones.
This
makes
the
assumption
that
the
custom
namespace
namespaces
will
inherit
the
bindings
of
the
main
namespace.
A
However,
if
a
custom
namespace
includes
bindings,
then
the
client
should
always
force
a
new
connection
upon
connecting
to
it.
By
default,
a
secretary
of
clients
will
use
use
the
same
connection
when
connecting
to
multiple
different
namespaces
and
finally,
the
websocket
channel
bindings
is
the
only
possible
binding
that
can
be
included
in
socket
io
api,
and
one
would
argue
that
we
could
also
use
an
hdb
binding
as
well
since
circuit
ion
can
also
be
implemented
with
http
long
polling.
However,
this
is
not
possible
for
a
couple
of
reasons.
A
First,
is
that
the
sync
api
specification
does
not
allow
http
bindings
on
the
channel
item
object
level,
and,
secondly,
is
that
in
socratio
the
http
polling
implementation
is
done
in
such
a
way
to
resemble
the
websocket
implementation.
So
essentially,
the
http
polling
is
assumed
the
websocket
and
both
of
the
implementation
use
the
exact
same
handshake
object.
So
it
is
safe
to
assume
that
the
hdp
long
polling,
obj
bindings,
would
be
exactly
would
look
exactly
similar
as
the
websocket
ones.
A
I
have
created
a
github
issue
in
the
bindings
repository
refreshing
api
to
pitch
this
proposal,
so
moving
another
layer
deeper
next
to
the
bindings
field.
In
the
channel
item
object,
we
have
operations
which
document
how
and
why
messages
are
sent
or
received.
We
have
the
publish
operation
which
is
implemented
using
a
socket.emit
call
on
the
client
side,
and
we
have
a
subscribe
operation
which
is
implemented
using
a
socket.on
call
on
the
on
the
client
side,
where
the
client
register
registers
a
callback
for
an
event
to
subscribe
to.
A
So
there
we
have
an
extra
two
relationships
between
async,
api
and
second
io.
So
we
see
that
under
each
operation
either
publish
or
subscribe
one.
There
is
a
message
field
which
defines
a
message
object,
and
this
is
actually
defining
a
socket
io
event
that
can
be
published
or
that
can
be
subscribed
to
under
a
given
namespace.
A
In
this
case
here
in
line
five,
we
have
an
event
with
hello
being
the
event
name
and
payload
being
the
structure
of
data
that
can
be
emitted
as
part
you
know
as
part
of
the
mitification
from
the
client.
So
this
tell
the
client
that,
under
the
main
namespace,
they
can
emit
the
hello
event
name
using
an
object
that
has
fu
a
full
field
which
is
of
type
string.
A
We
have
seen,
however,
in
in
this
current
setup,
we
only
see
that
only
one
message
for
publish
and
one
message
for
subscribe
can
be
listed
under
a
single
name
space.
However,
in
practice
we
have
seen
that
a
namespace
can
support
multiple
different,
subscribing
or
publishing
messages.
So
the
way
you
can
achieve
that
with
a
sync
api
is
by
using
this
one-off
array
structure
under
the
message
field
of
the
of
its
operation.
A
So
we've
also
mentioned
that
socket
io
provides
acknowledgement,
functionalities
before
diving
deeper
into
how
this
is
achieved
in
the
in
the
circuit
io
protocol,
let's
first
to
get
some
basic
understanding
of
the
protocol
itself.
So
the
basic
unit
of
information
in
the
secondary
protocol
is
a
packet
and
there
are
seven
stick
packet
types
as
you
can
see.
In
the
left
hand,
side
secretary
of
sender
invokes
the
socket.emit
call
in
order
to
send
an
event
to
the
receiver
and
the
event
is
compared
to
the
receiver
using
the
event
or
binary
event
package.
A
Then
the
receiver
acts
on
upon
these
events,
using
the
handler
that
is
registered
using
the
socket.on
invocation,
the
handler
may,
after
it
executes,
may
return
or
not
return
an
acknowledgement
back
to
the
sender.
The
acknowledgement
is
sent
back
to
the
server
using
the
ack
or
binary
act
packet
types.
A
In
order
to
express
these
acknowledgement
semantics,
we
have
to
extend
the
async
api
specification
and
the
async
api
provides
a
good
framework
of
doing
that.
So
what
I
propose
here
is
extending
the
message:
object
to
include
a
next
arc
field,
and
the
value
of
this
field
should
be
a
message
object
that
we
are
going
to
cover
in
a
bit.
A
Also,
the
components
object
may
include
the
x
messages
field
where
one
could
list
multiple
messenger
objects
that
can
be
used
throughout
the
specification
file,
and
this
is
how
the
mess
attack
object
would
look
like.
There
is
going
to
be
an
object
of
a
single
field
which
is
going
to
be
called
args.
The
type
of
this
field
would
be
a
schema
object,
and
this
would
be
the
schema
of
the
arguments
that
are
passed
as
input
to
the
acknowledgement
callback
function,
and
this
is
how
it
would
look
in
practice.
A
So,
for
example,
let's
take
this
socket.emit
invocation,
which
is
documented
as
a
publishing
operation
under
the
main
namespace.
So
this
this
operation,
this
invocation
is
described
using
this
hello
event,
which
has
an
event
name,
which
is
hello
and
then
a
payload
which
describes
the
schema
of
the
arguments
and
then
x-act
defines
the
schema
of
the
input
that
is
to
be
passed
in
this
acknowledgement,
callback
method
and
similarly
for
the
socket
on
invocation
for
the
subscribing
messages,
the
x-args
schema,
who
defines
the
acknowledgement
type
that
the
event
callback
should
return
after
it
executes.
A
So,
let's
move
on
to
the
final
object,
which
is
servers,
which
is
a
top
level
object,
and
this,
as
we
said,
defines
all
the
server
instances
of
our
application.
Each
server
instances
is
required
to
have
a
url
field
as
well
as
a
protocol
field
from
the
url
field.
We
cannot.
We
can
not
only
extract
the
host
of
a
circuit
io
server,
but
we
could
also
get
the
path
to
our
secondary
server,
which
the
client
can
pass
when
they
instantiate
a
connection
to
that
server.
A
Also,
there
is
a
protocol
field
within
the
server
definition
which
could
be
either
of
websockets,
secure
web
sockets,
http
and
https.
It
doesn't
really
matter
if
it
is
websocket
or
http,
but
it
only
matters
if
there
is
a
secure
character
as
a
suffix
to
that
protocol.
So
the
protocol
essentially
signals
the
inclusion
or
absence
in
tls
for
the
server,
so
we
made
it
to
the
end
of
this
long
modeling
exercises
here
is
a
summary,
so
we
managed
to
establish
a
lot
of
relationships
between
socket
io
and
the
sync
api.
A
A
A
socket.emit
invocation
is
a
publish
operation
of
a
channel
item
object,
while
a
socket.on
invocation
on
the
client
side
is
a
subscribe
operation
within
the
channel
item
object.
A
circuit,
io
event
is
essentially
an
async
api
message
and
an
event
name
is
the
name
field
of
the
message
of
the
message:
object
the
arguments,
the
event
arguments
are
described
by
the
payload
of
the
message:
object,
which
is
a
json
schema
and
the
acknowledgements
can
be
achieved
using
the
x-act
specification
extension
that
we
proposed.
A
A
It
is
a
very
simple
application
where
the
user
enters
a
nickname
to
join
the
chat
and
the
rest
of
the
participants
get
notified
whenever
a
user
joins
or
whenever
a
user
types
or
stops
typing
a
message
or
whenever
a
user
someone
leaves
the
party.
I
also
put
here
the
full
implementation
of
the
socket
io
server
in
javascript.
It
is
not
a
very
complex
implementation.
It
doesn't
exceed
90
lines,
we're
not
going
to
go
through
each
of
the
lines
here
in
detail,
but
I
put
the
full
snippet
here
for
anyone
in
case.
A
They
want
to
review
it
on
their
own
time.
So,
let's
start
putting
together
on
our
sync
api
yaml
and
let's
start
with
the
simple
things.
First
like
pinning
their
sync
api
version,
the
version
of
the
specification
that
we
want
to
use,
as
well
as
putting
together
some
information
with
regards
to
a
service
like
the
title,
the
version
and
some
brief
description
of
what
it
does
also
we're
going
to
have
a
server
section
which
are
going
to
define
the
server
instances
of
our
application.
A
As
far
as
I'm
aware,
this
is
an
application
that
is
only
sitting
in
a
single
environment,
so
we're
going
to
have
just
this
demo
server
object,
which
has
a
url
as
well
as
a
protocol
field
for
the
url.
We
picked
the
actual
url
that
is
within
the
circuit,
io
website
source
code,
which
is
this
hero
co-op,
and
it
also
seems
that
they
are
using
the
default.
A
A
So
if
here,
on
the
left
hand
side,
we
have
a
simplified
version
of
the
socket
io
server
code
that
we
presented
above,
and
we
can
see
here
that
the
server
listens
for
connections
under
two
namespaces
on
line
three,
we
have
the
connection
handler
for
the
default
namespace
and
online
seven.
We
have
the
connection
handler
for
the
admin
namespace,
so
we
can
identify
that
we
have
two
channels
here:
the
single
slash
default
channel
and
the
slash
admin
channel.
A
If
we
expand
the
connection
handler
of
the
default
channel
of
the
of
the
main
namespace,
we
can
see
that
there
are
multiple
socket.on
invocations.
These
are
essentially
the
events,
the
secretary
events,
that
the
server
listens
for
from
the
client.
So
we
have
a
new
message
event
that
is
accompanied
with
some
data
arguments
on
line
five
on
line
12.
We
have
another
add
user
event
which
has
a
username
argument,
and
we
also
have
the
typing
and
stop
typing
messages
that
have
no
arguments
at
all.
So
no
event,
payload
is
expected
as
part
of
this
event.
A
So
these
are
the
events
that
the
circuit,
io
client,
can
publish
to
the
server
under
this
namespace.
So
essentially,
this
compose
all
the
message
of
the
objects
that
we
can
put
under
the
publish
operation
in
our
sync
api
schema
for
that
name
space.
Similarly,
we
can
also
enumerate
all
the
socket.emit
invocations
we
can
see
with
our
namespace
implementation.
So
on
line
six,
we
have
an
admission
to
the
new
message
of
a
new
message.
Event
and
line
13
will
have
an
admission
of
the
user
joint
event
and
so
on
and
so
forth.
A
So
these
events
are
the
events
that
the
client
can
subscribe
to
and
listen
from
the
server.
So
essentially,
these
are
message:
objects
that
populate
the
publish
operation
of
the
default
namespace
of
the
default
channel
of
aspect.
So
if
we
put
this
together
in
our
yaml,
we
see
that
we
have
our
main
namespace,
which
has
a
publish
operation
and
a
subscriber
creation
and
under
each
under
the
message
field
of
each
operation.
A
Now,
let's
expand
the
connection
handler
of
the
admin
namespace.
We
can
see
here
that
the
handshake
context
of
the
socket
is
being
used.
This
means
that,
upon
connection
the
handset
context
of
the
request
is
being
used
to
extract
some
information.
In
this
case,
a
token
is
extracted
from
the
query,
parameter
object
of
the
request
and
some
validation
is
applied.
On
top
of
that
token,
these
signals
us
that
we
should
include
some
bindings
as
part
of
the
channel
definition.
A
So
in
this
case
we
have
the
websocket
bindings
for
the
admin
namespace
that
put
together
a
schema,
adjacent
schema
for
our
query.
Parameters,
object,
and
this
schema
has
a
token
property
which
is
of
type
string,
and
it
is
always
required.
So
if
the
token
parameter
val,
if
the
token
query
parameter,
fails
the
socket
disconnects
otherwise
the
socket
emits
an
event
to
the
client,
which
is
a
server
metric,
and
if
you
see
actually,
if
you
were
not
paying
attention,
this
server
metric
event
is
also
listed
under
the
subscribe
operation
of
the
admin
channel.
A
So
let's
now
move
into
how
we
can
populate
our
message:
definitions
within
a
component
section
of
our
schema,
and
for
that
we
can
expand
the
add
user
event
handler
of
the
default
namespace.
This
event
handler
is
being
invoked
whenever
a
user
is
joined,
the
chat
application.
So
you
see
here
if
the
user
is
already
added
sorry,
so
you
see
here
that
the
inputs
of
our
event
handler
is
a
username
string
and
an
acknowledgement
callback
function.
A
So
if
the
user
is
not
added,
then
we
increment
the
number
of
users
and
then
we
broadcast
we
emit
an
event
to
the
rest
of
the
clients
that
are
connected
to
that
namespace,
that
a
new
user
joined
and
this
event
has
this
particular
argument:
structure
of
a
username
and
number
of
users.
If
we
are
in
the
happy
path
scenario,
of
course,
of
not
having
the
user
already
added,
then
we
acknowledge
that
the
user
was
added
and
the
error
of
that
acknowledgement
is
of
no
type.
A
So
we
can
see
here
that
we
have,
we
can
define,
we
can
populate
two
event,
two
message:
definitions.
One
is
the
add
user
message
which,
as
you
can
see
here
on
the
second
line,
it
is
the
method
that
the
server
listens
for.
So
it's
a
message
listed
under
a
subscribe
operation,
so
it
has
a
not
space
user
event,
name
and
a
payload
of
type
string.
Since
the
username
is
the
only
argument
of
that
event,
we
also
see
that
we
think
that
event
handler.
A
Then
an
acknowledgement
can
be
returned,
and
this
acknowledgement
has
this
following
structure.
It
is
an
object
containing
an
error
field
which
could
be
either
string
or
null.
So
we
can
add
this
x-act
field
that
we
proposed
as
part
of
a
specification
extension
and
this
args
object
can
describe
the
the
properties
of
the
acknowledgements,
for
example,
the
error
property
that
we
either
string
or
not.
Similarly,
we
see
that
the
new
alatan
event
is
being
emitted
to
all
other
clients
that
the
user
has
joined
our
chat.
A
So
now
I
think
we
can
put
together
everything
into
a
single
specification
file,
so
we
see
here
we
start
with
traditionally
with
a
version
of
our
specification.
Then
we
have
the
info
infoint
service
object,
and
then
we
have
all
the
channel
definition,
which
is
the
the
main
channel
and
the
admin
channel
and
within
its
channel
we
have
all
the
messages
under
the
publish
and
the
subscribe
operations
respectively.
A
Another
benefit
that
we
get
for
free
by
documenting
our
secretary
apis
is
the
sync
api
playground
visualization,
which
is
a
tool
that
receives
an
async
api
specification
as
an
input
and
produces
a
beautiful
visualization
of
our
api
as
an
output.
So
here
we
can
see
all
our
operations
of
our
api.
We
can
see
all
our
different
messages.
A
A
A
A
It
empowers
a
specification
first
approach
when
building
socket
io
apis
in
python,
and
it
actually
guarantees
that
your
api
will
work
in
accordance
with
its
documentation.
So
what
does
sanction
offer?
In
particular,
it
automatically
registers
all
event
and
terror
handlers
that
are
referenced
within
the
sync
api
specification.
A
It
provides
out
of
the
box
validation
on
every
socket,
io
interaction.
This
means
every
incoming
or
outgoing,
socket
io
event,
and
this
validation
is
fueled
by
the
json
schemata
within
the
message
payloads
within
the
channel
bindings
and
even
within
the
x-act
arguments,
objects
that
we
previously
mentioned.
A
It
also
generates
html
rendered
documentation
similar
to
the
async
api
playground
and
exposes
it
through
a
separate
http
endpoint.
There
is
also
mock
server
support
when
one
could
spin
up
a
fully
functional
mock
server,
just
used
by
referencing
a
local
asic
api
file
without
the
need
of
any
extra
code.
There
is
also
cli
interface
and
there
is
also
an
authentication
feature
coming
soon,
which
will
be
based
on
the
security
schemes
of
the
specification.
A
So
ascension
was
originally
inspired
by
connection
and
hence
the
naming
connection
is
a
framework,
a
python
framework
for
rest
apis
and
it
isn't
driven
by
the
open
api
specification
on
the
left
hand,
side
of
the
slide.
We
have
a
very
simple,
open
api
specification
of
a
hello
world
api
where
it
has
a
single
greetings,
name
resource.
As
you
can
see
here
in
this
resource,
there
is
a
path
parameter
by
called
name
and
within
that
resource
we
have
a
single
post
function.
A
This
post
endpoint
is
related
to
a
python
callable
using
this
operation
using
this
operation
id
field.
So
the
python
call
label
is
actually
a
post
quitting
function
within
the
hello.pi
module.
So,
on
the
right
hand,
side
you
can
actually
see
the
post,
the
hello.pi
module,
which
includes
the
post
reading
method
and
this
post
greeting
method
takes
a
name
as
an
input
argument,
and
this
is
the
name
which
is
the
path
parameter
that
we
see
here
in
this
api
resource.
A
This
x
handler
field
relates
this
new
message:
event
to
a
python
callable
which
sits
under
the
app.pi
module,
and
it
is
this
new
message
function
so
here
the
socket
io
client
will
emit
a
new
message
event
to
the
server
and
the
server.
We
will
look
at
this
x
handler
field
in
order
to
call
the
correct
function:
the
correct
python
callable
to
act
upon
this
event.
Of
course,
ascension
will
validate
the
input
parameters
that
this
callable
will
take,
such
as
the
message
payload,
or
it
will
also
validate
what
this
function
returns.
A
If
there
is
an
acknowledgement,
argument,
payload
that
needs
to
be
validated
so
here.
How
is
it
look
how
it
looks
on
the
python
side
again,
it
is
very
simple
to
spin
up
an
ascension,
socket,
io
server.
You
only
need
to
reference
a
local
async
api
yaml
file
and
then
run
the
section
up
like
you
run
any
other
flask
app
and,
at
the
bottom
hand
side.
You
can
see
an
example
of
a
simple
event
handler
that
can
be
referenced
within
the
sync
api
example.
A
So
you
can
find
a
fully
fledged
example
of
how
to
use
a
sanction
in
the
ascension
repo
under
the
top
level
example
directory.
This
example
also
uses
the
minimal
chat,
application
sync,
api
gamble
and
re-implements
it
in
python
using
a
section.
It
is
also
fully
documented.
So
if
you're
interested
about
ascension
and
how
you
can
use
it,
I
would
suggest
to
have
a
look
there
and
finally,
another
killer
feature
of
ascension
is
the
mock
server,
which
is
also
comparing
with
the
cli.
A
So
you
can
install
the
cli,
the
ascension
cli
from
homebrew
using
brew,
install
extinction
and
then
with
a
single
line
command.
You
can
just
reference
a
local
async
api,
yaml
file
and
spin
up
a
fully
functional,
socket
io
mock
server.
This
mock
server
will
listen
for
all
the
events
that
are
referenced
within
the
sync
api
yaml
file
and
return
acknowledgements
appropriately
based
on
the
xx
schemata.
It
will
also
periodically
publish
fake
events
that
adhere
to
the
message
payloads
for
any
clients
that
may
may
be
connected
to
that
mock
server.
A
So
we
have
reached
the
end
of
this
talk.
Thank
you
very
much
for
attending
it.
I
hope
you
enjoyed
it
and
I
hope
that
this
talk
was
not
just
purposed
for
socatio
enthusiast
and
I
hope
it
could
maybe
have
motivated
others
to
start
modeling
more
protocols
with
a
sync
api,
spec
or
even
model
protocols
that
are
used
internally
within
your
organizations.