►
From YouTube: AsyncAPI Onboarding - Part 1 - Intro to basic terms in Event Driven Architectures and APIs
Description
Based on https://github.com/derberg/Documenting-Event-Driven-Architectures---Workshop-Script
This time we will not talk much about AsyncAPI as we need some broader intro to event-driven architectures
A
A
A
A
A
A
I
estimate
three
hours,
but
let's
see-
and
there
was
a
really
good
idea
from
the
community-
that
we
should
just
basically
split
it
into
a
few
parts.
One
hour
long
for
two
reasons
like
one
I
was
doing
the
workshop
in
person
with
people,
and
I
already
saw
that
after
two
hours,
people
were
super
bored
because
it's
hard
to
be
entertained
for
longer
period
of
time
and
also
online.
I
think
it's
even
harder
to
keep
people
on
track,
so
we
are
gonna
like
this
one.
A
I
hope
that's
fine,
that
we
don't
do
it
one
day
after
another,
because
the
the
that
is
my
my
plan
is
to
have
a
one
week
breaks
first
of
all,
to
apply
the
feedback.
If
something
will
not
be
the
best
in
the
in
the
script.
You
think
I
should
show
it
better.
Next,
in
the
rings
part
two
or
part,
three,
then
I'll
just
digest
the
the
feedback
and
and
also
it
will
be
like
you
will
have
one
week
time
to
ask
follow-up
questions
so
yeah.
A
A
Let
me
know,
do
let
me
know
if
you
prefer
that
part
2
is
a
set
of
of
slides,
but
I
think
that
if
it's
not
a
slide,
it's
a
markdown
that
I
scroll
through
and
and
zoom
in
and
zoom
out.
Maybe
it
will
keep
you
more
focused
on
on
the
on
the
whole
workshop.
So
please,
let
me
know
later,
how
did
it
work
for
you
and
the
link
to
the
script?
A
A
A
A
We
are
always
using
this
also,
this
phrase
like
they
have
a
heavy
interface
like
so
don't
go
to
peter
because
he
has
pretty
heavy
interface,
go
to
other
java
developers,
they'll
help
you
out
and
and
then,
if,
if
they're
not
able
to
help
you
out
with
your
questions,
then
then
go
to
peter.
So
so
it
it
really
maps
one
to
one,
in
my
opinion,
to
the
to
the
world
of
the
of
the
services
and
the
apis.
A
So
it's
basically
the
interface
that
you
that
you
have
on
the
service
or
on
a
human
that
you
can
use
to
communicate,
and
you
can
see
some
simplification
if
we
would
say
that
we
have
a
in
that
we
have.
The
like.
People
have
api
the
interface
and
they
can
also
document
it
in
a
way.
The
life
would
be
much
much
much
easier.
A
A
A
Now
another
term
that
you're
gonna
see
in
the
world
of
evangelion
architectures
and
using
dpi,
we
quite
often
say
this
is
async.
This
is
synchronous
communication.
This
is
asking
communication.
So
the
best
way
to
understand-
and
let
me
this
one-
let
me
zoom
more
if
it's
possible
so
for
now
just
left.
Look
on
the
left
side.
A
The
left
hand
side
shows
you
a
asynchronous
communication,
asynchronous
communication
over
http
protocol,
and
here
you
can
see
a
a
a
pattern
called
http
polling,
but
the
most
important
is
the
the
the
communication,
the
synchronous
communication.
So
you
have
a
donkey
and
you
have
shrek
and
they
basically
traveled
to
some
some
place.
A
I
think
it
was
a
some
kingdom,
seven
mountains
and
seven
forests
away
and
the
and
the
donkey
asks
constantly
shrek
a
question
if
they
are
there.
Yet
if
they
manage
to
get
to
the
destination-
and
it
like,
you
can
imagine
it
that
donkey
is
basically
poking
shrek
all
the
time
for
the
information,
so
he
expects
in
real
time
he
requests
the
the
answer
and
gets
a
response,
sometimes
at
the
beginning
response
like
in
the
cartoon.
A
It's
pretty
okay,
but
you
can
imagine
at
some
point
of
time
if
you're
bombing
a
service
with
too
many
questions,
you
can
get
a
connection
timeout.
There
are
some
rules
on
the
services
where
you
can
basically
cut
a
connection
if
it
doesn't
follow
some
rules.
So
so
that's
basically
asynchronous
what
we
mean
by
synchronous,
that
you
have
two
actors
and
in
majority
of
cases
you
expect.
When
you
ask
a
question,
you
expect
the
answer.
A
Are
we
closer?
Are
we
getting
closer?
Are
we
getting
closer?
It's
totally
opposite.
Like
you
just
say
I
wanna
I
wanna
have
an
info
and
then
the
server
or
shrek
will
notify
you
every
given
time
or
only
when
there's
some
change
in
the
system
will,
let
you
know
like
that,
we're
getting
closer
or
that
only
50,
kilometers
or
40
miles,
left
to
the
destination,
etc,
etc.
So
you're
basically
subscribing
to
information
and
subscribing
to
the
server.
A
I
already
introduced
here
and
two
terms,
http
and
and
websocket.
So
that's
another
thing
that
you
will
see
and
hear
in
the
world
of
asking
api
and
and
even
driven
architecture,
so
protocols
what
is
basically
protocol
and
when
I
started
in
in
tech
I
still
did
not
know
what
protocol
is.
I
could
not
understand
the
explanation
of
java
developers,
even
though
I
finished
my
computer
science
studies.
A
A
Couple
and
again,
like
the
protocol,
says
clearly
that
you,
when
you
interact
between
each
other,
a
woman
should
first
put
her
hand
out
to
shake
a
hand
of
somebody
like
you
should,
like
even
a
president,
should
not
be
the
first
one
that
pulls
out
the
hand
and
in
this
situation
the
u.s
president
did
it
in
the
wrong
way.
He
was
the
first
one
that
pulled
out
his
hand
and
the
first
lady
of
polish,
like
of
poland.
She
did
it
later,
but
she
directed
the
hand.
A
First
to
the
first
lady
of
us,
so
you
basically
like
because
of
not
following
the
protocol.
There
was
a
tiny
diplomatic
issue
and
it
also
reflects
how
it
works
in
the
in
real
life
with
protocols.
So
protocols
like
they
describe
the
same
like
in
tech,
they
describe
the
same
like
communication
between
services
between
different
things
in
in
tech
and
protocol
is
a
like.
It's
a
set
of
rules
right
and
someone
wrote
these
rules,
but
sometimes
implementations.
A
Don't
they
don't
implement
protocols
as
you're
described,
so
there
are
some
mistakes,
some
misbehaviors
on
the
server
side,
just
like
in
the
real
life
just
like
with
the
diplomatic
protocol
also
another
example
of
http
protocol.
I
gave
you
a
just
just
small
snippet
from
the
async
api
website
you.
What
you
can
see
is
a
screenshot
like
when
I
go
to
the
browser
and
in
the
console
I
can
see
what
happens
when
I
try
to
access
asyncapi.com
right.
A
It
knows
browser
knows
that
should
follow
the
http
http
http
protocol,
and
it
knows
that
with
first
request,
it
should
send
a
a
request
to
the
server
with
using
method
get
so
it
specifies.
What's
the
what's
the
method.
What's
the
scheme
used
an
additional
information
that
is
needed
for
a
given
request
and
then
the
server
on
the
other
side
in
case
of
asking
api.com,
it's
netlify
that
serves
asyncapi.com,
the
server
gets
a
request
for
async
api.com
and
it's
a
get
request
and
it's
to
the
root.
A
Even
though
I
wrote
here
that
it's
for
rest
apis,
I
know
that
in
3.1
version
they
removed
this
reference
from
the
spec,
so
it
can
be
for
any
http
apis
because
they
are
different
but
yeah.
It's
it's
a
specification
is
definitely
not
a
protocol.
So
specification
is
a
a
way,
a
a
a
a
kind
of
contract
that
that
tells
you
how
you
can
describe
your
application,
how
it
follows
how
it
implements
the
and
the
given
protocol,
how
it's
using
the
given
protocol
for
the
communication.
A
You
use
open
api
to
describe
your
your
api
interface,
that
is
using
http
protocol
and
you
specify
like
what
get
methods
you
have
on
the
on
the
on
the
server
if
anything
can
be
created
through
your
server
service,
etc,
etc.
So
you
describe
all
this
all
these
things
in
details.
What's
possible
through
http
protocol
to
be
to
happen
with
the
within
with
the
server
graphql?
I
don't
think
it's
very
much
useful
for
the
whole
onboarding
explanation.
A
It's
it's
basically
a
query
language
so,
but
it's
under
underneath
it's
based
on
http
protocol
because
to
send
a
graphql
query
to
a
server
and
ask
for
some
information
from
the
server
the
transport
protocol.
It's
http
and
async
related
protocols.
This
is
more
important
for
you
to
know
and
again
I
don't
write
a
specific
name
of
the
protocol,
we're
going
to
get
there
later
and
that's
one
of
the
most
complicated
things
about
even
driven
architectures
here,
but
yeah
async
related
protocols.
There
are
actually
three
I
could
mention
here.
A
So
one
is
asking
api,
so
I
think
epi
is
a
pro
sorry.
I
say
as
a
specification,
so
I
mean
protocols
for
the
specifications
for
the
protocol,
so
asking
api
specification
allows
you
to
describe
what
your
application,
what
what
users
can
do
with
your
application
and
like
how
they
can
interact
with
your
application
using
your
api
and
you
describe
the
entire
application
with
asking
api
now
cloud
events.
That's
not
something
like
in
case
of
open
api
and
graphql.
A
You
will
never
use
both
for
for
a
single
api
in
case
of
even
driven
architectures
and
asynchronous
protocols
asking
api
and
cloud
events.
They
complement
each
other
because
cloud
events,
it's
a
specification,
but
it's
only
focused
on
the
on
the
on
the
message
itself
to
put
it
like
in
a
common
envelope
like
you
have
an
envelope
when
you
send
the
letter
where
you
put
an
address,
you
have
some
rules:
how
the
envelope
should
look
like,
what's
the
size,
etc,
where
you
specify
the
recipient
and
and
sender,
that's
what
cloud
event
is.
A
So
it's
only
focused
on
a
on
a
message
while
remember
asking
api
is
more
than
that:
it's
not
just
listing
what
messages
you
can
send
to
the
application,
but
also
where
you
can
send
it
what
security
is
applied,
etc,
etc.
So
you
should
basically
mix
both
not
just
choose
one,
because
they
are
both
being
pushed
as
standards.
A
A
A
A
A
What
kind
of
data
is
sent
if
it's
string,
or
something
else
and
and
it's
needed
because,
like
the
user
of
the
api,
needs
to
know
how
to
name
these
properties
when
the
message
is
being
sent
and
we're
calling
this
schemas
of
the
messages?
So
we
can
basically
see
the
dependency
asking
api
describes.
The
entire
application
cloud
event
describes
the
a
given
message,
but
sometimes
you
don't
want
to
mix
them
in
one
document.
A
A
You
don't
want
them
to
have
their
own
schemas
for
for
the
services
if,
in
the
end,
they
send
the
same
messages,
so
you
create
schema
registries,
so
basically
a
bank
of
schemas
that
I
can
reference
to
and
point
to
in
my
asking
api
document.
So
again
greeting
message
in
my
asking
api
document
I
could
say:
okay,
the
schema
of
the
greeting
message
is
in
the
schema
registry
under
given
path,
so
I
don't
have
to
copy
and
paste
it
into
documents,
so
I
don't
have
to
repeat
myself
in
many
different
places.
A
So
that's
if
it
comes
to
the
specifications
in
the
even
driven
architectures,
now
even
driven
architecture.
What
is
it
I
like
this
question
answer
so,
but
it's
something
that
I
already
said
like
the
question
is:
why
would
you
use
even
driven
architecture
if
you
have
rest
apis
like
you,
can
do
http
polling
and
ask
every
five
seconds
if
there's
some
new
update
in
the
system,
but
the
thing
is
no
like
to
know
what's
happening
in
real
time.
You
should
not
be
asking
for
the
update
every
five
seconds.
A
A
It's
just
a
message,
no
conversation
now
there
are
definitely
much
more
patterns
and
you
should
definitely
check
it
out.
60-Something,
pretty
interesting
resource
now,
even
driven
architectures
they're,
not
not
new,
it's
pretty
pretty
old
thing
that
was
there
already
many
years
ago
in
the
browser.
You
can
see
it
easily
on
our
website,
like
so
when
you
hover
over
open
studio
button
and
it
changes
the
color.
A
So
before
microservices
I
saw
basically
three
different
servers
communicating
to
each
other
before
that
we
had
all
these
three
services
in
one
server
and
it
was
called
a
a
monolith.
So
it
was
a
huge
server
with
many
different
functionalities
and
but
they
still
needed
to
communicate
like
the
services
inside
one
server.
They
still
needed
to
work
in
sometimes
in
a
synchronous
way.
Sometimes
some
situation
in
the
system
had
to
be
replica
not
replicated,
but
I'm
communicated
to
different
services,
and
it
was
done
through
events
as
well.
A
At
least
that's
how
it
worked
in
my
monolith
that
I
was
working
on
in
my
previous
company.
That's
how
many
extensions
were
written
in
in
java
because
of
events
that
were
populated
in
the
whole
system,
but
the
microservices
made
it
like
put
it
into
the
renaissance,
like
more
people
started
talking
about
it
because,
basically
microservices
after
the
hype,
people
notice
that
they
are
pretty
difficult
to
handle
the
communication.
A
If
you
want
to
do
point-to-point
request
reply,
communication,
it's
getting
pretty
complex
and
only
even
driven,
is
the
and
the
solution
here
and
then
I
think
that
serverless
is
putting
it
to
the
moon.
Really,
there's
a
there's,
a
huge
discussion
around.
That's
like
why
actually
cloud
events
came
up.
This
whole
need
for
having
a
a
one
way
of
describing
the
the
message
like
this
this
envelope.
On
top
it
was.
A
Now
eda
protocols
like
yeah,
I
just
mentioned
few-
the
ones
that
are
supported
by
async
api,
pretty
large
number,
the
most
popular
the
ones.
That
again,
I'm
basically
biased,
because
it's
just
my
view,
but
whenever
to
asking
api
people
come
and
ask
how
to
use
async
api,
the
most
common
is
websocket
kafka
and
then
mqtt,
I
would
say,
but
I
would
not
like
say,
which
is
the
most
popular,
because
I
hear
them
constantly
and
then
the
the
rest,
of
course
so
again
protocol.
A
A
Blue
web.
It's
one
of
the
two
portals
that
I
know
the
most
that
list
different
apis.
They
have
like
from
cat
api
to
whatever
different
apis.
It's
a
basically
a
catalog
of
apis
out
there
in
the
world
that
you
can
browse
through
and
and
see
what
apis
are
out
there
and
you
can
interact
with
and
they
have
like.
24
000
different
apis
registered
and
just
around
150
is
about
asynchronous
api,
and
it's
not
even
asking
api.
That's
why
the
space
here.
A
So
you
can
imagine
like
not
many
examples
and
looking
at
the
amount
of
the
protocols
that
we
have
like
then
again,
like
the
examples
of
a
given
protocol.
It's
it's
even
less,
then
in
rapid
api,
like
they
don't
even
provide
the
final
number
of
all
the
apis
that
they
have
they're
registered,
but,
like
thousands
and
everything,
is
the
for
the
synchronous
apis
in
apis
guru.
You
can
find
like
over
2000
examples
of
open
api
files
so
again
like
when
you're
starting
with
open
api.
A
A
Then
then,
something
from
from
the
ground
and
api
tracker
has
seven
using
dpi
examples,
and-
and
it's
not
because
I
don't
know-
like
somebody's
lazy
and
not
not
putting
them
and
it's
first
of
all,
because
even
driven
architectures
in
majority
of
cases,
they
are
internal
apis
and
they
are
responsible
for
the
communication
inside
the
product,
not
as
a
as
a
interface
to
the
outside
world.
In
majority
of
cases,
it's
internal.
So
if
it's
internal
then
why
people
would
share
their
internal
apis.
A
So
the
like
the
largest
amount
of
the
examples
that
I've
mentioned
here.
It's
websockets
because
from
the
public
perspective
of
public
apis,
the
most
common
are
websocket
based
apis
because
that's
mainly
designed
for
the
ui.
So
they
have
to
be
public
for
the
ui
and
also
sometimes,
but
very
rarely,
it's
mqtt,
which
is
for
iot
use
cases.
So
that's
what
make
even
driven.
A
A
It's
even
much
more
complicated
like
asking
api
like
open
api,
it's
just
for
some
so-called
reference
documentation
where
you
describe
everything
that
you
can
do
with
the
application,
but,
as
you
know,
especially
like
google
summer
of
dogs
mentees
that
already
started
and
got
familiar
with
the
whole
information
architecture
that
alejandra
recently
introduced
like
reference.
Docs
is
just
part
of
the
entire
of
the
entire
information
architecture.
There
are
more
information
that
you
have
to
provide
more
documentation,
tutorials,
etc.
A
This
thing
that
I
call
setup
is
because
it's
also
good
to
understand
these
two
different
setups
in
even
german
architectures,
because
they
also
cause
some
headaches
in
us
and
api
to
zero,
because
these
two
setups
are
different.
You're
gonna,
see
in
a
second.
Why
and
because
they're
different
and
they
show
different
perspectives.
A
You
can
imagine
that
if
you
have
more
than
one
perspective
with
describing
it
with
one
spec
is
also
is
getting
complex.
It's
not
com
getting
complex
only
because
of
how
you
put
the
information
in
the
spec,
but
it's
also
when
you
have
two
contexts
like
you
have
two
different
ways
of
doing
things.
When
people
come,
for
example,
to
asking
api,
they
just
know
their
context.
They
just
know
their
setup
that
they're
working
in
and
they
don't
know
all
the
different
setups.
A
So
for
them
it's
hard
to
digest
like
why
something
is
done
in
aspect.
This
way
why
it's
not
more
simplified,
and
it's
taking
us
a
lot
of
time
as
well
to
address
these
questions
and
explain
why
things
work
in
using
api
this
way,
and
not
the
other,
but
yeah,
go
talking
about
the
setup,
the
first
setup,
something
that
I
just
called
here:
a
client
and
a
server.
So
basically,
that's
the
simplest
one,
and
it's
very
easy
to
present
in
case
of
web
sockets.
A
No,
so
they
are
connected
through,
let's
say
a
websocket
to
the
server
that
gives
you
a
status
updates
and
and
there's
a
there's,
a
connection
that
is
maintained
over
which
you
get
updates
and
you
know
like
frankfurt
arrived
san
francisco
is
delayed.
Warso
is
not
gonna,
come
because
there's
a
strike
of
some
folks
at
the
airport,
and
that's
that's
where
you
have
this
communication
between
client
and
different
clients,
multiple
clients
and
one
server.
A
So
it's
just
one
place
that
exposes
the
messages
and
sends
the
messages
about
the
status,
and
you
have
multiple
clients
connected
directly
to
this
single
server.
So
it
can
be
a
browser
where
I'm
checking
the
on
on
the
website.
I'm
checking
what's
the
status,
it
can
be
a
mobile
phone,
so
I
have
a
mobile
application.
That
also
is
subscribed
to
messages
from
this
websocket
connection
and
is
checking.
A
What's
the
status
changes
and
I
can
have
a
tv
screen
as
well,
and
it's
important
to
know
that
in
this
setup,
where
you
have
multiple
clients
in
the
server
asking
api
is
used
to
describe
the
server
this.
This
flypoland.com,
where
asking
api,
describes
okay,
how
the
server,
how
to
connect
to
the
server
if
it's
web
socket
or
not,
how
what's
the
url?
A
What
are
the
messages
like
how
the
message
the
status
message
looks
like
what
information
is
presented
in
the
object
where
I
can
see
the
the
name
of
the
airport
in
the
in
the
status
update
in
the
message
where
I
can
see
if
it's
arrival
or
departure
all
of
this
is
described
for
the
server
and
it's
described
for
the
clients,
so
the
browser
implement
the
developer
that
implements
the
browser
he
from
the
asking
api
document.
He
learns
how
the
server,
how
to
talk
to
the
server?
A
What
I
can
expect
from
the
server
so
to
summarize,
as
an
api
file
for
this
websocket
server,
contains
information
how
to
how
everything
how
all
the
messages
are
are
being
like.
What
kind
of
messages
are
being
delivered?
You
can
also
what
kind
of
messages
you
can
send
and
how
you
can
connect
to
the
server.
A
Now
the
thing
gets
more
complicated
when
again
people
come
from
different
world
worlds,
they
never
did
websockets.
They
never
had
to
deal
with
this
client
server
approach
and
they
are
coming
from
the
setup
of
like
like
this
fire
and
forget.
So
when
you
have
producers,
consumers
or
a
server
that
can
be
a
producer
and
a
consumer
at
the
same
time
and
then
there's
a
message
broker.
So
there's
additional
servers
somewhere
in
the
middle
between
all
those
different
services
responsible
for
delivering
messages.
A
So
I
tried
to
do
I
had
a
bigger
diagram,
so
I
split
it
into
smaller
parts,
so
it's
not
so
overwhelming,
as
it's
gonna
be
in
the
end,
so
we
can
imagine
again
like
something
related
to
flights,
so
there's
a
ui
where
I,
as
a
user,
can
go
and
ask
like
okay,
give
me
updates
about
this
and
this
flight
and
send
it
to
this
and
this
phone
number
and
from
the
ui
to
flight
subscriber
service.
So
the
service
that
is
handling
the
like
accepting
the
information
about
the
new
subscriber.
A
A
We're
gonna
send
you
updates
whenever
they
show
up
now,
but
then
the
flight
subscriber
service,
it
is
not
sending
a
http
post
like
a
synchronous,
call
to
another
service
that
will
and
ask
him
like
hey,
monitor
service.
Please
do
monitor
flights
for
this
and
that
user,
the
subscriber
service
sends
it
to
a
broker.
A
So
that's
this
in
the
middle,
so
we
have
a
broker
in
this
case.
In
this
example,
it's
a
mqtt
broker.
So
it's
again
it's
a
server
like
any
other
that
has
that
implements
mqtt.
That
uses
a
a
an
application
like
mosquito
that
implements
mqtt
protocol
and
in
there
you
have.
You
have
topics
like
so.
Basically,
you
can
imagine
like
a
service
that
is
consists
of
like
multiple
different
pipes
with
different
names,
and
so
the
subscriber
service
sends
a
message
to
a
flight
queue.
A
The
monitor
service,
the
one
that
is
checking
really
what's
the
status
of
the
flight,
as
I
said
like
it,
doesn't
not
communicate
the
monitor
service
does
not
communicate,
maybe
I'll
make
it
smaller
yeah.
The
monitor
service
does
not
communicate
with
subscriber
service
directly
they.
The
whole
communication
happens
over
this.
This
message
broker
this
one's
one
piece
of
of
like
one
broker.
A
That
knows
what
different
topics,
what
different
cues,
what
different
channels
there
are
different
names
for
it
are
there
and
if
the
message
got
delivered
to
fightq
the
broker
knows
that
monitor
service.
When
it
started
it
asked
broker
okay.
Whenever
you're
going
to
have
some
messages
sent
to
flight
queue,
please
send
them
to
deliver
them
to
me
now
what
it
does.
A
A
So
it
sends
message
back
to
the
broker
on
a
given
queue
and
then,
in
the
end
we
have
a
notifier,
a
user
notifier
service
that
lis
is
listening,
is
subscribed
to
flight
status
channel,
so
monitor
service,
send
a
message
to
flight
status,
channel
on
the
broker
and
then
broker
knows
okay.
User
notifier
service
wants
to
have
all
the
messages
coming
to
flight
status,
so
I'm
gonna
send
a
message
to
user
notifier
service.
A
What
the
what's
the
stat
of
status
of
a
given
given
flight
and
then
notifier
service
knows
how
to
figure
out
who
was
it
for?
What's
the
phone
number
and
then
in
the
end,
it's
just
doing.
In
this
case
the
synchronous
call
to
the
external
independent
sms
service,
asking
okay,
send
this
and
this
information
to
this
and
that
number.
A
So,
in
the
end
it
looks
more
or
less
like
this,
like
the
there
is,
so
you
can
see
like
it's
not
just
asking
it's
sometimes
synchronous
communication,
sometimes
asynchronous
communication,
so
you
can
see
like
the
first
interaction.
It's
synchronous,
then,
whatever
happens
in
between
the
services
in
this
microservices
setup
and
the
broker.
That's
pure
asynchronous
communication,
all
based
on
queues,
subscriber
service.
Doesn't
care
like
subscriber
service,
doesn't
care
if
it's
monitor
service
or
some
different
service.
A
A
The
relevant
is
the
the
payload
of
the
message
that
was
sent
to
flight
status,
and
then
it
can
figure
out
where
it
should
send
the
final
call
to
a
service
that
will
send
a
message
so
mapping
it
to
donkey
and
shrek
like
so.
Here
was
the
donkey
like
donkey,
went
to
the
ui
and
said
like
okay,
I
want
to
know
when
we
would.