►
Description
AsyncAPI Conference 2022 - Day 1
3rd November 2022
In AsyncAPI you can define payloads with any type of payload standard through something called schema format. This is the story of, arguably the most impactful feature in AsyncAPI, which creates ripple effects of not only problems but opportunities for tooling. Jonas will introduce the basics of payload standards such as but not limited to OpenAPI schema object, AsyncAPI schema object, JSON Schema, Avro, and JTD by digging into their use-case and limitations and what that means for tooling. It will then follow into the state of AsyncAPI tooling and how they handle and try to solve the problems at hand to create a better API toolbox for you.
A
So,
for
let's
see
if
my
clicker
works
there,
so
the
complex
keyword
schema
format.
Well,
what
is
it
in
async
API?
You
can.
Whenever
you
define
the
message
payload
of
something
you
can
you
can
customize
how
exactly
you
define
that
payload,
for
example,
by
default,
even
though
that
you
never
use
this
keyword
before
by
default,
it
will
always
be
this
async
API
schema
object
always
is,
and
that
is
just
the
default
format
that
it
that
the
specification
expects.
A
But
this
keyword
also
allows
you
to
Define
other
formats
in
order
to
use
the
one
that
fits
mostly
within
your
use
cases
and
how
your
organization
works.
So
that's
what
I'm
gonna
try
to
cover
in
this
presentation?
I'm,
gonna,
I'm
gonna,
introduce
you
to
three
different
formats
which
are
free
a
bit
similar
in
some
cases
and
very
different
than
another,
so
I'm
going
to
introduce
those
three
formats
and
then
I'm
gonna
talk
a
little
bit
about
well.
A
How
does
tooling
handle
something
like
this
where,
where
you
can
have
arbitrary
schema
formats
and
need
to
support
all
these
kind
of
things,
and
then
I'm
also
going
to
talk
a
little
bit
about
well,
what's
what
kind
of
problems
does
this
create
for
tooling,
so
by
the
end
of
the
talk?
I
hope
that
at
least
you
have
learned
these
three
schema
formats
and
a
bit
of
the
pros
and
cons
for
the
pro
for
all
of
them.
A
A
A
A
A
A
So
what
is
it
well
in
a
very,
very
basic
terms
as
I
introduced
earlier?
It's
you
validate
data.
You
create
a
type
of
constraint
on
the
data
on
the
Json
data,
for
example,
you
can
have
this
very
simple
type.
Keyword
called
Boolean
now.
Booleans
just
means
that,
well
all
of
my
input,
data
or
instance-
data,
for
example,
true
and
false-
are
validated
against
my
schema
in
this
case.
True
and
false,
both
validate
correctly
or
is
valid
against
our
schema.
A
A
A
A
A
A
Then
we
have
constant
values.
For
example,
if
you
expect
that
a
specific
Json
value
to
be
present,
you
can
Define
it
using
a
constant
keyword.
Const,
for
example,
I
expect
there
to
be
42.
That's
the
only
thing,
that's
that's
valid
as
an
input
we
can
also
say.
Well.
We
also
have
multiple
values
that
we
accept,
for
example,
42,
but
it
could
also
be
43,
for
example,
so
those
two
numbers
are
the
only
one
that's
valid
and
everything
is
everything
else
is
not.
A
Then
we
have
objects,
so
adjacent
object
is
just
just
a
basic
object
which
has
a
property,
for
example,
in
this
case,
it's
test
that
has
some
value,
also
Json
value,
of
course,
the
first
property
that
we're
going
to
look
at
is
properties.
So
this
one
is
here
we
can
Define
well
if
we
encounter
a
property,
for
example,
if
we
encounter
test,
it
must
be
valid
against
whatever
we
Define
within
here.
A
A
A
A
A
A
Arrays
we
have
our
items,
keyword,
which
then
defines
well.
What
are
the
items
that
are
allowed
within
within
this
array
that
they
must
validate
against?
For
example,
in
this
case,
where
we
have
a
string
and
a
number
well,
then
the
items
keyword
probably
contains
something
like
a
union
between
Type
string
and
number
or
integer.
A
For
numbers,
we
have
something
like
multiple
of
that.
The
input
at
the
Json
input
must
be
a
multiple
of
two
can
also
say
something
about
whether
we
have
minimum
or
maximum
as
a
value.
For
example,
minimum
and
maximum
are
always
inclusive.
So
this
means
that
it's
one
inclusive,
so
it
can
be
between
one
and
five.
You
can
also
Define
exclusive
minimum
and
maximums,
where
you
exclude
one
and
five,
so
it
can
only
be
two
three
and
four,
for
example,.
A
A
A
A
A
A
A
Then
we
reach
the
properties,
keyword
and
this
property
keyword.
Then
we
iterate
over
all
the
different
properties
in
there.
So,
for
example,
we
just
check
well,
does
our
input
data
have?
Does
our
input
data
have
a
display,
name,
property
yep
definitely
does
okay.
Then
we
must
validate
it
against
the
following
schema
here.
A
In
here
we
first
encountered
the
type
string.
Well,
the
value
of
the
display
name.
Property
is
a
string.
So
that's,
of
course,
valid.
The
description
is
a
kind
of
metadata
information
about
it
and
it
doesn't
validation
tools.
Kinda
ignore
this,
so
this
means
that
this
entire
schema
is
valid,
and
then
we
go
over
the
email
property
because
well
do
we
have
an
email
property
within
our
input.
We
do
perfect.
A
So,
let's
validate
against
the
schema-
and
we
start
with
the
same
thing
as
we
did
before-
with
display
name
type
string,
and
that
is
of
course
ballot.
Then
we
look
at
the
format.
Email,
well,
email
matches
against
a
very
specific
records,
and
in
this
case
the
input,
data
or
the
value
of
email
is
definitely
not
an
email.
So
here
it
marks
this
as
being
invalid.
A
So
what
happens
now?
Well
then,
we
Mark
the
entire
schema
as
the
entire
schema
for
the
property
email
as
being
invalid
here,
okay-
and
that
means
that
once
it
returns
to
the
root
object
and
there's
nothing
more
to
pass
well,
we
can
say
that
the
properties
keyword
is
invalid,
because
well
one
of
the
properties
didn't
accurately
validate
against
our
constraint.
A
So,
let's
try
and
emphasize
this
even
more
because
I
want
to
drive
this
I'm
using
this
as
an
example.
So
please,
please
don't
do
this
in
your
in
a
production
environment
it
does
nothing
but
create
headaches,
but
there
is
specific
use
cases
where
nut
keywords
can
be
very
useful,
but
here
I'm
just
using
it
as
an
example
to
really
emphasize
what
validation
means
and
what
it
means
to
to
Define
message:
payload
using
Json
schema.
A
So
what
happens
here
is
that
we
have
this
double
nut
keyword
which
sound
nested.
So
let's
try
and
go
through
everything
again.
The
very
same
thing,
then:
the
the
internals
of
these
not
schema
is
exactly
the
same
thing
as
we
saw
before
so
I'm
just
going
to
quickly
go
through
it
again.
Well,
the
type
object
valid
display
name
is
still
valid.
A
A
So
Json
scheme
is
really
really
good
at
validating
the
instance
data,
and
it's
really
good
at
at
creating
these
runtime
constraints
on
our
data,
for
example,
if
else
and
even
well,
if
this
property
is
present,
then
the
other
property
must
be
present
as
well
Etc,
but
for
generating
data
models
because
an
async
API.
Well,
if
you
use
spec
first
approach
when
you
design
your
apis,
it
means
that
that
you
use
Json
schema
to
describe
the
constraints
of
the
data,
but
you
kind
of
don't
want
to
manually
create
these
data
models.
A
Yes,
so
Avro,
so
Avro
is
well
it's
a
definition,
language.
You
define
the
data
types
here
and
it
has
a
little
bit
of
special
perspective
if
I
can
call
it
that
so
an
async
API.
You
can
Define
this
using
this
schema
format
where
we
defined
it
as
an
everyone
we're
using
version.
1.9
now
Avro
is
sold
as
a
as
a
system
that
comprise
of
multiple
components.
A
A
And
then
it
also
have
the
possibility
of
creating
something
like
request,
response
calls
and
other
types
of
information
within
Avro
I'm.
Going
to
leave
that
out,
though.
So
we
also
have
an
interface
description,
language,
more
tuned
towards
developers
as
it's
more
similar
but
common
programming
languages.
A
A
A
A
A
A
A
A
We
can,
for
example,
see
that
well,
a
record
is
an
object
and
it's
well,
it's
a
Json
object.
Enums
is
just
a
basic
string
character.
That's
constant!
We
also
have
array.
An
array
can,
of
course
be
one
of
multiple
types
and
in
the
end
we
have
something
called
fixed
and
fixed.
Is
it's
just
a
fancy
word
of
saying
that
it's
a
bite-sized
type
to
represent
something
like
md5,
hashes.
A
And
yeah,
then
we
have
a
type
of
in
the
middle
of
the
two
formats
that
we
got
introduced.
We
have
a
Json
type
definition
now,
Json
type
definition
is
it's
for.
It
describes
the
shape
of
the
Json
data,
for
example,
we
don't
have
in
async
API.
We
don't
have
a
specific
format
listed
as
that
you
can
use
for
the
Json
type
definition,
but
it
doesn't
really
matter
that
we
Define
it
from
a
standard
perspective,
because
you
can
always
use
custom
Keys
here
and
tooling
will
well,
you
can
make
tooling
understand
it.
A
A
A
A
And
then
we
have
the
properties
Forum,
which
are
this
well,
it's
for
objects
in
Json,
where
you
can
Define
well,
which
kind
of
properties
exist
there.
All
properties
are
by
default
required
and
then
you
can
use
optional
properties
to
Define,
well
optional
properties,
and
you
can
of
course,
also
Define.
A
A
A
And
yeah
tooling,
how
the
hell
do
we
handle
this
in
the
past,
for
example,
it's
possible
to
always
Define
or
it's
always
possible,
to
define
a
custom
schema
parcel.
For
example,
how
do
you
pass
a
message
that
has
that
matches
this
schema
format?
Then
you
can
create
some
custom,
formatting
logic
and
adapt.
The
message
object
to
be
more
accessible,
I,
actually
don't
give
a
second,
no
okay,
I
can't
remember
how
much
time
I
have
left.
So,
let's
see
problems.
A
Well,
don't
you
want
to
know
the
structure
of
it,
but
it's
kind
of
difficult
right,
because
you
can't
have
at
the
moment
at
least
it's
not
possible
to
have
the
best
of
both
worlds,
where
you
both
have
a
the
definition
of
the
structure
and
the
validation
rules,
and
this
is
a
bit
of
a
problem
and
especially
for
code
generation.
How
do
we
generate
code
based
on
this
schema
here?
Where
you
have
the
double
negation?
A
A
What
else
is
and
well
we
all
know,
programmers
are
really
stubborn
and
like
the
way
their
thinking
is
so
they
want
their
format.
They
want
their
types
that
they
think
should
be
there
and
there's
nothing
within,
for
example,
Json
schema
that
enables
you
or
helps
you
create
these
type
of
data
models
and
I
think
I'm
going
to
skip
this
because
I
think
I'm
out
of
time,
right,
yeah,
I,
think
so,
or
at
least
right
at
the
edge.