►
From YouTube: Thinking Out Loud #7 — with Ian Cooper
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
everyone
once
again
to
thinking
out
loud
episode.
My
name
is
fran
mendes
for
those
of
you
who
don't
know
me,
and
I
run
I
work
as
a
director
of
the
async
api
initiative
and
also
director
of
engineering
advancement.
A
So
I
like
to
introduce
this
this
all
the
I
think
in
a
thinking
of
loud
episodes,
start
by
saying
like
what
is
about
right
like
what's
thinking
out
loud
like.
Is
it
a
podcast?
Is
it
something
like
a
just
a
live
stream
or
what
it
is
like?
What
does
it
have?
What
is
special
about
thinking
out
loud
right,
and
so
let
me
explain
like
thinking
that
loud
is
it's
a
space.
It's
a
live
stream
right
that
we
that
I
host
here
every
every
week.
A
So
far,
let's
see
if
we
can
keep
this
rhythm-
and
I
invite
people
to
to
join
me
during
this
time
and
discuss
a
little
bit
about
specific
topic
right
every
week
is
a
different
topic
and
even
though
sometimes
I
I
may
ask
questions
to
the
to
the
guest,
this
is
not
an
interview.
A
This
is
a
what
I
like
to
call
a
thinking
process,
so
we're
here
to
think
out
loud
like
for
real,
and
we
may
end
up
producing
some
good
thoughts
and
coming
up
with
some
good
thoughts
and
may
not.
So,
let's
see,
let's
see
what
happens
and
as
I
used
to
say,
like
thinking
out
loud
can
be
the
most
boring
show
so
so
yeah,
it's
not
the
show.
Actually,
so
so
yeah
stick
with
us
anyway,
it's
not
gonna
be
boring.
A
I
promise
if
in
case
you
like
even
driven
architectures
apis,
and
you
know
and
thinking
about
these
things.
So,
oh
before
I
forget
in
case
you
need
or
prefer
to
have
subtitles
or
closed
captions.
We
are
only
able
to
enable
this
on
on
youtube,
so
please
have
to
head
over
to
youtube
to
to
watch
it
there,
and
I
made
sure
I
made
sure
that
closed
captions
are
enabled
there.
A
So
today,
what's
the
topic
for
today,
so
today
I
I
like
it
to
you.
I
wanted
to
invite
a
think.
It's
already
like
an
old
member
of
our
community.
It's
not
because
he's
old
right!
A
It's
because
it's
been
here
for
a
while
and
and
yeah,
so
we
wanted
to
discuss
about
something
that
happened
in
a
thread
in
a
tree
in
a
twitter
thread
like
we
said
that
something
happens
like
things
that
were
discussed
there
and
and
and
some
people
were
contrary
to
what
to
like
what
the
synthetic
is
doing
or
the
way
I
think
api
is
is
built,
or
you
know
like
in
some
ways
like
it's
negative
feedback
right
like
we,
we
don't
usually
get
a
lot
of
negative
feedback
and
and
that's
sad
because
I'm
sure
we're
not
doing
everything.
A
Well,
I
mean
I'm
sure
now.
I
know
we're
not
doing
everything.
Well,
it's
impossible,
so
so
yeah
I
like
to
hear
good
feedback
positive
feedback,
but
I
also
like
to
to
hear
people
say
hey.
So
this
is
not
quite
good
and
this
probably
have
to
be
changed
right
and
so
yeah.
A
So
in
this
thread
I
I
discovered
that
in
this
thread,
ian
was
involved
like
given,
given
this
his
opinion
and
and-
and
I
already
said,
the
the
guest
name
right
so
so
ian
cooper,
I'm
inviting
young
cooper
today
to
to
discuss
about
like
the
current
state
of
async
api,
what
can
be
changed
and
so
on
and
so
on.
So
let
me
introduce
ian
and
I'm
sure
he
will
be
able
to
introduce
himself
much
much
better,
hey,
hey
everyone.
A
So
oh
I'm
hearing
myself
a
lot.
I
don't
know
if
if
you
have
some
headphones
or
something
because
I'm
hearing
myself
and
it's
quite
weird.
D
A
Yes,
okay,
it
works.
So!
Oh
I'm
still
listening
to
myself,
that's
weird!
So
yeah!
I
was
saying
that.
Can
you
please
introduce
yourself
like
to
the
community
just
in
case
someone
doesn't.
B
Keeper
and
oh
I'm
getting
echo
now,
I'm
a
principal
engineer
at
the
minute:
adjusted
take
hikeaway.
So
we
deliver
you,
your
takeaway
for
you
dude
and
I
deal
a
lot
with
a
little
bit,
but
I
deal
a
lot
there
with
how
we
get
our
micro
services
to
talk
to
each
other.
B
So
events
http
any
kind
of
ending
you're
all
doing
well.
I've
got
a
lot
of
echo.
A
Yes,
I
was
going
to
mention
that,
maybe,
if
you
want
to
get
rid
of
the
headphones
and
we
get
back
to
the
initial
setup,
I
will
be
happy
to
deal
with
the
the
echo
myself.
I
don't
know
if
well
maybe
people
also
will
hear
the
echo-
I
don't
know
anyway
so
yeah.
So
I
just
wanted
to
mention
something
I
I
am
an
like
a.
How
do
you
say
that,
like
I
mean
an
avid
user,
not
an
avid
user
but
a
recurring
user
of
just
it?
I
like.
D
A
What
the
hell
what's
happening,
you
don't
know,
might
be
suffering.
You
told
me,
you
were
in
suffering.
A
Might
be
because
of
that
it
happens
to
me
in
in
firefox.
There's
all
these
noises,
so
maybe,
if
you
move
to,
I
cannot
hear
you
now.
A
Okay,
so
while
we
wait
for
ian
to
come
back,
is
there
any
topic
you
want
to
talk
about?
A
So
you're
still
in
time,
if
you
want
me
to
if
you
want
to
talk
about
something
people
in
the
in
the
chat,
I
think
it's
a
right
time,
while
ian
configures
his
sound.
B
B
A
Yeah,
so
it's
not
any
webkit
server
browser,
it's
it's
chrome.
In
the
end,
so
yeah
yeah
was
saying
that
I
am
a
regular
user
of
of
just
it.
I'm
sorry
for
those
who,
like
cooking.
Like
me,
I
actually
like
cookie,
but
I
don't
find
time
with
a
baby
even
less,
and
then
I
find
myself
like
this
is
this
is
much
easier
right
and
funny.
A
What's
funny
like
in
a
few
weeks
ago,
I
was
discussing
with
with
david
david
boyne
who's
in
the
chat,
by
the
way
that
we
should
be
creating
a
like
a
demo
application
using
async
api
and
specification
and
tools
right,
not
just
as
in
kpi
like
also
using
cloud
events,
and
you
know,
and
other
standards
out
there
and
see
how
everything
fits
together
and
experience
the
pain
ourselves
in
first
person
right,
because
when
you
spend
so
much
time
developing
tools,
you
frequently
forget
about
the
user.
A
A
B
I
can't
imagine
right
it's
it's
certainly,
I
mean
for
asynchronicity
that
there's
certain
parts
of
it
that
are
obviously
embarrassingly
asynchronous
and
that
can
really
help
in
the
sense
that
you
know.
Once
you
have
made
your
order
and
press
the
button,
it
all
happens
without
the
need
for
a
kind
of
user
interface.
Apart
from
us,
so
pushing
notifications
to
tell
you
that
you
know
your
order
is
on
its
way.
The
driver
is
nearly
10
minutes
away
and
the
whole.
B
Can
run
through
a
asynchronous
pipeline,
you
know
we
can
get
asynchronicity
around
the
user
experience
as
well
by
you
know.
When
you
look
at
a
restaurant
or
a
menu,
that's
probably
a
we've
built
a
what
we
call
a
projection.
Sometimes
people
call
kind
of
reference
data.
B
We
build
a
read,
only
store
of
events
elsewhere
in
the
system
that
effectively
is
actually
populating
council
on
that
data
as
well
to
be
yeah,
I
mean,
overall,
we
have
a
model
that
we
say
we
want
to
use
asynchronous
communication
between
services,
because
we
see
that
as
more
reliable
if
the
other
server
you're
talking
to
is
down,
it
doesn't
necessarily
matter
from
your
perspective
as
a
service.
B
So,
if
you
think
about
it,
if
you
can't
currently
add
restaurants
to
just
eat
that
shouldn't
stop
us
serving
you
from
existing
restaurants,
and
if
you
think
about
it,
you
know
we're
not
signing
up.
B
You
know
thousands
of
restaurants
a
second
we
are
serving
thousands
of
customers
a
second
but
we're
okay,
with
stale
data,
we're
okay
with
restaurants,
as
it
was
three
hours
ago,
so
that
kind
of
model
it
works
very
well
for
us
in
that
kind
of
business.
So
it's
a
great
example
of
try
and
and
it's
one
of
those
domains
that
probably
it
works
kind
of
the
way
you
think
it
does,
and
so
in
terms
of
you,
you
modeling
it
out
to
try
and
basically
for
an
experiment.
B
A
lot
of
it
does
work
the
way
you
think
you
know
you
can
reason
about
how
you
think
it
might
work.
There
are
a
few
strangenesses
around,
so
one
of
them
is
is
whether
or
not
you
care
whether
we
care
whether
the
courier
has
actually
delivered
the
the
food
to
you,
and
there
are
various
schools
of
thought
in
the
industry
on
that
one.
So
one
is
yes.
We
do
obviously
want
to
know
that,
basically,
it's
been
delivered,
but
you
have
to
incentivize
drivers
to
basically
press
that
button.
B
To
basically
say:
yes,
it's
been
delivered
yet
another
school
assault
says
we
don't
because
in
the
event
it's
not
delivered
your
phone
is
anywhere
and
say
where's
my
food
and
then
we'll
know
that
there
was
a
failure
of
the
delivery.
So
it's
kind
of
interesting
there's
different
ways,
but
mostly
you
can
reason
about
it.
I
think
actually
chris
richardson's
book
on
microservice
patterns,
I
think
it
is
or
microservices
conference
called
now,
but
he
he
uses
food
delivery
as
an
example
microservices.
A
Yeah,
actually,
I
used
to
work
for
stuart,
which
is
another
delivery
company,
and
it's
more
in
the
line
of
you
know
like
you
can
deliver
anything.
That's
just
food
right
yeah,
so
we
introduced
you
yeah,
okay,
yeah.
I
used
to
work
for
stuart
in
the
in
the
early
days
and
when
they
got
their
first
round
of
investment,
they
hired
us
to
to
build
they.
They
built
like
a
prototype
which
was
working
perfectly
but
yeah.
It
wasn't
scalable.
A
It
was
all
synchronous
and
http
and
so
on
right
so
and-
and
it
was
a
monolith
right
so
so
it
was
working
well
for
a
prototype,
but
they
wanted
to
scale
right.
So
so
the
design
that
we
did
at
the
time
was
okay.
We
need
to
create
an
even
driven
architecture
here,
like
everything
needs
to
happen
as
an
event.
We
need
to
have
the
mobile
applications
connecting
with
mqtt,
probably
if
plus,
if
possible.
A
At
that
time
it
wasn't
like
100
possible,
like
some.
Some
fonts
were
cutting
the
connection
on
mktt,
but
you
could
use
notification
systems
on
for
that
right,
so
yeah
it
was
all
it
was.
It
was.
It
was
cool.
A
It
was
an
interesting
and
interesting
project
because,
aside
from
what
people
can
see,
what
people
can
can
see
about,
you
know
like
ordering
food
and
so
on,
like
order
is
addressed
or
finished
or
rejected,
or
whatever
cancelled
aside
from
that,
aside
from
food
and
so
on,
there
was
a
a
team
of
as
a
call
like.
A
Can't
remember
the
name,
there's
a
data
scientist
right,
so
a
team
of
data
science,
scientists
and-
and
they
were
trying
to
predict
where
the
next
order
was
going
to
happen
right
or
at
least
not
the
next
one.
But
the
next
bunch
of
of
orders
we're
going
to
happen
to
send
anticipatedly
anticipatedly,
send
drivers
to
that
area
right
of
in.
A
Barcelona
right
so,
and
it
was
super
cool
like
they
were
taking
care,
they
were
taking
into
account.
Many
things
like
like
barcelona
was
playing
or
not.
That's
important.
Is
there
a
riot
somewhere?
Is
there
the
streets?
Is
there
some
kind
of
street
cat
or
something
like
you
know,
like
yeah,.
A
Yeah,
exactly
it's
a
big
one
as
well,
and
it
was
interesting
to
see
how
they
could
actually
predict
a
high
percentage
of
the
of
the
next
of
the
times
like
the
next,
where
the
next
order
was
going
to
happen.
It
was
like
to
me
it
was
like
magic
like
how
the
hell
are
you
doing
like
and
how
you
get
the
data
as
events.
They
were
getting
the
data
as
events
and
they
were
able
to
compute
these
events
and
predict
stuff.
B
B
We
don't
want
to
show
you
any
more
because
we
can't
get
you
the
food,
hot
yeah
and
it's
kind
of
a
problem.
You
work
in
that
sector.
It
doesn't
necessarily
occur
to
you
that
just
delivering
you,
hot
food
is
an
additional
problem
beyond
say
delivering
you
a
milk
bottle,
which
you
know
the
model
doesn't
tend
to
go
off
during
the
time
to
deliver
from
your
local
convenience
store.
If
it
could
well
get
cold
again,
an
ice
cream
could
melt
right.
A
And
I
find
it
funny
something
that
you
said
before
is
that
many
of
these
things
are
not
being
triggered
by
a
user
behind
the
ui.
So
this
many
of
these
things
are
just
a
weather,
api
reading,
reading
the
temperature
or,
if
it's
raining
or
not
and
then
sending
an
event
and
about
changes
and
then
activating
certain
services
or
updating
certain
services
so
like
well.
Maybe,
if
you
think
about
it
like
there's
someone
updating
the
weather
data
right
in
some
place,
but
yeah.
A
Yeah,
there's
no
one
in
in
this
case
or
or
that
or
who
works
for
just
that
updating
this
information.
It's
just
all
continuously
happening
as
you
receive
events,
and
that's
I
mean
that's,
that
is
huge.
That
is
actually
huge.
I
love
it.
A
So
if
I,
if
I'm
not
mistaken,
I
think
you
were
using
async
api.
I
just
did
is:
is
that
correct?
So
we
are
yeah,
I
mean
we.
B
Just
we're
at
the
beginning
of
our
journey,
I
would
say
with
it,
so
we
have
a
lot
of
apis
that
in
terms
of
event-based
api,
that's
in
kpis
and
by
comparison
to
the
http
apis
which,
where
we,
when
we
use
open
api,
our
realization
was
that
we
just
didn't
really
have
any
useful
way
of
discovering
them.
B
If
you
were
as
the
order,
if
there's
only
like,
I
don't
know
10
of
you
in
a
room
right,
you
can
just
shout
over
the
desk
and
say:
oh
anyone
got
an
api,
but
but
we
have
I
don't.
I
don't
think
we
actually.
Even
I
don't
know
the
exact
number,
but
it's
an
order
of
a
thousand
or
engineers
and
large
numbers
of
components
so
that
breaks
down
you
can't
really
even
again,
it's
not
even
really
a
reasonable
practice.
So
that's
what
people
did
to
go
into
a
kind
of
public
channel.
B
On
slack
and
literally
said
anyone
gonna
know
who
raises
this
event
and
where
it
comes
from
and
what
the
schemer
is.
You
can't
really
do
that
either
people
would
try
trolling
github
searches
to
find
stuff
right,
particularly
events.
You
know
hey,
I
need
to
find
who
consumes
my
event
that
I'm
sending
out
or
actually
has
anyone
got
an
event
that
deals
with
this
aspect
of
stuff
and
you
might
find
over
time.
B
An
async
api
seemed
like
a
really
good
way
for
us
to
say:
okay,
we
can
standardize
how
we're
going
to
document
our
endpoints,
and
then
we
may
be
able
to
use
tooling
or
hopefully,
if
we're
lucky
tooling,
effectively
arrives
in
the
ac
kbi
space.
That's
not
enough
ahead
of
us
that
we
can
then
do
much
easier
discovery
of
those
apis.
Yeah,
potentially
also
do
ability
to
understand
our
flow,
because
it's
almost
the
other
day
saying
you
know
in
typical
event,
architectures
you've
got
these
two
approaches:
choreography
or
orchestration.
B
So
orchestration.
I've
got
a
component
directs
everything
it's
easy
to
understand,
but
doesn't
scale
very
well
and
then
you've
got
choreography.
Where
you
know
we
I
send
an
event
to
you.
You
send
an
event
to
them.
If
there's
an
error
path,
it
goes
this
way
and
the
problem
a
little
bit
is
it
works
all
the
dancers
have
their
steps
they
perform,
but
we
don't
really
quite
often
have
a
if
you
like
that
are
laid
out
here.
Are
all
the
steps
in
the
dance,
so
it
can
be
difficult
to
understand.
B
What's
actually
going
to
happen
so
some
particularly
for
someone
in
operations,
you
know
something
happens
and
they
go.
Oh,
I
don't
know
what
happened
in
that
context
and
being
able
to
map
that
out
is
also
something
we
thought
you
know.
Maybe
we
get
standardized
documentation
for
endpoints
but
to
map
stuff
out
right.
So
you
know
we're
looking
at
interesting
ideas
like
event
catalog,
to
see
quite
how
that's
being
picked
up.
Scaffolding
would
also
be
useful
to
us.
B
The
ability
to
really
you
know
generate
first
versions
of
consumers,
particularly
not
less
senders,
but
the
other
thing
we
also
want
to
use
it
for
is
directing
infrastructure,
so
an
ability
for
you
as
a
developer,
to
simply
say
hey.
I
need
basically
to
talk
to
like
to
expose.
B
You
know
to
publish
something
via
sms
or
I,
as
a
consumer,
want
to
subscribe
to
their
sms
channel
or
sqs
right,
and
what
we
would
like
to
be
able
to
do
is
rather
than
have,
teams
have
to
take
responsibility
for
provisioning
that
themselves
for
us
to
be
able
to
essentially
say
fine
drop,
that
in
your
repo
we'll
pick
that
up
and
we
will
go
away
and
provision
that
the
reason
that
becomes
important
a
certain
scale
is
if,
for
some
reason
we
have
an
incident
where
we
lose.
B
For
example,
a
given
channel
in
say
s
s,
it's
very
hard
for
us
to
then
figure
out
well
how
who's,
who
subscribes
to
that.
If
I
know
that
their
channel's
gone
for
some
reason-
and
I
recreate
it,
I
also
have
to
recreate
all
the
subscriptions.
Where
are
they
yeah?
I
do
I
trawl
github
to
find
them
and
so
documenting
all
of
that
process.
B
So
that's
the
other
thing
that
that's
why
I
got
interested
quite
a
lot
in
the
bindings
was
because
what
we
wanted
to
do
with
it
was
have
enough
information
in
the
binding
to
then
say.
Okay,
I
can
go
away
and
create
that
infrastructure.
On
that
given
broker,
we
pretend
to
use
ss
sqs
and
kafka.
There
are
some
pockets
of
rabbit,
mq
and
mqtt
in
the
org
as
well,
but
that's
why
that
became
important
to
us
that
kind
of
idea
that
we
once
better
use
it
for
to
drive
infrastructure
as
code
effectively.
A
Yeah,
that's
cool,
and
actually
what
I
hear
as
well
is
is
a
common.
It's
a
common,
let's
say
complaining
about
even
driven
architecture.
Specifically,
you
know
like
choreography,
which
is
funny
I
I
I
created
async
kpi
out
of
a
need
while
doing
choreography
choreographed
by
microservices,
and
I
was
feeling
the
same
thing
like
damn
it.
This
is.
This
is
growing
super
fast
like
we
were
doing,
we
were
doing
microservices
wrong.
I
would
say,
like
probably
everybody.
B
A
A
That's
not
the
point
right
so,
but
yeah
like
we
like
quickly
get
a
lot
of
new
services
right
micro
services
and
all
of
them
were
doing
different
things,
but
their
code
we're
looking
mostly
the
same
and
except
it
was
just
subscribing
using
the
same
framework,
subscribing
to
the
same
broker
and
then
doing
something
with
event
or
publishing
to
the
broker
or
something
like
that,
and
then
on
the
documentation
side.
On
the
discovery
side,
it
was
hard
to
answer
this
question
like
who's
who
is
subscribing
to
this.
A
To
this
event,
right,
like
who's
gonna,
be
receiving
this
event
and
it's
important,
especially
when
something
blows
up.
Basically,
it's
like
when
something
fails
and
it's
like
who's
getting
affected.
I
don't
know-
and
this
I
don't
know-
is
like
look
at
the
broker
yeah.
It
was
a
broker,
the
the
piece
that
failed
or
something
in
the
broker
failed.
A
So
you
can't
really
look
at
the
broker
or
the
broker
is
not
reachable
because
of
a
network
problem
or
something
like
that,
and
then
you
can't
query
the
the
broker
or
look
at
the
information
there.
So
and
then
it's
scary
right
and
it
gets
even
more
scary
when,
when
it's
not
just
your
infrastructure,
your
private
infrastructure,
but
you
share
in
some
of
these
events
with
third
party
with
other
companies
right
with
partners
right
and
they're
doing
something
with
these
events
and
then
it's
like
they
met
like.
A
I
can
query
like
you
said
like
I
can
query,
github
or
github
organization
and
so
on,
but
I
cannot
know
if
it's
not
somewhere
else
in
a
document
or
something
who
which
partner
is
using
this.
This
event
right
and
and
so
we
were
documenting
these
things
by
hand
in
a
document
in
a
google
doc
or
something
like
trying
trying
and
praying
that
it
it
didn't.
But
google
google
doesn't
go,
google
docs
doesn't
go
down
right
and
we
can
access
this
right
and
so
yeah.
A
What
I
hear
all
the
time
is
discovery
and
governance
right.
It's
always
the
same
thing
like
discovery
and
governance.
Yeah
generating
code,
it's
cool,
it's
something
that
you
might
want
to
do.
It
was
for
us.
It
was
a
big
deal
because
we
we
had
like
a
an
in-house
framework
for
subscribing
and
publishing
to
the
broker,
and-
and
so
we
were
iterating
on
the
framework
as
well
at
the
same
time
as
in
the
product.
A
So
whenever
you
you
released
a
new
version
of
the
of
the
framework,
you
wanted
to
go
to
all
the
microservices
and
update
their
code
to
to
update
to
the
newest
version
of
the
framework
you
know,
which
is,
which
is
a
pain
right.
It
can
be
automated,
and
now
we
have
more
means
for
that
right,
but
back
in
the
days
it
wasn't
like
ci
wasn't
really
a
thing
and
it
wasn't
or
or
if
it
was
a
thing.
A
I
honestly,
I
didn't
know
how
to
do
it
myself
so
and
and
our
team,
so
so
yeah
it
was.
It
was
a
pain
and
so
yeah.
So
this
this
is
like
this
is
a
really
common.
Let's
say
complaint
that
I
hear
from
people
like
and
and
complain
about,
even
the
architectures
and
an
advantage
that
that
is
in
kpa
can
give
you
less.
So
I
hear
about
infras
code
right,
lower
infra
or
defining
infra.
C
A
On
on
the
kpi
specification,
which
is
something
interesting
like
it
was
out
of
scope
from
the
very
very
beginning,
we
got
lots
of
requests
for
that.
I
mean
a
few
of
them,
not
a
lot
and.
B
On
a,
I
think,
a
couple
of
teams
use
it
at
justice,
but
I
work
on
a.net,
open
source
library
that
we
use
what
my
previous
gig
called
brighter
so
and
it
like
just
saying,
which
is
the
one
that
comes
out
just
eat,
another.net
kind
of
library.
B
Both
of
those
have
this
kind
of
model
which
says
okay,
as
a
consumer
I'll
generate
the
necessary
infrastructure
to
subscribe
and
as
a
producer,
I'll
generate
the
network
structure
to
publish-
and
you
know
they
self-service
and
that
works
up
until
a
point
and
so
brighter,
which
I
would
it
was
kind
of
the
first
time.
I
really
built
a
big
messaging
framework
that
was
open
source
because
I've
done
it
a
lot
of
times,
and
what
did
I
didn't
want
to
write
again?
B
Another
job
we
started
off
really
focusing
on
rabbit
and
key
was
the
first
transport
we've
really
had
and
robert
mq
those
creation
statements
are
even
potent
right.
So
if
the
clue
already
exists
doesn't
matter,
I
just
say
I'm
going
to
recreate
it
and
it's
very
low
latency.
B
When
you
can
start
to
deal
with
cloud
infrastructure
like
sms
nescs.
One
of
the
things
you
find
is
that
first
it's
not
it's
not
important,
so
you
will
get
an
error
if
you
try
basically
to
recreate
something
that
already
exists,
so
you
have
to
kind
of
test
and
say:
does
it
exist
or
you
have
to
try
and
catch
the
error
and
kind
of
abandon
it?
B
And
the
second
is
that
when
you're
running
multiple
consumers
using
using
a
competing
consumer
patent
when
you're
scaling
out,
if
the
first
thing
that
does
when
it
scales
out,
says
well,
I
like
to
check
my
infrastructure,
that's
obviously
delay
and
then,
if
it
says,
if
you're
well,
I've
got
to
create
it
because
it
doesn't
seem
to
be
there.
It's
missing,
but
you've
got
four
or
five
and
they
all
then
hit
a
race
condition.
They
all
want
to
create
it.
B
B
So
we
said:
well,
actually
that's
a
pain
point
and
then
we
coupled
that
with
well.
Do
we
really
want
developers
in
the
organization
to
have
all
the
rights
required
to
do
that,
and
do
we
really
want
to
create
the
scenario
where
that
they
could
fail
easily
at
something
that
requires
that
they
only
have
to
do
every
so
often.
B
Obviously
we
want
them
to
focus
on
writing
their
kind
of
main
logic
in
the
same
way
that
their
app
their
framework
today
takes
care
of
that
we
really
want
to
take
care
of
it
for
them
outside
the
framework,
and
so
we
ended
up
saying
well.
What
we
really
want
to
better
do
is
support
the
idea
that
your
infrastructure
is
created
outside
the
framework,
and
so
it's
kind
of
a
flag
or
an
option.
We
get
people
now
to
say:
hey
emphasis
created
and
then
we
said
well.
B
We
could
use
async
api
if
we're
asking
to
find
an
endpoint
anyway
for
documentation
purposes
for
governance.
As
you
say,
I
don't
want
to
force
you
to
define
something
else
right,
because
that's
the
classic
developer
problem
of
I
have
to
fill
out
five
documents
and
I'm
now
really
annoyed.
B
Areas
like
kubernetes
et
cetera,
becomes
more
powerful
to
say,
hey,
let's
take
over
the
work
of
creating
the
infrastructure,
let's
then
create
environment
variables
for
the
light
that
give
you
anything
that's
created
at
runtime,
inject
them
into
your
given
environment.
You
can
look
for
those
and
anything
that
we
need
you
to
create.
You
need.
You
need
the
address
identity
of
we'll
pass
that
back
to
you
in
that
environment.
B
So
so
we've
got
that
kind
of
running
and
we're
really
going
to
start
trying
to
roll
that
out
and
then
there's
a
whole
back
floor
process
of
trying
to
backfill
everybody
who's
doing
it
themselves
onto.
Can
we
can
we
take
control
of
that?
For
you
and
in
theory
you
know
you
get
closer
to
the
ability
to
be
able
to
say,
let's
spin
up
everything
again
in
an
entirely
new
place.
If
we
need
to
video.
A
Sorry,
are
you
I'm
curious
now
how
on
how
you
do
it
like?
Are
you
only
using
existing
information
of
the
on
the
async
api
document,
or
are
you
defining
any
specific
extensions
of
your
own
for
infrared.
B
So
we
we
use
I've
got
a
pr
and
somewhere
for
ac
kpis
bindings
fresco
sns.
That
contains
a
lot
more
detail.
That's
why
we've
got
that
detail
in
there.
We
do
also
have
like
a
custom
binding
for
any
additional
information
that
we
think
well
that
wouldn't
be
generic,
that's
something
that
we
care
about.
So
we
then
we'd
add
a
custom
binding
to
houston,
where
you
can
specify
some
additional
properties
that
we
might
need,
and
then
we
use
the
generator
to
generate
to
turn
that
into
to
pull
out
the
information.
B
We
need
from
the
async
api
specification
to
really
just
be
effectively
a
dictionary
of
the
values
that
we
need
to
set
and
then
under
the
hood.
We're
using
pollute
me
to
then
actually
go
away
and
create
the
infrastructure
from
the
properties
that
you
give
us.
A
B
Or
a
blog
post
until
we've
had
this
conversation,
I've
not
realized
that
maybe
we
are,
you
know,
pushing
the
envelope
in
a
different
direction
for
people.
So
maybe
we
should
talk
about
that
I
mean.
Maybe
I
encourage
one
of
the
devs
on
the
team
who's
doing
a
lot
more
of
the
implementation,
and
I
I
did
a
kind
of
first
proof
of
concept
and
they've
really
taken
it
to
the
air
to
the
end.
So
if
I
persuade
one
of
them
to
do
more
of
a
talk
about
something.
A
Oh
yeah,
that
will
be
like
super
cool
so
and
speaking
a
little
bit
about
coming
back
to
the
original
thread
where
this
invitation
happened
and
so
on.
So
I'm.
C
A
I'm
curious
like
where,
how
can
I
say
I
like,
like
I
know
I
know
more
or
less
now
how
you're,
using
this
in
kpi
and
and
and
and
so
on.
But
what
are
the
pain
points
for
you
like
on
on
this
in
qba
side?
What
do
you
think
it
doesn't
really
fit?
Well
so.
A
B
The
threat,
I
think,
really
actually,
I
think
the
strongest
part
of
the
criticism
came
a
little
bit
from
clement's
bastards.
He
was
looking
at
ac
kpi
and
it
was
more
by
trying
to
understand
his
criticism.
I
mean
we
have.
I
think
I
think
we
have
some
of
the
classic
pain
points
that
everybody
has
around.
B
You
know,
publish
and
subscribe
around
the
channel
name,
not
necessarily
being
the
actual
being
logical
concept
we
want,
but
we
want
not
the
actual
identifier
for
that
item
because
we
may
have
it
in
multiple
environments,
etcetera
and
you
need
to
pick
up
the
name
which
has
been
in
that
environment
et
cetera,
et
cetera.
So
we
have
all
of
those
kinds
of
pain
points,
but
we're
digging
into
what
clem
said.
I
think
I
began
to
understand
what
he
was
driving
at.
B
So
what
one
thing
I
think
is
is
more
of
a,
I
think,
there's
a
misunderstanding
on
this
part
in
terms
of
saying
how
rpc
might
be
seen,
you
might
be
defining
on
a
server
a
set
of
operations
which
effectively
are
behaviors
that
the
server
exposes
looks
like
it's
an
api
and
then
a
client
calls.
Those
ask
for
specific
behaviors
and
I
think
clarence's
perspective-
is
that
from
a
messaging
point
of
view,
that's
rarely
true.
Now
I
don't
necessarily
entirely
agree
with
him.
B
C
D
B
You
get
into
the
world
of
events,
you're,
not
really
trying
to
drive
a
specific
operation.
You're
communicating
some
facts
in
in
inside
an
event
and
really
all
you're
doing
on
the
far
side
is
saying.
I'm
listening
to
events
right
and
somebody
else
on
the
other
far
side
says:
I'm
publishing
events
and
in
between
things
can
happen
yeah,
and
I
think
that
he
he
over
time.
In
this
conversation,
I
think
people
have
driven
a
couple
of
things.
B
The
first
is
that
when
we
think
about
asynchronous
conversation,
what's
the
characteristic,
this
is
what
async
api
is.
What's
the
characteristics
of
an
asynchronous
conversation
and
really
the
key
one
is
that
both
parties
don't
need
to
be
present
right
and
how
do
we?
How
do
we
make
that
work?
Well,
the
the
knowledge
I
might
use
is
I
I
I
put
what
I
wanted
a
letter
and
I
go
to
go
to
your
house
and
I
put
it
in
your
mailbox.
B
B
I
am
delivering
you
some
kind
of
post
and
I
think,
what's
in
that
letter
is
a
little
bit
this
behavior
thing
right
in
order
for
it
to
be
more
rpc
like
it's
almost
as
though
I've
sent
you
something
where
I've
asked
for
a
specific
thing
that
you
offer
and
you
you
give
me
that
right
so
I
say:
oh,
can
you
send
me
one
of
those
cute
teddy
bears
for
my
daughter
or
whatever
I'm
just
gonna
put
my
head
and
you
go
yep
great,
so
that's
kind
of
instruction
of
some
behavior.
B
You
said
you've
exposed
I'm
using
messaging
to
get
hold
of
it,
but
then,
but
the
way
I
get
hold
of
it
is
more.
I
send
you
a
message
and
in
the
message
the
content
would
tell
you
that
I'm
not
really
sending
it
to
an
end
point
called
you
know
by
teddy
bear
or
whatever
I'm
sending
it
to
your
house
where
effectively.
I
know
that
you
run
your
business
and
you
look
at
the
message
and
interpret
that
to
figure
out
what
you
do.
B
So
it's
a
slight
shift
in
the
sense
that
saying
operations
seem
a
bit
strange
in
that
world,
because
I'm
not
really
asking
you
for
an
operation.
You
are
saying
I
I
receive.
B
I
will
need
to
receive
messages
and
I
say
I'm
sending
messages
and
then
you
get
into
this
world
a
little
bit
of
brokers,
which
I
think
is
a
really
interesting
topic.
B
What
kind
of
what
is
a
broker
example,
if
you
think
about
it,
if
I
send
you
I'll,
come
to
your
mailbox
and
deliver
it,
I'm
just
doing
that
for
myself,
I
could
do
it
by
the
post
office.
I
could
go
to
a
mailbox
put
it
in
the
mailbox,
then
delete
it
to
you
and
then
messaging
point
of
view.
Arguably
the
main
difference
is
what
what
are
we
talking
to?
B
Am
I
talking
directly
to
your
mailbox
or
another
mailbox,
so
something
invisibly
happens
in
between,
but
it's
still
really
pretty
much
a
point-to-point
interaction
right,
I'm
sending
it
to
your
address.
I
put
your
address
on
the
front,
and
I
say
this
is
for
you
slightly
different
to
that
is
when
we
get
into
pub
sub,
because
what
I
tend
to
do
there
is
I'm
not
sending
it
to
a
specific
address,
I'm
just
kind
of
sending
it
to
a
a
result.
What
would
be
called
a
recipient
list?
B
So
on
the
front
of
my
thing
rather
than
writing,
you
know
24
acacia
avenue.
I
might
write
everyone
interested
in
my
newsletter
and
then
what
happens
is
somewhere.
It
goes
to
somewhere
where
I've
actually
read.
They
hold
this
list
of
who's
interested
in
subscribing
to
my
newsletter
and
they
send
everybody
a
copy
when
we
think
about
brokers,
it's
interesting
to
understand
what
do
we
mean
by
a
broker?
B
Do
we
meet
someone
at
the
post
office
where
really
it's
still
a
kind
of
point-to-point,
interaction,
I'm
delivering
to
a
specific
person
right
and
I
put
their
address
in
it?
Or
do
we
actually
mean
something
more
like
a
router
right
where
effectively,
the
router's
got
some
rules
of
how
to
deliver
stuff
to
people
and
a
recipient
list
is
a
typical
router.
B
So
one
of
the
other
interesting
questions
is:
what
do
you
mean
by
channel
right
so
a
channel
if
you
look
at
kind
of
the
gregor
hope
kind
of
a
theory,
but
it's
just
basically
how
two
things
kind
of
communicate,
it's
a
virtual
pipe
and
in
principle,
what
we
often
think
of
as
my
distributing
message
via
broker
is
really
me
with
a
channel
might
be
tcp
ip.
It
may
not
really
have
any
store
and
forward
characteristics
talking
to
a
broker
where
there's
essentially
a
recipient
list,
which
we
call
dynamic
recipients.
B
You
can
sign
up
to
a
topic
or
a
routine
key,
which
then
distributed
the
whole
set
of
channels
which
are
probably
cue
based,
in
other
words,
they
have
store
and
forward
characteristics
which
consumers
then
subscribe
to,
and
I
guess
one
of
the
questions
is
when
we
think
in
terms
of
channels
and
servers
etc.
Are
we
missing
concepts
or
ideas
there
in
the
sense
that
when
I
say
I'm,
I'm
a
app
that
I
send
something?
B
Well,
what
am
I
sending
I'm
sending
a
message
and
I'm
sending
it
to
you
somewhere
right
and
I
could
be
sending
it
to
another
party
that
listens
to
it
or
it
could
be
sending
it
to
a
server,
but
I'm
probably
sending
it
to
a
channel.
B
But
the
question
to
do
that,
so
I
send
it
to
a
channel,
but
where
does
that
channel
go
so
the
channel
might
go
then
to
a
broker
right,
which
then
says?
Okay.
When
things
come
on
here
I
can
effectively
like
you
know.
Your
message
would
get
rooted
to
this
topic,
which
would
then
transmit
it
to
everybody
by
another
channel.
B
You
know
protocol
for
basically
reading
stuff
off
the
right
and
but
for
you
and
keep
people,
but
basically
one's
not
doing
any
kind
of
storm
for
one's
other
key,
so
I've
got
a
key
one
and
I've
got
basically
a
tcp
ip
on
and
here
what
I'm
doing
is
routine
and
what
I'm
saying
I'm
rooting.
B
The
kind
of
routing
I
want
to
do
here
is
everybody
in
a
recipient
list,
so
people
can
subscribe
and
then
effectively
to
this
topic
and
then
they'll
get
a
copy
of
it,
but
there
could
be
other
types
of
routing.
I
might
do
right.
I
might
have
a
set
of
rules
based
on
the
content
of
the
message,
so
I
could
say
what
I
do
is
if
it
basically
turns
out
when
I
inspect
the
content
of
the
message.
B
Large
orders
over
a
million
dollars
go
here
and
orders
between
medium
sized
orders
but
down
to
a
hundred
thousand
go
here.
Otherwise,
that's
100
000
go
here
that
router
is
no
longer
really
doing
that
kind
of
classic
pub
sub
model.
It's
using
a
rules
engine
to
determine
where
things
go,
and
I
guess
the
question
would
be
you
know
in
asian
kpi.
Do
we
you
know
if
we
think
about
a
server
and
we
think
about
channels
as
belonging
to
a
server.
B
Do
we
miss
that
kind
of
aspect
of
really
the
broker
is
something
a
little
bit
more
than
that
it's
acting
as
a
router.
It's
got
probably
all
rules
based.
It's
probably
thinking
about
different
rules,
for
how
you
then
distribute
work
out
to
the
channels
and
would
point
to
point
really
be
much
more.
B
We
share
a
channel
right
and
the
server
might
be
sure
might
be
a
server
that
hosts
the
channel
right
because
we
actually
physically
have
that
channel
on,
but
a
broker
might
be
a
thing
on
a
server
in
the
same
way
you
know
so
you've
got
a
server.
You've
got
channels
that
may
be
hosted.
So
if
you
might
have
a
router
or
something.
B
How
does
this
channel
get
to
that
channel
right?
This
is
kind
of
separation,
you're
sharing
using
the
channel
just
to
communicate
over
or
hey.
I
I
send
her
something
to
basically
an
intermediary
router
that
effectively
then
distributes
for
me
to
other
other
channels
and
that's
an
interesting
kind
of
question
as
to
whether
we
do
we
want
to
understand
more
of
that
kind
of
apology.
A
I
I
yeah
I
I
actually.
It
is
very
interesting
because
we
need
to
draw
the
line
somewhere
right
like
where,
where
do
we
stop
like
we
define
until
here?
Otherwise
it
can
get
really
complex
right,
and
that-
and
I
think
that's
why
I
mean
I
know
that's
why
I
stopped
there
like:
okay,
I'm
not
gonna,
get
into
rules
on
how
routing
happens
in
the
router
and
the
broker
and
and
so
on.
Right,
because
then
it's
like
we'll
enter
we're
entering
in
another
land
right.
A
Why
I,
I
called
it
async
api
right
like
api
in
the
sense
of
it's
just
interface,
it's
just
a
surface
right
like
I
don't
care,
what's
happening
behind
the
scenes
like
that's
why
I
never
explored
infrastructure
as
code,
because
it's
like
I
don't
care,
what's
your
infra
behind
it
like
I'm,
I'm
telling
you
right
like.
A
Oh
I'm
communicating
to
people
like
how
can
they
communicate
with
me
like
how,
if
you
want
to
send
a
message
to
me,
you're
gonna
send
the
message
to
this
broker
on
this
channel
and
then
I'll
receive
it
right
or
you
can
subscribe
from
my
messages
on
on
this
broker
and
on
this
topic
right
on
this
channel.
So
so
or
it
can
be
yeah
like
this
last
channel,
which
is
like
there's
only
one
channel.
There
are
no
channels,
it's
just
a
a
tcp
connection,
for
instance,
and
and
that's
it
right.
A
So
there
are
no
concept
of
channels.
So
when
you
have
that
concept
like
so,
it
is
highly
frustrating
trying
to
think
in
in
these
terms,
because
people
often
get
confused
about
publish
and
subscribe
meaning,
and
and
it's
because
you
see,
publish
and
you
subscribe,
and
you
think
this
is
what
this
is.
The
behavior
of
your
application,
like
your
your
service,
your
micro
service
or
whatever,
it's
going
to
publish-
and
it's
going
to
subscribe
to
this
topic
on
this
on
this
broker
right,
but
it's
not
so.
A
This
is
not
the
meaning
of
the
publish
and
subscribe.
It's
it's
actually
like
if
someone
wants
me
to
receive
this
email
at
this
event,
you
gotta
send
me
the
message
on
this
on
this
channel
on
this
broker
right
so
effectively
I
mean
it
is
more
cocky.
It
is
more
complicated
to
understand,
but
effectively
what
it's
doing
is
like
it's
like
obstructing
the
whole
infrastructure.
What
is
like,
I
treat
the
whole
infrastructure
as
a
black
box,
like
I
don't
care,
what's
happening
there
right,
I'm
just
telling
you
like
this
application.
A
If
you
want
to
communicate
with
this
application,
this
is
what
you
have
to
do.
Instead
of
this,
application
is
doing
something.
It's
not
what
what
I'm
what
the
application
is
doing
is
what
you
can
do
with
the
application
right
like
how
you
can
communicate
with
the
application
and-
and
I
think,
if
we
stick
to
that
model,
then
there
can
be
any
routing
rules
in
the
middle
that
you
don't
really
care
because
it's
like,
if
you
want
to
communicate
this
one,
let's
say
not
communicate.
A
But
if
you
want,
if
you
have
a
publisher
here-
and
you
have
a
subscriber
here
on
a
specific
type
of
message,
not
necessarily
on
the
same
on
the
same
topic
on
the
same
channel,
what
can
happen
is
that
I
publish
on
topic
or
channel
a
here.
A
There
are
some
routing
rules
in
the
middle
and
it
gets
published
to
channel
d
right,
and
this
one
is
subscribing
to
channel
d
and
receiving
the
the
message
on
channel
d.
So
here
it's
described
that
I'm
subscribing
or
you
can
publish
to
me.
Let's
say
I'm
subscribing
right
on
channel
d,
and
here
I'm
describing
that
you
can
subscribe
to
the
messages
that
I'm
publishing
on
channel
a
right.
So
the
cool
thing
is
that
you
don't
have
this
problem
like
everything
can
be
extracted
in
the
middle.
A
The
worst
thing
here
is
that
is
highly
complicated
to
think
in
death
terms
like
like
look
what
look
at
what
I
just
said
like
you
can
pound
this
to
me
right,
I'm!
So
you
don't
have
this
to
anyone
like
this.
One
is
subscribing
to
the
topic
to
the
specific
topic
in
the
broker.
You're,
not
publishing
to
the
to
the
microservice
right.
So
I'm
in
in,
like
in
in
more
strict
terms,
might
be
that
the
broker
is
publishing
to
the
microservice.
A
If
it's
using
a
push
model
or
something,
then
okay,
it
could
be
happening,
but
yeah
like
from
the
application
development
point
of
view.
It
is
highly
confusing
to
you
to
thinking
that,
in
the
terms
now,
for
version
three,
we
are
reverting
the
meanings
of
publish
and
subscribe
and
to
make
it
clear
that
we're
reverting
them,
we're
even
changing
the
names.
So
it's
going
to
be
so
far
the
way
it
is
so
far
it
can
be
still
changing
there
like
there's
still
time
it's
send
or
receive,
and
these
times
are
operations.
A
Let's
say
these
are
actions
behaviors,
not
what
a
potential
client
or
another
person
can
do
with
the
service.
It's
what
the
service
is
doing
like
send
is
sent
means
the
service
is
sending
the
message
to
the
broker
receives
means
that
it's
receiving
this
message
from
the
broker
from
the
broker
right
so
trying
to
make
it
a
little
bit
clearer
and
less
confusing.
A
B
B
I
can't
think
of
top
of
my
head
with
a
better
word
action
or
something
or
but
what
you're
really
saying
is
you
know,
am
I
am
I
sending
or
receiving
right?
What's
my,
what
am
I
doing
to
this
channel
I'm
either?
I
might
want
to
send
for
the
channel
or
receive
this
channel.
It's
almost
the
app
says
what
he
wants
to
say:
hey
I've
got
some
send
actions
and
I
do
them
on,
and
I
push
this
to
this.
B
You
know
this
message
to
this
channel
or
I
received
messages
from
this
channel
right.
So
tell
us
a
little
bit
like
we
say
we're
thinking
out
loud.
I
don't
really
have
a
better
way
of
describing
that,
but
I
think
that's
one
of
the
criticisms
is
we
don't
want
to
think
about
having
a
set
of
behaviors
you
can
engage
with.
B
We
are
literally
just
saying
there
is
kind
of
a
pipe
and
I
am
effectively
on
one
end
of
the
pipe
and
I'm
either
pushing
things
in
or
I'm
receiving
things
and
then,
and
so
as
an
app
I've
got
and
I've
made
you
both,
and
I
have
some
things,
I'm
listening
on
and
some
things
I'm
publishing
to
then
in
the
middle.
I
guess
yeah.
I
agree,
there's
a
level
of
complexity.
You
don't
want,
but
you
could
think
well.
B
Actually
you
know
I
could
have
the
notion
that
some
servers
are
just
basically
servers
were
effectively
hosting
a
kind
of
point-to-point
channel.
Some
servers
are
servers
where
essentially
I
do
routine
right
and
whether
effectively
you
have
a
kind
of
special,
a
specialization
of
that
object
to
say:
oh
well,
actually,
it's
acting
as
a
router.
So
what
it's
going
to
do?
You
know
that
effectively,
if
you
send
something
to
that
channel,
but
it's
going
to
route
it
to
everything
else
that
basically
shares
that
name
or
all
right.
B
B
If
you
just
treated
it
as
this
kind
of
identifier
on
the
server
that
we
use
to
essentially
connect
two
things
together,
the
channel,
that's
really
what
we
thought
of
channel
as
then,
really
you
could
say
that
the
behavior
of
that
channel
depends
a
little
bit
on
the
type
of
the
server
object
that
you
put
it
into
right,
and
I
know
we've
got
this
kind
of
local
and
remote,
but
you
potentially
wonder
whether
is
a
kind
of
pub
sub
server
a
thing
right.
Where
effectively,
we
say:
okay
right.
B
I
know
that
if
effectively,
I've
got
a,
I
listen
to
a
channel
on
a
pub
sub
server.
That
probably
means
that
somebody's
published
a
pub
sub
server
and
everybody's
connected
to
it
and
getting
it
right
or
if
it's
basically
a
point-to-point
kind
of
server.
That
means
that
we
have
probably
got
we've
got
a
narrow
communication
from
the
two
of
us
and
it's
one
me
listening
on
one
at
the
other
end
now.
Is
that
useful?
I
I
don't
know,
that's
an
interesting
question.
B
I
mean
the
question:
is:
does
that
level
of
depth
of
understanding
that
does
that
provide
utility
to
anybody
or
or
is
it
just
basically
noise
where
eventually
it's
which
we
don't
care,
it's
really
just
a
box.
We
just
need
to
know
that.
Basically,
this
thing
from
here
goes
to
this
thing
here
and
we
need
to
understand
how
it
works,
but
it's
just
an
interesting
one,
but
there's
a
level
of
abstraction
missing.
If
you
like.
A
That's
that's
I
actually
like
like
if
it
provides
any
level
of
utility
to
people
that
is
actually
a
a
like
a
good
concern
right
like
when,
when
I
started
drafting
this
proposal
for
version
three
to
to
solve
the
problem
with
palu
subscribe,
I
was
I
mean
this
is.
I
was
listening
to
to
lots
of
different
point
of
views
and
actually
that's
how
thinking
out
loud
started
like
I
started
this.
A
These
live
streams
as
a
way
to
to
gather
feedback
from
the
community
right
like
like
what
is
wrong
in
your
opinion,
right,
like
what
can
be
doing
better
and
and
so
on,
right
and
and
what
I
understood
by
listening
to
the
community
is
that
there
are
people
who
are
mostly
interested
in
in
generating
code,
for
instance,
generating
code
and
and
reading
the
generating
documentation,
so
the
user
potential
customers
they
have
everything
they
need
to
communicate
with
their
infrastructure,
so
treating
effectively
as
an
api.
A
In
the
end,
even
though
the
protocol
might
be
a
mqp
or
mqtt
or
whatever,
but
yeah
like
you,
send
the
message
and
you
don't
expect
any
response,
but
you
know
that
something
will
happen.
On
the
other
side,
right
and-
and
it's
like-
you
know
that
if
you
publish
here
something
will
happen,
even
though
you
don't
get
the
response
so
so
yeah
effectively,
there
is.
Is
any
api
use
case.
A
If
you
want
that's
one,
that's
precisely
what
we
have
right
now
on
on
on
version
two
right,
but
so
thanks
to
thanks
to
dale
at
ibm,
I
also
discovered
that
some
people
are
not
really
interested
at
all
in
the
operations
like.
I
just
want
to
list
like
where's
the
broker
here,
the
list
of
channels,
and
here
the
messages
that
you
should
be
publishing
or
reading
depends
on
what
you
do
if
you
publish
or
subscribe
to
this
channel
right.
So
it's
like
effectively
like
a
menu
and
there
are
no
operations.
A
It's
just
a
list
of
things
like
so
here's
channel
a
and
message
a
channel
b
message,
b,
right
and
or
a
set
of
messages
or
whatever
and
that's
it,
and
then
they
don't
care
about
who's,
publishing
or
subscribing
right.
So
it's
not
interesting
for
them,
because
they
must
probably
I
mean
in
their
case
it
was
because
they
were
they.
They
are
working
on
a
kind
of
api
gateway
if
you
want
like
an
api
gateway,
but
for
events,
so
they
don't
really
need
to
know
who's
publishing
or
subscribing
it's
just
I
want
to.
A
I
want
to
look
at
the
at
the
event
that
is
being
published
to
this
channel
and
see
if
it's
correct
or
not
if
it
matches
the
definition
of
the
file
and
if
it
doesn't
I'll,
reject
it
and
do
whatever
and
and
if
it
matches
I'll,
let
it
pass
right
so
so
that
that
is
a
a
use
case
right
and
what's
the
other
one
yeah,
oh
yeah,
and
the
other
one
is
that
people
yeah
like
people
wanting
to
define
the
whole
architecture
they
have,
or
at
least
domains
right
in
a
single
file
right,
so
so
yeah.
A
So
what
what's
your
opinion
about
that
by
the
way
like
having
a
single
file,
for
I
don't
know
for
domains
or
for
the
whole
architecture
like
we
tend.
B
To
already
want,
I
think,
a
file
for
an
app
with
basically
what
that
app
sends
and
receives.
Although
the
idea
of
being
able
to
reference
a
menu,
I
think
we
tended
to
call
it
the
minute
document
that
basically
has
a
collection
of
messages.
Etcetera
is
helpful
because,
obviously,
if
I've
got
an
app,
that's
you
know
12
apps,
that
receive
a
message
that
this
one
over
here
is
sent,
sending
I'd
really,
which
ones
better
refer
to
that
message
document
rather
than
having
to
in
line
everywhere,
and
so
what
I'd
like?
B
Is
this
sort
of
century
definitely
to
find
things
like
message
contracts
and
then
active,
find
things
like
what
channels
do
I
talk
to
and
what
message
messages
come
up
with
those
channels,
but
most
that'd
be
references
to
things
that
were
different.
You
know
are
a
central
pool
that
I
can
actually
pick
stuff
out
of
so
I
want
to
know
this
app.
Does
this
in
a
separate
file,
but
it
can
pull
stuff
from
that
pool
of
the
globally
defined
resources,
that's
cool
so
on
just
just
just
before
we
get
there.
B
So
the
other
thing
I
think
on
this
point,
the
last
thing
was
a
bit:
people
like
clementine
people
that
we're
getting
into
right
is
one
of
the
things
that's
also
out
there
a
little
bit
where
there's
not
necessarily
a
good
solution
right.
It's
let
me
get
into
the
world
of
things
like
kafka,
connect
and
k
sequel.
B
So,
in
someone
like
connect
with
the
k
sequel,
what
I
might
do
is
say:
hey
here:
are
those
three
or
four
streams
right:
pull
them
in
and
then
run
it
through,
say:
okay,
sequel,
aggregate,
some
stuff
and
produce
out
another
stream
at
the
other
end,
so
in
other
words,
I
take
in
the
information
in
this
form
right
and
I
actually
aggregate
it
in
some
way
and
put
it
out
the
other.
B
I
think
one
of
the
points
is:
how
would
we
represent
that?
Would
you
represent
that
by
having
an
app
that
effectively
listens
to
those
and
then
produces
new
messages
right
or
would
you
actually
want
to
have
another
kind
of
primitive?
So
it's
this
idea
of
basically
having
teacher
server
types
that
said:
okay,
when
you
have
this
server
type.
B
What
we
can
show
is
that
you
know
these
channels
back
to
these
check
to
this
channel.
So
guess
what
I'm?
What
don't?
I
guess,
what
I'm
I'm
wondering
is
if
you
increase
the
number
of
server
types
and
you
have
some
slightly
different
characteristics
on
each
server
type
beyond
saying
local
remote,
but
to
actually
be
slightly
more
explicit
and
say
it's
this
kind
of
server.
B
Does
that
solve
some
problems?
For
you,
some
people
can
say
hey
the
kind
of
server
I'm
interested
in
is
making
this
look
like
an
api
with
a
with
a
range
of
behaviors
that
I
basically
expose.
Oh,
no,
I'm
interested
more
pub
sub
style
server.
Where
effectively
it's
going
to
have
this
model.
Actually
I've
got
an
event
stream
server.
Where
effectively,
I
may
want
to
combine
streams
together
and
aggregate
stuff,
and
that's
the
only
that's.
The
only
question
I
have
is
local
remote
is
perhaps
not
far
enough
down
that
line.
B
What
we
need
are
other
abstractions,
potentially
a
an
expandable
list
in
the
future
right,
so
people
could
say:
well,
we
don't
represent
this
and
you
can
say
great.
We
can
create
a
new
server
type
with
some
properties
on
it,
which
would
enable
you
to
represent
how
that
works
and
make
that
kind
of
more
extensible
thing.
If
we're
saying
hey
my
server
hosts
channels
and
what
I
do
then
effectively
is
talk
to
a
given
channel,
you
could
still
represent
things
like.
Oh
in
this
type
of
server
I
can
you
can
represent.
B
It
would
have
properties
that
let
me
represent
these
incoming
channels
map
to
aggregate
to
these
outgoing
channels
right
and
then
over
here
in
this
app.
I
just
subscribe
to
that
outgoing
channel.
I'm
seeking
this
model
if
I've
got
an
app
defined
in
a
file,
but
I've
ended
up
with
some
kind
of
things
that
are
global
resources
and
kind
of
a
memory,
particularly
my
broker.
B
It
may
be
that
having
different
types
of
that
kind
of
intermediary,
if
you
like,
being
able
to
represent
different
types
of
intermediary
lets,
you
represent
some
of
some
of
those
apologies
that
in
the
future
we
might
find
people
want
to
document
other
than
just
the
use
cases
we
have
right
now,
which
are
more
classic
rpc
style
and
pub
sub
style.
So
I
mean
most
of
the
arguments
today
are
about
rpc
and
pub
subs.
A
The
meaning
of
channel
in
regards
to
servers
or
brokers,
it's
implicit
to
be
in
the
case
of
brokers,
it's
it's
implicit
to
be
pops
up
right,
like
yeah
and
in
the
case
of
point-to-point,
is
usually
rpc
right.
So
it's
a
single
channel
or
no
channel
depends
on
how
you
want
to
call
it
right.
We're.
B
A
Necessarily
that
no,
not
necessarily
I
mean,
I
don't
think
it
represents
the
same.
So
the
thing
is
that
local
remote
is
from
the
perspective
of
an
application
of
a
service
that
you're
defining.
Is
it?
Is
it
a
local
server
that
I'm
exposing
like
an
http
or
websocket
server,
or
is
it
a
remote
server
like
a
broker
right?
Okay,
what
you're
defining
right
then
inside
the
the
server
definition
you
could
be
saying
type.
A
I
don't
know
aggregator
type
pops
up
type
whatever,
so
it's
still
compatible
the
local
or
remote
is,
is
more
about
the
perspective
from
the
service
being
defined.
On
the
on
the
specific
on
this
file
right.
B
All
right
am
I
the
server
effectively
yeah,
so
I
guess
you
might
be
rpc
and
server
rpc
or
local
right
or
local,
but
in
other
words,
do
you.
A
Expose
the
api,
exactly
if
I
am
the
server
yeah
yeah.
If
I
am
the
server,
I
will
be
defining
it
as
local.
If
you
are
a
client,
then
you
will
be
defining
it
as
a
remote
right
or
pointing
it
as
a
remote
as
a
remote
server
right
because
you're
not
exposing
this,
this
interface
right.
It's
someone!
Yes,
it's
me
not
you
right,
so
so
yeah
and
that's
why
now
in
the
in
the
in
the
new
version,
what
we're
aiming
for
is
you
need
two
async
aba
files
in
the
case
of
client
server.
A
You
need
two
right
not
like
before,
like
we
were,
we
were
saying
like
we,
you
can
just
define
the
server
for
instance,
and
then
the
client
can
be
like
how
can
I
say,
like
the
client
can
be
not
generated,
but
like
the
client,
you
have
enough
information
to
generate
a
client
if
you
want
yeah
right,
but
it's
not
true
like
it's.
It's
not
really.
It's
not
really.
True,
like
we
proved
to
be.
We've
proven.
A
We've
been
proven
wrong
right,
like
yeah
and
and
then
it's
and
that's
why
the
client
server,
which
will
treat
it
the
same
way
as
in
a
broker-based
topology
right
where
there's
a
broker
in
the
middle,
and
then
you
have
service
a
and
service
b,
which
is
the
client
and
the
server
and
they're
communicating.
There's
no
broker.
That's
the
only
difference,
there's
no
broker,
but
you
still
need
twisting
kpa
files
right.
A
So
so
that's
why-
and
I
think
this
thing
about
aggregators
like
k,
sequel
and
things
like
this,
the
the
fear
that
I
have
about
going
that
dip
like
defining
these
routing
rules
on
the
missing
kp
file,
is
that
from
what
I've
seen
in
my
experience,
none
of
these
rules
are
static.
B
C
B
B
And
so
so
one
of
the
the
concerns
with
people
you
tend
to
have
environments
for
lots
of,
say:
okay,
sql
stuff
floating
around
is
you
know.
So-And-So
basically
over
here
is
subscribing
to
this
topic,
basically
and
reading
information
right,
but
we
don't
clearly
know
the
as
the
sender
of
another
topic
that
there's
a
relationship
between
the
two,
because
yeah
essentially
he's
subscribing
to
an
entirely
different
topic,
and
I
may
say:
oh
well,
I've
got
you
know
subscribers
to
my
topic,
but
actually
they've
all
been
retired.
B
So
I'm
going
to
turn
myself
off
right
and
then
this
guy
at
this
end,
basically,
whereas
I'm
certainly
getting
no
more
information.
How
did
that
happen
right?
And
that's
because
there's
no
way
of
tying
out
that
his
topic
came
from
that.
So
I
think,
there's
quite
specific
things
that
people
want,
which
is
the
more
the
discovery
aspect
rather
than
the
yeah.
Let's
encode
all
the
rules
here,
it's
more
this
black
box
needs
to.
B
That's
just
saying:
well,
I
always
maps
today
right
and
there's
one
consumer
on
each
side,
sort
of
thing
and
the
the
pub
subsets
will
a
maps
to
many
consumers
of
a.
But
what
we
really
want
to
better
see
is
in
some
cases
it
might
be
a
maps
to
b
and
c
through
some
black
box
thing
that's
happening
and
that's.
I
think
the
interesting
question
is
whether
that's
representable
in
some
way,
so
that
you
would
know
that
oh
okay,
a's
actually
has
got
some
dependencies
here.
B
A
Yeah,
you
want
to
know
like
potential,
let's
say
potential
channels
where
this
message
can
end
up
routed
to
right
like
so
it
might
get
routed
to
here
here
here
and
you
don't
want
to
define
the
rules.
It's
just
like
saying,
hey,
so
there
this
channel
might
be
routed
to
these
other
three
channels.
B
Getting
routed
to
this
yeah
so
now
now
I
can
see
the
dependencies
now.
I
can
understand,
there's
a
flow
somewhere
that
the
logic
of
the
flow
anymore,
that
I
don't
know
the
logic
if
your
app
basically
receives
a
message
and
raises
a
new
one,
I
just
know
that
it
does
right,
and
even
that
is
true
a
little
bit.
I
I
don't
necessarily.
B
I
think
this
is
one
of
the
points
that
got
raised
and
a
part
of
that
thread
was
if
my
app
receives
a
message
right
when
she'd
message,
food,
doesn't
work
and
then
raises
a
message
bar
there
isn't
a
clear
way
for
me
to
better
trace
the
food
with
what
leads
to
bar
right
coming
out,
and
if
I
want
to
trace
how
something
then
moves
through
the
whole
application.
I
think
that's
the
key
point
that
was
kind
of
a
particularly
clever
just
driving
through
on
that
thread.
C
A
Right,
that's
going
to
be
interesting,
channel
channel
a
challenge
also
in
how
to
visualize
that,
because,
like
there
will
be,
you
can
see,
I
can
imagine
a
diagram
like
you
know
like
like,
like
david,
was
doing
with
event
catalog.
So
you
have
a
diagram
where
you
can
see
like
this
service
is
publishing
this
event
here,
but
it
might
get
routed
to
these
three
any
of
these
three
right
or
multiple
of
of
these
three.
B
A
B
Right
and
one
of
the
the
puzzling
things
is
to
begin
to
think
when
we
think
about
a
router.
We
tend
to
think
about
in
messaging
terms
this.
You
know
almost
third-party
piece
of
software
that
basically
has
a
set
of
ways
that
it
roots
something
you
know
the
rabbit.
Enqueue
comes
with,
basically
its
exchanges,
which
are
religious
roots,
that's
right,
but
really
our
app
right.
If
our
app
consumes
a
message
and
spits
out
a
new
one
effectively,
it's
acting
as
a
router.
A
B
A
I
can
see
I
can
see.
Where
are
you
going
sam
yeah?
I
think
we're
over
over
the
hour
already.
I
didn't
want
to
interrupt
because
yeah
we
started
late.
So
no,
no.
B
A
Exactly
so
I
I
I
try
to
make
the
these
episodes
always
as
as
collaborative
as
possible.
So
this
one
we
either
got
people
bored
and
they
left
or
or
they
are
listening
to
us
very
closely
and
they
they
didn't
want
to
interfere.
And
so
we
didn't
get
any
questions.
But
if
you
have
any
questions,
I
think
it's
the
right
time
to
ask.
A
I
would
say,
and
if
not
you
know
that
we're
always
on
on
slack
and
then
twitter
and
and
many
other
platforms
right,
so
so
yeah,
you
don't
have
to
ask
now
or
I
mean,
ask
or
suggest
anything
like
you
can
and
you
can
interrupt
at
any
time
not
not
today,
because
we're
gonna
finish,
but
in
the
next
ones,
right
so
so
yeah
in
the
meantime,
ian
thanks
a
lot
for
for
joining.
It's
been
really
a
a
pleasure
and
yeah.
C
B
Yeah,
no,
I
mean,
I
think.
The
main
thing
I
would
say
is
that
I
I
think
they
see
kpi.
You
know
it
is
a
tremendous
step
ahead
from
where
we
are-
and
I
see
a
lot
of
you
know:
smart
motivated
people
who
are
working
to
make
things
better
with
every
iteration
and
I've
got
real
confidence
around
the
community
that
you
know
we're
going
to
get
from
set
to
step
and
and
and
each
iteration
you
know
really
solve
a
whole
new
slew
of
use
cases.
B
So,
and
I
definitely
don't
want
anyone
to
think
that
I'm
negative
about
ac
kpo,
we
definitely
much
pretty
much.
You
know
we're
bought
into
18
kpi,
and
it's
more
about
you
know
what
other
challenges
can
we
see
that
we
need
to
help
with
that?
It
might
be
interesting
to
understand
that
ac
kpi
would
would
be
a
the
tool
to
help
solve
those
as
well.
B
I
think
it's
more
well
existing,
but-
and
I'm
impression
that
I
am
critical
in
that
sense
of
the
efforts-
we're
definitely
very
much
behind
it,
it's
more
hey.
Where
could
we
go
next
sort
of
thing.
A
Well,
I
agree,
and,
and
and-
and
we
all
need
to
to
learn
to
be-
you
know-
to
listen
to
different
types
of
feedback.
That's
why
I
I,
after
this
conversation
on
twitter,
I
I
wanted
to
invite
you
like
hey,
let's
discuss
this
in
public
because
I
think
not
just
in
public
but
over
work
old
right,
so
because
twitter
is
not
really
the
right
place
to
discuss
these
things.
A
It's
too
short,
and
you
know,
and
and
and
chaotic
also,
the
organization
of
the
information
is
really
chaotic
and
and
not
really
a
good
place,
but
happy
to
always
listen
to
to
all
types
of
feedback.
I
think
it's
really
useful.
This
conversation
has
been
really
useful
and
I
hope
it's
at
least
for
me,
and
I
hope
it's
been
for
you
know
for
the
rest
of
the
people,
those
who
have
been
watching
those
who
who
will
watch
the
the
conversation
later
and
and
yeah
like.
A
I
encourage
you
ian
and
everyone
else
watching
to
to
give
also
you
know
to
to
also
express
your
frustrations
or
what
you
don't
like,
or,
of
course
we
all
like
like
to
do
to
hear
good
feedback
and
how
good
you
are
and
blah
blah
blah.
A
So
we
all
like
to
be
loved
right,
but
but
if
you
want
to
grow,
if
we
want
to
grow
well
and
and
make
something
really
solid
right
as
a
community,
we
can't
be
silencing,
you
know
the
the
the
the
bad
feedback
or
the
negative,
not
the
benefit,
but
the
negative
feedback
right
or
or
the
frustrations
for
from
different
users,
so
so
yeah.
A
So
thanks
a
lot
ian.
I
really
appreciate.
B
It
I
can't
just
say
on
that
last
point,
that
your
openness
does
you
credit.
I
mean,
I
think,
that's
one
of
the
things
I
think
is
great
about
this
community
is
the
willingness
to
be
open
to
other
viewpoints
to
take
on
what
people
are
saying,
and
I
think
you
know.
Hopefully,
people
do
feel
that
sense
that
you
want
to
engage,
because
I
I
certainly
feel
that.
A
Thanks
a
lot
man
so
see
you
on
the
around,
on
slack
and
so
on,
and
on
github
and
and
yeah.
Let's,
let's
keep
chatting
don't,
please
don't
leave
we'll,
have
a
chat
after
the
the
live
stream.
I'll
just
take
you
out.
A
Cool
folks,
so
thanks
a
lot
for
watching
today,
it's
been
over
an
hour,
but
I
hope
you
find
you
found
this
content
interesting.
A
A
I
know
that
these
words
are
very
often
used
by
different
projects
like
it's
community,
driven
blah,
blah
blah
blah
blah
right
now,
we're
trying
to
make
it
really
community,
driven
and
and,
as
you
can
see,
we'll
listen
to
all
types
of
feedback
and
and
yeah
so
leave
all
your
feedback
whenever
you
think,
whenever
you
you
think
about
it
right
so
see
you
again
next
week,
I'll
be
announcing
soon
who's.
The
next
guest
and
cheers
bye,
bye,
take
care.
A
By
the
way,
we
have
a
really
cool,
outro
right
now
coming
out,
which
is
dumb
by
missy
who's
in
the
chat,
mr
turco
and
and
yeah
and
come
for.
I
forgot,
like
he's:
gonna
call
he's
gonna,
kill
me,
damn
it
damn
it.
Let
me
just
anyway
I'll
say
another
day.
No
worries
cheers
thanks
a
lot
bye-bye.