►
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
A
To
be
honest,
let's
suppose
that
I'm
here
with
you
know
with
this
thin
with
the
balls
and
I
catch
ball
and
say
5
what
you're
actually
doing
if
you
play
in
bingo,
you're,
gonna,
look
and
you're
gonna
try
to
find
5
and
mark
it.
Ok
and
eventually,
what's
gonna
happen
is
that
some
of
you
is
gonna,
say
line
or
bingo
right.
So
nobody,
nobody
seems
to
to
to
to
feel
like
this
communication
is
awkward
or
anything
right.
It's
natural
right!
It's
it
feels
like
natural.
A
Why
it
isn't
in
technology,
then
I'm
gonna
explain
a
little
bit
better,
we're
very
used
to
request
response
patterns
in
technology
with
API,
especially
that's
why
we
are
here
today
for
api's.
So
when
you
make
a
request,
you
actually
get
to
wait
until
you
get
the
response,
and
then
you
proceed
to
the
next
thing,
but
that
that's
not
what
what's
happening
with
the
being
example
right.
So
you
don't
I,
don't
actually,
if
I
tell
you
the
number
I
don't
get
to
wait
for
you
to
tell
me
anything
to
tell
me
a
response.
A
I
just
continue
right
until
when,
until
I
receive
a
message
from
you
and
that's
what
I'm
going
to
talk
about
today
about
messaging
API
is
there's
another
part
in
part
I'm
in
in
api's,
which
is
not
request
response,
it's
even
driven
or
message
driven
call
it
whatever
you
want.
It's
not
the
same,
but
mostly
saying
so.
I
think
API
is
actually
how
many
of
you
heard
about
swagger
or
open
API
before
Wow
nice.
A
A
A
I'm
sure
that
all
of
you
who
are
using
Kafka
WebSockets
and
all
these
messaging
technologies
have
experienced
the
mass
that
it
is
the
the
explosion
of
topics
for
those
who
don't
know
what
the
topic
is.
The
topic
is
a
channel
where
the
message
flow.
Okay,
you
can
have
many
topics,
many
channels
and
you
can
send
messages,
exchanged
messages
between
systems
through
the
these
channels,
so
in
big
companies
like
I,
was
working
in
erotic
recently.
The
explosion
of
topics
like
in
Kafka
topics,
for
instance
it's
amazing
and
and
and
a
new
relic.
A
It's
not
one
of
the
biggest
companies
and
it's
not
even
near,
and
that
the
number
of
topics
was
certainly
huge
and
the
worst
thing
is.
It
was
unknown
and
that's
what's
that's
well.
That
is
what
was
worrying
me
like
only
the
Kefka
that
the
team
in
charge
of
the
Kafka
cluster
knew
about
how
many
topics
they
have,
but
they
don't
know
anything
about
it.
They
just
know
the
name
of
the
topic
and
their
message
is
flowing
there.
I
don't
know
yeah.
A
There
are
some
activity
here,
but
nobody
in
the
company
was
actually
aware
of
what
was
being
pushed
in
this
in
this
topics.
This
information,
this
this
is
the
same
example
as
we
have
like
lots
of
api's
and
nobody
know
the
number
of
ApS
we
have
so
it
led
to
an
explosion
of
topics,
because
people
were
built
things
repeatedly.
A
I'm
gonna
before
this
is
like
I
want
you
to
understand
what
the
problematic
is
in
in
this
area
of
api's
and
I'm,
calling
it
API
some
purpose,
because,
even
if
it's
Kafka,
if
it's
rabbit
in
queue,
if
it's
queues
and
messages,
this
is
an
API,
we
are
sending
messages
that
are
going
to
produce
a
change
in
another
system.
This
is
what
you
do
with
without
request
right,
you
call
it
you
send
a
message
via
HTTP
and
it
produces
a
change
in
the
in
the
other
system.
The
only
difference
that
you
don't
get
a
response
right.
B
A
This
is
pretty
much
like
an
open,
API
document
right.
This
is
you
have
the
on
the
first
line.
You
have
a
sink
API,
you
have
info.
So
it's
information
about
your
API.
You
have
servers,
so
servers
are
where
you
actually
get
to
reach
the
API
and
there's
something
different
from
open,
API
here
already,
which
is
the
scheme
here.
A
For
those
of
you
who
don't
know
what
mqtt
is,
this
is
a
very
lightweight
protocol
and
it's
very
using
Internet
of
Things,
which
is
all
about
messages
because,
as
you
can
imagine,
you
have
devices
like
sensors
or
all
kind
of
devices
connected,
and
they
are
not.
They
are
not
pulling
your
server
all
the
time.
You
know
to
get
information
because
otherwise
it
will
drain
the
battery
and
it
will
that
and
the
cost
of
the
connection
will
increase
as
well.
A
A
This
example
of
an
API
is
what
I
call
the
strict
lights
API,
so
I'm,
gonna,
I'm
gonna,
explain
briefly
what
it
is.
Imagine
that
we
have
a
streetlight
that
smart
city
company,
if
you
want
and
we've
been
given
the
task
to
install
street
lights
all
around
the
city,
and
we
want
to
measure
the
light
that
this
district
lights
have
around
and
we
want
to
be
able
to,
at
some
point
dim
the
lights
of
some
of
some
of
the
the
street
lights
right.
A
So,
if
you
notice
already
what
I'm
saying
here
is
we
want
to
receive
data
from
the
street
lights,
but
we
also
want
to
send
data
to
the
street
lights.
We
want
to
tell
them
hey
do
something,
but
we
also
want
to
receive
events
like
hey
the
Lightning
conditions.
The
lighting
conditions
have
changed.
So
this
is
the
new
value.
Okay,
so
I
implemented
a
very
simple
and
purpose.
A
Async
API
document
here
and
the
topics
as
I
was
saying,
is
the
channels
you
can
call
it
channels
if
you
want-
and
we
have
something
here
like
streetlights,
ideal
lighting,
measured,
okay,
this
is
pretty
match
if
you're
familiar
with
open
API
like
the
path.
Okay.
This
is
like
the
path
where
you
send
a
request
and
we're
saying
here
that
as
a
client
as
a
consumer
of
this
API,
we
can
publish
we
compile
this
information,
and
this
information
is
gonna
be
about.
Light
has
been
measured.
A
We
will
talk
about
more
about
this,
this
this
message
and
then
you
have
another
channel
which
is
about
an
order.
I
want
to
make
it
clear.
This
API
is
like
the
one
installed
inside
this
inside
the
strip
like
strict,
like
device,
okay,
so
the
strict
like
and
subscribe
to
receive
the
order,
the
command
or
can
send
information.
That's
why
the
other
one
was
published.
Okay
and
this,
this
information
is
going
to
be.
This
command
is
going
to
be
deemed
dim
delight
to
ascertain
percentage
or
whatever.
So
like
measured.
That
I
was
explaining
before
it's
defined.
A
Here
we
have
light
message
in
the
light
measured
in
the
messages.
This
is
also
different
from
open
API,
and
this
message
has
a
payload
which
is
an
object,
and
it
has
a
key
called
lumens
for
those
who
don't
know
what
lumen
is.
This
is
like
how
the
light
gets.
Measured
is
like
meters
in
for
distance
right,
and
then
you
have
type,
which
is
an
integer
minimum.
A
Zero
zero
will
be
like
totally
dark
right
and
format
is
going
to
be
in
an
integer
and
description,
and
we
also
have
a
feel
here,
which
is
a
timestamp,
because
every
time
we
receive
a
message
from
the
from
the
street
light
telling
us
that
the
lighting
condition
has
changed.
We
want
to
understand
when
these
measure
has
been
has
been
taken.
A
Remember
that
the
the
street
light
maybe
is
saving
some
of
this
information
and
sending
this
information
every
minute,
so
we
might
receive
in
a
single
message
a
bunch
of
of
these
changes
right
and
we
have
a
command
which
is
deem
and
the
summary,
as
a
summer
explained,
changes
the
light
intensity
in
the
inner
street
light.
It
has
a
percentage
field
and
it
has
a
number
like
the
maximum
is
gonna
be
100%,
because
it's
a
percentage
and
it
will
just
change
that
it
was
deemed
the
lights
in
the
in
the
in
the
in
the
street
light.
A
So
this
is
this
is
an
example
of
how
you
can
write
a
simple
document.
Async
API
document
on
the
left
side
and
on
the
right
side
you
get
to
generate
documentation
like
pretty
much
like
open
API
does,
with
some
tooling
for
open
ap,
that
open
API
do
for
documentation
and
for
human
readable
purposes
right.
But
this
is
not
for
generating
documentation.
Only
from
from
there
you
can
generate
code.
You
can
just
build
marks
to
test
your
API.
You
can
pretty
much
do
whatever
you
want.
A
This
is
a
specification.
This
is
not
a
tool,
this
is
not
a
service
or
something
that
you
can
use.
This
is
a
like
an
RFC,
it's
a
specification.
The
idea
for
this
specification
is
to
describe
even
driven
microservices
high
atapi
streaming
API
eyes
and
pretty
much
anything
that
it's
message
base
right.
A
We
care
we
care
about
the
protocol
because
we
don't
want.
We
don't
want
to
put
pressure
on
the
vendor
side
and
we
restricted
the
list
of
protocols
that
it
supports
to
a
bigger
list
of
protocols
that
appear
here,
but
mainly
that
the
most
uses
are
AMQP
MQTT
web
sockets
in
Kafka
and
and
we're
exploring
more
so
we
so
far
we
provide
some
documentation,
generators
and
code
generators
and
some
people
are
working
on
tests.
A
This
is
not,
as
I
said
this.
The
the
async
API
is
a
specification,
but
a
specification
is
useless
without
tooling
right.
So
we're
also
trying
to
provide
some
tooling
around
it,
and
some
people
are
helping.
I
got
I,
get
that
recently,
some
news
from
some
big
companies
and
I'm
not
sure
if
I
could
mention,
but
let's
just
stick
with
a
bank.
It's
a
big
bank.
A
A
A
A
So
far
as
I
mentioned
before
it
can
help
you,
with
the
API
lifecycle
again
reinforcing
the
point
that
API
is
not
just
HTTP.
Api
is
with
the
design.
You
can
actually
do
design.
First,
if
you
want
documentation
code
generation
now
people
are
doing
testing
and
soon
people
will
start
doing
API
management.
So
you
can,
for
instance,
write
limit
how
the
consumers
at
what
speed
consumers
consume
your
API
or
you
can
monetize
it.
If
you
want
many
things
and
monitoring.
A
It's
community
driven,
it's
open
source
I
actually
would
like
to
see
more
people
involve,
but
so
far
it's
been
good.
We
are
already
a
team
or
around
20
person,
more
or
less,
with
a
with
the
help
of
some
companies
there,
and
but
it's
it's
open
source.
It's
gonna
be
open
source
forever
and
actually
soon
it's
gonna
be
more
than
just
open
source
so
how
to
get
started.
A
A
More
info
can
be
read,
I've,
seen
and
in
the
web
site,
and
also
you
have
a
slack
out
invite
there
in
case
you
want
to
you,
want
to
join
the
the
slack
channel.
I
will
share
the
slides
afterwards
and
and
yeah,
so
what
I
was
saying
is
so
recently
until
recently,
it's
been
a
side
project
of
mine
and
I
would
like
to
to
announce
that
this
is
not
a
side
project
of
mine,
anymore
and
I'm.
A
Gonna
be
starting
the
effort
with
some
of
the
companies,
some
companies
and-
and
some
of
them
are
listen
Lisa
here
so
so
far,
I
get
the
support
from
Salesforce
mules
of
the
ACPs
Lac
Keene
Lane,
the
API,
evangelist
and
and
TIBCO,
and
some
other
people
who
want
to
join
as
well
and
and
and
and
yeah.
So
so
far.
At
least
two
of
these
companies
have
put
already
an
effort
in
improving
the
async
API
specification
further,
with
the
help
of
some
engineers.
A
Again,
this
is
open
source.
The
idea
behind
it
is
that
we're
gonna
be
creating
the
async
API
foundation.
So
we
all
keep
this
project
neutral,
vendor
neutral,
so
I
don't
get
to.
As
you
can
imagine,
so,
I
don't
get
I,
don't
get
to
favor
any
any
vendor
and,
as
you
can
see
there,
there
are
some
competitors
there
in
this
list
already
and
I
did
it
on
purpose
like
if
I
want
to
create
a
foundation
and
get
support
from
from
companies.