►
From YouTube: AsyncAPI SIG meeting 13 (Sep 3, 2019)
Description
This is the recording for the AsyncAPI Special Interest Group (SIG) meeting #13.
Attendees:
- Emmelyn Wang
- Fran Méndez
- James Higginbotham
- Jonathan Schabowsky
- Łukasz Gornicki
- Marc DiPasquale
- Raisel Melian
- Travis Reeder
- Waleed Ashraf
Moderation:
- Fran Méndez
Agenda:
- Publish/Subscribe semantics
B
Cooled
so
so
the
meeting
today
is
actually
for
this
debate
generated
in
the
select
channel
and
out
of
the
stock
channel,
but
most
of
you
probably
don't
see
it.
So
the
thing
is
that
from
in
person,
one
publish
and
subscribe,
where
were
seen
as
the
same
from
the
same
point
of
view
of
open
API,
for
instance
like
from
the
consumer
point
of
view,
it
means
that
if
you
see
publish
in
the
spec
it
means
that
you
can
publish
and
a
second
Sumer
or
a
set
a
user
or
I.
B
Don't
I,
don't
like
to
use
consumer
because
it's
an
overloaded
term
right.
That's
a
client
and
the
same
for
subscribe.
You
see
if
you
see
subscribe,
it's
because
you
can
subscribe,
but
in
since
I
saw
a
problem
kind
of
problem
in
pursuing
one
of
people,
not
really
understanding
the
point
of
view
of
the
birds,
I
decided
to
change
it
from
the
other
side
like
okay,
if
you
see
publish
it
means
that
this
application
is
gonna,
publish
and
you
as
a
consumer
can
subscribe
sites,
the
opposite
right
that
was
fired
until
I.
B
Think
I'm
till
until
we
had
some
to
him
and
we
could
test
it
a
little
bit
more,
the
real
candidates
and
all
that
and
then
people
started
noticing.
This
is
weird.
I
was
suspecting
that,
to
be
honest,
it's
weird
for
me
too,
the
reason
I
did
it
was
as
I
mentioned
it's
because
people
were
people
were
using
it.
The
the
the
other
way
around.
B
B
I've
been
investigating
a
little
bit
myself
and
in
in
the
pros
and
cons,
but
I
don't
want
to
distort
the
opinions
here
or
the
conversation.
So
I'm
not
gonna.
Stop
myself.
I,
don't
want
to
say
my
opinion
first.
Otherwise
some
people
can
get
like
you
know,
biased,
so
either
either
with
me
or
against
me.
It
can
be,
it
can
be
buy
it.
Sir
I
want
to
hear
from
you.
B
B
But
since
it's
an
API
also
supports
HTTP
for
streaming
API
is
it
was
mandatory
to
consider
this
case
too,
and
that
was
done
in
purpose
like
use,
synchronous
and
asynchronous
protocols
just
to
see
how
they
fit
together,
and
this
get
endpoint.
You
know
supposedly
keeps
the
connection
open
and
you
get
status
updates.
You
know
as
an
HTTP
streaming
API
and
then
in
parallel
you
have
an
A
to
B,
endpoint
or
Channel
right
with
orders.
You
know
subscribe
to
order
status
messages,
so
the
idea
was
to.
B
To
test
this
simple
example:
I
know
I've
done
them
on
purpose
because
from
I've
done
it
on
purpose
that
this
this
example
is
oriented
to
sharing
the
API
with
third
parties
like
like
Travis,
said
like
what,
about
certain
days,
your
API
with
third
parties
right
just
so
far,
we've
been
considering
so
much
internal
use.
Cases
like
how
to
how
to
use
the
spec
to
orchestrate
micro
services,
for
instance,
or
all
this
stuff
right,
but
not
so
much
about
sharing
with
third
parties
and
therefore
there
could
be
a
lack
of
feet.
B
Super
quick:
that's
an
async
API
to
file.
We
have,
as
I
said,
we
have
a
broker
with
AMQP,
that's
supposed
to
be
in
the
e-commerce
system
box.
We
don't
care
about
the
internal
implementations,
supposedly
there's
a
broken
there
and
our
HTTP
ends.
Okay
channels
are
order
status
and
you
have
a
subscribe.
So
this
one,
for
instance,
this
one
is
seen
from
the
client
perspective.
Okay,
as
in
open
API.
First,
so
you
can
subscribe
to
receive
messages,
write
it.
Then
you
have
message
X
whatever
we
don't
care
so
much
about
the
content
of
the
messaging.
B
B
This
is
just
an
example,
so
maybe
it
will
make
sense
in
the
future
to
to
add
support
for
open
api
chunks
into
the
HTTP
bindings,
but
that's
a
side
conversation
another
conversation
and
and
then
you
have
a
kewpie
with
exchange
decoration
like
there's
an
exchange
which
name
is
public.
The
type
is
a
topic,
the
type
it's
durable.
The
queue
is
durable,
blah
blah,
okay
and
then
you
have
a
binding
key,
which
is
orders
asterisk.
B
Same
thing,
for
the
other
end
point,
which
is
last
order,
this
one
it
only
has
the
HTTP
binding
and
again
this
is
a
post.
This
is
looking
a
lot
like
like
open,
API
right,
but
the
same
in
the
same
document.
You
have
the
two
words
you
have
the
HTTP
and
you
have,
and
you
have
them
messaging
once
right
through
the
the
bindings,
because
you
can
do
you
can
customize
how
a
cinch
API
behaves
in
depending
on
the
protocol.
B
So
that's
one
way
of
saying
it:
I'm
not
gonna
go
into
the
components,
because
that's
not
important
now,
and
then
we
have
the
other
example,
which
is
this
one
and
if
this
is
seems
like
an
async
API
so
far,
this
is
seen
from
the
application
point
of
view,
so
the
e-commerce
system
will
publish
messages.
So
then
the
consumers
can
consume
this
messages
right.
It's
gonna
publish
messages
as
responses
as
HTTP
responses.
B
That's
how
you
that's
how
the
e-commerce
system
tablets,
so
you
see
that
there's
not
so
much
information
here
for
it
to
be
like
it
was
in
the
previous
example.
Here
you
don't
really
have
much
information.
It
is
I
mean
this.
Could
be
debated,
but
probably
this
could
be
augmented,
the
could
be
similar
to
the
other
one,
and
then
you
have
same
thing.
This
is
this
is
the
same
as
the
other
one.
It
doesn't
change
just
messaging.
This
is
fired
and
same
thing
for
last
wonders.
B
B
D
D
If
there
is
a
we
available,
the
SUBSCRIBE
thing
we'll
be
referencing
to
a
publish
method
in
another
async
APA
documentation
which
will
be
another
services
publishing
passages,
and
then
this
service
will
subscribe
them
in
the
SUBSCRIBE
and
then
there
will
be
a
publish
which
this
services
publish.
So
that's.
What
is
my
understanding
of
subscribe
and
published
in
a
service.
B
D
F
That's
what
a
curl
is
right.
Yes,
discussion
is
whether
that
should
be
flipped
around
yeah.
Basically,
whether
these
AC
KPI
documents
should
be,
you
know
given
out
to
third
parties
so
that
they
can
interact
with
your
service
right.
So,
instead
of
saying
my
publishes
on
this
channel
and
subscribe
to
this
channel
mo
say
if
you
want
to
interact
with
my
service,
publish
this
type
of
event
on
this
channel
and
then
I'll
do
what
I
do?
Is
it
and.
F
So
it's
more
it's
more
from
the
open,
API
point
of
view,
rather
than
from
the
services
internal
point
of
view,
and
the
conversation
in
slack
is
you
know
whose
point
of
view
are
we
looking
at
here
like
who's,
gonna,
see
these
documents
when
I
think
of
like
people
taking
these
documents
and
generating
code
and
whatnot
to
use
them,
then
it
seems
to
make
sense
to
be
from
the
open,
API
point
of
view
right
cuz.
Then
the
code
will
match.
The
document
will
be
whatever
it
got
published
to.
D
D
Even
for
like,
if
we
use
it,
you
are
right
as
if
it
is,
this
document
would
be
for
external
users,
but
in
my
company
we
use
them
internally.
But
still
our
like
perspective
of
developer
is
when
we
we
say
like
okay,
you
need
to
listen
to
this
event
from
that
service,
and
then
we
go
to
the
API
definition
of
that
service
and
see
what
message
is
publishing
and
what's
the
payload
and
then
we
can.
We
know
like
okay,
we
can
consume
this
message
in
whatever
service
we
want
so
who
use
them
internally.
D
D
G
I
think
no
matter
what,
but
where
do
you
see?
It
I
mean
if,
if
you
don't
have
start
from
the
beginning,
understanding
who
is
doing
what
there
would
be
always
people
confused,
because,
for
example,
if
you
right
now
right
now
we're
saying
okay,
this
is
what
this
service
is
doing
with
with
sterner
service
right.
This
is
this
service
is
polishing
and
is
consuming
this
when,
when
the
person
won,
it
was
wasn't
like
this
right,
so
I
I
was
always
confused.
G
F
To
me,
I
think
it's
less
important
but
like
if
you're
developing,
say
a
REST
API,
you
know,
maybe
you
start
with
the
open
API
thing,
or
maybe
you
start
you
just
build
your
API
and
you
know,
what's
going
on
behind
that,
API
doesn't
really
matter
to
the
rest
of
the
world
right.
It
only
cares
like
I
think
and
this
microscope.
It's
it's
order
system
that
Brian
just
showed
us.
You
know
the
people
interacting
with
that
order
system,
don't
really
care
what
it's
doing.
You
know
what
I
mean.
F
They
only
want
to
know
how
to
interact
with
it
and
that's
kind
of
what
the
rest
API
or
that
open
API
would
define.
So
you
create
you're,
creating
a
contract
that,
hopefully
you
never
break
so
these
other
services
can
use
it
and
interact
with
that
service,
and
you
know
they
have
this
contract
together.
You
know
what
I
mean,
so
these
micro
service
talked
to
each
other
and
you
can
have
both
sides
like
it
can
say.
F
If
you
want
to
talk,
if
you
want
to
talk
to
me
as
a
service
I'm
the
order
processing
service,
then
you
need
to
publish
orders
onto
this
channel
and
if
you
want
us,
you
know
after
I
process
an
order
I'm
going
to
publish
them
on
this
other
channel.
So
you
need
to
subscribe
to
that
channel.
If
you're
interested
in
what
you
know,
the
after-effects
of
what
I
did
with
the
orders
yeah.
H
H
If
I
might
just
share
this
real,
quick
and
walk
you
through
it,
I'm
not
going
to
spend
a
lot
of
time
walking
through
everything,
but
what
I
what
I
was
doing
was
I
was
realizing
that
the
beauty
of
a
OS
for
the
things
that
it
doesn't
do
perfectly
the
way
I'd
want
them
to
do.
It
really
does
an
excellent
job
of
capturing
the
interface
of
an
HTTP,
API
and
I.
Get
that
a
think.
H
Api
has
to
deal
with
both
sides,
but
but
I
think
we
tend
to
confuse
things
a
little
bit
as
a
result
of
this
and
I
think
we
might
need
to
reset
our
reference
point
a
little
bit
so
that
we
can
be
both
in
line
with
OAS,
as
well
as
making
sure
that
we're
addressing
the
architectural
concerns.
So,
from
an
OS
perspective,
it
defines
it
delineates
between
the
interface
and
the
server
instances
and
I
kind
of
take
some
issue
with
that.
H
But
it
allows
us
to
enumerate
the
list
of
servers
that
implement
this
interface,
and
so
it
mixes
the
interface
but
predominantly
focuses
on
the
interface
and
then
happens
to
mentions
some
servers
as
well
as
endpoints
that
we
can
use.
So
we
see
something
you
know
fairly
similar
over
and
over
again,
when
we
look
at
a
sync
API,
there's
I
think
an
opportunity
to
address
both
of
these
use
cases,
but
I
think
the
core
of
a
sync
API
should
be
the
interface
and
to
me
the
interface
is
really
the
channel
and
right
now.
H
What
it
feels
like.
Is
that
we're
trying
to
at
least
the
way
it
was
before
a
Fran
renamed,
a
few
things
I
renamed
the
verbs.
We
had
an
interface
which
then
talked
about
the
subscribers
or
publishers
which
then
referenced
again,
the
interface
wilt
from
interface
to
implementation,
to
interface,
and
it
confused
me
a
lot
and,
as
an
author
of
it,
I
have
to
start
thinking
about
the
implementation
when
the
goal
of
a
broker
based
message,
oriented,
middleware
or
event-driven
architecture
style
approach
is
to
decouple
those
things.
H
I
shouldn't
care
who's,
publishing
a
new
subscribing
I
should
care,
however,
about
the
contract
of
the
message
is
placed
on
those
channels
to
make
sure
that
both
publishers
and
subscribers,
no
matter
how
many
what
the
cardinality
is
on
both
sides
are
adhering
to
the
same
contract,
which
is
the
message
and
or
maybe
some
of
the
protocol
details
as
well.
So
what
I
wanted
to
do
is
say
is
there
a
way
that
we
can
use
a
sync
API
to
separate
the
interface
from
the
implementation?
H
Maybe
we
need
that
in
there
somewhere
and
I
need
to
take
a
look
at
that
I,
like
that
example,
he
he
posed.
What
we
might
be
able
to
do
is
take
that
and
then
layer
on
this
idea
of
publishers
and
subscribers
at
the
top
level
that
allow
us
to
define
actual
implementation
details.
If
we
want
to
Co,
generate
details
now,
I,
don't
know
exactly
what
this
is
going
to
look
like,
but
my
guess
is
it's
going
to
be
something
a
little
like
this.
H
Where
we
have
sorry,
let
me
pull
up
some
code
here
where
we
have
this
idea
of
publishers
and
subscribers
that
reference
the
channels,
therefore,
and
you
could
provide
additional
traits
if
you
wanted
to
for
those
components
that
are
actually
subscribing
and
publishing
to
those.
But
my
biggest
concern
really
is
the
interface
and
the
interface
lies
in
this
channels
block.
H
You
know
a
consumer
publisher
type
of
thing
outside
of
it,
I'm,
not
sure
where
that
belongs,
but
I
think
the
core
here
that
I
want
to
make
sure
we
come
away
with
is.
Can
we
all
agree
that
the
channel
is
the
interface
the
contract
and
we
need
to
make
sure
we
don't
have
any
implementation
details
about
what
services
are
publishing
or
subscribing
in
the
channels
block?
Because
that's
up
to
you,
architectural
II
and
that's
the
whole
point
of
a
loosely
coupled
system
that
a
sync
API
would
document?
Does
that
make
sense
I.
B
I
realized
that
what
you
say
it
like
the
channel
is
the
interface
and
then
more
people
were
coming
to
me
like
hey
I,
don't
really
care
who's,
publishing
or
subscribing
I
just
want
to
list
a
list
of
channels
and
the
messages
that
are
going
to
be
flowing
there
and
that's
it
I
don't
want
to
understand
who's,
publishing
or
subscribing
right,
but
the
problem
is
so
the
way
I
didn't
go.
That
way
is
because
of
tooling
basically
right
yeah
for
tooling
you
need
you
need
to
understand
what
the
specific
applications
gonna
do
right.
B
H
B
H
Would
make
an
argument
that
not
everybody
would
and
I
work
with
several
enterprises
that
don't
they
don't
generate
from?
They
use
their
specs
as
governance
as
respects
to
enforce
and
to
determine
if
run
time
is
actually
working
or
not,
but
but
what
I
wouldn't
do
is
drive
a
specification
purely
off
of
tooling.
If
you
need
tooling,
then
separate
tooling,
separating
the
tooling
semantics
away
from
the
interface
makes
sense.
H
So
if
you,
if
you
want
to
describe
more
details
about
what
that
component
needs
to
do,
the
interface
could
exist
on
its
own
and
then
you
could
write
the
definition
for
tooling.
But
what
I
wouldn't
want
this
to
devolve
into
is
how
the
what's
the
topology
of
your
architecture,
because
open
API
doesn't
even
get
into
that
yeah.
It
doesn't.
G
From
open
API,
when
you,
when
you,
because
an
open
API,
you
are
required
to
to
mention
the
verb
right
because
you
don't,
you
need
to
say
okay,
this
is
what
you
can
get
from
me,
and
this
is
what
the
service
is
posting
pouring
or
whatever
how
that
is
different
from
acing
API.
When
we
are
saying
okay,
we
are
polishing,
and
this
is
what
is
being
subscribe.
Attitude
at
I,
don't
still
don't
get
I
feel
sorry.
B
B
But
so
far
what
we
have
so
far
right,
because
you
know
it's
a
second-place
candidate,
so
we're
not.
If
we
keep
making
changes
and
changes
and
changes
to
spec,
then
we
will.
We
will
never
release
anything
right.
So
I
will
prefer
to
release
this
and
then
start
working
from
day
one
to
release
the
next
major
version,
which
will
realign
anything
right
and
and.
C
B
B
There
will
be
in
any
problem
in
lieu
in
in
having
the
verse
with
one
semantics
or
the
other
like
I
know
that
another
people,
for
instance,
used
things
the
other
way
around
with
question
one,
and
now
people
are
confused
because
of
the
new
meaning.
But
my
concern
is
not
so
much
about
educating
people.
You
can
educate
people
too,
you
can
tell
them
be
letters
like
hey.
This
is
the
meaning
and
that
you
should
stick
it
to
this.
My
concern
is
more
about
like.
B
Are
we
committed
a
mistake
by
changing
it
to
one
or
the
other
like?
Can
we
find
an
example
of
where
it
will
cause
problems,
because
if
it's
just
a
matter
of
point
of
view,
you
will
always
have
people
complaining
and
then
I
don't
like
this
point
of
view
banned
and
that's
fine.
My
concern
was
not
so
much
about
flavours
right,
it's
more
about
if
this
can
actually
cause
a
bigger
problem.
Having
you
know,
one
perspective
or
the
other,
you
know
what
I
mean.
F
But
one
more
thing
and
then
I
want
to
hear
your
opinion
yeah.
So
one
thing
that
would
also
benefit
of
having
the
flip
point
of
view.
The
open,
eight,
the
add
point
of
view,
I'll
call
it
well
one-
is
that
it's
more
in
line
with
open
api,
which
I
think
is
easier
for
people
to
gerak,
but
to
it
also
the
duplication
stuff,
where
everything
has
a
publish.
Everything
has
a
subscribe.
I.
F
Think
if
you
flip
the
point
of
views,
I
think
you
get
rid
of
that
duplication
quite
a
bit
because,
for
instance,
if
I
say
used
to
you
can
subscribe,
so
you
can
publish
to
this
channel
and
I'll
deal
with
that
stuff.
Like
publish
orders
to
this
channel
and
the
order
service
will
deal
with
it.
But
you
don't
have
another
service
that
needs
to
define
the
exact
same
check
with
the
opposite
operation.
It's
just
one
channel
one
day
model
of
one
operation
that
that
Porter
service
defines
because
that's
how
you
interact.
F
B
F
I
F
G
You
will
need
to
you
to
document
in
the
other
side
that
it's
subscribe
right,
because
we
were
saying
today:
okay,
these
Service
publishes
this
message
a
and
and
your
service
and
your
service
subscribe
to
that.
So
you
have.
We
have
the
thing
that
we
need
to
duplicate
the
message
of
create
another
another
file
and
references
from
there
right.
But
if
you
flip
this,
they
point
to
you.
How
would
you
can
read
up
document
in
let's.
F
Use
it
so
there's
two
two
things
at
one
like:
let's
say
the
order:
processing
like
in
my
toy
store,
Crona
type
thing
after
the
artist
processed
like
through
payment
processing,
it
goes
to
fulfillment
when
once
payment
processing
done,
it
gets
sent
to
fulfillment
right
so
fulfillment
there's
two
ways:
fulfillment
will
get.
The
message
will
be
a
published,
stuffed
this
fulfillment
channel
and
I'll
take
care
of
it
all
right
or
the
other
side
is
and
then
and
then
the
orders
or
the
payment
process
and
service
has
to
know
which
channel
to
publish
to
you.
F
But
the
order
service
doesn't
have
anything
that
says.
I
published
to
fulfillments
channel
fulfillment
defines
that
channel
in
that
contract
right
or
the
other
thing
is:
maybe
order
service
doesn't
care
and
they
just
publish
to
a
channel,
so
they
go.
I'm
gonna
publish
the
processed
order
to
this
channel
and
whoever
once
whoever's
interested
in
it,
can
attach
that
channel
and
do
this
thing
and
maybe
fulfillment
has
on
their
side
they
go.
Oh
I
am
interested
in
these
orders
that
are
done
processing
because
I
need
to
fulfill
them.
Wait.
D
F
The
contract
made
by
payment
processing
does
this
make
sense.
Sorry
if
this
is
a
bit
confusing,
but
payment
processing
says
I'm
publishing
processed
orders
on
this
channel
and
fulfillment
will
subscribe
to
it
or
whoever
else,
but
fulfillment
doesn't
define
that
description
it
just
as
a
service.
It
knows
it
needs
to
get
it
also.
It
subscribes
to
the
channel
that
making
a
processing
defined.
That's.
B
F
Subscribe
one
is
like
from
the
browser
collecting
an
order,
for
example,
or
a
new
order
comes
in,
and
the
payment
processor
says
you
need
to
send
stuff
onto
this
channel.
For
me
all
right,
so
that's
the
SUBSCRIBE
operation
and
it
may
have
a
publish
operation
or
it
may
know
who
to
talk
to
you
directly.
So
it
knows
it
has
to
talk
to
fulfillment.
So
it
says
it
to
fulfillment
subscribe
operation
in.
B
This
case
it
will
not
make
sense
to
have
a
subscriber
liberation
right.
Like
you,
you
read
the
tablet
operation
from
the
this
is
crime
operate
on
the
server,
take
right
off
from
the
service,
and-
and
you
just
can
you
know
that,
because
it
says
subscribe
there,
it
will
only
sorry
see
it's
the
other
way
around.
It's
like
you
will
never
have
a
stinky
bait
piles
with
the
public
operations.
You
will
only
have
subscribe
operations
right,
go.
F
D
We
should
I
think
we
should
flip
it.
From
this
point
of
view.
The
correct
implementation
I
think
yeah
what
it
is.
We
should
flip
it
like
France.
You
suggest
it
because
if
you
keep
it
like
this,
it's
okay
for
the
internal.
But
if
you,
if
you
are
supposed
to
give
your
a
sink
API
to
external
users,
they
won't
understand
it
because
this
because
the
French
way
it's
it's
tells
you
the
what
the
service
publish
and
when
they
serve
you
subscribe
to.
The
external
user
is
nothing
with
them.
D
G
D
B
G
B
F
F
I
And
maybe
maybe
just
to
chime
in
as
well
I
guess
I
agree
that
the
channel
is
definitely
the
interface.
I
also
agree
right
now
from
an
18-game
guys
specification
perspective.
We
are
defining
it
from
an
applications,
point
of
view
and
I
think
I
think
in
a
way
that's
good
like
from
a
tooling
perspective
and
in
a
way
it's
bad.
I
If
you
look
at
it
more
from
the
system's
perspective
of
what
you
could
do
right,
and
so,
but
what
what
you
know
we've
been
talking
about
from
a
solace
perspective
is,
is
that
you
can
generate
these
specifications
that
basically
show
you
what
your
app
looks
like,
which
is
kind
of
like
again
sort
of
the
server
implementation
side
of
arrest
service,
and
but
at
the
same
time
you
could
be.
You
know
what
we
might
want
in
the
future
as
well
as
sort
of
almost
like.
I
You
know,
and
this
is
a
bad
name,
but
you
know
either
a
catalog
or
a
broker
specification
of
all
the
things
that
you
could
do
based
off
of
what
applications
are
actually
doing
right.
So
you
have
sort
of
the
abstract
which
is
sort
of
the
what's
available
and
in
what
actions
are
you
available
to
do
against
the
broker?
I
And
then
you
actually
have
a
specification
that
map's
details
to
what
an
app
actually
does
so
that
then
you
can
have
code
generation
that
fixed
the
developer
experience
that
I
guess
that's
the
way
we're
sort
of
looking
at
the
world,
and
just
looking
at
that
you
know
a
CG
API,
2,
0,
0
or
C
1
at
least
does
something
for
the
app
side
which
is
good
I.
Don't
think
that
means
we're
done
at
all
and
I
kind
of
liked
James
sort
of
proposal
there
of
you
know.
B
C
A
Yeah,
just
maybe
other
the
channel
use
case
to
the
discussion
so
yeah
in,
for
example,
in
kima,
where
we
integrate
with
a
single
API.
We
started
using
from
the
very
beginning,
custom,
API,
one
zero,
of
course,
and
when
yeah
I
saw
RC
one
of
to
zero
I
was
confused
with
these
swaps,
swapping
of
the
words
not
because
I
felt
they
wrong.
A
Actually
I
was
afraid
that
I'm
using
them
wrongly
from
the
very
beginning,
because
actually
the
previous
version
was
confusing
and
and
why
was
it
confusing
because
for
us,
the
most
important
is
really
to
describe
what
events
are
broadcasted
from
the
from
the
application.
So
with
the
previous
version
we
had,
and
then
this
back
was
simply
saying
what
messages
you
can
subscribe
to,
but
like
physically
technically
you
don't
really
subscribe
to
the
application.
A
You're
subscribed
to
there's
a
broker.
You
subscribe
to.
There
are
channels,
and
you
simply
need
to
only
know
what
channel's
is
the
application
sending
messages
to
and
how
the
message
looks
like
I,
don't
believe
and
I
don't
really
want
to
know
from
the
suspect
point
of
view
to
which
system
at
the
moment,
in
this
particular
instance
of
the
cluster,
the
message
will
will
go
to
and
where
I
have
to
subscribe.
That's
for
us,
the
most
important
is
really
this
information
of
the.
A
What
is
the
list
of
the
channels
how
the
message
looks
like
and
this
this
new
approach
that
you
we
simply
say.
Ok,
we
publish
to
this
channel
and
this
channel
in
this
channel-
that's
much
more
clearer
for
me
for
the
developer,
that
is
about
to
extend
the
application.
So,
for
example,
we
like
Chema's
from
a
CP,
so
you
can
imagine
the
situation
that
you
have
e-commerce
application.
A
You
have
marketing
the
application
and
customer
service
application
and
the
developer
that
needs
to
handle
all
all.
So,
for
example,
he
needs
to
react
to
the
order,
then
maybe
do
something
with
the
marketing
application
and
then
also
do
something
with
the
customer
service.
He
only
wants
to
know.
Okay.
A
What
are
the
channels
coming
from
what
channel's
the
the
e-commerce
is
publishing
to
to
what
channels
marketing
this
publishing
to,
and
these
are
asking
a
PR
specs,
but
and
on
the
other
side,
you
also
want
to
see
open,
API
spec
with
the
API
definition,
so
I
can
so
for
us.
The
interaction
with
the
service
with
the
application
is
only
through
the
REST
API,
but
you
can
consume
an
extended
through
the
events
using
custom
API,
so
this
separation
actually
of
the
specs.
Also
it's
much
actually
gives
us
much
clearer
approach
here.
B
B
A
Yeah,
so
we
you
can
imagine
that
there
are
hormonal,
it's
like
yeah,
ecommerce
from
a
CP
marketing
from
a
CP.
That's
a
try.
They
all
have
different
rest.
They
are
so
ecommerce
is
trust.
The
API,
if
you
want
to
communicate
to
it
marketing,
is
all
data.
So
quite
something
like
graph,
you,
let's
say,
and
the
third
one
is:
let's
the
graph
you.
So
they
have
three
different
interfaces
you
can
talk
to
with
from
through
rest,
but
then
they
are
also
connected
into
the
kubernetes
service
that
server
cluster.
A
A
We
know
what
channels
to
create
actually
inside
the
the
cluster
and
to
what
channels
you
can
subscribe
to
and
as
a
user,
but
you
say
as
a
user
as
a
developer,
but
your
perspective
is
rather
you
read
the
information
about
the
application,
what
it's
publishing
and
not
to
what
you
can
subscribe
to.
You
know
what
I'm
trying.
D
D
B
To
only
create
one
one,
a
syncope,
a
file
like
you
only
have
one
like
the
internal
one,
for
instance,
and
then
from
for
the
external
one.
They
can
just
do
the
opposite
like
if
the.
If
the
birth
is
published,
it
means
that
you
have
to
subscribe
right.
Well,
no
turns
out
that
I
didn't
realize,
there's
a
problem.
There.
F
B
You
may
you
may
publish
to
an
end
point.
I
can
explain
this
with
diagram
with
the
previous
diagram.
I
think
it's
gonna
be
easier,
so
this
is
the
same
the
same
as
before,
just
a
little
bit
reorganized.
So
if
you
notice
here
there
is
a
this
could
be
seen
as
a
publish
I
say
this
right
now,
like
the
comer
system
is
publishing
the
event
and
one
could
say
like
a
because
this
is
families
you
want
to
subscribe.
Yeah,
that's
fine,
but
this
this
box
here
represents
the
channel.
B
Okay,
I,
like
can
be
a
queue,
can
be
a
channel
attached
to
a
queue
wherever
right,
but
this
channel
actually
has
two
endpoints.
It
has
this
endpoint
here
you
can
see
my
cursor
right,
so
it
has
this
endpoint,
like
the
cover
system,
is
published
in
to
this
channel
in
this
endpoint
in
this
network.
Address.
Let's
go
like
this
and
you
can
subscribe
in
this
one
in
this
case
they're
both
related
right,
but
because
you
publish
here
it
doesn't
mean
that
you
will
be
able
to
subscribe
here.
B
B
The
thing
is
that
we
are
mixing
here,
the
concept
of
channel
and
end
point
and
we're,
assuming
that
the
end
points
are
always
attached
to
the
channel
right
and
that's
not
always
the
case.
So
some
are
why
I'm
saying
this
so
my
opinion
and
now
that
I
think
it's
it's
good
time
to
say
that
I
think
my
opinions
will
be
to
keep
it.
B
Once
you
get
used
to
this,
you
get
it's
super
easy
like
it
says,
Polly's
and
you
if
you
have
to
generate
code
or
if
you
have
to
build
tooling
on
top
of
the
spec.
That's
super
easy
super
clear,
but
yet,
as
James
said,
maybe
we
are
maybe
we
are
polluting
a
little
bit.
He
didn't
say
that,
but
you
know
building
a
little
bit
the
the
spec,
because
we
want
to
adapt
it
in
favor
of
totally,
which
is
there's
nothing
wrong
with
this.
B
B
B
B
B
H
H
H
So
if
the
channel
is
the
interface,
does
the
message
belong
at
the
channels
level
and
then
that
would
allow
people
to
define
channels
with
messages
for
their
interfaces
without
the
bindings
or
they
can
include
the
bindings.
In
other
words,
they
could
progressively
add
more
to
it.
It
makes
the
specification
little
bit
more
approachable,
but
just
by
shifting
that
one
level
to
the
left.
B
B
H
I
mean
that's
I,
know:
API
design
is
very
subjective.
The
way
that
I
generally
tend
to
approach
things
is
to
try
to
group
things
together
and
and
make
sure
that
there's
a
parent
that,
if
it's
optional
than
everything
underneath
it
goes
away,
and
that
was
I,
think
the
thing
that
I
I
struggled
the
most
with
version
2
was
that
for
me
to
actually
get
into
just
the
definition
of
what
the
message
format
looks
like
when
I'm,
modeling
and
I
have
to
start
thinking
about,
publish
and
subscribe
and
I'm.
H
Not
you
know
the
channel
to
me
is
the
one
that
should
have
the
definition
of
the
message.
If
the
binding
requires
a
different
message
structure,
then
that's
effectively
a
different
channel,
because
you're
gonna
have
to
to
do
that
right
now.
What
we're
saying
is
a
channel
could
have
any
number
of
message
formats
based
on
how
you
interact
with
a
subscriber
publish.
B
You
will
want
to
have
a
way
to
describe
that.
This
message
is
only
for
sending
like
a
request
for
response.
You
know
messaging
like
a
message
like
an
embroidered,
for
instance.
This
is
fine.
If
you
have
a
broker,
you
have
a
channel,
that's
totally
fine.
The
usually
good
practice
is
to
only
have
one
message:
definition
for
per
channel
right
and
and
that's
totally
fine
you
don't
you
don't
care
of
you,
not
care
about
publishing
and
subscribing,
but
woman.
We
enter
the
land
of
support
in
HTTP
or
because
the.
H
F
B
B
When
I
was
using
async
API,
one
I
was
I
was
still
able
to
define
internal
systems
right
it
might,
it
might
work.
It
was
probably
a
little
bit
weird.
Like
look
I
said
like
it
was
strange
right
because
she
wanted
to
have
fabulous
or
when
something
is
probably
not
because
you
can
publish,
but
you
could
do
it
and
there
was
no
problem.
I,
don't
like
you
just
need
to
and
understand
years
need
to
learn
this
right.
B
But
when
it
comes
to
external
api's,
you
have
to
offer-
or
you
have
to
tell
people
like
a
this-
is
my
internal
file
and
you
as
a
consumers,
will
have
another
Aysen
KPI
file
and
they
sue
both
play
together.
Well,
so
you
end
up
offering
and
it's
in
keep
a
file
for
third
parties,
but
you
cannot
control
how
the
third
party
I
think
APA
file
looks
like
right,
because
we
don't
know
that
basically
so
yeah,
it's
it's
a
little
bit
weird.
B
In
this
case
we
lose
a
little
bit
of
control
of,
or
we
put
too
much
responsibility
on
people
to
handle
that
things
are
cohesive
and
then
don't
break
so
so
yeah.
It's
a
and,
and
and
if
we
go
to,
if
we
go
this,
if
we
keep
going
this
way
like
your
person,
to
probably
we're
ditching
a
good
use
case
for
for
a
sync
API,
which
is
the
use
case
where
it
is
for
public
API
right
like
to
imagine
like
WebSockets,
api's
or
or
HTTP
to
with
server
sent
events.
Api
and.
I
Why
do
we
have
to?
Why
does
it
have
to
be
one
or
the
other?
Why
can't
we
have
a
mission
to
support
both
Gunny
right
now,
probably
90%
of
messaging
utilization
is
internal
I
think
the
world
is
starting
to
do
more
and
more
external.
Certainly
you
know
many
of
our
customers
are
doing
that
as
well,
but
I
mean
to
me.
We
need
to
be
able
to
support
both
methods
to
really
solve
the
overall
problem.
That's.
B
My
point:
if
we
keep
the
the
vision
that
we
have
a
Mason
KPI
y1
or
we
can
do
both.
If
we
keep
going
this
way
like
in
KP
2,
then
we
are
not
supporting
world
external
useful.
You
know,
and
and
and
we
will
be-
we
will
be
putting
too
much
responsibility
into
the
into
the
consumers
to
maintain
their
own
SM
KPI
files,
when
it
doesn't
really
make
sense,
because
you
already
have
one
file
that.
B
You
know
like
in
this
case
is
ecommerce
is
something
new
like
hey.
This
is
how
you
can
interact
with
me.
Why
you
like
meeting
another
one
right,
just
use
this
one
I,
don't
know
I,
feel
like
we
mix
and
mix
it
too
many
things
that's
about,
and
and
that's
why
I
want
to
keep
it
like
the
more
conservative
as
possible,
instead
of
making
a
big
change
now
important.
A
It's
good,
it's
gonna
be
again
confusing,
simply
so
something
that
we
already
have.
But
so
you
could
say
no,
it's
not
a
big
problem,
but
what
I've
learned
over
years
is
that
making
quick
decisions
that
change
something
quite
heavily
right
before
release,
there's
a
something
back
in
my
head,
saying
like
wow,.
B
And
that's
why
you
know
it's
and
then,
if
I
change
and
I
start
looking
more
than
Turtles,
then
it
will
be
like
really
strange
me
so
yeah,
maybe
I,
don't
know,
I
mean
with
this
there's
an
also
another
way
of
like
I'm.
We
could
do
it
in
a
different
way.
Like
there's
a
you
know,
couple
on
the
route
of
the
document
saying
this
is
how
you
saw
interpret
the
birds.
H
B
H
If,
if
mentally,
if
I
switch
to
thinking
about
the
channel
as
the
interface,
then
the
channels
the
thing
doing
the
work,
then
just
like
open
API,
the
channel
is
the
thing:
that's
either
publishing
or
accepting
just
like
an
HTTP.
We
accept
so
so
in
some
ways.
It's
it's
really
about
a
lot
of.
It
is
about
how
we're
going
to
frame
this
and
we
de
frame
it
by
this
way.
Vacation.
Like
you
kind
of
said
you
know,
maybe
you
have
jokingly
or
whatever,
but
yeah
just
being
able
to
frame
it
up
or
we.
H
I
don't
want
to
make
a
major
change
at
the
last
minute,
but
I
also
don't
want
to
say
this
has
to
be
the
last
minute
in
it.
If
the
right
thing
to
do
for
the
community
is
to
slow
down
a
bit
and
take
stock
and
examine
multiple
angles
so
that
we
can
have
a
thoughtful
decision,
then
that's
that's
what
we
might
want
to
do
and
if
that
means,
we
have
to
extend
the
deadline
from
what
we
anticipated.
Then
that,
maybe
is
the
right
thing
to
do.
H
The
right
thing
to
do
isn't
always
to
either
keep
it
the
same,
to
meet
the
deadline
or
to
rush
and
still
meet
the
deadline.
Sometimes
it's
to
move
the
deadline,
so
so
I
guess
what
I'm
looking
for
is
you
know
what
you
know?
Maybe
the
output
of
this
is
we
all
go
off
and
start
thinking
about
it.
Maybe
we
narrow
down
a
couple
of
decisions.
Maybe
we
start
taking
what
we
already
have
that
we've
done
internally
and
and
reorient
it
to
some
new
structure
that
we
just
see
what
it
looks
like.
H
We
don't
change
the
tooling.
We
don't
change
anything
else.
We
see
what
it
looks
like
just
like
when
we
design
our
API
is.
We
have
to
kind
of
come
back
and
say:
does
this
work
and
maybe
do
some
prototypes
or
some
mocks
to
make
sure
that
this
is
going
to
support
what
we
want
and
that
it's
feasible
for
for
the
majority
of
the
use
cases.
B
All
the
time
you
know,
maybe
the
way
to
do
it
is
just
responded
that
way
right
like
if
this
such
a
major
concern
around
the
spec,
not
only
in
person,
and
it
wasn't
really
in
question
one-
maybe
or
maybe
not
I
mean
if
it's
if
it
was
already
in
version.
One
I
mean
that's
fine,
that
the
problem
is
that
between
this
person,
I
don't
want
to
be
an
easy
person
free
in
in
six
months,
right
right.
H
B
B
B
D
I
D
Would
be
okay,
do
we
are
take
a
decision?
The
next
call,
maybe
next
Tuesday
I,
will
also
look
into
our
like.
How
would
you
define
in
further
the
use
cases
and
also
talk
over
like
documentation
team
if
we
are
going
to
use
it
externally,
how
it
would
make
sense,
and
then
I
can
construct
a
like
a
final
thing
and
then
making
shade
in
this
like,
and
we
can
discuss
in
the
next
I
think.
B
That
will
be
awesome
yeah,
even
even
just
like.
You
know,
just
tell
me
how
you're
easily
eight
each
of
you
how
you
or
how
do
you
plan
to
use
it,
or
you
know,
what's
your
mass
common
use
case
and
then
I
think
that
that
just
doing
that
will
help
up
right.
Just
doing
that
without
you
know,
without
having
to
come
to
me
and
say
hey,
this
is
what
I
will
that's
postponed
based?
You
know,
let
sister
tell
tell
me
or
where
would
you
like
to
see
this
peg
going?
B
You
know
I
mean
if
you
wanted
to
add
it
as
well.
That's
fine,
but
you
know,
sharing
your
use
case.
I.
Think
it's
really
important,
because
when
I
was
free
previously
to
working
full-time
on
async,
API
I
have
a
it's
funny,
but
I
had
a
better
perspective
of
how
to
use
async
API,
because
I
was
using
it
daily
right
at
my
job
right
now.
I
don't
have
a
use
case
myself.
I
don't
have
a
company
where
I
need
to
use
async,
API,
in
fact
that's
funny,
but
now
I'm
liking.
B
D
D
B
A
B
Message
of
slack
and
yeah,
to
put
it,
doesn't
have
to
be
something
really
I
mean
really
elaborated
right.
So
just
tell
me
you
use
case
I.
Think
I
know
your
use
case,
for
instance,
but
yeah
like
I,
don't
know
what
do
you
felt,
for
instance,
moving
from
a
syncope
I
wanted
I
pay,
it
simply
paid
to.
What
did
you
like
what
these
on
you
didn't
like
and
yeah
regarding
this
topic
right,
like
comment
subscribe
and
all
the
stuff
why
it
will
be
better
for
you
in
one
way
or
another.
B
It's
just
like
a
regular
conversation
in
slacks
doesn't
have
to
be
super
elaborated
I
just
want
to
gather
all
points
of
view
right.
So
when
I,
when
I'm,
for
instance,
testing
the
news
in
deaths
from
spec
or
meaning
from
spec
I
can
take
into
consideration
all
the
use
cases
right
like
what
will
happen
to
look
at
what
will
happen
to
things.