►
From YouTube: Thinking Out Loud #11 — with Dominik Obermaier
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
A
Hello
once
again,
folks
welcome
to
thinking
out
loud
from
async
api.
My
name
is
fran
mendez
and
today
we're
going
to
be
talking
with
dominic
obermayer
from
hivemq
and
we're
going
to
be
discussing
about
a
really
cool
topic.
A
That
actually
makes
me
think
a
lot
which
is
like
what
could
be
we
doing
or
what
could
brokers
be
doing
more
in
order
to
achieve
this
data
consistency
and
this
documentation
of
everything,
every
topic,
every
every
message
and
so
on,
right
and
and
how
we
could
be
integrating
better
with
with
brokers
like
I
said,
api
with
brokers
or
even
cloud
events
with
brokers
like
how
could
brokers
be
integrating
better
with
with
existing
specifications
right
so
for
those
before
we
start
for
those
of
you
who
don't
know
so.
A
This
is
an
easy
kpi
live
stream,
so
we
adhere
to
the
async
pay
code
of
contact
that
you
can
find
on
the
on.
Our
organ
github
organization
also
would
love
to
share
that
here.
It
is
so
I'm
gonna
put
it
there
for
a
while.
So
if
you
need
closed
captions,
please
head
over
to
youtube
and
enable
them
there
you
will
be,
it
will
be
possible.
I
hope
we
didn't
mess
up
with
like
last
time
and
and
they're
working
also,
and
I
want
to
make
it
clear.
A
This
is
not
an
interview
format,
so
this
is
a
chat
like
I
like
to
call
it
like
a
castle
chat
or
a
thinking
session.
If
you
want
so
so,
don't
be
shy.
Just
join
the
conversation
on
the
chat.
If
you
want
be,
you
know
like
be
part
of
this
live
stream,
even
if
you're
not
on
the
on
camera.
That's
totally
fine
right!
So
so
yeah
as
we
do
with
this
in
kpi,
we
try
to
make
everything
as
community
driven
as
possible,
and
this
is
no
exception
right.
A
So
so
please
join
the
conversation.
Don't
don't
be
shy
about
it
and
and
yeah
so
yeah,
I'm
not
gonna,
be
like
talking
more
about
it
with
no
more
delay.
I'm
gonna
introduce
our
guest
today,
so
hey
dominic,
hi
everyone
how's
it
going
hey.
Look
how
much
time
like
it's
been
a
long
a
long
time.
We
don't
speak
like
what,
like
five
minutes,
no
kidding
so
everything's
going
well.
I
hope
the
though
so
I
don't
know
so.
Dominic
was
telling
me
on
private
chat.
A
If
the
sound
is
good,
your
sound
is
good.
I
hope
my
sound
is
as
well
I'm
on
chrome.
A
I
hope
you
are
as
well
less
than
three
streams
on
firefox
and
I
use
firefox
for
as
my
daily
browser,
so
so
yeah.
So
that's
why
I
was
telling
you
before
to
use
chrome
or
brave
as
well
right
so
yeah.
I'm.
B
A
I
tried
I
can
try
it
for
some
time,
but
the
then
I
don't
know
I
switch
it
back
to
firefox.
Don't
know
why
and
yeah
so
so
dominic.
Maybe
you
want
to
to
tell
us
a
bit
more
about
yourself
like
introduce
yourself
for
those
who
don't
know
you.
B
Oh
yeah,
absolutely
hi
folks,
my
name
is
dominic
ubermeyer,
so
I'm
cto
and
co-founder
of
a
company
called
hyphen
q,
we're.
B
Basically
the
company
is
providing,
let's
say
software
for
the
internet
of
things,
so
many
people
will
probably
know
the
hivenq
mqt
platform,
which
we
also
have
an
open
source
version,
I'm
available
and
yeah.
Basically,
I'm
a
messaging
guy,
so
I've
been
doing
communication
protocols
for
quite
some
time.
So
I
I
think
for
more
than
10
years
now
I
almost
exclusively
deal
with
mqtt
and
and
other
let's
say,
communication
systems
in
the
iot
space.
B
So
I
also
worked
on
on
a
book
about
the
foundations
of
the
internet
of
things
and
yeah,
so
in
general,
I'm
this
kind
of
iot
guy,
but
really
more
on
the
the
service
on
our
communication
side.
B
So
I
had
with
the
specification
of
mqtt
version
3
as
well
as
version
5,
which
is
the
2018
version
of
mqtt
and
yeah,
and
also
I'm
currently
working
on
protocols
like
mqtt
sn,
which
is
mqtt
for
sensor
networks,
as
well
as
higher
level
protocols,
basically
sitting
on
top
of
mqtt
like
spark
plug
and
others,
and
this
is
something
I'm
really
interested
in.
B
So
I'm
super
excited
to
have
this
conversation
today
about
async
api,
because,
while
of
course,
I
think
messaging
is
really
great
for
a
lot
of
use
cases
when
it
comes
to
tooling
compared
to
traditional
or
request
response
protocols
like
http,
I
still
feel
we
aren't
quite
there
at
the
criteria
and
there's
a
lot
to
improve,
and
this
is
why
I'm
so
excited
about
sync
api
really
driving
that
forward
and
pushing
the
envelope
here.
So
yeah
excited
this
conversation.
A
Nice,
yes,
that
was
a
a
great
introduction.
I
love
it
so
maybe
so
for
those
who
don't
know
as
well
like.
A
So
hi
from
I
don't
know,
I
don't
know
folks
who
are
watching
us
or
who
will
watch
us
in
the
future,
the
recording,
if
you,
if
you're
learning
or
if
you
learn
in
the
past
or
if
you're
gonna,
learn
about
mqtt,
like
I
did
in
the
past,
most
probably
you'll
end
up
reading
hivemq
resources
and
the
internet
at
least
for
this.
A
B
So
yeah,
so
we
have
some
multiple,
multiple
series.
We
started
the
blog,
I
think
I
think
2013
or
so
with
the
so-called
mqtt
essentials
series,
which
was
really
basically
was
me
trying
to
basically
make
the
mqt
specification
more
digestible.
This
was
christian
guts,
who's,
our
ceo,
the
company
and
me
so
because
we
felt
that
this
was
a
even
it's
a
very
simple
specification
that
folks
found
it
not
as
accessible
for
learning.
B
While
the
specification
is
really
great,
if
you
want
to
implement
that
to
get
an
overview
on,
especially
for
the
architects,
these
people
are
usually
pretty
busy,
and
so
so
we
figured
hey.
Why
don't
we
bring
it
in
a
bite-sized
version,
but
also
for
ourselves?
I
mean,
while
I
do
love
writing
specifications.
B
My
brain
is
really
not
designed
as
a
hard
drive.
Apparently.
This
is
why
why
I
usually
write
also
stuff
for
myself,
so
I
can
find
it
easily,
because
google
is
my
default
information,
finding
thing
and
so
yeah,
and
so
this
is
true,
but
I
mean
the
more
recent
series,
like
the
mqtt
version,
five
fundamentals
and
so
on.
We
have
awesome
colleagues,
writing
that
and
also
when
it
comes
to
the
higher
level
protocols.
B
So
we
have
some
some
awesome
people
there
who
are
really
good
at
what
they
do
and
they
provide
this
kind
of
content
for
your
community,
because
I
mean
in
the
end
when
it
comes
to
open
protocols,
and
this
is
a
fundamental
belief
I
have
by
the
way
is
I
I
so
believe
in
open
protocols,
because
literally
the
reason
why
we
can
talk
now
is
based
on
open
protocols
and
and
the
whole
internet
is
based
on
that.
B
Also
with
this
online
data
or
this
some,
I
call
it
the
only
layer,
some
some
people
are
calling
it-
let's
say
the
the
the
aussie
layer.
Basically
so
so-
and
this
is
yeah
it's
just
so
so
great
that
we
have
tcp,
which
is
open.
We
have
all
the
other
protocols
on
top
which
we
can
use
and
also
on
the
application
side
and
mqtt,
for
example,
is
no
difference.
B
I
mean
it
relies
on
things
like
tls,
which
we
also
use
for
http
and
yeah,
but
usually
when
it
comes
to
messaging
protocols.
B
Historically,
a
lot
of
the
especially
very
old
messaging
protocols
are
more
on
the
proprietary
side,
and
there
are,
I
mean,
obviously,
for
that.
Many
folks
will
know
that.
We
also
had
this
kind
of
weird
thing
in
the
past,
where
we
specified
on
apis,
for
example,
with
jms,
but
the
implementations
of
the
wire
protocol
was
completely
proprietary,
so
you
don't
really
get
the
interoperability.
B
You
just
basically
get.
Let's
say
you
can
program
against
the
same
api,
but
in
the
end
you
still
have
this
kind
of
vendor
login,
and
this
is
something
I'm
really
glad
that
we
left
that
beyond
us
and
now
the
industry
is
focusing
on
open
protocols
like
mqtt
for
iot
devices
or
amqp,
which
is
really
great
for
the
backend
system,
and
also
protocols
which
are
like
are
technically
open,
like
the
kafka
protocol
and
so
on
for
messaging.
I
think
this
is.
This
is
really
great,
that
that
is.
B
A
It's
it's
awesome
that
we
get
more
and
more
open
protocols
and
they're
not
closed
closers.
I
would
argue,
though,
that
it's
like
please
stop
creating
protocols.
Yes,
then
we
have
to
support
them.
Amazing,
kpi,.
B
Yeah,
I
mean
something
I
mean
this
is
what
I
really
like,
but
I
think
from
a
score
perspective.
Async
api
is,
is
a
harder
not
to
correct.
Then,
for
example,
open
api,
which
is
like
focusing
on
http,
and
I
feel
it's
a
bit
more
narrow,
but
with
like
messaging
systems
are
so
different
because,
like
amqp
is
completely
different
from
mqtt,
while
on
the
surface
it
looks
pretty
similar
the
problems-
and
I
hope
we
can
talk
about
this-
are
so
much
different.
B
So
so
I'm
wondering
so,
do
you
also
feel
that,
with
with
essing
api,
the
scope
is
really
it's
a
much
broader
and
sometimes
probably
a
bit
harder
than
with
open
api.
A
I
I
I
felt
the
pain
and
then
you
know,
like
the
the
headache
in
the
past,
trying
to
come
up
with
a
a
an
async
api
specification
that
was
like,
let's
say,
outlining
what
every
protocol,
or
at
least
every
protocol,
that
I
that
I
knew
at
the
time
had
in
common,
and
that
was
that
was
a
headache,
because
you
couldn't
go
like
really
too
deep
into
each
protocol
feature
because
yeah,
like
you
said,
like
amqp,
for
instance,
is
so
different
to
kafka
or
to
mktt.
A
Then
how
do
you,
for
instance,
with
kafka
you
have?
I
just
came
to
my
mind,
like
kafka,
has
a
concept
of
a
key
key
and
the
value
right
that
doesn't
exist
in
in
in
in
amqp,
for
instance,
right
or
in
mqtt.
So
how
do
you
map
that?
If
we
add,
if
we
had
a
key
val,
a
key
and
value
on
async
api,
then
how
do
you
map
that
to
mqtt
and
mkp,
even
even
more
what
if
the
concept
of
a
topic
doesn't
exist
like
in
the
case
of
web
sockets,.
A
Right
so
so
we
kept
it
as
simpler
as
possible.
Like
keeping
I
mean,
not
simply
it's
not
the
the
word
here.
So
we
we
try
to
to
keep
it
as
as
common
as
possible,
like
only
having
in
the
course
pack.
A
You
have
only
the
common
stuff
between
protocols
and
then
we
incorporated
this
feature,
which
is
protocol
bindings,
where
you
can
define
specific
protocol,
specific
information
right
and
and
that's
that
that
is
like
a
next
kind
of
extension
like
you're,
using
mqtt
cool
here's,
your
mqtt
protocol
binding
there,
you
can
bring
all
the
mqtt
specifics
right,
so
yeah
and-
and
that
was
I
was
listening
to
you
before
when
you
were
saying
like
when
you
were.
A
You
were
working
on
this
essential
guides
right
the
essentials
and
you
were
saying,
like
you,
sometimes
write
for
you,
because
your
brain
doesn't
function
as
a
hard
drive,
and
I
was
like
completely
related
so
shameless
confession.
Here
I
keep
looking
at
asian
kp
documentation
every
day,
and
I
sometimes
because
I
I
don't
remember
how
how
to
do
some
things
in
asian,
kpi
and
and
even
what's
more
funny
to
me.
Is
that
sometimes
it's
like
who
wrote
this?
B
A
So
yeah
so
yeah.
I
completely
relate
on
that,
so
so
the
the
topic
today
for
for
the
audience
I'll
remind
it
again
like
so
I
wanted
to
invite
dominique
to
talk
about
how
we
could
better
integrate
brokers
or
how
do
we
imagine
we
could
integrate
brokers,
not
just
hyphen
q
right
so
like
brokers
in
general,
with
async
api
or
in
doing
the
last
interactions
on
twitter
yesterday,
also
not
just
a
async
api,
but
specifications
like
cloud
events
like
which
I
completely
forgot
in
the
initial
topic
definition.
A
How
do
you
imagine
that
we
can,
or
do
you
imagine
this
is-
is
possible
and
it's
viable
that
from
a
brokered
perspective,
we
end
up
having
some
such
kind
of
of
features
like,
for
instance,
validating
the
message
payload
or
the
headers
validating
against
a
messenger
definition
or
a
cloud
events
definition
or
something
like
that.
Yeah
yeah.
B
Oh
yeah,
absolutely
I
mean,
I
think
I
think
they're.
Basically,
I
think
it's
a
three
level
three
levels
to
to
talk
about
on
the
when
it
comes
to
essence,
api
and
so
for
for
people
who
are
not
as
familiar
with
mqt
I'd
like
to
give
a
quick
background.
B
So
so
it's
hopefully
easier
to
understand
what
I'm,
what
I'm
trying
to
to
say
so
mqtt
is
when
you
look
at
large
deployments
and
here
at
hivenq,
we
have
like
very,
very
large
deployments,
like
we
have
a
typical
just
for
for
people
who
are
not
familiar
with
the
scale.
B
So
a
typical
mqtt
deployment
we
do
with
our
company
when
it
comes
to
cloud
deployments,
is
usually
one
million
devices
and
above
and
we're
talking
about
concurrently,
connected
devices
who
are
basically
sending
stuff
all
the
time,
and
so
so,
somewhere
between
1
million
and
10
million
is
let's
say
on
the
the
higher
end,
but
usually
having
a
deployment
has
more
than
10
000
devices
connected.
This
is
usually
where
it
gets
interesting
in
the
cloud,
but
also-
and
this
is
now
this
might
also
be
really
interesting.
B
For
that
conversation
is
that
mqtt
brokers
are
not
only
residing
in
the
cloud.
Very
often
you
have
this
kind
of
tiered
architectures,
where
you
have
an
mqtt
broker,
sit,
for
example,
inside
a
factory
or
multiple,
but
let's,
for
the
sake
of
concession,
make
it
simple.
You
have
one
broker
in
a
factory,
and
you
have
10
factories,
for
example,
and
then
have
one
big
cloud
deployment,
for
example.
So
you
have
to
and
then
on
each
of
these
brokers
you
have
multiple
devices
be
connected,
so
get
off
this
kind
of
tiered
architecture.
B
B
So
I
think
I
keep
a
key
thing
with
enquity
that
is
quite
different
to
a
traditional
messaging
system
or
let's
do
it
with
kafka.
Kafka
is
something
we
see.
We
see
at
the
use
with
mqtt
and
kafka
all
the
time,
they're
complementary,
because
they're
solving
very
different
problem
in
a
very
elegant
way,
and
they
they
really
blend
together
very
nicely.
So
you
probably
could
edit
you
for
cases
where
you
would
use
kafka
and
you
definitely
shouldn't
use
kafka
where
you
would
use
it,
and-
and
I
mean
kafka
is
like
from
a
in
a
white
board.
B
Kafka
would
be
usually
a
big
pipe.
You
don't
have
a
lot
of
topics,
usually
I
mean
so
what
we
have
like
for
10
to
100
maximum
for
most
deployments.
Some
of
them
do
have
more,
but
usually
you
scale
over
the
partitions
and
you
don't
have
a
lot
of.
Let's
say
topics.
Usually
there
are
other
use
cases,
but
I
mean
we
know
customers.
We
have
like
two
topics,
basically
in
kafka.
A
I
I've
been
working
on
one
of
them
like
at
new
relic
when
I
was
working
at
the
new
relic,
so
the
the
kafka
the
kafka
broker
had
like.
A
To
be
honest,
to
be
honest,
it's
because
it
was
used
as
it
was
used
for
two
different
purposes.
One
is
to
ingest
data
from
the
from
the
agents,
so
neurologic
is
for
monitoring
right.
So
when
you're,
so
the
agents
installing
your
server
and
your
machines
are
constantly
sending
data
to
new
relic.
So
this
ingestion,
this
data
ingestion
is
done
through
kafka,
and
so
that's
the
main.
That
was
the
main
purpose
and
it's
because
of
the
you
know
the
the
high
throughput
of
kafka.
A
That's
why
they
chose
this
technology,
but
then
it's
like,
oh
since
we
have
the
broker
here.
Let's
just
also
do
our
services
architecture
event,
driven
architectures.
A
On
top
of
kafka
as
well,
and
what
happens
is
that
it?
It
people
start
creating
topics
for
their
microservices,
but
since
it's
not
documented
anywhere
right,
what
the
topic
is
doing,
I
mean
not
anywhere,
but
it's
not
clear,
then
whenever
they
have
to
make
a
breaking
change
on
the
messages
that
that
are
being
sent
on
the
topic,
since
they
don't
know
who's
consuming
this
message,
they
don't
touch
it.
A
A
So
that's
that's,
really
cool,
but
but
yeah
like
the
thing
is
that
you
end
up
with
a
lot
of
topics
because
of
this
because
you're
using
probably-
and
I
I
mean
I
don't
want
to
be-
I
don't
want
to
sound
like
an
idiot
here,
but
probably
it's
because
like
people
are
using
kafka
in
this
case,
for
something
that
is
not
meant
for,
like
in
the
case
of,
for
instance,
like
communicating
microservices
like
like
as
it
pops
up
as
a
pops
up
broker.
You
know
like
for
that.
A
But
kafka
has
this
stream
capabilities
which
yeah
you
know
like
I'm,
not
sure.
If
I
mean
it
can
be
used,
it
certainly
can
be
used.
We
did
it
and
we
have
sir
here
on
the
on
the
chat,
who
was
also
working
with
me
at
new
relic
and-
and
he
was
saying
like
yes,
there
were.
There
was
a
lot
of
topics
so
yeah,
so
so
yeah.
B
But
I
think
you're
completely
right,
but
I
think
that
the
point
I
I
try
to
make
is
so
even
if
you
have
thousands
of
topics
so,
let's
say
10
000
of
topics,
let's
even
say
for
a
second
of
conversation,
you
have
100
000
kafka
topics.
I
mean
this
would
be
very
huge
like
this
would
be
a
lot,
so
this
might
be
orders
of
magnitude
more
than
people
have.
B
When
you
think
about
an
mqtt
deployment,
you
literally
have
usually
at
least
one
topic
per
device,
at
least,
if
not
more
so
I
guess
I'll
give
you
one
example
one
the
one
deployment
of
this
is
a,
but
this
is
on
the
larger
side
of
things.
B
We
have
a
deployment
of
a
single
mqtt,
hivenq
cluster,
which
has
more
than
160
million
subscriptions
growing
every
day,
and
this
is
like
really
a
lot
at
mqtt
topic
subscriptions
which
in
the
end
are
mean
individual
topics,
and
this
is
like,
even
if
you
have
100
000
topics
like
I'm
saying
more
than
100
million.
B
This
is
like
a
lot
of
additional
stereos,
and
this
is
like
completely
mind-blowing,
because
if
you
think
about
mqtt
has
so
many
devices,
this
means
you
have
this
kind
of
a
lot
of
very
small
data
streams
from
each
device
to
a
single
led,
broken
the
cloud,
a
lot
of
very
small
streams.
When
you
think
of
a
cuff,
you
usually
have
this
very
thick
pipe
where
you
basically
pipe
in
data
and
what
is
often
done
at
the
mqt
level
and
the
equity
broker
level.
B
So,
for
example,
we
have
a
native
kafka
integration,
our
broker
for
doing
exactly
that.
You
can
take
all
of
these
very
small
streams
and
basically
pump
it
into
a
a
big
kafka
stream
or
multiple
kafka
topics,
and
that's
also
bi-directionally.
So
very
often
you
also
get
this
kind
of
kafka
topics
where
mqt
broker
consumes
and
then
figures
out
how
to
distribute
it
across
probably
millions
of
devices.
B
So
this
is
like
very
different,
and
so
you
have
a
lot
of
topics.
A
lot
of,
let's
say,
data
streams
on
the
mqt
side
and
on
the
kafka
side
is
usually
orders
of
magnitude
less
usually,
and
so
this
is,
I
think,
where
it
really
blends
together
very
nicely,
and
this
is
also,
I
think,
an
interesting
point
where
we
can
basically
from
an
api
standpoint
where
yeah
a
lot
of
interesting
conversation
can
happen.
B
Also
what
essence
api
can
provide
here
on
the
npt
level,
but
also
in
the
kafka
level,
because-
and
I
think
you
you
mentioned
that
earlier-
if
I
understood
correctly-
the
enquity
broker
has
one
advantage.
It
is
the
central
entry
point
and
the
bi-directional
conversation
point
with
all
the
devices
out
there
and
be
it
cars,
be
it
whatever
washing
machines
or
just
mobile
apps,
and
so
you
can
do
a
lot
of
interesting.
So
you
could
do
a
lot
of
interesting
things
here.
B
From
let's
say,
validation
like
is
the
top
like
policies
in
the
end,
basically
async
api
specifications
could
serve
as
a
policy
like
what
what
is
the
device
allowed
to
do?
So?
This
is
the
specification,
even
even
what
kind
of
of
data
is
the
device
allowed
to
send
and
so
on?
I
think
an
interesting
conversation
would
be
how
this
would
be
structured
if
you
have,
let's
say
100
million
topics,
how
you
would
get
that
manageable
with
the
api
and
this
this
might
be.
B
I
think,
they're
part
of
the
conversation
where,
where
I,
if
I
need
to
learn,
I'm
not
an
expert
on
topic,
but
this
might
be,
I
think,
an
interesting
challenge
to
solve
so.
A
Yeah
not
not
easily,
so
that
how
do
you
do
it
not
easily
for
sure
like?
Because
would
you
say,
like
you
have
in
multiple
occasions,
you
have
brokers
deployed
on
the
edge
so
like
in
a
factory,
for
instance,
so
they're
like
close
to
the
machine
that
is
actually
emitting
or
receiving
events,
so
so
yeah
like
this
is
like
the
edge
right.
So
how
do
you
I'm
curious
about
before
I
answer
the
q?
A
This
question,
I
think
I
need
to
know
something
like
is
the
topic
creation
needed
beforehand,
like
before
a
publisher
can
publish
on
a
certain
topic
on
an
mqtt
broker.
I
know
it's,
this
can
be
automatic.
Like
you
publish
you,
can
this
can
be
dynamic,
the
publisher
publishes
in
the
topic
and
then
it's
it's
created
behind
the
scenes.
B
B
This
is
yeah,
so
I
would
say
it's
dynamic,
but
within
a
certain
rule
set
so,
for
example,
let's
to
make
it
more
plastic,
I'm
just
looking
out
of
the
window-
and
I
see
a
lot
of
cars
here.
So
let's
do
a
car
example,
so
so
one
could
imagine
to
have
a
topic
trend
for
the
people
who
are
not
familiar
with
mqtt.
B
You
have
this
kind
of
hierarchical
topics
with
like
a
posix
file
system
right,
so
you
get
this
nice
tree
basically,
and
just
for
the
sake
of
conversation,
let's
say
the
topic
would
be
car,
slash
the
identifier
of
the
car,
slash
gps
data
really
just
for
server
translation,
and
this
would
be
the
topic
like
gps
data
for
the
cover
would
be
published,
and
this
is
a
pattern.
You
see
a
lot
of
mqtt,
so
you
usually
have
this
kind
of
identifier
of
of
the
device
itself
also
in
the
topic.
B
So
while
you
get
a
decoupling,
of
course,
on
the
back
end,
you
can
then
still
figure
out
like
for
what
car
is
this
gps
data?
So
you
can
address
that,
and
the
same
is
all
true
for
subscribing.
Let's
just
say
the
car
is
subscribing
to
cars,
slash
my
id
slash
commands,
for
example,
to
receive
commands
from
the
cloud.
So
just
with
that
pattern
you
would
have
for
each
car
deployed
and
manufactured.
B
Basically,
you
would
create
two
topics,
one
for
a
subscription
and
one
to
publish
tool,
and-
and
so
this
is
what
I
mean-
it
will
be
dynamic
because
with
each
car
basically
connected.
B
There
will
be
these
two
topics
that
we
created,
but,
like
only
this
specific
car
will
probably
use
it
and
should
use
that
and
what
you
should
do
on
the
mqt
broker.
You
provide
rules
and
say:
okay,
the
only
car
with
identifier,
france
car,
would
basically
should
also
be
allowed
to
subscribe
and
publish
to,
like
the
the
france
car
identify
like
cars,
france,
car
gps,
for
example-
and
this
is
what
you
would
usually
do
so
this
kind
of
of
variable
interpolation,
if
you
will.
A
So
let
me
turn
the
frame
in
another
way,
so,
for
instance,
when
you
we're
in
a
factory
and
we're
publishing
to
a
a
broker-
and
that
is
sitting
in
that
same
factory-
and
this
you
said
like
it's
federated,
because
you
have
10
factories
and
it's
probably
federated
what
between
the
10
factories
and
probably
with
one
on
the
cloud
as
well
so
they're
all
like
in
that
federated
right.
So
there
is
a
federation
mechanism
happening
there,
which
is
like
communicating.
A
This
broker
is
communicating
not
just
that
the
message
has
been
published,
but
that
a
topic
has
been
created
right,
like
there's
a
new
topic
here
in
this
broker.
So
I
want
to
notify
the
rest
of
the
brokers
that
this
topic
is
already
like.
It's
brought
into
life.
It
is
it's
like
that.
You
know
what
I
mean
it's
like,
so
the
rest
of
the
the
brokers
are
aware
that
this
topic
now
exists.
Is
this
yeah
something.
B
B
Behind
the
scenes,
yeah
you're-
usually
usually
not
not
that
much
so
I
think
from-
and
this
is
this-
I
think,
a
key
difference
with
mqt
towards
let's
say
other
technologies.
That
topics
are
a
thing
like
like
a
like.
A
for
example,
like
a
traditional
rabbit
infusion
I
mean
a
topic:
has
a
configuration
usually
and
and
and
yeah
takes
reserves,
some
kind
of
memory
and
and
stuff
and
with
mqtt
a
topic
is
actually
just
a
metadata
of
the
message
of
the
message
yeah.
B
So
so,
while
the
broker
of
course
needs
to
be
aware
of
that-
and
I
mean
this
is
pretty
complex
and
complicated-
how
a
broker
would
basically
even
do
that
scale.
This
is
not
not
easy
to
do.
This
is
actually.
C
B
Hard
to
do
in
a
distributed
system,
but
but
in
in
the
end
it's
still
completely
dynamic
and
the
broker
usually
will
not
make
any
assumptions
on
that.
B
And
while
I
mean
you
can
restrict
that
of
course-
and
this
is
something
like
our
customers
do,
because
you
really
want,
if,
especially,
if
you
know
beforehand
like
how
does
it
look
like
a
factory-
is
pretty
static,
it's
not
that,
like
there
are
10
machines
each
day
they
come
online
by
accident,
because
if
a
new
machine
is
deployed
somewhere,
usually
people
know-
and
this
is
not
an
overnight
thing.
B
This
is
a
like
a
huge
thing
if
a
new
car
is
manufactured
like
this
is
not
something
you
want
an
administrative
action
to
be
happening
right,
and
so
so
these
are,
I
think,
different
use
cases.
So
I
would
argue
for
the
factory
use
case.
You
would
actually
want
a
kind
of
static,
let's
say
an
enforcement
of
that,
and
then,
of
course
I
could
imagine
that
you
also
want
to
notify
other
participants
and
brokers
about
that
happening.
I
haven't
seen
that
yet,
but
this
is
an
interesting
case
to
think
about.
A
Yeah
I
was
I
was
asking
because,
like
I
was
trying
like
to
think
like,
maybe
we
can
take
advantage
of
this
federation
mechanism
where
this
information
sharing
happens
between
different
brokers
and
and
so,
if
we
deploy.
If
we
configure
one
broker
with
a
sync
api,
we
just
imagine
imagine
we
don't
know
yet
how
to
do
it,
but
it's
like
the
broker
supports.
I
don't
know
configuring
uploading,
some
amazing
kpi
files
and
to
or
some
some
missing
kpi
document
or
whatever
to
configure
it.
A
Then
this
could
be
federated
across
all
the
all
the
brokers,
taking
advantage
advantage
of
the
existing
mechanism
right.
So
it
only
happens
whenever
there
is
a
change
in
the
configuration
right.
So
it's
not
on
every
message.
Otherwise
it
will
be
yeah
too
much
right
and
that
that
the
way
I
was
thinking
is
like,
maybe
you
you
say.
A
For
instance,
you
have
a
cloud
broker
and
you're
interacting
with
your
cloud
broker,
and
you
want
to
you
configure
it
with
this
in
kpi
or
with
cloud
events
or
whatever,
and
then
you
spread
this
information
across
all
the
nodes,
all
the
other
brokers
in
the
factories
in
everywhere
right.
So
so
then,
these
brokers
become
aware
of
of
of
the
topics
that
they
might
that
they
can
expect
the
messages
they
can
expect
in
in
these
topics
or
if
that
makes
sense
from
in
kennedy
point
of
view.
But
you
know,
but
the
headers.
A
You
know
like
what
kind
of
what
kind
of
data
they
can
expect
there
like
policy
enforcement,
I
can
understand,
might
not
be
a
big
deal
here.
I
may
be
wrong,
but
I
don't
know
how
often
you
hear
that
now
situations
where
people
publish
wrong
messages
like
with
the
wrong
shape
or
something
and
then
something
breaks,
but
but
something
that
I
will
be
really
interested
is
about,
for
instance,
having
visibility
like
how
many.
B
A
We
have
in
the
platform
who
which
who's
publishing
what
who
is
subscribed
to
this
topic.
You
know
who
is
receiving
this
information
who
which
how
they
are
communicating
to
each
other,
because
they're
not
communicating
directly,
so
the
only
way
to
know
how
they're
communicating
to
each
other
because
in
the
end,
a
message
flows
from
one
point
or
multiple
points
to
multiple
points.
So
you
want
to
know
these
connections
right
so
yeah
so
that
you
can
go,
learn
like
or
or
or
even
monitor,
what's
happening
in
your
in
your.
B
Basically,
create
a
create
a
a
map
of
of
what's
happening.
If
you
will
so
so
to
discover
that
yeah.
This
is
actually
an
interesting
point.
I
also
think
a
lot
about
that,
because
there
are
especially,
for
I
mean
just
look
at
people
who
have,
for
example,
you
you
basically
have
a
smart
home
deployment
with
mqdt,
so
a
lot
of
people
are
using
mosquito
there
or
having
a
community
edition
for
their
smart
homes
and
so
with
a
lot
of
people.
B
I
have
a
conversation
with
after
while
they
start
with
one
device
bringing
that
online,
a
second
device
with
amputee
and
so
on,
and
sometimes
people
are
wondering
like
what's
actually
happening.
What
kind
of
topics
are
subscribing
what's
actually
happening,
and
this
is
in
a
small
case
like
with
probably
10
devices
20
devices
people
are
still
getting
confused,
what's
actually
happening
and
imagine.
B
And
and
honestly,
you
would
be
surprised
when
we,
when
we
also
had
people,
basically
discover
what's
happening
in
their
deployments.
People
are
very
often
surprised
by
some
applications
which
nobody
knows
about
who
are
like
elected
application,
but
the
platform
team
was
not
informed
that
then
the
now
selective
application
policies
or
their
permissions
were
too
too,
let's
say
too
broadly
configured
in
the
beginning
and
and
then
yeah,
and
so
this
stuff
happens
like
in
real
life
and
and
so
yes,
this
would
absolutely
help.
B
I'm
wonder
I'm
wondering,
though,
as
from
and
this
this
might
be.
I
don't
have
experience
with
this,
so
it
would
be
interesting.
Your
perspective
from
a
scale
perspective,
let's
so
maya
settings,
async
api
usually
is
done
with
one
file.
This
is
at
least
how
I
use
it
right.
So
can
can
you
can
you
basically
split
it
up,
because
I'm
worried
about
what
do
you
do
if
you
have
whatever
one
million
topics
or
so
if
a
single
file
wouldn't
be,
let's
say
overkill?
B
A
There
are
there
are
there
are,
but
they're
not
perfect,
yet
they're
not
like
not
perfect,
but
they're,
not
even
good.
I
will
say
so.
You
will
still
need
to
have
like
a
single
file
with
all
the
million
topics,
just
that
each
topic
will
be
defined
on
another
file.
So
but
you
still
will
need
this
single
file
with
the
with
the
one
million
list
right
just
it
will
be
just
a
list
of
topics
and
reference
to
external
files,
okay,
but
you
still
need
that.
A
You
still
need
that
file
like
an
index
file
right,
but
but
with
version
three
we're
trying
to
we're
trying
to
make
that
better
right,
so
the
reusability
a
little
bit
a
little
bit
better
and
actually
something
that
we
are
we're
not
yet
proposing,
because
actually
after
this
live
stream,
we
have
a
spec
3.0
discussion
where,
because
we're
working
on
the
next
version
of
the
spec
and
and
something
that
we're
working
on
is
how
can
we
make
it
like
you
know?
A
How
can
we
make
to
speak
in
a
way
that,
where
you
can
actually,
maybe
not
like
you
said
like
in
you,
have
one
million
topics
say,
for
instance,
you
want
to
have
like
groups
of
this
one
inside
this
one
million
you
want
to
have
domains
right,
like
some
people
call
it
domains
or
it
can
be
domain
as
in
domain-driven
design
or
can
be
domain
as
in
something
you
invent
yourself
that
is
suitable
for
you
right.
So
a
group,
that's
a
group
of
topics,
so
that
will
actually.
A
A
To
my
to
my
experience,
I
think
this.
The
way
it's
going
to
happen
is
not
inside
the
sync
api,
so
pro
will
have
to
create
like
a
top
level
new
specification
where
you
can
group
all
of
them
and
and
they
will
reference
existing
cpa
files
or
something
like
that.
So
so
yeah,
that's
we're
still
yet
to
figure
out,
but
it's
possible
so.
B
B
Because
we
had
actually,
we
worked
on
a
similar
problem
and
because
we
we
so
we
developed-
or
we
basically
opened
to
the
public,
a
tool
called
having
to
swarm
a
while
ago.
B
And
so
since
we
all,
we
always
had
the
problem
that
the
scale
we
are
testing
and
quality
assuring
our
product
against
is
very
hard
to
achieve
because,
like
we
are
literally
having
10
million
of
devices
like
hundreds
of
thousands
of
messages
per
second
flowing
through
multiple
data
scenes
around
the
world
and
stuff
and
mqtt
has
the
interesting
property
that
it
has
an
open
and
standing
tcp
connection
and
having
10
million
standing.
Tcp
connections
really
brings
every
infrastructure,
I'm
especially
looking
at
azure
to
its
yeah
to
its
limits.
B
Actually
so-
and
this
is
why
we,
we
developed
a
tool
also
like
a
distributed
load,
test
tool
and
basically
scenario
tool
where
you
plug
in
a
scenario
what
we
call
scenario
and
then
under
the
hood.
It
basically
will
will
do
that
similar
to
what
you
do
with
jmeter
like
in
a
click
this
this.
B
Basically,
it
generally
creates
that
the
load
and
index
that
behavior
and
can
publish
to
millions
of
topics
and
so
on,
and
here
we
also
had
this
kind
of
grouping
concept,
where
we
grouped
mqt
clients,
every
group
topics
and
so
on,
and
also
basically
work
also
with
rules
very
basically
embed
rules,
how
messages
are
created
and
how
are
they
subscribed
to
so
there's
a
kind
of
rule
engine
in
there
which
works
pretty
well.
B
Actually,
it
gets
complicated
for
complex
scenarios
after
some
time,
but
yeah,
and
you
can
of
course
expand
that
if
you
want,
but
usually
you
you
get
like
in
the
scenario
which
I
could
just
mention
like-
there's
a
car
and
then
slash
the
identifier.
This
will
be
literally
like
this
line
of
code
instead
of
probably
millions
so
this
this
is.
This
is
something
like
in
a
follow-up
conversation
also.
B
A
Yeah
yeah
yeah,
but
please
please
share
this
like
even
during
the
call,
if
you
want,
or
after
the
call
so
this
just
reminded
me
of
ak,
so
we
have
some
faults
from
sora
robotics.
Let
me
just
make
sure
that
I'm
doing
this
I'm
reading
this
correctly,
but
this
limit
damn
youtube.
A
I
don't
want
to
watch
ads
now,
so
they
they
gave
a
talk
at
the
zinkepe
conference
and
there
are
their
robotics
company
and
they're
using
this
in
kpi,
and
they
had
this
exactly
the
same
problem,
which
is
they
had
like
a
huge
deployment
with
many
topics
and
therefore
having
a
single
async
api
file.
It
was
like
too
much
right,
so
they
created
a
tool
where
they
could
split
into
multiples
and
kpa
files,
and
then
they
they
had
the
tool
that
they
will.
A
It
will
assemble
all
of
them
together
right,
so
they
were
working
on
separate
asynchrony
files,
but
at
the
end
of
the
day
they
will
assemble
them
together
and
there
is
the
recording
yes.
So
let
me
share
this
on
the
chat,
so
people
can
also
watch
it.
So
there's
this
talk
right
and
I
completely
recommend
you
watching
this.
Since
it's
you
know,
iot
related,
they
created
some
some
cool
tools
to
to
to
use
this
in
kpi
with
mqtt
and
with
you
know
this
iot,
let's
say
application.
A
If
you
want,
and
and
also
solving
this
problem,
I
I
knew
this
was
this
was
a
problem
for
them.
Usually
we
don't
have
that
problem
like
like
people
doing
microservices
architecture.
They,
like
you,
say
like
they,
have
lots
of
topics,
but
not
that
lots
of
topic
right
so
not
usually
right
or
they
just
don't
document
everything
which
is
also.
A
A
No
kidding
that
I
mean
I
understand
that
some
people
don't
want
to
document
everything
like.
Sometimes
if
you
have
inside
the
same
team,
if
you
have
three
services
talking
to
each
other
through
the
broker,
but
it's
just
to
coordinate
something
between
the
two
or
three
services
and
it's
not
to
meant
to
be.
It's
not
meant
to
be
consumed
by
external
other
teams
or
something
like
that.
Then
I
understand
it's
like
I
don't
I
don't
care
it's
like
I.
I
know
the
code,
this
my
team
knows
the
code.
They
know
how
it
works.
A
B
So
speaking
of
that
there's
one
thing
I
so
now
now
I
have
have
you
here
in
this
course.
I
wanted
to
to
learn
about
that,
just
for
a
long
time
actually,
but
never
had
a
chance.
So
perhaps
you
can
help
me
here,
so
this
is
true
for
many
messaging
systems
right.
So,
while
there
is
a
specification,
let's
do
an
mqt
as
an
example
here
there's
the
specification
with
version
three
and
version
five,
for
example,
with.
B
Feature
sets,
but
also
I
mean,
while
with
mqt
version
three,
there
is
really
no
optional
features
like
a
mqtt
broker
must
support
everything,
still
some
things
that
have
limitations,
for
example
aws
iot
as
well
as
azure
iot
hub.
They
have
basically
just
support
a
subset
of
the
features,
for
example,
when
it
comes
to
retail
messages
or
the
topic
structure,
and
so
on.
There
might
be
limitations
on
the
site,
so
does
it
as
an
api?
B
Also,
this
kind
of
let's
say
so,
let's
say
distribution
thing
where
you
can
also
indicate,
for
example,
okay.
This
is,
for
example,
like
a
full-fledged
mqt
broker
that
supports
everything.
This
is
whatever
the
iot
hub
profile,
which
like
has
this
kind
of
certain
limitations,
so
so
because
when
it
comes
to
validation
and
so
on,
because
now
the
architect
would
would
basically
write
their
file
against
that
and
say.
Okay,
I
want
to
use
a
free
topic
structure
with
iot
hub,
for
example.
This
might
be
a
problem
because
you're
not
allowed
to
do
that.
B
B
That
you
can
do
yeah,
yes,
so
basically,
because
if
you,
for
example,
generate
code
for
example,
then
then
you
I
mean
it
would
be
very
bad
if
you
would
generate
the
code
against
basically
a
system
that
is
not
supporting
the
code
generated
right
and-
and
I
would
think
if
you
get
because
I
think
the
value
of
essence.
B
One
of
the
values
is
that
you
have
the
single
source
of
truth
like
in
this
file,
which
you
can
generate
code
from
and
they're
like
you
document
things,
and
this
should
really
reflect
the
reality
and,
and
so
so
is
there
anything
like
that
plan
or
or
possible
like
the
limitations
in
kind
of
a
metadata
or
so
or
give
applications
a
chance
to
understand?
Okay,
this
is
iot
up,
so
my
code
generation
should
not
use
all
that
standard
feature
supported
by
other
platforms,
for
example,.
A
No,
we
don't
have
this
kind
of
of
like
like
division.
If
you
want
like
like
this,
must
be
supported
if
or
this
should
not
be
supported.
If
it's
iot
case
or
something
like
that,
like
the
way
we
do,
we
have
optional
features
that
the
tooling
might
or
might
not
support.
A
That's
that's
the
only
thing
that
we
have
then.
For
the
rest,
if
you
say
I
support
async
kpms
and
this
tool
is
supporting
using
kpi,
then
you
should
be
supporting
all
the
required
all
the
required
features.
Let's
say
right,
you
have
like
I
said
you
have
optionals,
but
they're
not
a
lot.
A
Most
of
them
are
like
required,
and
I
think
you
actually
brought
an
interesting
point
because
for
for
certain
use
cases
you
might
not
need
to
have
a
fully
fledged
async
api
support
right
like,
for
instance,
yeah.
There
are
cases
where
correlation
id,
you
don't
care
so
much
about
the
correlation
id
on
the
message.
A
A
What
but
yeah
like
we
don't
have
that
kind
of
thing,
but
we
could
we
can
have
it
like
it's
just
a
matter
of
of
of
making
a
proposal
like
we're
like
really
community
driven
and-
and
we
listen
to
it's,
not
that
we
listen
because
we
I
mean
when
I
say
we
it's
really
the
community
and
and
the
tse
is,
is,
I
think,
we're
30
something
people
already
and
and
and
from
from
different
companies
and
backgrounds,
so
they,
but
on
the
spec.
A
We
we're
so
far
with
three
cloud
owners
still
and
we're
looking
to
augment
that.
So
we
still,
but
then
in
case
this
is
these
are
code
owners
that
doesn't
mean
that
we
have
to
do
all
the
work,
and
actually
we
don't
want
to
do
all
the
work.
We
want
the
community
to
influence
the
the
future
like
like
with
version
three
right,
so
so
yeah
like
this.
This
is
definitely
open
to
you
to
to
happen
that
we
have
like
we.
A
We
looked
through
the
through
the
spec
and
say
like
hey
from
an
iot
perspective.
For
instance,
I
don't
care
about
this,
and
I
don't
care
about
this,
and
I
don't
care
about
this,
and
and
when
it's
iot
and
generating
code,
it
should
work
like
this
when
it's
iot
and
generating
documentation.
It
should
work
like
this
other
way.
A
Cool
work
I
mean,
might
might
alleviate
a
little
bit
of
the
load
on
the
tooling
developers
right
on
the
on
the
on
the
product
developers
as
well,
because
because
yeah
like
supporting
the
full,
it's
in
kpi
specification
might
be
a
little
bit
of
a
pain
right,
so
so
yeah.
I
I
actually
see
the
value
there.
B
So
I
I'm
really
curious
also
about
code
generation,
so
so
I
think
we
haven't
covered
that
yet
so
do
you
so
because
I
think
this
is
like
super
interesting
also
for
us,
the
kind
of
that's
the
code
generation
on
the
client
side,
because
if
you
now
really
either
define
beforehand,
even
would
have
the
possibility
to
create
a
let's
say,
an
essence:
api
specification,
basically
on
the
broker
side,
and
then
it
might
be
really
useful
to
also
generate
the
clients
based
on
that
for
an
mqt
perspective.
B
And
so
so,
since
we
also
have
an
apache
two
licensed
library.
We
developed
with
a
bmw
a
while
ago,
which
is
a
high
performance
java
library
for
for
mqtt,
which
supports
mqt
version,
three
five
and
all
features
and
all
the
optional
features
just
like,
like
the
perfect
fit
also
and
we're
thinking
also
about
like
how
would
this
be
a
fit
of,
let's
say,
code
generation,
because
I
think
this
is
interesting.
What
what
I
personally
don't
understand-
and
I
mean
this
is
a-
I
think,
a
philosophical
question.
B
I
know
from
the
days
back
then,
when
I
did
a
lot
of
let's
say:
database
stuff
with
the
or
or
orm
the
object
relationship
layer
like
are
you
writing
the
database?
First?
Are
you
writing
your
let's
say
in
java
entities
first,
which
generate
the
database
so
so
that
the
egg
versus
versus
hand
problem
and
yeah.
C
B
A
I
see
it
too,
and
I
don't
see
one
like
predominant
above
another,
so
we
have
that's,
we
call
it
like
code
first
or
design
first
right.
So
what
do
you
do
like?
Do
you?
Do
you
do
sign
you
design
your
apis
or
you
even
driven
architectures
first
and
then,
and
then
you
generate
the
code
or
do
you
code
first,
and
then
you
generate
this
and
give
a
file
from
your
code
from
annotations
or
something
like
that
right.
We
see
both.
A
We
see
both
and
actually
I
have
a
blog
post
on
the
pipeline
right
now
that
I'm
going
to
publish
in
the
next
in
the
next
week
about
this
and
and
and
that
it
doesn't
have
to
be,
it
doesn't
have
to
be
either
way
like
or
either
they
design
first
of
code.
First,
I
think
about
it
like
what,
if,
like
my
our
proposal
with
glee,
we
have
a
framework
called
glee,
which
is
it's
not.
The
concept
is
not
new.
A
The
concept
is
the
same
as
in
graphql,
for
instance,
the
way
graphql
uses
the
schema
file
to
to
actually
create
the
api.
A
So
if
you
want
to
create
a
new
query,
your
mutation
on
graphql
or
you
or
in
grpc,
if
you
want
to
add
a
new
message
or
something
like
that,
you
have
to
add
it
first
to
protobuf
in
the
case
of
jrpc,
or
you
have
to
add
it
first
to
to
the
schema
the
graphql
schema
file
right
so
because
the
code
itself,
it's
using
the
the
specification,
the
schema
file
as
a
config
file
right.
So
if
it's
not
there,
if
it's
not,
if
it's
not
in
the
schema
file,
it
doesn't
work.
A
Basically,
it's
like
it's,
not
it's
not
even
like
you
cannot
make
it
work
without
putting
it
on
the
on
the
schema
file.
So
what
we're
developing
since
almost
a
year
now
is
a
framework
that
takes
a
a
nissan
kpa
file
as
a
config
file
right
and
then
you
only
work
on
the
business
logic
right
and
if
you
want
to
subscribe
to
a
new
topic
or
publish
to
a
new
topic
or
something
like
that,
the
only
thing
you
have
to
do
is
to
put
it
on
the
asyncpro
file
right.
A
A
So
that's
what
you
will
have
to
do
yourself,
of
course
we're
not
yet
with
wizards,
but
but
the
concept
is
this:
the
concept
is
like
what,
if
it's
something
that
you
have
to
do
at
the
same
time
like
I
mean
while
you're
writing
your
code,
you
have
to
be
writing
your
spec
right,
because,
if
you
do,
if
you
don't
do
it
like
this,
it
will
not
work,
let's
say
for
instance,
if
it's
not,
if
you
don't
have
a
subscribed
verve
on
your
sync
api
file,
then
it
will
not
subscribe
to
the
to
the
broker
and
you're
not
going
to
receive
the
the
message,
and
so
you
will
have
to
put
it
there
if
you
want
to
subscribe
right,
but
that's
like
a
limited
use
case
and
not
use
case.
A
That's
a
limited
solution,
because
it's
only
for
people
who
don't
have
any
code
yet
and
can
start
with
typescript
with
cli
right
doing
this,
so
cool
they're
covered,
but
those
where
they
have
a
huge
code
base
like
they
have
hundreds
or
thousands
of
projects
already
with
code
with
java,
for
instance,
how
do
you?
How
do
you
enforce
that
at
code
level
right?
So
one
thing
that
we're
going
to
propose
is
adding
for
at
least
for
the
major
protocols,
major
frameworks.
A
Sorry
plugins,
for
these
frameworks
that
you
can,
where
you
can
actually
enforce
the
plugin
will
force
you
to
have
an
sdk
file
that
matches
what
the
code
is
doing
right,
not
easy,
not
easy
solution
but
but
possible
nonetheless.
So
so
so
yeah,
that's
it!
That's
that's
what
we
see
and
that's
what
we're
advocating
for
lately.
B
And
this
is,
as
I
said,
I
mean
this
is
what
I
find
so
interesting
about
messaging
and
even
after,
like
doing
nothing
else,
the
messaging,
basically
in
in
more
than
10
years.
Now
it's
really
exclusively
working
on
mqt.
It's
still
so
interesting
because
of
the
decoupling
of
stuff
in
messaging
makes
it
so
so
interesting
as
a
such
an
interesting
problem
to
solve
and
but
yeah.
As
I
said,
it's
it's
complex
a
bit
more
complex
than
if
you
have
a
very
tight
relationship
between
a
client
and
a
server.
A
A
Listening
to
subscribing
to
this
topic
and
just
doing
something
with
the
message
or
publishing
or
whatever
right
and
it's
it's
a
it's
really
a
plugable
architecture.
It's
it's
really
easy
right,
but
yeah.
That
is
an
advantage,
and
it's
also
a
drawback,
because
as
soon
as
it
grows
exponentially
right
and
it's
it
can
go
quickly
out
of
hands.
A
You
don't
know,
what's
happening
like
you,
don't
know
which
messages
are
being
published.
You
don't
know
who's
subscribing
to
what.
Then
you
cannot
answer
the
question.
This
question
that
I
often
hear
is
like
I
I
often
ask
which
is:
do
you
know
if
you
change
this
message,
you
make
a
breaking
changes.
If
the
in
this
message
that
is
being
published,
do
you
know
who's
going
to
get
affected.
C
A
B
The
whole
topic
of
retrofitting
stuff,
which
which
I
I
don't
think
we
should
open
that-
can
of
worms
right
now,
but
this
is
also
something
that
is
very
often
needed,
and
this
is
also
like
what
we
see
a
lot
like,
basically
having
also
the
mqtt
broker,
help
translate
between
versions
because
of
incompatibilities
in
the
field,
because
usually
it's
much
harder
to
update
everything
in
the
field.
Then
just
have
this
kind
of
ritual
fitting
stuff
similar
what
you
mentioned
with
kafka,
but
people
with
coffee
like
just
publishing
on
new
topics
mqt.
B
A
Yeah
yeah
yeah,
so
that
is,
that
is
why
that
is
one
of
the.
So,
after
all
like
when
I
invited
you
to
have
this
chat
about
like
how
can
we
make
brokers
to
be
more
aware
of?
What's
all
in
the
whole
thing
in
the
whole
architecture,
if
you
want
the
whole.
A
It
was
all
coming
from
this
from
this
situation
like
people
are
like.
We
want
to
have
that
that
control
right.
Yes,
but
if
you're
starting
a
fresh
new
project,
that's
not
a
problem!
You
have
glee,
you
can
use
glee
and
that
will
make
you
that
that
will
make
you
happy
and
so
that's
actually
playing
like
you'll
be
covered,
like
everything
will
be
documented
because
you
have
no
other
option.
A
But
if
you
already
have
a
huge
code
base,
we
cannot
ask
people,
I
don't
know
like
say
imagine
at
ibm
or
something
like
that,
having
a
bmw,
probably
or
adidas,
for
instance,
who
already
have
lots
of
deployed
code
to
simply
migrate
to
glee
all
their
services
right?
That
would
be
insane
like
it
said:
no,
no,
we're
not
going
to
do
it,
but
who
has
this
this
power?
Who
has
the
power
to
do
it
like
really
easily?
A
A
Like
that
just
trigger
some
kind
of
notification
or
paging
someone
or
something
like
that
right
or
or
something
just
just
for
you
to
discover
that
something
is
wrong
right.
Maybe
the
schema
definition
is
wrong
or
the
message
is
growing
whatever
whatever
is
is
correct
right,
so
so
that
that
is,
that
would
be
actually
super
super
cool
in
terms
of
governance
of
the
whole
event-driven
architecture,
because
that
will
give
you
visibility.
You
will
be
able
to
draw
this
map.
A
People
will
be
able
to
search
for
certain
information,
something
that
happened
I
mentioned
eurolec
before
so
I
wanted
to
subscribe
to
specific
user
actions,
let's
say,
for
instance,
when
a
user
signs
up.
A
I
want
to
receive
this
message
with
the
user
information
right,
like
email
display,
name
and
so
on,
but
I
didn't
know
who
was
publishing
this
kind
of
message
and
it
was
already
being
published
and-
and
I
and
I
could
just
ping
someone
who
has
this
information
from
the
database
like
it
was
a
microservices
architecture,
so
whoever
whoever,
whichever
team
that
had
access
to
the
user
information
on
the
database,
could
be
triggering
this.
These
events
for
me
right,
I
could
ask
that,
but
I
didn't
want
to
do
that.
I
didn't
want
to
do
that.
A
This
way,
like
instead
ins
started
investigating,
and
I
discovered
that
this
same
message
like
a
user
was
signing
up,
was
triggered
in
three
different
points
in
three
different
topics.
So
the
same
almost
the
same
information,
because
people
were
not
aware
that
this
message
was
already
being
triggered
in
this
topic,
so
they
couldn't
discover
it.
So
they
were
asking
to
create
a
new
one,
a
new
topic
for
them
to
consume
the
data
right
so
so
effectively.
A
Is
that
you're
creating
a
new
topic
per
per
consumer
right,
which
is
like
it's
a
waste
of
resources
and
and
yeah,
and
it's
because
of
the
lack
of
visibility.
A
So
so
that
is,
that
is
something
that
people
could
be
just
going
into
the
broker
platform
or
website,
or
something
like
that
and
search
like
user
email.
Something
like
that
and
here's
a
list
of
topics
where
the
user
email
is
being
is
in
the
data
payload.
It's
in
the
message
payload
or
in
the
message.
Headers
might
not
be.
B
Something
like
that,
right
and
and-
and
I
think
you're
spot
on
with
your
observation-
and
I
think
so
because
I
mean
these
are
exactly
the
things
like
we
think
a
lot
about.
We,
we
also
work
on
specific
things
to
to
make
what
just
had
more
reality.
B
I
personally
do
believe
that
essence,
api
might
might
play
a
key
role
here.
I
think
there
is,
I
mean
the
time
is
like
there's
so
so
much.
We
could
talk
about
the
topic.
This
is
just
amazing,
and
so
so
this
would
be
something
I
I
would
love
to
follow.
Follow
up
at
some
point
of
time
to
really
discuss
also
that
in
detail,
because,
like
I
think,
and
especially
now,
with
async
api,
three,
let's
say
I'm
baking
and
kind
of
at
some
point
of
time.
B
I
do
think
there
might
be
a
few
tweaks
that
would
make
it
even
more
more
possible
for
this
kind
of
very
large
scale,
let's
say
scenarios
and
yeah-
and
this
is
something
like
I
would
be
super
interesting
and
having
that
conversation
I
could
look
like
or
even
how
having
you
could
help
make
that
a
reality.
A
We're
also
interested
because
we
want
to
for
the
next
version
we're
not
in
a
rush,
so
we
don't
know
yet
when,
when
we
are
releasing
version
3.,
but
this
time
we
don't
want
to
make
a
version
of
a
simple
async
api
based
on
assumptions.
So
we
want
to
make
it
like.
We
want
to
make
an
snkpa
version
that
solves
real
problems
right,
so
we
want
to
work
with
with
the
companies,
especially
with
brokers
or
and
not
just
brokers,
but
companies
having
huge
event-driven
architectures
deployments
right.
A
You
know
like
so
and
and
understanding
what
are
their
their
pain
points
right,
so
so
yeah
and
and
and
see
what
what
we
can
do
there.
If
we
can
do
something,
of
course,
maybe
we
can
so
yeah,
so
so
time
is
running
over
actually
we're
one
hour
passed
already.
So
in
case
you
want,
you
want
to
say
something
before
we.
We
leave.
B
Or
not,
really
so
just
thank
you
for
it's.
I
really
like,
like
the
format
this,
it's
really
great
and
time
really
really
flies
here.
I
do
hope
all
the
people
found
it
interesting
so
for
people
who
are
not
familiar
with
enquiry
and
still
made
it
to
the
end
of
the
of
this
episode
so
yeah
you
can
find
more
about
if
you're
interested
in
mqtt
and
also
a
lot
of
things.
B
I
said
you
should
just
google
it
or
have
you
having
your
dot
com
and
you
find
a
lot
of
stuff
here,
but
I
personally,
as
I
said,
I
just
use
google
all
the
time,
also
for
the
old
stuff.
I
write
or
people
right
here
so
so
yeah
and
also
also
people
feel
free
to
reach
out
to
me
on
twitter
or
linkedin
or
yeah,
wherever
wherever
you
can
find
me
on
the
internet.
I
usually
monitor
these
channels
and
I'm
happy
to
to
start
conversations.
B
I
I
really
love
the
the
messaging
space,
the
iot
space
and
also
now
that
when
it
comes
to
specifications
and
so
on
as
async
apis
of
high
interest,
so
if
people
have
any
input,
please
please
reach
out.
I'm
super
curious
about
all
the
thoughts
from
the
community.
A
So
thanks
a
lot
for
for
joining
today
really
enjoyed
that
and
when
once
we
can
do
this
in
physical
place
together
at
some
point,
we're
gonna
do
this
over
a
cup
of
coffee,
maybe
or
something
like.
A
Travel
that
much
so
right,
cool
dominic
thanks
a
lot
for
again
for
joining
and
thanks
everyone
for
joining
the
the
live
stream.
I
hope
we
didn't
bore
everyone
at
least
and
and
yeah
see
you
in
the
in
the
next
episode.
Thank
you.