►
From YouTube: AsyncAPI Onboarding - Part 4 - AsyncAPI in Action
Description
https://github.com/asyncapi/community/issues/415
- Creating AsyncAPI file
- What can you do with the file, some possible use cases
A
A
A
A
A
And
also
for
others
like
it's
like
pedro
joint
others
can
also
join.
So
if
you
have
some
questions
during
the
workshop,
you
can
ask
them
live
and
even
though
it
might
look
like
it's,
this
live
stream.
Zoom
room
is
not
only
for
bald
guys.
If
you
have
a
lot
of
hair
on
your
heads,
you
can
also
join
like.
So
it's
not
only
for
us.
A
A
So
as
a
reminder
like
this
is
part
four
of
the
onboarding,
even
though
I
planned
three
parts
but
yeah,
it
just
requires
more
time.
If,
if
we
want
to
slowly
like
introduce
every
concept
in
the
announcing
dpi
and
even
driven
architectures,
but
the
plan
is
that
today
is
really
the
last
part.
So
even
if
one
hour
will
be
not
enough,
I
I
will
push
and
I
will
just
simply
continue.
A
I
want
to
keep
it
together,
even
if
it's
going
to
take
1
hour
30
minutes,
but
the
good
news
is
that
another
async
api
live
stream
starts
in
in
two
hours,
so
I
I
cannot
talk
longer
than
two
hours,
so
at
least
there
are
some
boundaries,
so
the
link
I
will
share
in
I
just
sent
in
a
youtube
live
chat,
link
to
the
workshop
and
quick
recap
from
last
live
stream.
So
during
the
live,
the
last
live
stream.
I
introduced
async
api.
Yes,
at
live
stream
number
three.
A
It
took
an
the
whole
hour
and
today,
when
I
will
be
like
creating
this
asking
api
file
live
and
you
will
basically
you
will
be.
I
will
be
explaining
like
every
single
line
that
I
add
I
will
be
referring
to
my
previous
live
stream.
To
kind
of
you
know
like
first,
I
talked
about
theory
now
practice
and
let's
connect
the
dots.
A
A
A
A
I
think
that
still
it
is
not
labeled
as
asking
api
owned,
but
it's
in
the
it's
I
think
ivan
is
still
the
owner,
but
he
donated
the
the
plugin
a
long
time
ago
to
the
initiative
and
we're
actually
in
the
process
of
taking
over
the
brand.
So
it's
clear
it
belongs
to
us
in
api
and
it's
and
it's
pretty
refreshed.
So
it's
using
already
the
react
components
that
we
use
for
rendering
documentation.
A
So
you
can
try
with
vs
code
extension.
If
you
do
not
like
uis.
I
definitely
recommend
you
asking
api
studio
because
I'm
going
to
be
using
asking
api
studio
during
the
live
stream,
but
you
can
also
use
simple
editor
and
then,
for
example,
as
an
api
cli
to
just
validate
the
document
or
if
you
like
java
and
you
are
into
intellij
ide,
then
there
is
also
a
community
built
plug-in
for
for
intellij.
A
As
far
as
I
know,
it
does
not
support
latest
async
api
version,
but
it
shouldn't
be
a
big
problem,
just
just
use
2.0.0
but
yeah
again
asking
api
studio
to
the
to
the
moon.
I
definitely
recommend
you
to
use
that
now.
Just
give
me
a
moment,
I'm
gonna
move
the
the
live
chat
to
the
site,
so
I
see
it
and
we're
already
ready
to
go
the
the
asking
api
file
that
we
will
be
creating
in
the
ui.
A
It
is
an
async
api
file
that
I
created
last
year.
It's
for
some
to
have
some
dummy
example.
It's
called
shrek
up
and-
and
it's
basically
somehow
relating
to
the
first
diagram
you
could
see
on
one
of
my
first
live
streams
when
I
was
explaining
asynchronous
and
there
was
shrek
and
the
donkey.
So
that's
why
it's
a
shrek
up
the.
So,
let's
start,
let's,
let's,
let's
actually
stop
talking,
because
I'm
talking
a
lot,
so
that's
the
that's
the
studio
so
studio.askingapi.com.
A
I
think
it's
large
enough.
If
not,
then
just
dropping
me
a
message
folks.
So
it's
like
like
a
classical
editor.
So
you
have
that's
where
we
put
our
asking
api
document
and
on
the
right
we
will
see
how
documentation
start
is,
is
getting
generated
after
we
provide
data
on
the
left,
so
we
always
and
yeah
the
first,
the
first
we
need
to
decide.
As
I
said
during
the
last
live
stream.
Async
api
is
machine,
readable,
yaml
or
json.
A
So
you
can
write
these
documents
in
the
yaml
format,
where
you
need
to
be
just
careful
about
identitation
or
you
can
invite
it
in
json,
where
you
just
have
to
be
super
careful
about
curly,
braces
and
quotation
marks.
So
I
definitely
I
can't
imagine
someone
choosing
freely
using
json,
so
we
will
use
yaml
and
if
we're
using
yaml,
then
yeah,
it's
it's
cleaner,
you're
gonna
see
that
the
document
is
much
cleaner
and
first
information
that
we
need
to
provide.
When
writing
asking
api
file
is
the
async
api
file
version
so.
A
So
you
need
to
be
also
always
careful
about
like
what
version
you
want
to
use.
Of
course,
the
best
is,
if
you
always
use
the
latest
so
yeah,
that's
the
that
was
the.
That
was
the
easiest
one
line.
Next
one
is
the
info
object
in
the
async
api
document,
so
you
can
like
info
object,
holds
information
about
the
application.
A
A
And
that's
that's
the
that's
the
minimum
you
have
to
provide,
which
means
title
and
the
version
they're
critical.
This
is
this
is
like
critical
information.
Therefore,
in
the
spec
we
specify
that
information
like
title
and
version
is
required.
If
you
do
not
provide
it,
the
the
file
will
not
go
through
the
validation.
It
will
be
an
invalid
document.
So
yeah
keep
that
in
mind
and
before
before
we
do
the
more
information
in
the
document.
A
So
that's
why
we
are
basically
getting
errors
that
we
are
missing
some
additional
fields,
because
it's
not
just
in
it's
not
only
asking
api
info
with
title
and
version
required
channels
also
has
to
be
there,
but
it
can
be
empty
and
that's
like
that's
the
most
minimum
asking
api
document
not
very
much
useful,
but
yeah
we're
fixing
it
simply
this
way.
So
simply
we
can
already
see
rendered
documentation
on
the
right.
So,
for
now
we
just
have
the
title
and
the
version.
A
A
And
I'll
just
copy
paste,
because
I
have
long
description
in
my
example
that
is
in
the
script,
and
it's
simply
to
show
you
to
to
present
one
of
the
features
that
we
support
in
descriptions
in
asking
api,
which
is
like
we
can
also
in
the
yum
file,
provide
multi-line
scripts
and
we
support
that.
The
descriptions
are
written
with.
A
Excuse
me
are
written
with
markdown,
so
that's
pretty
pretty
critical,
but
I
think
that
dancing
shrek
all
the
time
on
the
right
will
be
super
annoying.
So,
let's,
let's
remove
that
green
monster
for
a
sec,
okay
cool.
So
we
have
the
the
basic
information
for
the
user
like
what's
the
title
of
the
app?
What's
the
version
that
they're
interacting
interacting
with
and
in
the
description
now,
the
next
information
you
want
to
know
is
how
you
can
actually
connect
to
the
api.
A
So
in
this
case-
and
this
example
is
based
on
the
application-
that
is
a
websocket
server,
so
we
basically
need
to
specify
like
what's
the
url
of
the
server
and
what
protocol
is
used
in
that
in
that
application
in
that
application.
So
it's
a
object
called
servers
and
you
can
have
multiple
servers
because
you
can
have,
for
example,
multiple
instances
of
the
application
in
different
environments
like
you
can
have
a
test
environment
where
you're
just
testing
application
and
it's
not
available
to
public
or
you
can
have
a
production
server.
A
So
you
can
have
multiple
servers.
You
just
need
to
provide
the
name
so
swamp
and
yeah
url
and
in
our
case
like
it's,
just
gonna
be
localhost
because,
like
it's
not
it's
not
a
real
application,
it's
not
hosted
anywhere,
so
we
don't
have
any
real
url.
We
are
able
need
to
start
this
application
locally
on
a
localhost
which
is
also
valid
url
and
the
protocol
is,
is
ws,
which
is
scheme
name
for
websocket.
A
A
A
And
and
that's
it,
we
will
not
provide
more
because
yeah
again,
I'm
biased
and
that's
how
basically,
I
would
design
my
application.
That's
how
I
would
write
as
an
api
file
for
my
application
that
I
don't
know
yet
how
it's
gonna,
how
the
api
will
be
structured
because,
like
the
first
thing,
I'm
actually
thinking
about
is
the
messages
how
the
what
messages
will
be
available
in
the
system.
I
only.
A
If
you
know
this
scene
when
donkey
is
asking
shrek,
are
we
there
yet
are
we
there
yet?
Are
we
there
yet?
So
that's
the
reason.
It's
not
related
to
flight
status.
At
all
example,
from
the
first
live
stream,
so
yeah,
I
know
that
the
server
will
have
two
functionalities,
but
the
main
information
I
want
to
know
like
is
how
the
the
message
for
the
chat
will
look
like
how
how
the
message
will
look
like
for
for
travel
status.
A
So
that's
why
I
always
recommend-
and
it's
also
a
good
practice
because
automatically
you
think
about
better
structure
of
asking
api
document
and
sharing
information,
and
so
I
always
recommend
to
start
with
components,
because
components
is
a
it's
an
object
in
using
api
document
that
allows
you
to
like
put
a
lot
of
messages,
put
a
lot
of
schemas
and
then
sometimes
you
might
have
a
situation.
That
schema
is
the
same
for
two
different
messages,
so
we
can
reference
instead
of
duplicating
information.
A
Last
week
we
were
talking
about
one
of
the
very
important
features
which
and
optimization
of
the
structure
of
the
information
in
the
document,
which
is
json
reference,
so
yeah.
We
will
definitely
use
it
here,
so
the
information
we
put
in
the
components
and
then
we
can
reference
them
in
other
places
and
before
I
continue
there's
a
question
in
youtube.
I'm
assuming,
if
someone
once
wants
to
document
an
async
api,
they
should
have
a
total
understanding
of
what
and
how
the
api
will
display
messages
in
the
system.
A
Right,
yes,
and
no
like
like
basically
yes
to
provide
us
an
api
document
with
good
data.
You
first
need
to
have
this
data,
but
but
asking
api
and
open
api
and
other
specs
they
allow
they
enable
you
to
actually
design
the
application.
So
so
it
depends.
So
if
you're
writing
asking
api
document
for
existing
api,
then
yes,
you
have
to
know
first,
how
the
messages
look
like,
so
you
can
describe
them,
but
sometimes
like,
for
example,
with
this.
This
asking
api
document
shrek
app
when
I
was
creating
it
last
year.
A
I
didn't
have
my
app.
I
didn't
have
my
api,
so
I
was
designing
it
basically
like
I
was
like
experimenting.
How
the
message
would
look
like
then
I
was,
I
could
see
it
in
documentation,
so
I
I
did
not
have
a
info,
how
the
message
looks
like
prior,
creating
the
async
api
file.
Asking
api
file
actually
enabled
me
to
to
make
them
to
work
on
this
design
and
brainstorming.
A
A
A
A
String
and
it's
and
that's
it
and
you
can
see
already
like,
even
though
I
don't
have
yet
operations
defined,
I
don't
know
yet
if
there's
any
publishing
or
subscribing
available,
but
I
already
can
see
the
messages
in
the
that
are
in
the
system.
So
I
can
already
like
tab
again
answer
your
question
additionally,
like
again
during
designing,
I
don't
know
how
the
message
looks
like
and
it
helps
me
like
to
visualize
and
see
like
because
it's
much
different
when
you
read
yaml
and
when
you
read
actually
beautiful
docs.
A
I,
like
my
personal
feeling
not
based
on
any
science,
is
I
think
that
just
the
brain
works
differently
and
understands
things
differently
and
it's
just
much
clearer
to
read
it.
This
way
then
read
it
that
way
and
looking
at
the
message
summary
that's
that's
obvious
what
the
summary
is
for
about
the
the
payload,
so
the
payload
comes
from
again
last
week
we
talked
about
you,
see
even
examples
here,
so
we
talked
about
schema
of
the
message.
A
A
Actually,
sorry,
this
that's
the
actual
message
and
that's
the
example
schema.
So
in
the
schema
you
can
say:
okay,
there
should
be
display
name
and
it
should
be
string,
there
should
be
email
and
the
type
is
object.
So
that's
what
payload
here
is
like.
So
in
the
payload
we
say
that
the
type
of
the
message
is
string.
It's
not
even
an
object,
it's
just
a
simple
string
message,
so
that's
payload.
A
What
payload
is
referring
to
and
by
default,
I'm
not
specifying
any
specific
schema
format
like
avro
or
anything
like
this,
so
by
default
and
tooling,
assumes
that
the
schema
that
I'm
using
here
is
asking
api
schema,
which
not
sure
if
you
remember
from
the
last
live
stream.
It's
a
super
set
of
json
schema.
So
it's
basically
json
schema
with
some
additional
fields
or
some
modifications
in
the
in
the
spec.
A
And
there's
a
question:
could
someone
please
share
this
message?
Schema
markdown
file
with
me
here
yeah
I
can
show
you
actually
the
whole.
Actually,
whatever
I'm
doing
is
the
step-by-step
instruction
that
is
available
here,
just
confirm
if
you
got
the
link
okay,
so
we
have
pretty
simple
message,
but
now
it's
again
it's
a
simple
message:
the
the
next
message,
the
message
related
to
trouble
status.
It's
gonna,
be
it's
gonna,
be
an
object.
A
A
A
So
the
message
payload
and
why
we
need
to
explicitly
say
payload,
because
you
can
also
have
message
headers
in
some
protocols
they
are
supported,
but
not
in
case
of
websockets.
So
that's
why
we
don't
have
an
example
of
a
header
here,
but
normally
I
would
just
have
to
specify
that
it's
an
example
for
header
and
the
payload.
A
A
So
we
introduce
another
component
object,
which
is
not
only
messages
but
can
be
also
schemas
and
in
schemas
we
will
define
a
schema
for
travel
data.
Let's
call
it
travel
data,
it's
just
an
id
and
the
type
is
not
string,
it's
object.
So
if
it's
object
and
as
you
can
see-
sometimes
it's
just
enough
to
say
that
it's
going
to
be
an
object
and
that's
it
you
don't
specify
any
properties.
A
A
A
A
A
And
yeah
in
yaml
copy
pasting
can
also
cause
a
lot
of
headaches
yeah.
So
you
can
see
already
the
message.
One
two
and
the
schemas
is
available.
So
there's
a
travel
data
and
you
can
see
that
as
a
user
of
documentation,
I
can
clearly
see
like
what
how
my
object
should
be
structured
and
and
like
in
this
view.
A
A
A
We
have
example
of
the
more
complex
message,
so
we
so
we
managed
to
design
like
what
what
messages
will
be
available
in
the
system.
Now
we
need
to
say
like
which
ones
you
can
actually
send
to
the
system
to
the
api
or
which
ones
you
can
just
read
from
the
from
the
api
and
that's
what
operations
are
for
with
two
dot
x
versions.
A
A
So
again,
last
week
I
tried
to
talk
about
this
issue.
Semantic
issue
we
have
with
publish
subscribe
so
again,
like
just
just
remember
that
when
you
think
about
saying
that
the
api
can
publish
or
subscribe,
you
always
have
to
describe
it
for
the
user.
That
will
use
the
api.
So
when
I
will
write
here
subscribe
and
and
then
put
summary.
A
Then
it
means,
if
I
and
let's
say
I
don't
provide
more
information,
then
it
means
for
the
user
that
the
user
can
actually
subscribe
to
this
particular
channel,
not
that
the
shrek
app
is
kind
of
subscribing
to
the
channel
in
case
of
websocket,
it's
easier
to
understand,
because
websocket
is
kind
of
broker
and
in
case
with
broker-centric
applications,
that's
much
more
much
more
complex.
That's.
Why
just
remember
about
this
semantics
issue?
A
I
will
specify
operation
id,
which
is
for
just
like
information
about
message.
Sorry,
like
for
information
about
the
the
api,
it's
only
needed,
basically
when
you
think
about
coding
and
code
generation,
because
the
operation
id
is
something
that
while
you
generate
code,
you
should
use
for
the
for
the
names
of
the
of
the
functions.
A
Now
in
the
as
you
can
see,
we
don't
have
yet
the
the
chat
connected
with
the
chat
message,
so
things
that
are
encompa
under
components
can
also
belong
to
channels.
So
so
I
basically
say
message
and
I
don't
have
to
again
provide
all
the
information
about
the
message,
but
I
use
dollar
ref
again
and
in
dollar
ref
again,
I
point
to
components,
messages,
chat
message
and
it
looks
like
this
and
you
can
see
in
the
generated
documentation
that,
like
finally,
I
got
some
operation,
a
user
can
see
that
there's
a
chat
channel.
A
A
A
Not
only
just
read
messages,
but
you
can
also
like
so
subscribe
to
messages,
but
you
can,
as
a
user
of
the
api,
also
send
messages
so
publish
messages
and
I'll
just
copy
paste,
because
it's
basically
it's
basically
the
same
just
just
the
operation.
Id
name
is
different
and
of
course
the
summary
but
yeah
with
publish
client
can
receive
chat
messages.
A
A
A
A
A
A
I
know
what
operations
I
can
perform
with
the
api,
how
to
connect
and
what
messages
I
can
receive
or
send
to
the
api
and
how
they
look
like.
What's
the
schema
which
is
perfect
now
now
we
will
do
something
more
something
that
again
like
last
week,
we
talked
about
the
killer
feature
of
asking
api,
which
is
that
asking
api's
protocol
agnostic.
A
So
you
can
see
that,
even
though
the
application
that
I
was
writing
here
is
for
websocket,
but
there's
nothing
websocket
specific
in
in
this
document,
like
nothing
like.
Basically
all
is
super
generic
that
you
need
to
know
from
about
any
api,
no
matter
what
the
protocol
it's
using,
but
I
need
to
provide
some
additional
information
just
for
websocket
and
that's
where
we
use
bindings,
so
this
kind
of
micros
specifications
for
a
given
protocol
that
we
use
at
using
api.
A
So
we
basically
need
to
specify,
on
the
channel
level,
on
the
channel
level
that
the
travel
status
when
I'm
connecting
the
travel
status.
I
want
to
specify
that
this
particular
excuse
me
this
particular
channel.
I
can
put
some
query
parameters
when
connecting
to
the
server
and
with
the
query
parameter.
I
can
specify
that
I
want
only
status
from
a
given
destination,
so
let's
say
not
all
the
destinations,
but
just
one-
and
I
could
like
my
api-
could
support
something
like
this.
A
Bindings
and
first
thing
you
do
with
bindings,
you
say
which
binding
you're
using,
which
is
a
websocket
in
this
case,
and
again
like
the
first
one.
The
first
information
is
this
binding
version
because
yeah
it's
it's
like
with
the
spec
as
an
api,
spec
has
versions,
and
this
specification
that
have
also
their
individual
versions.
They
are
not
bound
to
asking
api
version
so
yeah,
let's
use
the
the
zero
one
and,
let's
specify
the
query.
A
Oh
yeah,
and
we
know
that,
there's
a
channel
binding
available.
I
know
what
kind
of
details
I
can
provide
and
I
know
that
there
I
can
provide
a
query
property
in
the
schema
and
I
can
see
use
here.
A
schema
object
to
describe
to
describe
what
what
values
I
can
put
in
the
query
when
connecting
to
the
to
the
server.
A
So
there
will
be,
there
will
be
one
query
parameter
available
so
again
like
let's
just
copy
paste
a
bit
because
yeah
we
know
it's,
it
must
be
an
object
it
definitely
doesn't
have
to.
But
it's
recommended
that
it
has
a
description
and
it
has
to
have
properties,
and
we
know
that
there
will
be
one
query
parameter,
which
is.
A
A
A
A
A
A
A
This
is
why
you
have,
and
it's
needed
only
for
websocket.
That's
why
you
have
websocket
binding
and
the
specific
feature
here
that
allows
you
to
specify
the
query
and
then
again
it's
available
in
the
documentation.
So
I
know
that
travel
status
have
some
specific
websocket
information,
and
I
know
that
I
have
a
query
available
and
it
can
it's
a
destination
and
the
value
is
destination.
A
A
A
A
A
We
do
render
extensions
that
we
use
when
we
that
we
see
in
the
document,
but
yeah.
That's.
I
don't
think
it's
a
topic
for
this
for
this
workshop
for
this
onboarding.
Just
remember
that,
like
these
extensions,
we
want
to
there's
a
extension.
Catalog
repository,
nothing
api
and
we
want
to
kind
of
try
to
help
community
share
extensions
and
also
push
for
the
solution
that
to
add
a
new
feature
in
the
spec.
You
actually
first
add
it
as
an
extension.
A
A
I
know
like,
for
example,
from
the
presentation
from
walmart
from
last
year
that
they
provide
some
additional
information
that
are
walmart,
specific,
so
extensions
that
they
will
not
share
with
others
that
they
will
not
even
push
for
the
spec,
because
it's
somehow
really
like
super
specific
for
their
architecture
for
their
solution
and
they
just
do
x
and
they
do
the
pattern
like
x
and
something
and
that
the
same
would
be
with
any
other
company.
It's
just
the
practice
that
they,
I
think
that
started
using
when
open
api
was
introduced.
A
So
yeah.
So
just
remember,
like
simply
the
example
I
have
here.
Is
that,
like
I'd
like
to
know
as
a
reader
of
documentation
that,
when
I
subscribe
to
chat
message
that
I
will
receive
also
in
res
what
I
will
receive
in
the
response
that
there
there
will
be
response,
not
direct
still,
I
think,
but
that
there
will
be
response.
So
I
can,
for
example,
using
I
can
do
it
using
the
extension.
A
Chat
message:
oh
yeah,
I
already
have
it
here
because
I
copied
the
correct
document,
so
I
just
add
additional
fields
x,
response
put
the
description
and
say,
like
response
will
be
available
here
in
the
in
the
payload
of
the
message
so
and,
as
I
said
like,
sometimes
we
do
support
them
in
the
in
the
docs
rendering
and
render
them
as
as
good
as
we
can.
Even
though
we
don't
know.
What's
the
schema
of
of
this
given
object.
A
A
Okay,
so
you
can
see,
for
example,
there's
a
channel
some
channel
on
the
on
the
broker.
We
know
that,
with
this
application,
we
can
subscribe
to
this
channel
to
receive
information
and
it's
kafka
and
the
client
id
everywhere
will
be
the
same.
So
you
so.
You
want
to
reuse,
binding
information
here
under
every
under
every
operation,
but
with
reference.
It
would
not
look
that
nice,
so
you
basically
say
okay
trades
for
this
operation.
A
A
So
it
will
not
be
like
with
reference.
It
would
usually
be
like
you
know
like
like
with
simple
referencing.
It
would
be
embedded
under
trades,
but
it's
trades.
It's
not
simple
references,
so
the
whole
binding
information
will
actually
be
injected
between,
like
on
the
same
level,
that
other
properties,
like
name
title
summary.
A
So,
let's
see
light,
measured,
lightning,
measured,
lightning,
measured,
that's
clear,
and
we
can
see
that
there
is
operation,
specific
information
about
kafka
and
the
client
id,
and
here
you
can
see,
there's
nothing
about
kafka
and
client
id.
We
just
have
a
reference
to
operation
trades
kafka,
so
you
can
see
that
whatever
we
see
rendered
here
under
operation
is
exactly
the
same
thing
that
is
provided
here.
A
So
it's
just
so
trades
like
are
like
again
it's
a
it's
a
feature
for
better
or
organization
of
your
of
your
asking
api
document
for
reusability
and
something
a
bit
different
than
ref.
So
yeah.
You
need
to
know
what
you're
using
for
what.
But
again
it's
just
about,
not
writing
the
same
stuff
twice
but
reuse.
A
And
one
thing
I
didn't
show
you
I
think
I
mentioned
but
didn't
show
you
was,
but
it's
not
possible
in
the
studio
like
studio,
is
a
web
app.
We
don't
yet
support
references
to
external
files
in
the
file
system,
but
yeah.
You
have
an
example
of
of
asking
api
file
here
where
the
reference
you
can
see,
it's
doesn't
start
with
pound,
key
or
or
hashtag,
but
it
starts
with
just
actually
pointing
out
that
it's
a
relative
relative
path
to
some
file
and
a
specific
property
inside
the
file.
A
A
A
A
A
A
I
I
have
constantly
issues
with
pasting
copy
pasting,
the
parts
of
the
ammo,
so
you
need
to
be
very
careful
about
idention.
So
there
is
a
huge
of
community
of
people
that
basically
hate
yamu,
but
it's
there's
nothing
better,
and
so
you
went
through
the
horror
of
writing
the
yam
fight.
You
went
through
the
horror
of
actually
learning
the
specification
because
to
write
the
yam
file.
A
A
Is
it
really
worth
it?
Like?
I
mean
I
think
it's
that
was
stupid.
Question
like
I
think
it's
actually
worth
it
like,
even
for
documentation
but
documentation.
You
can
also
write
by
hand,
of
course,
with
using
asking
api.
You
don't
have
to
worry
about
the
structure
of
the
document
style
of
the
document,
because
the
documentation
generator
will
do
it
for
you
but
like
if
you
already
went
through
hell
of
writing,
not
something
so
beautiful,
but
writing
something
so
yum
full
that
the
machine
can
understand
and
give
you
nice
documentation.
A
Then
why
not
use
it
for
different
use
cases.
So
definitely
don't
stop
with
dogs.
Dogs,
I
think,
should
be
always
the
the
first
goal,
the
first
step,
because
that's
the
easiest
to
achieve
now.
You
ride
the
fight.
You
get
the
dogs,
but
then
push
the
boundaries
and
try
to
try
to
use
this
async
api
documents
for
more,
because
if
machine
can
understand
it,
that
much
more
can
be
done
and
like
one
of
the
use
cases
is
real-time
message:
validation.
A
Let
me
actually
just
link
you
to
maybe
I'm
not
going
to
link
you
to
this
up
to
this.
Repos
just
have
a
look
at
them
later.
It
might
be
just
too
technical,
but
basically
real-time
message.
Validation
is
where
it's
not
about
validating
as
an
api
document.
It's
that
just
just
just
look
on
information
that
you
have
available
in
the
asking
ip
document.
A
You
have
the
information,
the
schema
of
the
message.
You
know
exactly
how
it
should
look
like,
so
it's
not
only
for
documentation
reasons
that
you
create
this
schema.
It
can
also
be
used
in
in
the
runtime
of
the
application
when
it's
running
when
you
validate
incoming
message
like
so
so,
let's
see,
I'm
writing
an
application
that
is
subscribing
to
the
travel
information
data,
and
I
want
that.
My
application
that
reads
the
messages
checks.
A
If
the
incoming
messages
message
looks
as
it
should
look
like
if
it
has
destination,
if
it
has
distance
and
if
it
has
an
arrival
and
if
the
type
of
the
information
is
string
like
what
I
would
have
to
do,
if
I
don't
have
a
schema,
I
would
have
to
write
everything
with
code
like
manually
provide
validation
code
that
checks
incoming
payload
destination.
Is
it
string
okay,
then?
A
If
distance
is
string
or
not,
if
arrival
is
string
or
not,
then
now
approve
it
or
drop
an
error
that
instead
of
type
string,
I
got
integer,
I
would
have
to
code
it
all
and
what
schema
is
for
actually
for
for
validation.
So
there
are
libraries
that
you
can
put
your
schema
through
the
library
get
validation
code
out
of
the
box
and
then
validate
the
message.
The
information,
the
object
against
the
schema
and
the
validation
library
will
handle
the
validation
because
everything
it
needs
to
have
is
in
the
schema.
A
A
A
A
A
A
A
A
And
we
have
already
another
window
here:
okay
and
pm
start
oh
wrong
and
pm
start,
so
you
can,
like
I
mean,
can
be
there
a
better
example
like
what
you
can
do
with
us
in
the
api
document.
You
see
that
I
was
able,
when
I
just
have
an
asking
api
document
ready
there
is.
There
are
some
projects
available
for
in
the
community.
A
A
A
I
can
send
it
and
it's
gonna
be
received,
and
it's
like
like
here,
you
can
see
we
have
console
logs
in
the
in
the
app,
so
we
console.log
that
the
app
received
a
message
from
the
broker
with
this
information.
Now
the
cool
stuff.
Is
that
this,
this
runtime
validation
of
messages
of
the
against
the
schema
is
already
can
be
already
plugged
in
into
the
code
generator
and
in
case
of
this
node.js
app
template.
It's
just
plugged
in
so
so
you
basically
you
have
to
do
you
don't
have
to
do
anything.
A
A
A
So
that's
that's.
What
real
time
message
and
validation
is
it's
what
this
library
is
doing?
It's
basically
reading
asking
api
document.
So
when
the
message
comes
in
into
the
system,
it
can
read
from
us
in
api
document,
all
the
schemas
that
are
available
for
a
given
channel
and
then
just
validate
out
of
the
box,
but
there
are
also
other
scenarios
like-
and
this
is
for
node.js
this
here
in
this
project-
that
sergio
is
working
on
it's
part
of
the
gateway.
A
Now,
discoverability
of
traffic
so
like
like
imagine,
there
are
two
types
of
companies:
small,
smart,
app,
startup
and
huge
corporation
simplified
world
in
small
startup.
You
have
just
few
microservices,
probably
at
the
beginning,
not
very
complex,
not
many
people
easy
to
share
information
in
huge
corporation
you
can
have
like,
and
I
was
there.
I
know
there
can
be
even
10
different
teams
working
on
the
same
product
and
each
can
have
multiple
different
micro
services
and
they
communicate
through
even
driven
architecture.
A
How
someone
can
know
what
messages
are
available
in
the
whole
system?
What's
going
through
the
broker?
What's
happening
like
what
microservices
we
have
and
that's
what
someone
can
do
with
with
asking
api
documents
so
because,
if
you
treat
this
seriously
like
you
have
an
example,
for
example
of
this
social
media
where
to
provide
a
social
media
product,
you
have
to
have
multiple
different
services:
uis
backends,
like
service
for
comments
only
and
etc,
etc.
So
you
have
multiple
lasting
api
files.
A
So
if
you
have
multiple
async
api
files,
you
can
define
some
some
rules
like
okay.
So
if
I
have
two
asking
api
files
and
two
of
them
have
servers
and
both
of
them
point
to
the
same
server,
I
can
connect
them.
I
can,
I
can
say:
okay,
they
they
both
are
connected.
So
I
can
analyze
these
two
documents
and
provide
a
kind
of
diagram.
For
example-
and
here
you
have
the
simplest
example
of
of
of
diagram,
that
is
not
the
most
beautiful,
but
that's
just
what
you
get
out
of
the
box.
A
You
can
always
style
it
properly.
So
we
can
see
that,
like
basing
on
few
asking
api
documents,
you
can
actually
run
it
through
some
library
analyze
check
what
information
you
have
in
these
documents,
where
they
match
if
it
comes
to
na,
comes
to
the
name
of
the
channels
etc.
So
you
can
actually
generate
the
whole
architecture
of
your
of
your
microservices.
You
know
how
and
how
they
communicate,
and
you
basically
know
that
if
you
will
unplug
comment
service,
that
something
can
be
broken
across
the
whole
architecture.
A
So
that's
super
helpful
and-
and
we
know
that
users
look
into
this
use
case
a
lot
especially
kafka
users,
design
first
use
case-
that's
something
I
already
actually
did
throughout
this
whole
onboarding,
so
creating
async
api
file
for
not
existing
application.
I
was
designing
the
app
not
having
it
yet.
So
that's
that's
what
that's
what
you
can
do
normally
without
the
spec
to
to
design
the
app
to
see
the
docs,
I
would
just
have
to
write
it
from
scratch
and
then
again
you
can
imagine
a
group
of
10
teams.
A
A
That
can
already
read
messages
right,
so
you
can
imagine
that
I
can
write
multiple
async
api
documents
in
the
in
the
documents
design
that
they
communicate
with
each
other
through
a
broker
on
a
given
channel,
and
then
I
can
actually
generate
all
these
apps
and
and
actually
start
them
and
actually
do
some
stuff
and
like
generate
some
messages,
some
fake
messages
and
that's
what,
for
example,
microx
is
doing
that.
You
just
provide
some
examples
and
basically,
on
the
examples,
microx
will
actually
start
generating
these
messages
like
send
them
to
the
broker.
A
So
we
can
actually
see
how
messages
behave,
how
how
many
messages
you're
getting
in
the
system,
etc.
You
can
prototype
everything
test
everything
without
writing
a
single
line
of
code
except
of
the
code
where,
if
you
are
not
using
microx,
you
might
want
on
your
own,
to
to
write
some
loops
that
generate
messages.
That's
it.
So
that's
that's
like
kick-ass
stuff
really
and
like
you
can
see
on
the
on
the
scale
of
of
adoption
of
my
crocs
that
it's
super
popular
now
the
code
generation.
A
A
Wait
I
have
to
first
yeah
into
a
proper
location
where
I
have
asking
api
dot
yaml,
so
you
can
see
that,
like
yeah
travel,
data
class
typescript
class
got
generated
like
for
you
out
of
the
box
so
again
time
saver,
especially
in
type
in
type
languages,
and
I
that's
why.
For
example,
I
don't
like
typing
languages
because
there's
a
lot
of
boiler
plate
codes,
but
if
you
can
generate
it,
then
it's
super
nice.
A
And
last,
I
can
also
tell
you
like
that
we
know
from
the
presentations
of
others
like
walmart,
but
it's
also
the
same
with
adio.
It's
also
the
same
with
a
new
bank
of
new
zealand.
What
they
do
is
that
internally,
because
they
have
a
lot
of
communication
done
over
even
driven
architectures,
they
they
provide
the
whole
self-service
platforms
where,
where,
where
teams
don't
have
to
even
talk
to
each
other,
like
scrum
master
from
team,
a
doesn't
have
to
go
to
scrum
master
of
team
b
and
ask
them
like
hey?
A
A
You
can
like
collect
the
information
about
all
the
messages
put
them
in
one
event,
catalog.
So
so,
basically,
developer
doesn't
care
basically
about.
Is
it
shrek
up
or
some
different
app
sending
the
message,
because
for
them
it's
irrelevant
for
them
relevant
is
the
message,
so
they
want
to.
First.
Actually
see
that
they
can
get
a
message
about
order
placement
and
they
don't
care.
A
If
it
comes
to
the
use
cases
like
yeah
a
lot
of
talking
code
generation,
docs
examples
I
have
used
so
actually
shrek
up
is
a
real
application,
so
I
generated
it.
I
can
quickly
show
it
to
you,
so
I
just
have
it
cloned
on
my
local,
but
it's
on
github.
The
link
is
in
the
script
so
just
quickly.
Looking
on
the
code
like
eighty
percent,
ninety
percent
of
the
of
the
code
for
this
project
was
generated
so
basically
using
the
async
api
document
for
shrek
up.
A
I
was
able
to
not
only
generate
code
but,
of
course,
even
publish
the
the
documentation.
So
we
can
see
travel
info
and
the
example,
for
example,
is
rendered
the
one
that
I
manually
provided.
So
I
can
generate
docs.
I
can
generate
app
and
later
I
just
have
to
provide
some
custom
code.
So
in
case
of
let's
just
start,
the
server.
A
Yes,
I
just
shared
my
token,
but
no
worries
it
doesn't
work
anyway
and
the
app
that
I'm
using
is
broken.
But
more
important.
Is
that
let's
talk
to
the
app,
so
you
remember,
there
were
two
channels,
so
I
websocket
you
had
to
recall
from
part
two
onboarding
where
I
was
using
websocket
to
connect
the
to
the
to
all
to
the
kraken
api,
and
here
we're
just
connecting
to
websocket
on
localhost.
A
A
A
A
So
I
got
all
the
codes
generated,
except
what
what
is
inside
the
service?
That's
something
custom,
that's
something
you
can't
describe
that's
like,
so
in
the
end
developers
are
still
needed.
They
they
need
to
write
this
business
code,
but
yeah
it's
much
more
fun
than
just
writing
some
validation
code.
A
So
you
can
see
here
that
I'm
basically
having
a
loop
and
using
some
library
for
generation
of
data,
I'm
just
sending
some
data
in
the
in
response
to
the
to
the
channel.
That's
that's
it
really
and
that's
it.
I
really
had
to
do
like.
I
didn't
have
to
all
the
colors
like
that,
the
the
nice,
the
nice
console
logs,
that
that
this
is
in
yellow
clyde
connected.
I
didn't
have
to
write
this
code.
That
was
all
generated.
A
Okay,
let's,
let's
start
the
chat
again,
but
yeah
chat
will
not
work.
There's
something
wrong
with
with
ai
that
I'm
using
so
I'm
using
actually
real
chatbot
service,
but
something
is
broken
with
it.
So
I'm
able
to
connect
to
the
chat,
send
the
message
to
shrek,
but
but
now
he
always,
he
like
the
service
returns
empty
answer.
So
my
my
app
says
like:
if
there's
no
answer,
then
it
means
your
question
is
strange
and
you're
gonna
be
asked
like?
Is
it
you
donkey?
A
A
A
A
So
today
you
created,
I
hope
you
created,
or
I
just
created
it-
a
real
asking
api
document
for
a
sample
application.
We
used
majority
of
features
of
asking
api
document
with
references
with
bindings.
So
but
you
definitely,
if
you
didn't
watch
part
three
I
am
might
be.
That
part.
Four
is
not
that
easy
to
to
understand
and
we
were
able
to
see
some
in
action
code
generation
message:
validation,
mocking
some
even
design,
first
approach.
So
do
you
have
any
questions
because
it's
part
for
the
last
part.
A
I
will
not
do
part
five
unless,
unless
you
give
me
feedback
that
something
was
not
mentioned,
that
requires
more
explanation
and
I
definitely
can
then
provide
something
for
you,
but
you
just
need
to
let
me
know,
but
so
far
any
questions
anybody
has
at
the
end,
because
we
still
have
30
minutes
until
the
next
live
stream.
So
I
can
still
stay
here
and
answer
some
questions.
If
you
haven't.
A
A
So
if
you
think,
if
you
have
some
feedback
like
well,
where
I
lost
you,
where
you
think
more
explanation
was
needed,
more
details
than
or
any
other
feedback,
please
really
don't
feel
bad
sharing
it
with
me.
I'm
I
can
I
can
handle
it.
I
can
handle
negative
feedback
so
because
I
know
it's
it's,
it
will
just
improve.