►
From YouTube: AsyncAPI SIG meeting 48 (May 11, 2021)
Description
This is the recording for the AsyncAPI Special Interest Group (SIG) meeting #48.
https://github.com/asyncapi/community/issues/25
Chat:
00:32:44 Fran Méndez: Folks, I have to leave now. I’ll watch the recording later. Thanks a lot for bringing up this discussion! Cheers!
00:33:59 Lukasz Gornicki: https://github.com/asyncapi/training
00:41:27 Jonas Lagoni: https://github.com/asyncapi/spec/blob/master/CONTRIBUTING.md
00:44:54 Mike Ralphson: Happy to help review release notes etc
00:45:35 Aayush Sahu: I can also help with github actions.
A
Okay,
recording
has
started
so
hi
folks,
I'm
a
mukesh
as
in
api.
Here
we
started
another
public
meeting
of
async
api.
This
meeting
is
being
recorded
and
will
be
later
on
uploaded
to
youtube
so
yeah.
It's
just
for
your
information
that
your
faces
and
names
will
be
visible
publicly.
Sorry
for
that,
but
it's
due
to
transparency
reasons.
A
The
the
meeting
as
usual
is
every
two
weeks
in
different
time
zones
and
again
like
more
more
and
more
people
join.
I
just
click.
Add
me
that
meat
we
have
a
few
new
faces
on
the
meeting,
and
so
the
the
beginning
of
the
meeting
is
always
a
like.
We
have
a
france
cut,
for
example,
so
the
the
beginning
of
the
meeting
is
always
a
good
a
moment
for
people
that
joined
for
the
first
time.
A
B
A
Okay,
so
we
have
two
items
to
fix
items:
let's
say
on
the
agenda
and
the
first
one
is
gonna
be
presented
by
by
jim.
It's
a
it's
about
the
idea
that
palbano
pointed
out
on
our
asking
api
slack
that
we
might
do
a
a
asking
api
workshop
for
for
the
community,
and
it
was
a
perfect
moment
because
I
think
barbarano
pointed
it
out
a
day
after
jim
joined,
our
slack
and
yeah
jim
immediately
jumped
in
and
wants
to
help
so
yeah
gym
stage
is
yours,
oh
yeah.
Of
course
I
did.
B
C
A
C
C
I
was
going
to
give
a
introduction
to
myself,
but
it
probably
makes
more
sense
in
the
context
of
this
presentation,
so
my
name
is
james,
odd,
jim
I'm
a
java
champion
and
an
author.
So
I've
been
working
on
a
book
recently
with
matthew,
actually
called
mastering
api
architecture
and
as
part
of
that,
we're
writing
a
chapter
on
streaming
and
asynchronous.
Apis
has
kind
of
been
the
the
building
blocks
on
top
of
open
api
and
where
things
are
going
or
this,
where
I
feel
things
are
going
in
the
future.
C
As
part
of
that
I
kind
of
dropped
into
the
community
and
saw
that
you
were,
you
know,
looking
to
create
a
workshop,
and
you
know
one
of
the
things
we've
done
in
the
past
with
open
api
and
done
this
o'reilly
conferences
and
sort
of
internally,
where
I
work,
and
also
for
the
community
as
well.
We've
presented
a
similar
workshop
on
open
api
specifications
and
designing
apis.
C
So
this
felt
like
a
good
opportunity
to
combine
what
I'm
doing
with
the
book
in
terms
of
writing
and
helping
to
create
this
workshop
for
the
community
in
my
day,
job.
I'm
a
distinguished
engineer,
working
on
api
platforms,
primarily
focused
on
open
api
and
rest
apis,
I'm
in
a
in
a
past
life
I
was
a
technical
trainer,
so
I
spent
around
four
years
teaching
in
in
different
companies,
workshops
and
training
courses.
So
it's
something!
C
Hands-On
helps
to
keep
people
engaged
and
sort
of
interested
in
the
topic
and
and
to
that
to
that
fact,
so
we
try
and
keep
all
of
the
introductions
less
than
15
minutes.
So
we
want
to
give
enough
content
and
enough
pointers,
but
the
majority
of
the
learning
is
done
by
coding
and
exploring
async
api
and
the
associated
technologies.
C
So
to
that
effect
you
want
to
make
labs
that
are
intuitive
to
follow.
So
you
know
you
can
potentially
choose
whatever
language
that
you
want
to
want
to
use
they're
about
40
to
50
minutes
in
time.
Because,
again,
you
know
if
you're
trying
to
explore
stuff
from
longer
50
minutes,
you
might
get
a
little
bit
bored
and
then
the
other
idea
with
this
is
to
make
sure
that
the
labs
are
kind
of
clear
in
effect,
so
that
you
can
take
these
offline.
C
If
english
isn't
your
first
language
and
just
explore
them
in
a
bit
more
detail,
you
don't
have
to
take
50
minutes
and
that's
going
to
be
a
theme
that
we
run
through
with
this,
I
think,
is
that
it's
either
led
by
an
instructor
or
it's
led
by
you
know
somebody
else
in
a
classroom
and
to
that
we'll
talk
about
that
as
well.
We
want
to
create
a
lot
of
links
and
examples
and
resources
for
a
variety
of
different
programming
languages.
C
So
this
is
one
of
the
places
where
I
really
feel
that
once
we
get
the
lab
together
and
the
workshop
together
and
we
kind
of
have
agreement
on
the
content
asking
people
to
participate,
helping
to
create
those
sample
solutions
is,
is
going
to
be
a
really
important
aspect
to
what
we
do
here
and
it's.
I
always
like
to
say
this
instructor
idea
or
idea
of
an
instructor
they're
much
more
facilitating,
so
it's
much
more
about
a
conversation
trying
to
get
people
working
together
in
pairs
on
the
labs
and
then
exploring
some
of
the
content
together.
C
So
the
overall
narrative
that
I
was
looking
to
to
potentially
get
to
was
was
something
that
looks
a
little
bit
like
this
and
we're
trying
to.
I
guess,
build
up
basic
knowledge
about
async
api
and
give
people
enough
to
be
able
to.
I
reckon
just
go
back
to
their
group
or
go
back
to
where
they
work
on
on
a
sort
of
for
their
day.
Job
and
talk
about.
C
You
know
sync
apis
with
a
bit
of
confidence,
so
I
think
that
level
set
comes
first,
so
we
we
sort
of
talk
about
what
event
driven
architecture
is
get
some
terminology
clear.
Compare
it
to
rest,
because
I
think
that's
an
important
starting
point
that
you
know
most
people
that
come
along
to
this.
This
workshop
already
have
so
it's
good
to
kind
of
find
a
common
starting
point,
and
maybe
just
a
very
brief
overview
of
websockets.
That's
probably
going
to
be
one
of
the
most
accessible
ways
to
get
started.
C
Initially,
we
then
kind
of
go
into
async
api,
so
actually
more
into
the
specification
talk
about
some
of
the
key
features
that
are
in
the
specification
just
kind
of
overview
to
the
community,
how
it
may
be
different
that
differs
from
open
api
specifications
really
like
the
diagram.
That's
on
on
the
page,
which
is
this
is
open
api.
C
C
The
idea
is
using
the
code
generation
tools
and
the
vs
code
plug-in
to
kind
of
like
design
the
spec
and
then
using
the
generator
to
actually
build
a
build,
a
sample
or
a
prototype
application,
and
that
will
be
kind
of
session
one
and
the
introduction.
We
then
go
into
a
specification,
deep
dive
so
trying
to
get
into
more
detail
around.
C
What's
in
the
spec,
giving
people
essentially
enough
extra
knowledge
that
they're
going
to
need
to
be
able
to
build
out
what
is
essentially
like
the
main
application
that
we'd
be
building
in
the
lab,
which
is
a
group
task
list?
So
if
you
think
about
github
issues,
this
is
kind
of
like
where
I
got
the
idea
from,
as,
as
we
were
actually
chatting
about
the
workshop,
so
different
people
can
add
in
posts.
C
Essentially
other
people
can
react
to
those
posts
and
you
can
create
new
issues
and
those
should
be
published
and
kind
of
like
getting
the
idea
of
like
a
collaboration
or
group
task
list.
As
being
you
know,
the
approach
that
we
take
towards
that
second
second
workshop
or
second
lab
and
then
the
final
thing
would
be
to
actually
then
go
into
some
more
practical
considerations.
So
what
what
are
the
toolings
available?
What
other
protocols
are
supported
like?
How
do
you
consider
state
management
and
beings?
That
being
an
important
part
that
we're
saying
is
different
from
rest?
C
We
need
to
talk
about
state,
that's
essentially
going
to
be
across
all
the
services,
and
then
how
do
you
participate
in
the
community?
So
really
a
plug
for
bringing
more
people
into
the
community
and
contributing
where
they,
where
they
see
gaps
and
certainly
like
the
narrative
that
well
I've
been
talking
about
async
api
in
my
communities
has
been
around
think
of
it
about
open
api
spec,
maybe
six
or
seven
years
ago,
where
we
need
support.
We
need
help
on
the
tooling
to
really
kind
of
give
it
that
richness
that
we've
got
in.
C
In
the
same
way,
we
would
have
open
apis
as
an
example
and
then
finally,
like
I
thought
this
was
kind
of
a
nice
part
to
the
workshop,
where
you
try
and
consume
somebody
else's
api.
So
you
build
a
client,
but
you
use
someone
else's
open,
sorry,
async,
api
spec
to
pull
in
that
information,
and
then
you
can
kind
of
like
say:
oh
well,
how?
C
So
that's
kind
of
the
narrative
and
to
go
into
a
bit
more
detail.
I
think
the
event
driven
architecture
section
is
all
about
terminology.
A
real
world
example
usage
looking
at
the
difference
of
rest
and
then
that
high
level
websocket
overview.
So
I
kind
of
went
into
a
bit
of
detail
around
that
back
before
the
hello.
Async
is
much
about
meet
the
specification.
C
Talking
about
design
considerations,
trying
to
pick
out
elements
that
you
know,
people
will
have
to
think
about,
or
developers
will
have
to
think
about
in
in
the
lab
itself,
and
that's
where
we
then
start
to
update
our
previously
working
example
that
had
hello
world
in
it
to
regenerate
the
the
to-do
list,
file,
application,
the
github
issue,
style
application
and
start
to
experiment.
With
with
how
that
would
work.
C
So
then
practical
considerations
we
talk
about
tooling.
I
think
security
is
an
important
point
to
mention
so
bringing
in
the
idea
of
security
whereabouts.
That's
modeled
in
the
specification
how
that's
kind
of
linked
into
the
transport
like
these
are
the
kind
of
practical
considerations
that
I
think
are
important,
as
almost
like.
C
Okay-
and
then
this
final
one,
which
is
which
is
not
titled
so
well,
is
the
idea
of
like
the
onward
project
resources
and
then
the
road
map.
So
I
think
the
the
nice
thing
about
the
async
api
community
is
we
we
have
a
road
map,
that's
set
out,
there's
stuff,
that's
in
the
future
that
people
might
look
at
and
go
actually.
Can
we
get
that
sooner?
C
It's
like
well,
you
can
but
kind
of
gonna
have
to
help
if
you,
if
you
want
to
get
that,
so
it's
really
kind
of
like
giving
people
those
onwards
like
how
do
I
get
involved?
How
do
I
participate
and-
and
where
do
we
go
from
here,
so
I
think
in
terms
of
the
workshop-
and
you
know
I
have
the
cycles
to
contribute
to
this-
it
kind
of
fits
directly
into
the
work
that
I'm
doing
at
o'reilly
to
to
write
this
chapter
within
the
book.
C
Is
I'd
like
to
start
to
get
to
creating
the
content
in
the
open
so
essentially
creating
some
of
the
some
of
the
presentations
that
would
go
with
the
these
sections
to
try
and
hopefully
kind
of
get
feedback.
So,
if
there's
a
bit
missing,
if
you
think
geo
watching
the
best
thing,
I
learned
about
async
api,
you
need
to
put
it
in
this
first
bit,
because
otherwise
people
won't
understand
why
it's
important
to
us.
C
I'd
I'd,
be
happy
to
try
and
like
put
that
in
and
try
and
get
to
the
point
where
we've
got
a
session.
That
makes
sense
to
to
as
many
participants
or
as
many
people
on
this
call
as
possible.
I
think
we'll
look
to
use
github
issues
to
at
least
probably
put
a
proposal
for
each
session
in
place
and
that
will
allow
people
to
provide
ideas
and
suggestions
to
things.
C
They
would
add
to
the
session
things
they
would
move
to
different
sessions
and
that
kind
of
thing,
and
then
there
are
two
points
where
I
think
you
know
we
kind
of
like
need
to
get
at
least
a
structure
around
this,
so
that
people
can
contribute.
So
we
can
get
like.
I
think,
the
best
use
of
everybody's
time,
but
I
think
the
the
place
where
we'll
get
lots
of
value
is
having
the
community
participate,
with
providing
sample
solutions
or
working
on
sample
solutions
and
then
also
having
a
pilot
class.
C
So
we'll
learn
so
much
from
going
through
this.
The
first
time
around
that
going
through
the
pilot
and
then
applying
any
feedback
will
be,
will
be
really
key
and
then
also
whatever
we
learn
and
whatever
so
eyes
and
instructors.
Maybe
the
first
instructor
or
whoever
teaches
this
first
we'd,
be
creating
an
instructor
guide
that
others
could
then
take.
And
then
this
workshop
could
be
run
either
as
a
hack
day
within
a
community
within
a
company.
It's
kind
of
like
up
to
you
where
you
run
it.
C
That's
that
to
me,
that'll,
be
the
the
final
like
measure
of
success
was
that
anybody
who's
kind
of
confident
as
a
developer
could
pick
this
up
and
and
teach
a
session
or
indeed,
if
you
just
want
to
go
for
it
on
your
own,
it's
self-study,
so
it's
the
most
trying
to
make
it
as
accessible
as
possible.
Really
so.
Thank
you
very
much
for
the
time
anyway,
that
that's
kind
of
the
the
pitch
as
it
were
and
it'd
just
be
interesting
to
hear
anybody's
the
feedback
or
thoughts
or
anything
that
you
know.
D
Hey
jim,
it's
in
keeper,
sir,
my
camera's
not
working
this
morning,
a
quick
question
on
you
on
your
goals,
obviously,
that
there
are
two
things
you're
trying
to
do
there.
One
is
talk
to
people
about
event,
architectures
and
the
other
is
teach
people
basically
how
to
use
async
api
to
describe
event-based
endpoints.
D
C
Cool,
so
that's
a
really
good
question
and
I
I
think
personally-
and
I
know
I'm
I'm
willing
to
be
proven
wrong,
because
I'm
fairly
new
to
this
as
well,
is
that,
in
order
to
understand
like
where
async
api
adds
value,
I
think
displaying
where
there's
like
a
problem.
First
helps
so
level
setting
the
idea
and
I'm
not
suggesting
that
we
go
into
you
know
a
one
hour.
Martin
fowler
talk
on.
You
know
this
is
what
async
sorry,
what
event
driven
architecture
is,
I
think,
just
enough
to
understand
the
basic
pieces.
C
So
if
we
can
understand
the
basic
pieces
of
the
idea,
if
there's
essentially
a
consumer
and
a
publisher,
a
broker
in
the
middle
that
there's
essentially
messages
that
are
going
from
one
side
to
the
other,
but
you
know
you
may
or
may
not
be
interested
in
receiving
those.
I
think
those
actually
also
the
api
spec
kind
of
gets
to
is
those
are
the
key
points,
at
least
for
getting
started
now.
The
challenge,
I
think,
with
not
doing
that
to
begin
with,
is
you
come
in
with
a
rest
mindset?
C
You
come
in
with
an
open
api
mindset.
That's
like!
Oh
okay:
this
is
completely
different,
I'm
trying
to
model
something,
but
actually
I'm
not
quite
sure
what
I'm
modeling.
So
I
think
that
the
reason
for
having
that
first
as
a
level
set
is
so
that
there's
an
appreciation
of
what
you're
about
to
try
and
model
in
the
async
api
specification.
So
it's
not
about
teaching
event
driven
architecture
per
se.
C
D
It
does
a
little
bit
yeah
I
mean
I
guess
I
I'm
I'm
curious
as
to
I
don't
know,
I
don't
have
any
other
information,
so
it's
definitely
a
kind
of
more
open
question
to
the
extent
to
which
does
18
kpi,
attract
developers
who
currently
work
with
open
api
and
swagger
and
see
this
as
a
route
into
event-driven
architectures.
Or
is
it
more
likely
to
be
people
who
are
currently
building
event-driven
architectures,
who
see
the
advantage
of
being
able
to
find
a
way
of
consistently
documenting
their
endpoints
in
the
way
they
have
with
open
api?
D
For
rest,
I
I
can
definitely
see
the
point
in
a
section
at
the
beginning,
which
kind
of
says:
let's
agrees
from
concepts
and
let's
agree
then
how
they
kind
of
map
to
async
api.
I
mean,
I
think
you
certainly
need
some
of
that,
but
I
guess
I,
when
I
look
at
you
saying
compared
to
rest
compared
to
web
sockets,
it's
kind
of
a
bit
like.
Are
you
digging
a
big
hole?
D
A
A
Because
that's
that's
your
that's
your
wall
world
and
it's
going
to
be
easier
for
you
to
understand,
or
maybe
let's
talk
about
architecture
where
there's
a
broker
in
the
middle
and
let's,
let's
try
to
explain
it
on
a
broker-based
architecture
so
like
to
give
like
you
give
the
basics
to
the
audience,
and
then
you
let
the
audience
decide
like
interactively
like
which
path
they
want
want
to
take.
Because
one
will,
I
guess,
that's
for
a
few
people
that
work
with
will
work
in
future
with
kafka
and
and
brokers.
A
E
I
was
about
to
raise
the
same
concern
and
and
and
actually
I
think
that
they
fundamentally
teach
you
different
things
like,
for
instance,
with
the
websockets.
It's
true,
it's
it's
event
driven
architecture,
but
it's
a
client
server
model.
I
mean
usually
it's
a
client
server
model.
Of
course
you
can
connect
to
some
brokers
using
web
sockets,
but
that's
not
the
usual
case
and
and
that
each
usually
teach
you
like.
E
You
know,
client
server
model,
which
is
like
kind
of
request
response,
similar
to
request
response,
but
with
events
and
actually
many
people
try
to
map
request
response
through
web
sockets.
Like
I
send
this
message
and
I
will
and
I'm
expecting
a
response
at
some
point
right
as
a
response
of
this
message.
E
So
so
introducing
something
like
broker-based
architectures
and
making
it
clear
like
hey,
even
driven
architectures,
can,
at
the
very
least,
diverge
in
these
two
paths
right
like
client,
server
and
broker
base
and
then
with
broker
base.
You
can
do
many
things
you
can
do
secure
ads.
You
can
do
I
mean
even
searching.
I
mean
event.
Sourcing
is
also
possible
with
the
web
sockets
not
with
with
client
servers.
E
So,
on
the
on
the
websocket
side,
it's
clear
on
the
client
server
side
is
clear.
You
define
problems
as
what
your
client
can
do
and
subscribe
us
what
your
problem
the
client
can
do,
but
on
the
broker
broker
based
architectures,
it's
like
who's.
My
client
right
who's,
the
client
here
so
so
yeah.
So
that's
also
a
that
would
be
also
a
good
opportunity
to
teach
also
this
meaning
of
the
operations
like
look.
This
is
what
18kpi
thinks
about
publishing
subscribe
and
yeah.
Just
my
two
cents.
C
C
Another
perspective
is
potentially
to
have
it
so
that
you
know
if
you're
interested
in
those
things,
your
learning
path
might
actually
be
different
and
possibly
not
actually
overlapping.
The
two
concerns
and
saying
like
look:
these
are
distinct
different
problems
that
we're
trying
to
solve,
or
you
might
be
trying
to
solve
and
actually
trying
to
learn
them
together
is
confusing.
So
that's
that's
another
option
that
we
could
play
so
we
could
put
a
an
intro
session
in
that.
C
You
know
goes
into
those
details
and
almost
like
just
introduces
that
as
a
as
a
key
point
that
there
is
this
difference,
the
spec
kind
of
handles
more
than
just
one
thing
really,
and
then
these
are
your
options
in
terms
of
like
onward
sessions,
so
people
can
watch
that
up
front,
get
the
level
set
without
having
to
be
there
and
then
decide
which
which
part
they're
gonna
it's
gonna
go
for
in
in
the
next
the
next
piece.
So
we
could
certainly
twist
it
around
and
maybe
think
of
things
more
in
that
in
that
way,.
A
One
thing
I
would
suggest
you,
you
suggested
github
issues
to
track
like
work
on
every
chapter,
but
you
mentioned
like
may
need
to
have
discussion,
ideas,
etc.
So,
most
probably
the
best
would
be
to
actually
enable
discussions
on
the
training
repo
because
discussions
they
give
you.
These
features
like
vote
up
and
like
clear
structure
so
yeah.
If
we
get
too
many
ideas,
it's
not
so
difficult
to
scroll
through
comments,
and
did
you
think
about
the
length
of
the
of
the
workshop
yeah.
C
I
mean,
I
guess,
like
my
my
kind
of
we've
done
two
formats
before
we've
done
full
days
and
half
days
and
half
days
seem
to
work
better
because
it's
easier
for
people
to
schedule
like
either
in
with
the
work
they're
doing
or
just
take
a
half
day
off,
whereas
a
full
day
starts
to
become
more
of
a
challenge.
I
guess
with
the
ideal
or
the
the
nice
thing
that
we
we
could
potentially
get
to
is.
A
A
A
A
So
just
an
update
for
you
folks,
we
did
not
forget
about
you,
of
course,
and
google
summer
of
code
is
still
running
and
the
deadline
is
this
thursday.
So
this
thursday
we're
gonna
pick
the
projects
and
I'm
afraid
I
cannot
say
more
because
there
are
some
rules
around
google
summer
of
code,
what
we
can
say
publicly
and
what
we
can't.
So
I
think
we
cannot
say
how
many
slots
we
got
and
who
will
be
accepted.
A
Us
whatever
was
the
decision
sent
to
you
from
google
summer
of
code,
yeah
talk
to
us
and
that's
it
if
it
comes
to
google
summer
of
code
and
then
the
two
one
release
so
yeah
the
release
is
going
to
happen
in
june
and
that's
it.
Everyone
has
some
questions
because
I'm
not
sure
really
what
to
say,
because
we
talked
about
it
last
time
and
I
can
just
answer
a
lot
of
questions,
so
we
I've
put
a
thread
yesterday
in
our
slack.
A
A
The
only
requirement
is,
of
course,
to
have
it
merged
into
the
future
branches,
because
we
agreed
that,
let's
say
async
api
spec.
If
you
want
to
introduce
some
change
intel
and
into
asking
api
spec
for
to
one,
you
need
to
open
a
pull
request
to
a
branch
called
release
2021
june,
something
like
this.
The
branch
does
not
exist
yet,
of
course,
info
for
dale
and
for
others
who
already
opened
prs.
A
F
F
F
A
Yeah,
okay,
just
double
check
but
yeah,
but
if
it
it's
not
there,
then
just
wait
with
the
request.
Once
we
have
the
branch
this
and
next
week
is
the
time
where
we're
gonna
start
setting
up
the
things,
but
that
should
not
block
you
from
working
on
your
pr's
folks
and
yeah.
Remember
about
the
contribution
guides
that
whatever
is
into
t
to
one
release.
A
G
A
Yeah,
but
I
was
just
talking
about
technical,
so
technically,
if
it's
gonna
end
up
in
the
release
branch,
then
it's
already
part
of
the
two
one
release.
So
I
didn't
want
to
tackle
on
the
on
the
naming
on
the
contribution
guide
unless
there's
something
different
written
and
that's
why
you're
confused?
A
A
I
guess,
as
far
as
I
remember
in
the
in
the
object
of
the
example
and
if
it's
going
to
be
merged
in
the
parser.js
in
this
schema
and
in
the
spec,
we
will
automatically
publish
artifacts.
So
anyone
can
use
the
parser
supporting
the
the
new
example
and
can
read
the
the
spec
the
candidate
for
to
one,
and
it
basically
means
that
if
it's
in
in
the
artifact,
then
it's
gonna
get
into
the
release.
G
A
A
A
Okay,
so
if
anyone
wants
to
help
with
the
release
with
automation,
it's
I
guess
it's
going
to
be
challenging.
If
you're
not
using
google
on
google
analytics
google
actions
as
much
as
we
do,
so
I
already
assumed
that
it's
probably
going
to
be
me
working
on
it.
What
anything
else
like
review
of
the
examples
of
dogs
and
like
preparing
release
notes
if
somebody
wants
to
volunteer
here.
A
A
C
D
A
F
I
guess
actually
sorry,
I
just
thought
one
other
quick
plug
if
anyone
has
some
time
today.
It's
kafka
summit
today,
which
is
like
the
big
kafka
community
event,
lorna
mitchell
and
I
have
both
got
sessions
on
async
api,
it's
free
to
register
and
it's
all
online
and
we're
also
both
running
demo
sessions
on
things
you
can
do
with
asian
kpi
and
kafka.
So
I'm
sure
lorna
would
appreciate
people
coming
along
to
support,
and
I
know
I
would
so
if
you're
interested
or
have
some
time,
please
do
come
along
and
help.