►
From YouTube: Thinking Out Loud #13 — with Laurent Broudoux
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
folks
welcome
once
again
one
more
week
to
thinking
out
loud
for
those
who
don't
know
me,
my
name
is
fernandez.
You
can
follow
me
on
the
fnvlass
on
twitter,
and
probably
most
of
the
social
media
is
the
same
handle.
A
So
this
is
a
this
is
thinking
out
loud
for
those
who
don't
know
what
thinking
out
loud
is
is
precisely
that
it's
a
session
where
I
invite
guests,
usually
from
the
community
or
from
the
open
source
community
in
general,
to
think
about
a
specific
topic
right,
so
it
it
depends
on
each
each
week
depends
on
a
different
topic.
A
This
week
I
I
invited
lauren
brudu.
I
hope
I
pronounce
it
his
name
correctly,
he's
saying
yes,
nice,
so
so
I
invited
him
to
join
me
live
to
think
about.
A
You
know,
even
during
architectures
mocking
testing
and,
of
course,
micros
right.
So
for
those
for
those
who
don't
know,
microx
you're
gonna
get
to
know
micros
today
so
or
probably
hear
a
little
bit
about
it,
and
then
you
can
learn
about
it,
a
little
bit
more
after
the
after
the
conversation.
A
Please
let
me
let
me
yes,
so
let
me
tell
you
that
we
have
enabled
closed
captions
on
the
youtube
channel,
so
that's
the
only
channel
where
we
have
it
enabled
for
now
at
some
point
we'll
have
it
enabled
in
all
the
channels.
I
promise,
but
I
don't
know
when
so
in
the
meantime,
if
you
need
or
if
you
prefer
closed
captions,
please
head
over
to
youtube,
youtube.comkpi
and
you'll
see
it
there.
A
Again,
like
I
remind
every
week,
this
is
a
chat.
I
always
invite
a
guest
or
two
guests
usually
to
chat
about
anything,
but
I
always
like
this
to
be
like
a
two-way
communication
between
us
and
the
community
and
the
rest
of
the
community
right.
So
please
get
involved,
don't
be
shy.
Ask
questions,
propose
some
topic,
whatever
that
you
have
in
mind,
share
it
with
us
so
or
just
say
hello.
A
We
always
like
to
see
that
we're
not
along
here
and,
of
course,
follow
us
in
kpi
on
on
twitter,
and
you
can
also
find
us
on
linkedin
on
async
api
initiative
as
async
initiative.
A
So
yeah
that's
pretty
much
it
so
we're
not
I'm
not
gonna,
be
delaying
it
more.
So
please
welcome
lauren.
A
No
problem,
I
mean
it's
my
pleasure
actually,
so
would
you
mind
to
introduce
yourself
for
those
who
don't
know
you
yeah.
B
A
So
I
I
gotta
ask
you,
I
told
you
privately
and
we
agreed
on
something.
So
I'm
going
to
ask
you
publicly
and
then
you
can
give
me
the
same
response
as
in
private.
A
That's
fine,
but
I
have
to
ask
like
for
those
who,
like
ask
that
we
know
you.
We
know
that
you're
switching
jobs
right
so
exactly
I'm
not
gonna!
Ask
you
where
you're
going
next,
but
because
actually
this
is
not
interesting
for
the
async
ebay
audience,
let's
say
for
the
azure
kpi
community,
but
we're
actually
interested
if
you
are
actually
gonna
continue.
A
Maintaining
microx.
B
Yes,
I'm
gonna
continue,
I'm
pursuing
the
the
work
on
my
cross,
yes,
of
course,
and
either,
even
if
it
will
not
be
my
my
full-time
job.
I
have
succeeded
in
having
a
little
bit
more
time
for
working
on
the
on
the
project,
so
I
hope
it
will.
It
will
evolve
even
faster
than
before.
A
Even
faster
than
before
might
mean
that
I
don't
know,
that's
you're
going
to
be
like
a
speedlight
right,
because
you
were,
I
remember
that
we
were
releasing
once
a
new
version
of
the
spec
and
you
and
bob,
and
the
band
folks
were
the
first
ones
to
implement
support
for
the
new
version
of
the
spec
like
a
day
or
two
after
something
like
that,
I
can't
remember
exactly.
B
Microx
is
supporting
a
wide
range
of
different
api
styles.
Api
styles
different
range
of
protocol
bindings,
and
we
have
to
say
that
since
we
we
had
it,
the
async
api
supports
it.
Yes,
we
had
a
lot
of
success.
We
had
a
lot
of
traction
for
the
community,
so
yeah.
We
we
absolutely
want
to
to
stay
at
the
edge
of
the
different
versions
released
and
at
the
different
protocol
supports.
You
may
have
it
so.
A
That's
cool
yeah
yeah,
that
is
cool,
and
that's
I
actually
thank
you
for
this,
because
yeah
yeah,
like
maintaining,
I
know
how
painful
it
can
be,
maintaining
a
tool
in
your
spare
time.
I
actually
know
like
I
did
this
with
this
in
kpi,
but
not
only
with
this
kpi
in
the
past,
I
I
I
was
maintaining
multiple
projects
and
and
yeah
that
is
tiring.
A
It
is
tiring
as
hell,
and
sometimes
you
just
don't
have
time-
to
enjoy
life,
basically
with
your
family,
with
your
friends
with
or
just
along
and
and
have
a
rest
and
and
yeah.
So
we
have
a
message
so
some
mark.
A
A
So
welcome
mark,
by
the
way
I'm
like
super
we're
super
happy
to
have
always
new
people
to
join
the
that
conversation
here.
So
real
welcome
for
that.
B
At
that
time,
we
we
were
supporting
basically
soap
web
services
and
also
rest
apis,
of
course,
and
we
had
a
discussion,
an
open
discussion
with
mark
on
what
were
the
the
plans
around
the
sync
api
around
the
asynchronous
event-driven
apis,
and
he
was
the
the
one
who
told
me
about
this
initiative.
A
I
think
api
yeah
so
mark.
Send
me
your
after
the
call
send
me
your
address,
so
I
send
you
a
t-shirt
and
or
some
kind
of
swag
for
this
evangelization
of
facing
kpi
and
thanks
for
that.
B
Excellent,
yes,
it
should
be
something
in
around
2018
or
something
it
was
just
the
beginning
of
the
oh
yeah
it
was.
It
was.
A
A
No,
no,
I
was
still
on
my
spare
time
at
that
time.
So
I
was,
it
was
a
side
project,
exactly
yeah,
so
so
yeah
pretty
early.
I
would
say
I
started
in
two
2016,
so
so
yeah,
I'm
in
late
2016.,
so
yeah
pretty
early,
pretty
early
cool
man.
So
so
the
topic
today
like
I,
was
mentioning
before
testing
mocking
mocking
micros.
Maybe
like
I
mean
then
I
say
maybe
because
we
don't
want
this.
We
don't
want
this
to
look
like
it's
a
exactly.
B
A
B
B
Yes,
just
to
to
start,
maybe
I
I'm
gonna
talk
about
my
experience
because
actually
the
all
the
work
related
all
the
work
on.
My
crux
is
related
to
my
past
experience,
because
before
joining
reddit
I
was
I
was
working
at
a
customer
that
was
a
big
company
in
financial
services
and
of
course,
we
have
to
deal
with
many
soap
web
services
all
around
the
world,
and
we
wanted
to
to
integrate
this.
B
This
new
kind
of
architecture,
this
new
event-driven
architecture
so-
and
I
was
a
technical
architect
in
charge
of
the
of
the
toolings-
and
I
worked
a
lot
on
everything
related
to
yes
to
developer
tooling.
That
would
be
able
to
deliver
this
kind
of
application
and
architecture
much
faster.
So
I
had
a
lot
of
experience
around
rest
api,
smoking.
B
Okay,
because-
and
I
found
it
was
very
valuable
to
have
the
same
kind
of
toolings
for
all
the
the
synchronous
stuff,
so
really
micro
started
from
that,
because
on
the
field,
I
I
felt
there
was
a
real
pain
around
the
different
development
teams,
waiting
for
each
other
waiting
to
have
either
rest
apis
to
be
up
and
to
start
their
front-end
development
or
to
have
to
wait
for
an
infrastructure,
a
broker
infrastructure
to
be
to
be
ready
to
be
there.
At
that
time,
we
were
speaking
about
mq
series.
B
We
were
speaking
about
a
gms
worker,
mostly,
but
yes,
there
was
a
real
pain
when
people
yes,
starting
to
design
an
api,
we
developers
have
to
wait
for
four
weeks,
four
months
before
actually
being
able
to
yes
to
to
start
consuming
the
events,
to
start
working
with
the
events
and
to
start
yes
developing
their
own
part.
So
this
was
really
the
the
starting
point
around
the
at
the
origin
of
my
cox.
A
Like
I
was
like
most
of
the
good
ideas,
let's
say,
or
good
product
or
good
tools
like
they,
they
start
by
solving
a
real
problem
right.
Yes,
I
I
always
I
I
always
like
to
tell
this
story
that
when
I
published
not
just
when
I
created,
but
when
I
published
async
api
for
the
first
time,
I
wasn't
imagining
that
it
was
going
to
have
this
kind
of
impact.
This
is
too
much.
A
I
would
have
never
imagined
this.
It
was
just
a
tool
for
me.
I
mean
for
me
for
the
company
right
like
to
document
and
to
generate
code
of
event-driven,
architectures
or
synchronous
apis,
call
it
whatever
you
want
and
and
yeah,
but
it
actually,
after
after
some
time,
working
on
open
source
and
and
working
with
different
tools
and
different
projects,
you
actually
realize
that
the
best
tools
are
always
the
ones
that
are
solving
a
real
problem
and
they
usually
start
small.
So.
B
Yes,
specific
problem,
so
yes,
so
yeah,
and
actually
at
that
time
we
we
just
started
with
with
postman
collection,
trying
to
reuse
postman
collection
where,
let's
say,
requests
but
not
really
requests.
Just
events
were
described
and
reuse.
Those
events
to
yes
to
infinitely
publish
those
events
on
an
existing
broker
so
that
we
can
speed
up
the
the
providing
the
yes
the
way
we
provide
messages.
B
We
provide
events
so
that
developers
can
start
working
on
it
and
then,
just
after
that,
I
discovered
a
sync
api
thanks
to
mark-
and
I
try
to
yes
to
to
change
things
around
my
clothes
so
that
my
trucks
could
be
able
to
to
support
all
the
things.
Yes,
all
the
the
synchronous
stuffs
on
the
request
for
response,
interaction,
style
and
also
all
the
things
related
to
just
publication
of
messages.
A
So
this
this
thing
about
postman
collections,
I'm
sure
it's
gonna
be
interesting
for
some
fall
except
postman
yeah.
I'm
gonna
make
sure
that
I
I
send
them
the
recording
of
this
yeah
yeah.
A
So
I'm
curious,
you
said,
like
you
needed
to
have
like
this
kind
of
mocking
functionality
for
events
like
we,
as
you
can
imagine
we're
we're
already.
Having
we've
been
already
having
this
discussion
at
pozman,
especially
since
we
joined,
how
can
we
enable
even
driven
architecture,
support
or
isn't
kps
support
on
postman
and
what
kind
of
specific
problems
should
we
should
we
be
solving
right
and
for
us
like?
There
are
many.
There
are
many
ways
so
the.
A
A
Mock
that
someone
is
sending
this
message
so
that
I
can
receive
it
and-
and
I
can
start
testing
my
my
service
right
like
so
I
I
subscribe
to
the
topic
in
the
broker
and
I
actually
received
the
event
right,
but
it's
yeah.
It
is
a
little
bit.
We
thought
like.
Maybe
it's
a
little
bit
simplistic,
maybe
not.
We
have
to
research
a
little
bit
more
other
things.
It's
like
this
is
for
receiving
or
subscribing,
but
what
about
the
other
thing
like
publishing?
A
If
I
publish
this
event,
then
I
don't
have
just
one
service.
I
have
two
services
and
I
want
one
to
publish
an
event
and
when
this
is
fabulous,
there
is
a
third
service
that
is
still
not
implemented
right,
and
this
is
the
one
that
we're
gonna
mock
and
when
it
receives
one
message,
it's
gonna
publish
another
one,
so
the
third
one
can
receive
it.
So
there
we're
we're
now
involved
in
some
kind
of
workflows.
A
Have
you
faced
the
same
same
situation
like
you
like?
How
did
you
start
with.
B
We
are
just
in
the
process
of
yes
of
thinking
about
this,
because
for
the
moment
we
we
have
a
strong
focus
on
everything
related
to
to
the
simplistic
use
case
as
well,
for
the
published
semantic.
As
for
the
the
subscribe
semantic
and
as
you
as
you
already
mentioned
it
in
in
some
other
episodes,
there
is
a
lot
of
confusion
today
around
the
subscriber
says,
publish
operation
semantics.
B
I
don't
know
what
I'm
talking
about,
and
we
are
first
to
have
an
idea,
yes
to
to
put
everything
in,
to
be
very,
very
clear
and
very
specific
on
the
different
use
case
we
were
supporting
and
to
who
are
going
to
be
the
the
the
most
interested
parts
for
the
different
use
case,
for
example,
to
be
specific,
if
you,
if
you
want
to
to
mock
a
subscribe
kind
of
operation.
B
In
fact,
this
is
really
interesting
for
the
events,
consumers
of
your
async
api
file
or
sync
api
application.
But
if
you
want
to
publish
to
sorry
to
mock
events
for
the
publish
related
application,
in
fact,
it
will
be
very
interesting
for
the
provider
side
of
the
application.
So
for
the
owner
of
the
apis-
and
we
we
in
fact
here
we-
it
takes
a
lot
of
time.
It
takes
a
lot
of
time
to
to
digest
everything
and
to
be
able
to
have
really
clear
ideas
around
that
also
testing
means
different
things.
B
B
So,
yes,
it
takes
a
lot
of
time
to
figure
out
everything
and
to
put
everything
in
place.
On
top
of
that,
we
we
had
also
many
feedbacks
from
the
from
the
fins
around
the
the
ability
to
have
smart
mocs.
B
Let's
say
not
just
a
static
message,
that
is,
that
is
sent
every
three
seconds,
but
some
kind
of
dynamic,
behavior
dynamic
messages.
So
we
we
introduced
lately
some
some
features
around
templating
so
that,
basically
you
can
microx
is
able
now
to
produce
smart
messages,
different
messages
with
unique
identifiers
with
timestamps,
with
random
data,
random
emails,
random
addresses,
for
example,
so
that
you,
you
have
the
the
ability
to
yes
to
not
just
specify
static
marks
back
to
make
them.
B
Let's
say
business
friendly
a
little
bit
so
that
people
can
really
start
doing
things
with
with
those
different
events,
and
now
I
would
say
the
the
first
step
we
were
just
starting
is:
he
has
to
to
try
not
to
say
to
to
implement
workflows
or
state
management,
but
to
try
to
to
link
things
together
by
adding
trigger
mechanisms
in
micros,
for
example.
The
really
the
really
obvious.
The
really
common
use
case.
B
A
So,
as
you
were
mentioning
this,
I
was
thinking
like
if
you
really
go
into
the
complex,
so
my
my
daughter,
I
think
it's
it's
super
well
for
her.
A
So
as
you
were
describing
this
complex
like
not
going
into
the
complex
workflows,
I
was
thinking
like
damn
it.
If
you
actually
produce
this,
like
you
actually
implement.
This
kind
of
features
like
someone
calls
a
rest
api
and
then
this
rest
api,
which
is
a
mock
right
and
it
publishes
an
event
which
is
a
mark
of
an
event
as
well,
based
on
the
on
the
on
the
payload,
for
instance,
on
the
rest,
api
called
payload
and
you
keep
adding
stuff
like
this,
like
workflows
and
so
on.
B
Yes,
yes,
and
in
fact
this
is
a
I've
discovered
that
some
people
in
the
community
are
starting
to
use
my
clocks
this
way
to
just
to
realize
early
prototypes,
let's
say
low
code
prototypes
on
of
their
their
next.
B
For
example,
I
have
discussion
with
people
that
are
using
the
they
are
using
the
the
rest,
the
synchronous
part
of
my
clocks,
and
in
my
cross,
you
have
the
ability
to
to
to
define
what
we
call
custom
dispatchers.
B
So
if
you
do
nothing
and
just
fill
microx
with
your
open
api
specification
or
postman
collection,
it
it
scans
the
document
and
it
creates
a
set
of
of
inferred
dispatching
rules
for
you
so
that,
without
specifying
anything,
you
have
request
response
matching.
You
can
define
different
different
mocks
for
the
same
operation
and
it
has
at
least
enough.
B
Yes,
it
is
enough
smart
to
to
be
able
to
to
do
the
basic
things,
but
you
can
override
this
and
you
can
provide
some
some
simple
scripts
to
check
more
couplings
things,
and
I
had
the
discussion
with
people
with
with
a
guy
who
was
starting
to
yes
to
to
prototype
a
chat
bot
using
this
dispatcher.
These
custom
dispatching
things
in
microsimple
scripts
that
analyzes
the
the
payload
incoming
payload
and
returned
different
cad
responses
depending
on
the
the
payload
content,
and
he
was
abolished
to
to
describe
its
logic
just
right.
A
The
very
moment
you
you
allow
people
to
put
some
code
there.
Even
if
it's
a
simple
yeah,
simple
code,
you
can
probably
already
start
creating
like
fully
featured
systems
on
top
of
this
mocking
platform
right
or
say
it.
Another
way
like
the
mocking
platform
could
be
the
base
for
a
future
low
code
or
no
code
platform.
A
I
mean
you
pack,
it
you,
you
duplicate
what
you
have
and
you
pack
it
with
a
different
name
in
a
different
logo
and
different.
You
know,
marketing
stuff
and
you
say
like
this-
is
for
local
no
code
and
what
what
you
have
behind
the
scenes
is
actually
the
same
thing.
Yes,
exactly.
B
A
Yes
and
it's
amazing
how
much
they
both
can
actually
meet.
You
know
like
a
loconoco
like
like,
like
kindling,
used
to
say,
like
he
calls
these
platforms.
B
In
fact,
yeah
this
is
a.
It
could
be
an
interesting
use
case,
and
definitely
it
would
be
easy
to
do
because
there
is
really
two
parts
in
my
class.
There
is
the
the
ingestion
part
that
allows
you
to
to
to
upload
or
to
connect
to
to
git
repository
to
to
gather
different
kind
of
artifacts
and
then
to
create
the
the
simulations
and
there
there
is
the
different
part
that
is
the
yes,
the
the
mock
engine,
the
dispatching
engine,
and
these
are
totally
separated.
B
So
actually
what
people
are
are
doing
with
microbes
that
they
in
a
certain
organization
they
may
use
different
instances.
So
there
is
a
let's
say,
a
master
instance
when
the
different
marks
for
the
yes,
all
the
apis
of
the
companies
are,
are
living,
and
this
master
instance
is
connected
to
different
git
repositories.
To
yes
to
to
gather
the
updated
api
definitions
and
to
to
change
mock
definitions
in
real
time
and
yes
from
time
to
time,
they
are
doing
export.
B
A
B
If
we
just,
we
paint
the
things
using
the
loconoco
idioms.
Yes,
it
could
be
nice.
A
It's
I
mean
I
was
at
the
very
moment
you
were
telling
this
to
me
like.
I
was
that's
like
that's
just
just
this
one
step
close
to
a
look
another
platform.
Is
there?
That's
that's
really
cool
exactly.
A
I
I
also
I
was
thinking.
I
was
thinking
on
something
as
you
were
talking
and
now
I
I
lost
it.
I
wanted
to
ask
you
a
question
and-
and
I
completely
lost
it-
maybe.
A
It
will
be
back
at
some
point,
yeah,
I'm
sure
so
well.
In
the
meantime,
I
I
also
so
there's
another
one
that
came
to
my
mind
before,
and
I
remember
this
one.
So
that's
why
so
in
terms
of
usage,
so
do
you
have
like
any
idea
of
what's
the
common?
A
What's
the
most
common
use
case
for
microx
on
even
driven
architectures
like
what
are
people
using
it?
For
I
mean
it's
for
it's
for
mocking,
of
course,
but
you
know
which
kind.
B
B
For
the
moment
we
just
talked
about
smoking
and
yes
it
it's
for
it's.
B
Yes,
it
always
starts
with
mocking
with
simulating
the
the
publication
of
events,
because
even
if
we
have
subscribed
and
published
semantics,
I
I
have
to
say
that
90
of
the
time
I
I
can
see
the
usage
of
a
sync
api
for
all
the
things
related
to
subscription
subscribe
operations.
B
That
means
that
to
describe
the
events
that
people
will
be
able
to
consume
on
a
defined
channel
or
topic,
so
it
always
starts
with
simulation,
but
the
yes
microx
is
also
able
to
do
testing,
and
the
nice
thing
is
that
it
reuses
the
do.
I
think
api
artifact
you,
you
may
have
with
the
different
attached
schemas,
maybe
json,
schemas
or
avro
schemas-
to
to
realize
conformant
testing,
so
it
is
used
just
at
the
beginning
of
the
development
cycle
in
order
to
provide
simulation
to
to
the
future
consumers
and
a
few
day
weeks.
B
A
B
Then
it
it
tries
to
to
validate
the
different
messages
it
receives
with
the
schemas,
so
it
allows
you
to
detect
failures,
to
detect
yes
exception,
bugs
in
your
implementation.
B
Yes,
for
sure,
at
least
for
at
the
moment,
it
is
able
to
connect
to
the
broker
it
has
if
it
has
the
the
different
credentials
or
certificates
and
so
on
to
to
connect.
A
You
know
that
two
weeks
ago
I
I
had
the
pleasure
to
have
a
chat
here
and
thinking
out
loud
with
dominique
over
mayer
from
hivemq,
so
they
developed
this
hyphen
q
broke
mqtt
broker
and
we
had
this
discussion
like.
A
Does
it
make
sense
to
have
brokers,
to
support
async,
kpi
natively
and
then
have
this
kind
of
capabilities
that
they
validate
the
messages
for
you
at
the
broker
level
say,
for
instance,
you
try
to
publish
a
message
to
the
broker
and
if
it's
not
valid,
it's
not
published
right
so
or
it's
published,
but
you
trigger
some
kind
of
alarm
or
something
like
that.
Right
alert,
not
alarm,
but
I
mean
you
can
trigger
an
alarm
as
well.
If
you
want,
but
it's
iot
in
the
end,
so
that's
that
would
be
cool.
A
So
so
we
had
this
discussion
and
now
you're
telling
me
that
is
already
possible
with
microx.
You
can
do
testing
you
can
plug
it
in
a
protection
broker.
A
I
will
be
worried,
though,
about
if
I
had
like
a
a
huge
amount
of
of
messages
right
like
imagine
that
we
have
many
like
how's,
it
called
I.
I
lost
the
word
but
yeah
like
we
have
lots
of
traffic
on
our
broker.
A
That
will
be
super
hard
for
the
micro
instance
to
to
handle
right
so
and-
and
you
probably.
A
B
So
actually,
the
the
validation
phase
in
micros.
B
It
is
done
asynchronously
regarding
the
consumption
of
messages,
so
if
it
doesn't
impact
it,
it
will
have
an
impact
on
the
the
microscope
time
itself
and
if
we've
done
things
correctly,
this
is
in
fact
a
very
scalable
runtime,
because
it's
all
based
yes
on
microservices
architecture
and
can
be
deployed
on
kubernetes
with
autoscaling
features.
So
there
is
a
lot
of
different
way
to
have
a
scaling
and
to
avoid
scaling
issues
with
my.
B
But
yes,
this
could
be
a
nice
feature
to
let's,
let's
say
if
the
the
batch
of
of
messages
is
is
more
than
50
60
100
messages,
then
you
just
take
a
sample
and,
let's
say,
validate
one
one
on
five
110.
Yes,
nice
id,
yes,
yeah.
A
So
it's
you
see
that
that's
what.
A
Stuff
so
mark
was
leaving
a
comment.
Well
huge
comment
here.
So
he
said,
could
be
interested
in
the
war,
consumers
plus
implementers
about
security
issues
using
schema
plus
microx
right,
I
guess
schema.
He
means
s
and
kpi
in
this
case,
so,
for
instance,
payload
sizes,
where
character
sets
middle
values,
mutation,
testing,
extreme
or
unusual
values.
A
B
Yeah,
so
a
lot
of
checks
may
be
already
included
in
schema
validation,
because
when
you
are
doing
schema
validation,
you
are
checking
yes,
the
different
character
sets
the
optional
or
medantary
property
of
any
field.
In
your
in
your
payload.
B
We
also
supporting
avro
encoding,
so
you
can
check
a
lot
of
things
with
with
the
overall
serialization
of
this
realization
process.
But
yes,
definitely
some
things
like
payload
size.
B
Security
schemes-
yes-
could
be
a
nice
announcement
on
that.
A
And
something
that
I
was
thinking
might
fit
into
the
extreme
or
unusual
values.
You
know
you
can
have
a
custom
policies
that
tells
you
when
imagine
that
you
feel
this
number
is
an
integer,
for
instance,
and.
A
But
it's
usually
in
between
0
and
20,
say,
for
instance,
yes
and
then
one
day
you
receive
2,
000
right
or
5
000,
so
yeah
like
you,
can
have
some
kind
of
policy
telling
you
like.
If
the
value
here
is
above
whatever
number,
please
trigger
an
alert,
and
this
could
be,
for
instance,
in
the
case
of
mkid,
mqtt
and
iot
use
cases.
This
could
be
temperature,
for
instance,
exactly.
B
B
A
Controls,
yes,
yeah,
because
what
you
have
on
json
schema
is
like,
for
instance,
like
we
were
saying,
say,
for
instance,
temperature
in
in
celsius
celsius
degrees,
depending
on
what
you're
measuring
it's
not
gonna,
it's
not
going
to
be
above
100
right
so,
but
you
you
might
want
to
limit
it,
for
instance,
from
minus
20
to
100.
You
can
put
this
in
just
define
range,
okay,
what
you
can?
What
what
I?
What
I
was
meaning
here
is
like
it
would
be
great
that
you
get
an
alert
when
it
goes
above.
A
B
No,
but
we
yes,
we
we
can
imagine
having
that
not
less,
not
in
the
monitoring
part,
but
in
the
the
testing
part
and
the
contract
testing
part.
B
In
fact,
we
already
have
these
kind
of
things
for
the
the
rest
apis
in
my
course,
because
we
have
different
levels
of
testing.
The
default
level
is
the
the
syntactic
contract
testing
level.
So
everything
you
put
in
your
in
your
json
schema
and
your
open
api
schema
will
be,
will
be
checked
and
enforced,
but
we
know
that
some
business
conference
constraints
are
really
really
hard
to
translate
into
into
schema
constraints.
B
So
if
you
have
described
this
this
business
rule,
let's
say
in
your
postman
collection,
we
are
able
to
reuse
this
one
to
ensure
to
have
an
extra
check
on
the
incoming
result
from
the
implementation.
So,
for
the
moment
we
have
that
on
on
top
of
rest
apis,
so
it
would
not
be
yeah.
It
would
be
different
for,
for
the
sync
api's
point
of
view,
I
would
say
once
we
we
found
a
correct
way
to
specify
additional
constraints.
A
No,
I
don't
think
it
will
be
different
in
this
case.
Yeah
you're
right,
you
probably
don't
have
this
such
contracts
constructs
like
you
want
to
reply
with
something
you
want
to
return.
You
want
to
respond,
so
you
don't
you
don't
respond.
You
just
might
filter
the
message,
but
you
can
probably
not
respond
but
trigger
a
different
message.
Yeah,
which
is
kind
of
responding.
A
Are
respected
and
not
just
impossible?
Sometimes
it's
just!
It
is
difficult
like,
for
instance,
jason
schema.
Has
this
eve
dang
else
stuff,
but
yeah?
I
myself
struggle
sometimes
to
use
it
exactly
or
to
read
it
not
just
to
use
it
but
to
read
it
like,
especially
if
you
have
how
you
call
this
like
like
an
if
inside
another,
if
right
so
in
the
else
you
have
another.
A
If
and
things
like
this,
then
it
becomes
complex
to
read
while,
if
you're
using
a
programming,
language,
let's
say
javascript
or
java
or
any
other
language,
it's
easier.
It's
usually
easier
to
read
sure.
B
Of
the
discussion
you
had
with
with
a
high
mq
people
and
just
one
difference
for.
B
Mike
rocks
versus
implementing
those
control
at
the
the
broker
level
is
that
with
microx
we
we
also-
we
have
this.
This
feature
this
behavior,
whatever
the
the
technical
protocol
behind.
So
basically,
as
of
today,
we
we
support
kafka,
websocket,
mqtt
and
rabbit
mq
protocol,
so
whatever
the
protocol,
whatever
the
the
the
broker
distribution,
you
you
choose
for
kafka
for
mqtt,
whatever
you
will
have
this
feature
in
microx,
so
this
is
also
a
nice
differentiator.
A
And
I
think
that
that
is
important
to
to
highlight,
because
even
if
we
manage
to
convince
every
broker
vendor
out
there,
like
all
of
them,
to
implement
support,
raising
kpi,
say
in
the
next
10
years,
yeah
it's
going
to
be
in
the
next
10
years.
In
the
meantime,
you
you
need
to
be
able
to
do
something
so
or
if
a
new
broker
appears
and-
and
they
don't
implement
this
in
kps
report-
then
yeah
same
thing
or
yeah
or
some
not
a
maintained
broker.
A
Let's
say:
doesn't
implementation
gps
support
because
it's
not
maintained
anymore,
but
a
bank
or
an
insurance
company
which
are
usually
using
all
technology
right.
They
don't
want
to
get
rid
of
this
broker.
Then
yeah.
You
still
need
a
solution,
so
micro,
of
course,
has
its
own
place,
even
if
we
convince
every
broker
vendor
that
they
implementation
kpi,
but
that's
yeah,
okay,
yeah
and.
A
Plan
b
scenario:
actually,
the
plan
a
it's
a
plan
a
for
now.
Eventually,
I
think
I
mean
not
eventually
if
things
will
be
perfect,
which
are
unsure
that
it
will
never
be.
A
If
every
broker
implements
support
phrasing,
kpi,
then,
yes,
then
microx
or
a
solution
like
microx
would
be
like
a
plan
b
right
just
for
those
brokers
that
don't
support
specific
features.
Like
you
know,
I
guess
in
kpi
or
something
like
that
in
this
case.
Yes,
but
like
I
said
that
that
is
a
very
remote
case,
there
is
a
really
low
chance,
or
I
have
really
little
expectations
that
we
managed
to
convince
the
broker
vendors
to
implement
this
in
kpi
support,
because
they
already
have
their
own
set
of
challenges
themselves.
A
Aside
from
all
this
validation
and
policy,
implementations
and
so
on,
then
so
that
we
can,
I
I
think
that
yeah
they.
B
A
Other
priorities,
and
right
now
and
they're
right,
I
mean
they're
solving
other
problems,
and
if
this
problem
can
be
solved
with
microx,
it's
not
a
problem
at
least
for
now.
They
will
do
it
once
they
have
no
bigger
bigger
problems,
which
is
probably
saying
in
10
years.
From
now,
like
I
said,
probably
yeah.
A
Oh,
no
so
yeah
so
actually
microx's
plan
a
is.
This
is
what
we
have.
This
is
what
you
should
be
using.
This
is
the
kind
of
solution
you
should
be
using
and
the
plan
b
is
or
the
plan
a
a
point,
one
which
is
like.
Let's
knock
every
broker
vendor
door
and
say
hey
what
about
this
in
kpi
or
what
about
cloud
events?
Can
you
please
support
it
sure
natively,
because
so
we
don't
have
to
install
two
tools
right
or
two
services
and
maintain
them
and
scale
them
separately.
A
Not
yet,
but
not
yet,
but
I'm
like,
I
said,
like
I'm,
giving
good
arguments,
but
they
have
good
reasons.
Why
not
to
do
it?
At
least
now
it's
like
yeah.
B
You,
if
you
are,
if
you
see
what
is
happening
at
open
api
version,
three,
yes,
it's
it's
specification
that
has
a
yes
six
or
seven
years
or
so,
but
people
are
still
stuck
in
a
in
swagger
version.
Two
most
of
the
time.
A
I
mean
I'm
confident
that
at
some
point
we'll
manage
to
convince
a
broker
vendor
to
implement
this
kind
of
smtpa
support
or
cloud
event,
support.
That
would
be
perfect,
but
and
someone
will
end
up
doing
it,
I'm
sure,
but
yeah
like
we
need
the
majority
of
them
at
least
or
the
major
ones
to
support
it
right,
like
let's
say
kafka
and
by
kafka
I
don't
only
mean
the
conflict
kafka.
You
know
like
kafka,
the
open
source
version,
so
so
kafka
any.
I
don't
know
active
mq.
A
A
Yes,
and
I
think
it's
growing,
because
people
are
tending
to
do
more
reactive,
uis,
real-time
uis,
you
know
so
they
they
in
this
case
you
want
to
use
web
circuits
because
that's
most
probably
the
only
thing
you
can
use
aside
from
http
2
push
and
all
this
stuff
right
and
servers
and
events
and
and
all
that
stuff,
but
yeah,
socket
dial
makes
it
much
easier
to
use
than
sse
right.
So
yeah,
you
don't
have
many
more
options.
A
So
the
question
I
mean
the
com,
my
mark
yeah.
The
question
is
so
you
know
that
we're
working
on
version
three
of
the
spec
and
that
changes
slightly,
let's
say
the
meaning
of
publish
and
subscribe.
A
So
if
everything
continues
as
it
is,
it
will
be,
send
and
receive
exactly
and
and
the
opposite
and
the
meaning
is
the
opposite,
meaning
that
right
now
publish
and
subscribe
means
what
a
client
or
a
potential
client
can
do
with
your
api,
which
is
clear
when
it's
an
api
which,
when
it's
a
rest,
api
or
web,
socket
api
when
it's
client
server
it's
clear,
but
when
it's
a
broker-based
architecture,
it
is
highly
confusing
because
everything
everything
is
a
client
right.
So
I
mean
it
is
confusing
for
me
as
well.
A
I
understand
that
it
might
not
be
confusing
for
you.
It
wasn't
for
me
in
the
beginning
as
well,
but
now
the
more
I
work
with
brokers.
It
confuses
me
even
more
so.
Okay
and
I
and-
and
I
get
people
also
like
complaining
that
it's
highly
confusing,
so
I
guess
it
is
confusing
so
so
yeah
now.
My
question
is
like
what
does
it
mean
for
microx
that
we
change
this
meaning?
Is
it
going
to
be
problematic
in
some
way,
because.
B
I
don't
think
so
from
from
my
perspective
and
from
my
understanding
of
the
the
yes,
the
work
in
progress
on
the
three
to
zero
to
it
would
not
be
a
big
deal
because
we
we
will
be
in,
we
will
be
able
to
handle
the
parsing
of
the
the
new
version
separately.
We
will
be
able
to
yes
to
introduce
those
new
semantics,
because,
even
if
the
the
name
are
more
accurate,
send
and
receive,
I
think
it's
better
that
publishers
subscribe,
because
there
was
also
a
lot
of
misunderstanding
around
the
cue
versus
topic.
B
Any
cast
versus
multicast
stuff,
so
for
me,
send
and
receive,
is
much
clearer
than
publish
because
publish
to
a
queue.
Some
people
are
have
difficulties
with
this
these
concepts,
so
it
will
not
be
a
big
deal
for
for
the
ma
for
micros.
Basically,
we
will
support.
We
will
continue
supporting
the
the
dot
2x
stream
and
we'll
be
able
to
implement
the
3.0.
B
On
top
of
that,
my
my
main
concern
about
the
the
3.0
and
you
know
because
we
already
talked
about
it-
is
yes,
the
the
the
actual
position
of
the
spec
regarding
its
scope,
because,
as
I
said
before-
and
we
have
discussion
of
this-
I
used
to
think
of
a
sync
api
of
a
way
of
describing
interface
and
thus
to
do
to
describe
interaction.
B
And
I
know
that
in
the
community
there
there
are
different
use
cases
and
different
interpretations
of
that
people
that
are
using
a
think
api
to
just
let's
say,
describe
a
catalog
of
topics,
a
catalog
of
data
sources.
B
So
just
to
say,
hey
these
data
sources
are
available.
They
are
there
in
different
channels,
so
you
can
do
anything
with
that
and
I
don't
care-
and
there
is
also
a
lot
of
people
who
yes,
who
are
using,
who
are
just
telling
about
a
sync
api
for
describing
application
and
not
interface,
not
interaction.
B
So
to
me
it
is
my.
It
is
my
main
concern
around
the
yes,
the
clarification
of
what
the
spec
is
for.
I
know
that
there
is
also
a
lot
of
need
around
the
description
of
application,
because
it's
a
very,
very
common
case
or
people.
B
So,
yes,
I
think
there
is
a
lot
of
yes
needs.
Different
needs,
different
perspectives,
and
yes,
we
we
absolutely
have
to
to
clarify
all
of
this
and
to
define
a
clear
scope
for
for
a
sync
api
or
for
some
other
complementary
specifications
that
may
that
may
arise
alongside
with
the
sync
api.
So.
A
Yeah
and
and
now
that
you
mentioned
that
we
actually
were
considering
other
than
so
in
version
three
so
far
you
can
define
like,
like
you,
said,
a
set
of
channels,
a
set
of
topics
where,
where
you
have
like
data
sources,
and
then
it's
like
you
said
like
I
don't
care
what
you
do
with
data
sources,
then
we
will
continue
as
as
we
are
right
now,
defining
the
application.
So
you
can
define
what
the
application
is.
A
A
What
we're
doing
right
now
is
you
can
define
what
to
do
with
this
application
that
you're
defining
and
that's
the
current
meaning
of
this
and
kpi
document
and
we're
going
to
change
slightly.
That,
which
is
this
document
now
defines
what
the
application
does,
which
is.
Okay,
like
you,
like
you
say
like
this,
is
this
is
not
interface.
This
is
behavior,
so
this
is
defining
behavior.
A
But
the
thing
is
that
that's:
if,
if
you,
if
you
define
the
send
and
receive
operations,
even
even
if
it's
saying
that
you're
sending
and
receiving
something
that
doesn't
mean
that
you,
you
will
have
to
do
it,
that
you
will
have
to
send
or
that
you
will
have
to
receive
like
that
says
like
in
case
you
send
something
it
needs
to
map
to
this
interface
and
in
case
you
receive
something
into
maps.
It
needs
to
map
to
this
interface.
A
So
somehow
it's
still
interfaced
right.
You
still
define
an
interface.
A
A
A
B
We
have
to
be
very
clear
because
it
was
really
yes
yeah,
her
hard
topic
to
explain
people,
the
differences
between
publish
and
subscribers.
Yes,
yes,
we,
I
think,
just
if
I
I
may
just
give
you
advice
just
be
really.
We
have
to
be
really
clear
on
the
the
point
of
view
to
to
to
adopt
when
we
want
to
use
a
sync
api.
A
Yes,
that
is
actually
what
would
we
like
right
now
like
we
made
it
clear,
we
were
actually
considering
also
adding
the
support
for
multiple
applications
in
a
single
document
defining
multiple
in
a
single
document,
but
that
was
left
out
of
scope,
at
least
so
far.
We
have
no
context.
What
will
people
want
to
do
with
this,
at
least
so
far?
It
is
left
out
of
scope
and
and
what
we
thought
while
we
were
discussing
on
the
spec
3-0
meeting,
which
is
happening
in
one
hour
by
the
way
yeah.
A
What
we
were
discussing
and
the
conclusion
we
we
we
arrived
to-
was
that
maybe
this
has
to
be
a
complementary
spec,
a
complementary
spec
that
allows
you
to
embed
multi-place
and
debate
documents
inside
that
could
be
an
option,
and
so
you
don't
pollute
async
api
itself
right.
So
if
you
say
you
can
say
we
call
it
api,
async,
spec,.
A
So
you
can
say
I
support
this
in
kpi,
but
I
don't
support
api
ac
right
so,
but
that
is
like
I
don't
support.
Multiple
applications
in
a
single
file
is
yeah.
It
might
not
make
sense
for
everyone
to
do
it
right.
So
now,
that's
it
with
in
regard
to
send
and
receive
so
in
regards
to
send
off
receive.
This
is
mainly,
and
that's
something
that
I
was
thinking
and
I
may
still
propose
it
before
3.0
is
send-
is
going
to
be
for
like
sending
to
a
to
a
broker.
A
Something
like
that
right,
you
send,
you
send
something
and
receive
is
receiving
from
a
broker
or
receiving
from
a
specific
channel
an
endpoint
right
now.
If
we
want
to
go
beyond
that
like
we
want
to
do,
we
want
to
also
define
rest
apis
in
the
future.
Also
leveraging
open
api
behind
the
scenes
inside
this
industry
document.
A
B
B
B
A
Right
and
there's
another
verb
like
what
I'm
talking
here
is
about
introducing
a
third
verb,
which
is
for
this
case
is
where
you
have
request
and
response
makes
sense.
Yes
and
then
inside
the
request,
birth
or
the
request
operation,
you
might
want
to
also
specify
what
is
the
potential
reply
or
response
right
leave
it
there
like
this
is
it's
still
not
proposed,
because
I
think
we
don't
need
to
do
it
in
the
3.0
version,
but
my
line
in
3.1
or
3.2.
A
So
if
we
propose
it,
of
course,
so
so
yeah
and
also
we
will
have
to
consider
request
reply,
request
reply
with
brokers,
you
know
with
brokers
in
the
middle,
like
I
want
to.
I
send
the
message
to
I
put
a
message
in
a
queue
and
and
the
consumer.
A
Will
the
message
has
a
header
saying
reply
on
this
other
topic
or
in
this
other
queue
right?
So
there
are.
There
are
different
reply:
request
reply
patterns
over
brokers,
so
so
yeah.
I
wonder
if
we
can
unify
both,
but
if
not,
we
will
have
to
find
a
fourth
verb.
B
A
That's,
let's
see,
that's
that's
that
okay,
I
mean
that
that's
an
option
like
like
well
or
oh
yeah,
no
you're
right
actually
like
sand,
could
also
potentially
have
like
a
reply
section
inside
like
in
this
cases
and
then
send
is
only
for
brokers
and
not
for
client
server,
architectures.
A
B
Yes,
I
will
have
to
to
update
my
my
reading
of
the
github
issues.
A
Yeah,
it's
it's
growing
too
much.
It's
not
too
much.
I
mean
it's
too
fast,
so
yeah
it
is
impossible
to
keep
up
to
date
with
everything
that's
happening
even
for
me
that
I'm
working
full-time
on
this,
so
so
yeah
lauren
so
we're
over
time.
But
I
want
to
ask
you
a
last
question
in
case
you
don't
mind,
yeah,
no
problem.
B
They
found
it
very,
very
handy
to
have
a
microx
in
their
company
and
they
were
asking
a
lot
about
how
to
reuse
easily
mocks
for
different
standards
between
a
different
or
to
share
marks
of
different
open
standards
between
different
companies
different
between
different
teams.
So
we
we
are
working
on
that
topic
around.
Let's
say:
yeah
a
marketplace
or
something
so,
and
it
has
evolved
a
lot
this
last
this
last
month
or
it
could
be
the
next
step
in
the
coming
weeks.
B
A
Nice,
this
is
really
cool
man,
so
yeah
just
that's
from
my
side.
That's
it
unless
you
want
to
bring
something
else,.
B
A
B
Just
tell
people
that
we
are
very
community
driven,
very
open
to
new
contributions,
so
do
not
hesitate
joining
us.
So
there's
the
the
microsdotia
website
we're
on
twitter
microsio
handle,
and
there
is
also
a
yes
a
zulip
chat.
We
don't
use
slack.
We
are
using
zulip.
B
That
is
an
open
source
alternatives
to
to
slack
so
do
not
hesitate
reaching
out
and
having
a
discussion
of
what
your
use
case
is
and
what
we'd
like
to
to
see
in
microsoft
in
the
future,
we're
really
eager
to
to
have
feedback
from
the
community.
B
B
Share
the
same,
open-minded,
yes
and
open
way
of
discussing
with
with
community
yeah.
A
I
agree,
I
agree
totally
agree
cool
folks,
so
yeah,
so
those
who
are
watching
thanks
thanks
a
lot
for
joining
us
today.
It
was
a
pleasure
thanks
mark
by
the
way
again
make
sure
you
send
me
your
address
privately,
so
I
can
send
you
a
t-shirt
and
and
and
thanks
a
lot
lauren
for
for
joining
me
today,
and
I
hope
you
enjoyed
the
format,
this
cash
chat,
format
and
and
yeah
hope
to
see
you.