►
From YouTube: Thinking Out Loud #5 — with David Boyne
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
Hey
hey
folks,
so
welcome
once
again
to
thinking
out
loud.
I'm
super
glad
to
finally
announce
that
we're
gonna
run.
I'm
gonna
run
another
season
of
thinking
out
loud
last
one
last
season.
If
you
want
to
call
it
like
this,
we
only
did
four
episodes.
That's
why
this
one
is
number
number
five
and
it
was
so
cool
it
was
so
let's
say
it
was
so
productive
that
that
we
decided
that
we
have
to
continue
this
right,
so
so
yeah.
For
those
who
don't
know
me,
my
name
is
fran
mendes.
A
I
am
the
director
of
snkp
initiative
and,
and
this
format
this
program
this
show,
if
you
want,
I
used
to
call
it
like
this-
is
the
worst
show
ever?
Why?
Because
you
might
be
expecting
me
to
do
like
funny
things
like
amazing
things
or
super
fun
things,
or
something
like
that,
and
no
so
this
is
about
thinking
out
loud.
A
That's
the
name
right,
so
I
for
those
who
don't
know
I'm
inviting
people
to
join
every
episode,
and
what
we
do
is
we
think
out
loud
about
different
things,
different
topics
and
yeah.
So
one
thing
that
I
would
like
to
mention
is
I'm
inviting
people
to
the
live
stream,
but
please-
and
I
encourage
you
to
join
us
via
chat,
so
if
you
want
to
participate,
you
know
that
we
are
on
youtube,
we're
on
linkedin.
A
We
are
on
twitch
and
on
on
twitter
as
well,
not
sure
I
think,
on
twitter.
If
you
comment
on
twitter,
we
don't
see
the
the
comments,
but
if,
if
you
comment
on
the
other
platforms,
it
will
be
all
fine
what
else?
Let
me,
let
me
recall
what
else
so
yeah
also
please
participate
like
this
is
a
session
for
the
community,
so
there
will
be.
A
You
know
in
this
case
two
people
in
the
live
stream,
but
we
want
to
be
this
like
a
collaborative
thinking
process
and
so
leave
your
comments
on
the
chat,
as
you
can
see,
they're
appearing
in
the
in
the
screen
trolls
allowed
as
well.
So
that's
that's
also
fine
in
a
nice
way,
of
course.
A
So
what
else
yeah
before
I
forget?
I
want
to
mention
that
we
we've
been
trying
to
understand
how
we
could
be
enabling
closed
closed,
captions
or
closed
captioning.
I'm
not
sure
how
to
call
it
and
subtitles
if
you
want
and
yeah
it's
hard,
it
is
a
tough
thing
to
do
it
live,
but
it's
not
impossible
and
we
managed
to
enable
closed
captions
on
youtube
only
on
youtube.
A
That's
the
that's
the
downside,
I
would
say
so
if
you
prefer
to
to
listen
to
ads
with
closed
captions
head
over
to
youtube
and
enable
them
other
than
that
yeah.
A
I
wish
I
wish
you
all
that
you
enjoyed
this
this
episode
and
this
show
right
call
it
whatever
you
want
and
and
that
you
actually
like
you
enjoy
it.
You
enjoy
time
with
us
and
participate
with
us.
A
That
topic
today
is
about
even
driven
architectures.
What
a
surprise
right,
and
it's
not
going
to
be
strictly
about
async
api.
This
time
this
is
going
to
be
around
event,
discovery,
event,
documentation
and
event,
governance.
If
you
want
like
the
different
parts
of
event,
governance,
if
you
want
and
and
now
I
was
curious
like
when
it
comes
to
event,
discovery
and
and
documentation
like
who
is
like
the
right
person
in
my
opinion
to
talk
about
this,
so
I
decided
to
invite
our
fault
dave
boyne.
A
So
welcome
dave,
hello,.
A
A
Yes,
I
was,
we
were
just
talking
before
the
before
the
live
stream
and
he
was
like
you,
you
gotta
get
a
a
countdown
or
something
I
was
like
hold
on
hold
on
hold
on.
I'm
ready,
I'm
ready
for
that.
So
this
is
all
this
that
you're,
seeing
all
the
designs
logos.
A
Everything
is
a
great
work
by
missy
missy
turco
since
the
designer
of
the
async
api
initiative
and
the
working
at
postman
one
of
the
designers
sorry,
so
she
used
to
be
the
only
designer
but
not
anymore,
so
so
yeah,
and
so
thanks
a
lot
missy.
This
is,
as
you
can
imagine,
as
you
can
see,
is
amazing
and
amazing,
work
and
and
hold
on.
I
mean
there's
more
you'll,
see
at
the
end
of
the
at
the
end
of
the
live
stream.
A
You'll
see
that
there
is
an
outro
video
and
there
is
a
tune
from
the
great
greg
meldrum
from
solas
so
who
created
the
async
api
song,
and
this
time
he
created
a
tomb
for
thinking
out
loud.
This
is
amazing,
like
collaborative
work
like
community
work.
This
is
this
is
amazing.
I
love
it
so
yeah,
so
yeah
dave.
I
was
explaining
to
people
that
this
is
a
like
a
thinking
session.
If
you
want,
so
it
wouldn't
be
different
than
than
any
other
meetings
that
we
have
regularly
and
but
yeah.
B
Cool
yeah,
yeah,
so
flows,
don't
know,
I'm
dave
so
at
the
moment,
so
kind
of
like
I've
spent.
Well,
I
don't
know
you
know.
I
spent
a
lot
of
my
career
kind
of
building
products
for
teams
and
you
know
even
standardized.
B
You
know
solutions
and
things
like
that,
but
the
last
kind
of
five
months
I've
been
working
actually
with
open
source
full
time
so
part
of
the
async
api
initiative
and
postman
open
technologies,
but
mainly
focused
on
event-driven
architectures,
and
you
know
a
bit
about
the
past
of
that
is
I
kind
of
got
introduced
a
couple
of
years
ago
to
the
concept
around
event
driven
stuff.
I've
got
more
hands-on
with
it,
and
mainly
in
aws
and
things
like
that.
B
But
then
just
learn
learn
to
love
it.
I
don't
know
what
it
was
and
then
start
writing
tools
around
it
and
then
start
meeting
people
like
fran,
for
example,
so
yeah
at
the
moment
I
get
to
I
get
to
work
on
this
stuff
kind
of
full
time
and
what
what
do
I
do
just
explore
kind
of
different
problems.
B
People
are
having
different,
tooling,
that's
out
there
and
engage
with
community
people
like
that
could
be
like
interviewing
people,
I'm
talking
about
their
problems,
vda
and
also
just
engaging-
and
you
know,
on
twitter
and
various
things
and
seeing
what's
out
there
and
what
problems
need
solving
and
trying
to
trying
to.
I
don't
know,
come
up
with
come
up
with
some
ideas
but
also
learn.
I
tend
to
try
and
learn
in
public
and
teach
in
public
if
that
makes
sense.
A
Yeah,
I
I
I
feel
you
there
like
it's
always
a
constant
learning
process
and-
and
I
completely
agree,
you're
teaching
in
public
as
well,
so
there
I
myself
discovering
a
lot
of
things
thanks
to
you,
thanks
to
for
of
the
staff
that
you're
sharing
and
I'm
I'm
sure
that
there
are
many
people
out
there
who
are
learning
a
lot
of
course,
not
just
junior
people,
but
also
experienced
developers
who
are
just
getting
started
with
even
driven
architectures
or
even
not
necessarily
I'm
not
getting
started
with
inventory
architectures,
and
I
can
I
keep
learning
from
you
as
well.
A
So
so
yeah
like
that's,
that's
really
cool,
that's
really
cool
man,
so
there
is
something
that
you
might
want
to
talk
about
as
well.
Just
you
tell
me
if
you
want
overall,
of
course,
but
I'm
gonna
show
a
quick
demo
to
people.
While
we
speak
right.
Let
me
enable
this
sorry.
I
went
mainstream.
A
Yes,
so
what
is
this
man?
You
might
want
to
talk
about.
B
Yeah,
so
this
is
kind
of
yeah.
This
is
a
project
that's
taken
yeah.
I
think
I
decided
about
december.
It's
called
event,
event
catalog
and
I
think
at
the
time.
So
what?
What
is
it
all
right?
Let's
start
with
what
is
it
it's
a
tool?
It
says
it's
a
tool
that
allows
you
to
document
your
your
eda,
and
how
do
you
do
that?
I
think
that's.
B
The
key
part
is
through-
which
I
feel
you
know
is
his
tooling,
that's
already
familiar
with
people
so
markdown
files
as
an
example
and
with
markdown
files
we
can.
We
can
we
can
document
our
events.
We
can
document
our
services
and
soon
you'll
be
able
to
actually
document
your
domains
and
group
things
out.
That's
what
I'm
working
on
now.
So
the
idea
here
is
so
why
okay
start
with
the?
B
Why
is,
as
I'm
engaging,
I
guess,
as
I'm
engaging
with
a
lot
of
people
in
the
eda
space,
an
async
api,
for
example.
There
is
a
need
that
you
can
see
right.
There
is
a
growing
need
for
governance,
there's
growing
need
for
specifications
and
async
api.
I
think
provide
a
good
good
example
of
how
to
do
that.
B
How
to
document
your
consumers,
your
publishers
and
your
channels
and
your
messages
and
all
event.
Catalog
really
is
and
kind
of
like
a
different
spin
on
that,
but
also
it
does
integrate
with
async
api,
which
is
an
optional
plug-in.
But
it's
just
another
way
to
how
do
you
visualize?
How
do
you
have
a
tool
that
your
team
can
use
to
understand?
B
What
an
event
is
understand,
what
the
services
understand
the
publishers
and
subscribers
and
everything
else
like
that,
and
there's
also
visualization
tools
in
here
that
allow
you
to
see
the
relationships
between
things
and
drag
things
around
as
you
can
see
there,
and
we
just
good
demo,
yeah.
A
A
This
is
actually
really
cool
like
this
sorry
to
interrupt
you
like
the
this
diagram,
where
you
can
see
a
service,
publishing
certain
messages
and
and
which
others
are
receiving
it.
This
is
actually
really
cool.
B
Yeah,
I
think
when
we
we
put
the
visualizer
this
a
similar
kind
of
tool
in
the
async
api
studio,
and
it
gets
quite
a
lot
of
good
feedback,
and
I
think
I
think
what
I'm
learning
anyway
is
that
I
think
there
is
a
lot
of
visual
need
with
eda
stuff
in
in
general.
I
don't
know
you
know
for
me
anyway,
I'm
kind
of
like
more
of
a
visual
learner
and
if
I
was
in
a
whiteboard
session
right
now
with
ufran
and
we
were
to
design,
I
don't
know
a
system
of
some
sorts.
B
I
would
start
drawing
boxes
like
most
of
us
do
and
drawing
things
and
how
to
visualize
things,
and
so,
but
I'm
not
sure
the
tooling
is
there
for
it.
Although
we
have
miro
and
stuff
like
that,
so
we
can
get
there,
but
I
wanted
to
explore
writing
a
tool.
It
just
allows
us
to
easily
just
a
tool
that
that's
a
static
site
generator
as
it's
built
on
next
chase.
That's
just
aimed
at
eda
documentation.
B
B
It's
designed,
you
know,
that's
what
it's
designed
for
is
just
to
yeah,
provide
people
with
a
tool
to
do
that,
and
I
think
I
think
what
I
kind
of
learned.
So
this
was
december.
You
know
we're
in
february
what
I've
learned
in
the
last
couple
of
months
is,
as
you
build
this
stuff
in
public
and
like
a
sherlock
on
twitter
and
stuff,
and
you
start
getting
a
lot
of
engagement
right.
You
start
thinking
people,
oh,
this
looks
cool.
What
is
it?
Where
can
I
have
it?
It's
like?
I'm!
A
You
got
all
of
us
hyped
like
when
is
this
guy
going
to
release
event
catalog?
I.
B
B
Yeah,
which
is
it
which
was
good
feedback,
good
initial
feedback.
I
think
so
I
felt
for
me
anyway.
There
was
a
need
for
something
like
that,
so
it
went
live
in
january
and
then
since
then
it's
had
you
know
a
slow,
healthy
progression.
We've
had
there's
a
community
on
discord
just
over
100
people.
Now
you
know
some
core.
You
know
cool
people
on
there
providing
feedback
and
actually
using
the
tool,
which
is
awesome
and,
as
we
had
paul
requested
his
11
contributions.
B
So
far
you
know
small
documentation
fixes
to
actual
full
implementation
stuff,
which
is
hype
machine,
which
is
which
is
good.
So
I
know
it's
exciting,
it's
exciting
to
see,
and
hopefully
it
solves
the
problem,
but
we'll
see
in
time
really
how
well
how
well
it
does
solve
a
problem
and
just
get
feedback
so
yeah.
It's
kind
of
a
big
explanation,
but
I
guess
and
yes
yeah
just
to.
A
I
was
just
like
I
wanted
to
read
it
out
loud
like
so
people
can
so
those
who
are
not
noticing,
like
sergio,
was
saying,
plus
one
to
the
hype,
machine,
generator,
cold
boy
or
pointy.
C
A
A
I
think
it's
that's
the
right
way,
so
yeah
head
over
to
event
catalog,
because
it's
it's
a
really
cool
tool.
I
want
to
mention
something.
So
this
is
an
async
api
live
stream.
It's
called
thinking
out
loud
blah,
blah
blah
and
all
stuff
like
if
kinder
looks
like
something
separated
sometimes,
but
no.
This
is
amazing.
Kpi
initiative
inside
this
in
kpa
initiative,
but
I
must
say,
like
event:
catalog
is
not
like
any
async
api
initiative
project
right.
A
So
this
is
dave
dave's
stuff
right,
so
he
actually
integrated
it
with
with
its
in
kpi.
So
you
can
you
can
actually
can
you
import
it
or
not?
Yet,
okay,
you
can
right.
I
think.
B
Yeah,
that's
right
yeah,
so
I
think
there
was.
There
were
two.
There
were
two
key
principles
with
the
tool
which
are
number
one.
It
needs
to
be
easy
to
use
as
he
and
needs
to
be
well.
Documented
itself
needs
to
be
documented
right
and
number
two.
It
needs
to
be
the
biggest
feedback
with
most
documentation
tools
is
they
they
get
out
of
sync
straight
away?
Okay,
so
what's
the
point?
B
Why
should
I
document
my
events
and
services
when
I
have
teams
constantly
building
them,
so
they
it
actually
supports
plugins
and
the
plugins
at
the
moment
called
generators,
and
you
can
take.
You
can
take
a
brand
new
async,
a
brand
new
event,
catalog
out
the
box
and
an
async
api
file
or
multiple
wasting
kpi
files
and
plug
them
in
using
the
plugin,
and
it
will
generate
your
services
generate
your
events,
generate
the
markdown
files
generate
the
relationship,
the
diagrams
and
everything
else
like
that.
So
that's!
Well,
that's
the
beauty
of
the
specs.
B
B
So
the
whole
idea
is,
you
know,
top
level,
really
it's
taking
taking
a
source
and
then
mapping
it
into
event.
Catalog
stuff,
you
know
which
is
markdown
files,
so
you
could
you
could
you
could
scrape
the
internet
somewhere
and
generate
a
markdown
file?
So
if
you
can
do
that,
then
you
can
create
a
plugin
for
event
catalog
and
then
you
can
just
render
if
it
follows
the
same
format.
You
know
the
front
matter
and
the
stuff
underneath
you
can
render
any
service
any
event
you
want.
B
A
I'm
that's
cool.
I'm
curious.
I
was
thinking
just
now
like
how
the
hell
did
dave
came
up
with
the
idea
of
event.
Catalog
like
I
know
that
you're
working
in
public
that
you're
listening
to
you're
reading
people
who
give
you
feedback
and
so
on,
but
at
some
point
and
I'm
saying
because
so
this
is
a
disclaimer,
so
dave
works
for
for
us
at
the
sync
api
inside
postman
right.
A
So
so
he's
working
on
a
sync
api
as
well
and
at
some
point
before
christmas,
you
kinda,
like
disappeared,
didn't
disappear
and
and
and
suddenly
I
started
seeing
a
lot
of
push
into
into
event.
Catalog
and
I
was
like
well,
that's
that's
a
cool
idea,
and-
and
I
and
I
I
remember
that
I
I
talked
to
you-
we
had
the
chat
and
and
then-
and
you
were
like
so
I'm
building
this
and
that
blah
blah
I'm
building
this
event.
A
Catalog
thing
this
is
really
cool
blah
blah
blah,
but
but
I
never
really
asked
you
like
what
was
the
main
motivation
for
you.
B
Yeah,
I
think
I
said
yeah
it's
an
interesting
one.
I
think
the
the
main
motivation
was.
I
don't
know
what
it
is,
but
I
I
I
when
I,
when
I
kind
of
build
when
I
build
tools
open
source
stuff,
I
quite
like
building
the
documentation
that
goes
with
it
and
static
site
generations
in
general.
I
just
quite
like
building
sites,
which
is
a
bit.
It
was
just
a
weird
thing,
so
there's
a
there's.
B
A
project
called
docusaurus,
which
is
which
is
owned
by
which
is
open
source
by
facebook
and
the
the
whole
purpose
of
docusaurus,
is
to
allow
developers
to
easily
create
documentation
for
projects
for
like
open
source
projects,
and
you
know-
and
if
you
go
to
well
any
of
my
open
source
projects,
you'll
see,
I
use
it
everywhere.
B
So
it's
a
really
nice
tool
that
you
can
basically
say.
Okay,
here's
the
command
line,
give
me
a
new
docusaurus
project,
and
I
and
how
do
I
fill
it
in?
I've
got
a
config
file
and
I
have
markdown
files,
okay
and
that
just
that
kind
of
I've
been
using
that
for
about
five
years
now,
and
the
back
of
that
was
just
in
the
back
of
my
head
and
I
was
kind
of
thinking.
B
Well,
what
if
you
know
what,
if
we
could
in
having
an
enriched
so
so
keep
that
in
the
back
your
head
and
now
you've
got
the
eda
kind
of
problem
emerging
in
my
head.
You
know
in
my
mind,
which
is
we
have
specs
emerging.
We
have
more
people
using
eda,
we
have
more
stuff
going
on.
Could
we
could
we
in
theory,
as
a
test?
You
know
write
this
thing
write
something
that
could
generate
documentation
just
for
eda
stuff,
so
yeah,
so
that
that
that
was
it.
B
A
So
in
some
to
some
degree,
you
basically
like
thought
on
a
subset
of
docuseries
like.
A
I
damn
it.
I
can't
pronounce
this.
A
A
That's
what
we
we
will
say
in
spanish,
so
like
a
subset
in
terms
of
use
case
right
so
docusaurus
is
for
everyone
right,
any
kind.
A
And
I
think
in
your
head
it
was
like:
oh,
it
would
be
cool
to
have
a
docker
service
for
even
driving
architectures
right,
like.
B
That
exactly
and
I've
spent
honestly,
I
spent
a
lot
of
time.
Look
at
that.
You
know,
thankfully,
github
now
have
the
feature
where
you
can
press
the
dot
right
and
go
into
the
editor.
I
literally
spent
a
lot
of
time
just
in
docusaurus
code.
How
do
they
do
this?
You
know
how
does
this
bit
work?
How
does
the?
How
do
we,
how
does
a
config
file
work
in
docusaurus?
B
How
do
they,
you
know
and
all
their
architecture
and
all
you
know,
and
if
you
stay
event,
catalog
you'll
actually
see
a
lot
of
it
was
inspired,
slash
copied
from
docusaurus,
so
yeah.
A
A
It's
re,
that's
what
we
say
in
open
source
right,
I'm
reusing
someone
else's
code,
but
it's
true.
Like
I
mean
in
my
in
my
experience
I
I
started
this
in
kpi
as
a
copy
as
a
it
was.
I
literally
copied
open
api
and
started
from
top
to
bottom
reading,
and
you
know
like
rewriting
stuff
that
didn't
make
sense
for
event
driven
architectures
and
that's
how
it
all
started
like
you
get
a
start
from
some
point.
A
Sometimes
you
start
from
scratch
because
you
have
nothing,
and
sometimes
you
have
something
some
kind
of
inspiration
and
if
it's
open
source
we
win
right.
So
it's
it's
it's
better
for
everyone.
It's
actually
also
something
good
for
open
api
as
well,
because
we
we're
given
a
bunch
of
feedback
during
this.
Through
the
years
we've
we've
gave
a
lot
of
feedback
to
open
api
as
well,
and
and
people
like
you
know,
like
we're,
coming
back
to
open
api
saying
hey,
so
I
can
do
this
in
missing
kpi,
but
not
enough
in
api.
A
I
can
do
this
in
open
api,
but
not
in
the
sync
api,
so
it
will
be
cool
that
things
are
at
least
the
common
parts
are
compatible
right
or
in
terms
of
features
so
yeah.
So
it's
it's
actually
really
cool.
So
no
shame
in
recognizing
that
you
copied
something
you
can
say
you.
You
can
always
say
like.
I
got
inspiration
in,
which
is
a
more
much
more
friendly
way
of
saying.
Yeah.
B
B
Would
it
be
possible
and
would
there
be
value
to
people
in
this
thing
right
and
as
I
was
building
it
rather
than
sitting
away
for
months
and
months
and
then
big
bang
release,
although
I
did
bit
of
that,
I
guess,
but
as
I'm
building
it
just
sharing
on
twitter
right
sharing,
okay,
would
this?
Would
this
be
value
to
anyone?
If
I
could
take
a
markdown
file
and
give
you
this
would
you
enjoy?
You
know,
is
that?
Would
you
find
that
valuable
and
a
lot
of
people
a
lot
of
people
engaging
yeah?
B
You
know
this
is
awesome,
and
that
was
it.
You
know
that
was
the
birth.
A
Before
you
were
mentioning
this
async
api
plugin,
that
was
the
first
plugin
you
created
for
for
event,
catalog
and-
and
I
got
immediately
curious
when
you
created
this
plugin-
I
I
was-
I
was
like
okay,
so
he
can
import
or
he
can
use
async
kp
files
to
generate
an
event,
but
currently
state
of
art
right
now
is
some
kpi
only
represents
a
single
application
or
terminology
of
even
catalog
a
single
service
right.
A
A
It
to
whatever
you
want,
and
you
have
different
services,
different
applications,
publishing
and
subscribing
to
different
events
right
so
and
and
actually
one
cool
thing
that
you
that
we
could
see
on
the
on
the
video
that
I
that
I
showed
before
about
when
the
catalog
is.
These
diagrams
is
generated
diagrams
like
this.
This
service
is
publishing
this
events
here
and
then
these
events
are
flowing
through
or
to
this
service
and
these
other
services.
A
So
they
all
share
this
right,
but
yeah
and
I
was
like,
but
that's
not
possible-
with
the
singularizing
kpi
file.
C
A
So
I
wonder
if
you
notice
this
limitation,
like
if
yeah
working
on
this
plugin.
B
Yes,
well,
the
first
initial
release
of
the
plugin
supported
one
file.
So
how
does
it
work?
So
you
know
it
goes
to
your
async
api
file.
It
could
figure
out
what
the
service
is,
because
it
assumes
this
is
the
file
with
the
service
and
then
you
know,
get
the
messages,
the
publishers
and
subscribers
from
that
and
then
on
discord.
We
had
someone
provide
feedback
and
say:
would
it
be
nice?
You
know
I've
got
lots
of
async
api
files
and
rather
than
because
they're
on
the
plugin,
you
have
to
specify
the
path
to
the
file.
B
Could
it
be
an
array
and
could
we
specify
multiple,
multiple
files,
so
yeah?
That
was
it?
You
know
a
couple
of
days
later,
pull
request
was
in
and
now
we
support
multiple
files,
which
probably
has
its
own.
You
probably
might
come
into
your
own
problems,
I'm
not
sure,
but
you
can
in
theory
at
the
moment,
use
as
many
as
you
want.
It
will
just
it
will,
go
through
them
and
generate
the
markdown
files
for
every
service
every
event,
every
publisher,
every
subscriber
yeah.
B
And
the
same
same
with
the
node
graph
stuff,
you
saw
the
visualizer
that
was
built
by
someone
in
the
community,
so
I
was
using
mermaid
in
in
the
markdown
files,
but
we
had
a
pull
request
to
use
flow
react
flow,
which
is
what
icing
kpi
uses
too,
and
you
know
they
look
a
lot
better
they're
enriched.
We
can
add
icons,
we
can
do
stuff
and
then
that
pull
request
was
in
and
then
I
just
I
just
extended
it
to
build
the
visualizer.
B
A
I
can
imagine
it's
overwhelming
sometimes
like
it's
like
it
says:
lots
of
feedback
that
you
received
from
the
community
and
and
you
get
explosive
response
from
the
community.
I
can
see
it
so
so
yeah
congrats
for
that
by
the
way.
C
A
So
you
know
you
know,
because
you're
part
of
this
in
kpi,
so
you
know
we're
at
this
in
kpi
we're
trying
to
like
literally
build
the
future
of
event
driven
architectures.
That's
what
the
website
says,
but
it's
true
like
it's
not
just
a
tagline
there,
beautiful
tagline
or
marketing,
tackling
right.
C
A
A
You
work
on
it
because
we
have
both
the
same
like
async,
api
and
even
catalog
are
both
like
driving,
even
driven
architectures
in
the
same
direction,
so
we're
pushing
for
the
same
thing
right
and-
and
that's
actually
something
really
good,
but
you
know
with
the
new,
not
bad,
but
also
with
the
new,
with
the
new
works
that
we're
doing
on
on
async
epi
3.
A
There
is
a
discussion
that
we
might
allow,
or
we
yeah
we
might
allow
on
the
spec
that
people
can
define
multiple
applications
or
multiple
services
in
a
single
snkpa
file
right.
So
this
is
an
ongoing
conversation
right
now
for
version
three,
which
we
hope
to
to
release
this
year.
We
don't
know
yet
when
that
all
depends
on
how
many
people
get
to
contribute
right.
A
So
if
you,
if
you
who
are
listening
like
you
all,
were
listening,
you
wanted
to
be
like
ready.
You
know
what
to
do
like.
You
have
to
join
the
airport,
so
so
yeah.
What
I
mean
is
that
at
some
point
anything
kpa
file
will
be
able
to
to
define
multiple
applications
and
therefore
we
have
studio
right.
We
have
facing
kpa
studio
and
sync.
A
Api
studio
is
currently
allowing
you
to
document
a
single
application,
because
that's
what
we
got
an
syn
kpi
is
a
single
application,
but
in
one
hand
we
have
this
spec
3
work
to
support
multiple
applications
in
a
single
file
and
on
the
other
hand,
we
have
studio
as
to
the
feature
by
magic,
urban,
czech
who's
on
the
chat
actually
first
message
of
the
of
the
chat
and
he
proposed
that
we
have
multiple
files
support
on
studio,
so
people
can
edit
multiple
files
they
can.
A
You
can
have
like
a
project
right.
You
have
your
ada
project
where
you
have
like
multiple
snkp
files
and
then
you
will
be
able
to
see
the
documentation
and
generate
code
and
so
on
and
so
on,
but
yeah.
It
kind
of
feels
like
natural.
That
next
step
will
be
even
catalog
support
right
or
something
like
what
even
catalog
is
doing.
A
It's
like
inside
studio,
as
well
or
or
maybe
outside
studio,
we'll
see
but
like
I
want
to
see-
or
I
want
to
explore
all
my
events
that
are
coming
from
these
snk
files
right
and
then
to
me.
It
feels
like
a
natural
next
step
will
be
as
a
user
as
an
essentially
a
user.
I
think
a
studio
user
right
either
with
multiple
file
support
or
with
the
multiple
applications
inside
a
single
snkpa
file.
A
I
will
want
to
see
my
whole.
My
whole
architecture,
like
my
whole
events
like
discovered
them
my
applications
so
essentially
even
catalog
right.
I.
A
So
I
was
like
damn
like
we
have
to
integrate
both
immediately
like
we
have
to
find
a
way
to
integrate
both
like
I
do
I
mean
I
don't
want.
I
don't
want
it
to
be
like
we
build
an
async
api
event,
catalog
call
it
name
it
whatever
you
want
and
that
will
compete
with
event
catalog
now
that
would
be
stupid
like
event
catalog,
it's
a
it's
open
source
and
I
mean
it's
not
open
governance.
A
It's
just
it's
your
project
yet,
but
could
be
in
the
future,
and-
and
what
I
mean
here
is
that,
in
my
opinion,
not
not
sure
what
you
think
about
it,
but
I
think
it
will,
in
the
future
not
a
distant
future
which
will
go
in
this
direction
like
like
event,
catalog
and
studio
and
event.
Catalogs
will
be
integrated
more
tightly,
not
from
the
event
catalog
site,
maybe
but
from
studio
side
of
things.
A
So
studios
will
be
able
to
let
you
visualize
all
your
all
your
stuff
right
like
event,
catalog
is
doing
maybe
embedding
an
event
catalog
dynamically
rendered
event,
catalog,
maybe
something
that
could
be
like
every
time.
You
make
a
change
in
your
synkpa
file.
It
could
be
like
boom
immediately
regenerated
the
event
catalog
right
on
the
fly,
so
I
don't
know
what
you
think
about
it.
B
Yeah
wow
yeah:
it's
a
lot,
there's
a
lot
there,
so
I
think
you're
right.
You
know,
I
think,
with
the
spec.
I
think
the
spec
changes
and
I
think,
as
you
said,
you
know,
if
you
could
do
multiple
files,
I
think
it's
definitely
stepped
in
the
right
direction.
Isn't
it
because
I
think
you
know
something
I've
been
doing
recently
is
also
kind
of
interviewing
what
interviewing,
but
I
guess
talking
to
community
members
about
async
api
right
and
specification.
B
Some
feedback
you
know
there
are:
there
is
some
feedback
in
the
community
about
how
do
you?
Well?
You
know
you've
heard
it
in
the
past
about
the
multiple
files
versus
the
one
file
versus
the
the
overall
thing
and
everything
else
like
that,
and
I
guess
if
we
were
talking
about
visualizations,
you
know
of
our
architecture
and
our
events
and
our
services,
it
kind
of
kind
of
makes
us
it
kind
of
makes
sense
and,
as
you
said,
it
feels
like
a
natural
direction
for
the
tooling
to
go
now.
B
One
is
it's
interesting
because
on
one
hand,
you've
got
so.
The
core
principle
of
the
event
catalog
is,
is
you
know,
is
the
static
site
generation?
Is
the
ease
of
use?
Is
the
not
not
not
tied
to
anything
but
can
visualize
stuff,
but
then,
by
most
things
there
could
there
be
definitely
parts
of
that
which
can
be
used
elsewhere?
B
You
know
but
but
there'd,
be
a
bit
of
work
a
bit
work
to
do,
but
also
it's
hard
with
this
stuff,
because
we
need
we
need
the
we
also
kind
of
like
need
the
use
cases
in
the
community
to
give
us
feedback
on
how
how
they'd
expect
that
to
work.
So
I
guess
we
could.
We
could
figure
out
how
it
how
we
could
get
it
to
work,
might
not
not
necessarily
be
what
we
should
be
doing.
I
don't
know,
do
you
see
what
I
mean.
A
A
Yeah,
I
agree.
I
agree,
I
mean
that's
one
way
in
the
end.
Actually,
so
maybe
we
don't
need
event
catalog,
so
we
don't
need
the
full,
even
even
catalog
thing
on
studio.
Maybe
we
just
need
the
diagrams
right,
so
that's
all
we
need
and
then
and
then
it's
just
a
matter
of
yeah
having
like
a
kind
of
visualizer
which
which
actually
you
already
contributed
to
to
studio,
that
you
can
visualize
one
single
application,
publishing
or
consuming
messages.
So
you
can.
A
See
like
the
whole
diagram
right
now,
this
is
just
one
application.
We
need
to
see
how
things
connect
to
each
other
right.
B
I
think
yeah
the
more.
I
think
I
think
about
a
lot
recently
and
the
more
I
kind
of
think
about
that
space
in
general
is
and
stuff
I'm
trying
to
get
into
at
the
moment.
B
Is
I
open
telemetry
right,
which
is
like
an
open
tracing
and
if
you
can
like,
if
you
talk
about
studio,
you
talk
about
event
catalog,
you
talk
about
the
future
of
any
eda
tool
or
open
source
cdna
tool
right,
yeah,
it's
kind
of
like
if
async
api,
for
example,
could
tell
me
the
broker
and
how
to
connect
to
it
and
everything
else
like
that.
B
That's
interesting,
so
I
can
actually
connect
to
something,
and
if
I
connect
to
something
I
can
actually
start
listening
for
stuff
and
if
I
can
listen
to
stuff,
I
can
actually
start
representing
this
on
the
ui
yeah
and
I
can
actually
start
so.
We
go
back
to
your
flow
diagrams
and
service
diagrams
sharing.
You
know
the
future
for
me
anyway,
showing
showing
the
architecture
is
great,
but
could
you
imagine
these
little
bubbles
going
between
things
in
real
time,
yeah
your
events
yeah,
which
is
which,
which
blows
my
mind?
B
How
do
I
do
that?
How
can
I
achieve
that,
and
I
think
I
think
things
like
open
the
you
know
the
open,
tracing
and
and
cloud
events
and
all
this
stuff
can
is
going
to
help
us
get
there
for
sure
yeah.
A
I
can
imagine
when
you
when
you
said
that
in
real
time
I
could
imagine
like
a
nice,
an
animation
on
the
diagrams
like
a
an
event
popping
up
like
you
get
a
new
one,
like
I
discovered
a
new
one
on
the
broker,
it's
like
a
one-off
and
suddenly
it's
connected
to
something
you
know
or
or.
B
That
would
be
amazing.
The
interesting
thing
about
it
all
is
it's
also
like
state
right.
So
all
your
events
going
on
and
they're
going
across
time.
So
why
couldn't
we
also
kind
of
you
know?
Imagine
a
slider
on
the
ui
where
we
could
like
go
back
in
time
and
forward
in
time.
So
we
can
see
we
can
replay
the
visualization
of
the
events
going
through.
B
So
if
you
had
a
bug
in
your
system
at
two
in
the
morning,
you
could
go
back
at
two
in
the
morning
and
press
play
and
you'll
see
the
events
come
through
click
on
one
and
now
you
can
see
the
event
and
the
male
form
payload
or
the
bugs,
or
the
problems
or
the
the
failures
or
the
service.
That's
you
know,
crossed
off,
and
so.
A
I
I
see
I
can
see
yeah.
I
can
see
that
there's
a
lot
of
overlap
there
with
open
telemetry
as
you
see
and
open
tracing
as
well.
That's
just
an
open
telemetry,
but
yeah
that
would
be
super
cool,
and
not
just
that,
like
we
have
tools,
there
is
one
I
can't
remember
the
name.
So
forgive
me
it's
all
as
folks,
but
solas
donated
a
tool
to
async
api
and
I
think
it's
event
discovery
or
something
like
that.
It's
a
tool
to
let
that
lets
you
connect
to
a
a
broker
and
and
listen.
A
You
know
like
listen
to
the
broker
events
and
and
document
them
generate
async
api
files
out
of
them
right
or
I'm
not
sure
if
it's
a
async
paid
file
only
altogether
or
or
just
the
message
right,
but
the
cool
thing
is
that
you
can
so
this
part
is
already
implemented
in
the
library.
So
we
have
that
piece.
We
have
studio.
A
We
have
the
spec,
we
have
event
catalog
with
all
these
diagrams
right
and
we
have.
We
will
probably
have
to
build
something,
so
people
can
actually
interact
from
the
documentation.
They
can
interact
with
the
broker
and
actually.
C
A
Or
subscribe,
and
and
see
like
I'm
gonna,
subscribe
to
this
channel
to
this
topic.
C
A
And
see
what's
in
there
right
and
and
that
will
be
super
cool,
maybe
not
for
production,
but
for
testing.
It's
not
gonna,
be.
A
B
Yeah
there'll
be
some
visualization
challenges
there
for
sure,
but
exactly
what
you
said
you
know
imagine
just
sending
test
payloads.
Imagine
just
listening
in
like
ease
dropping
in
on
your
flow
of
your
events
and
like
okay,
what's
going
on
here
and
you
know
there
are
tons,
there's
you
know,
I
I
think
the
key
the
key
for
me
anyway.
The
thing
I'm
passionate
about
is:
how
do
you
do
all
that?
But
how
do
you?
B
How
do
you
make
that
all
accessible
to
people
and
and
easy
enough
to
understand,
but
also
easy
enough
to
use
and
that
that
comes
with
the
tooling,
but
also
mainly
the
documentation
and
the
interfaces
and
plugins
and
all
this
kind
of
stuff?
You
know
as
soon
as
it
becomes
hard.
You
know
if
you're
you
know
we
we
just
spoke
then
about
we.
You
know
there's
if
we,
if
we
integrate
open
tracing.
B
If
we
do
open
this
and
open
that
in
cloud
events,
and
we
do
async
api
and
all
this
kind
of
stuff,
you
know
do
you
to
get
to
get,
I
don't
the
answer
is
but
to
get
to
the
end
goal.
How
many
steps
do
I
need
to
do
as
a
team
as
a
developer
to
get
there
and
we
kind
of
want
to
minimalize
that
if
we
can
and
make
it
easy?
But
I
think
that's
that's
the
key.
A
Yeah
yeah,
I
was
initially
thinking
that,
from
our
perspective,
like
the
ones
who
are
building
the
tools,
how
many
steps
we
do
we
need
to
do
to
to
get
there,
but
you
mean,
from
the
user
perspective
like.
C
A
Yeah:
okay,
how
many,
how
many
steps
do
I
have
to
do
to
in
order
to
get
to
where
I
want
to
get.
B
Exactly
you
know,
this
is
the
thing
about
event.
Catalog
that
I
wanted
to
do,
which
was
you
know.
I've
got
npm,
you
know,
create
event
catalog
package,
but
I
want
you
know,
get
to
get.
I
don't
know
for
me
anyway.
It's
coming.
How
do
you
get
to
the
immediate
value
for
a
developer
using
your
tool?
Because
if
it's
gonna,
I
don't
know,
I'm
lazy?
If
it's
gonna,
it's
gonna,
take
me
more
than
half
an
hour
to
use
a
tool,
I'm
probably
not
going
to
use
it
at
all.
A
No,
it's
not
just
you.
Developers
are
lazy.
We
all
are
that's
that's
why
we
get
here.
I
mean
not
lazy
but
lazy
in
doing
maybe
manual,
work
and
manual
stuff.
We
all
we're
always
looking
for
automation.
That's
why
we're
building
all
these
specs
and
different
catalog
and
all
this
stuff
like
we
don't
want
to
repeat
things.
We
don't
want
to
maintain
the
augmentation
out
of
band
documentation
right,
that's
yeah,
so
yeah,
because
that's
a
lot
of
work,
so
yeah.
B
A
I'm
imagining
as
well
like
we
from
from
studio,
we
cool,
so
I
initially
said,
like
I
see
event
catalog
like
embedded
on
inside
studio,
but
maybe
that's
not
the
right
word
so
because
that
will
mean
that
we're
literally
embedding
event
catalog
inside
and
but
I
was
thinking
like
what
about
or
what,
if
we
would,
we
will
build
like
so
studio
also
becomes
somehow
like
an
editor
for
even
catalog.
A
So,
for
instance,
I
I
explain
myself
better
so
imagine
that
I
want
to
create
a
new
application,
a
new
service
right,
I
create
a
new
service,
and
I
start-
and
this
is
what
I'm
going
to
describe,
is
so
the
feature
that
is
proposed-
that
we
create
a
service
like
we
described
like
I'm
published.
This
service
is
passing
this
message
and
subscribing
to
these
other
messages,
but
in
a
visual
way.
So
you
go
with
your
mouse
and
connect
things
and
here
and
there
blah
blah
blah
right.
A
A
True
I
mean,
unless
you
have
to
use
it,
then
you
probably
abandon
it
and
it's
like
don't
care
and
that's
one
of
my
main
goals
with
async
api,
like
that,
we
actually
hide
all
the
complexity
from
of
facing
kpi
from
the
user,
and
it
can
be
presented
in
a
nice
way
in
a
in
a
human
human,
understandable
ui,
rather
than
a
human
or
a
nice
ui
for
a
human,
not
for
machine
right,
not
for
not
for
a
a
developer
necessarily
so
so
it
will
be
cool
that
in
studio,
you
can
add
an
application
and
connect
all
the
dots
and
and
so
on,
to
create
an
easy
kpi
file
behind
the
scenes.
A
But
also
that
will
let
you
edit
the
markdown
stuff
that
you
can
put
on
on
the
on
the
sink
on
the
yeah,
there's
a
description
which
will
be
the
service
description
of
event,
catalog,
which
will
be
the
markdown
that
goes
there
right.
So
that's
there's
a
one
one
match
there
and
that
will
actually
be
super
cool
that
you,
you
have
all
the
ui
working
for
you
and
so
behind
the
scenes.
It's
generating
async
api
files.
A
So
then
you
can
navigate
everything
you
can
edit
everything
inside
studio
right,
not
necessarily
event
catalog,
but
at
some
point
you
might
want
to
share
this
with
your
colleagues
and
deploy
this
somewhere
in
an
internal
server
somewhere
in
your
company
I
or
a
publix
server
as
well
like.
I
want
to
share
this
with
my
colleagues
and
I'm
gonna
generate
event
catalog
and
deploy
to
this
server
from
studio.
B
A
A
It's
also
paying
because
you
have
to
go
manually
one
by
one
and
creating
all
the
you
know
like
produces
this
event,
subscribes
to
this
event,
blah
blah
blah.
That's
a
lot
of
manual
work.
If
you
have
a
big
architecture
like
with
with
many
like,
I
don't
know,
hundreds
or
thousands
of
messages,
that's
a
lot
of
work
and
and.
C
A
A
lot
of
things
that
you
will
have
to
do
so
if
we
could
make
it
easier
from
a
ui
perspective
that
they
can,
you
know
like
they
can
make
it
in
a
visual
way.
Probably
this
could
be
useful
for
the
people
we
have
to
check.
Of
course
we
have
to
consult
the
community,
of
course,
and
gather
feedback,
and
then,
at
some
point
like
I
said,
I
want
to
share
it
with
my
colleagues
and
I
deployed
even
cataloging
my
server
and
what
they
get
is
event
catalog
generated.
You
know,
I
think.
B
Yeah,
oh
yeah,
I
think
yeah.
I
think
it
could
be
yeah.
There
could
be
something
there
right,
as
you
said
like
you
want
to.
You
know,
start
to
start
start
from.
You
want
a
new
service,
so
I
use
I
use
a
tool.
I
use
the
studio
to
create
a
new
service,
so
I
said
kafka
thing,
and
these
are.
These
are
my
publishers.
You
know
I'm
using
this
loco
tool
to
do
that,
which
would
be
great
and
then,
as
you
said,
what
can
you
do
from
there?
Okay
generate
an
async
api
file.
B
Okay
generate
a
mock
server.
Okay,
it's
under
test
center
test,
payload
right,
okay,
that's
interesting
and
then
also
generate
some
external
documentation.
You
know,
as
you
just
said,
which
is
which,
which
you
could,
in
theory,
click
that
button.
It
builds
it
for
you,
because
you've
got
the
sync
api
files
and
then
automatically
host
it
somewhere
for
you
right
yeah,
which
is
wherever
you
want,
because
it's
just
static
content,
so
s3
bucket
or
whatever.
B
I
think
I
think
the
great
thing
about
that
is
you've
got
the
you've
got
the
you've
got
the
low
code.
You've
got
the
the
detail
for
enough
detail
for
developers
like.
What's
my
cafe,
you
know,
what's
my
kafka
broker
url
or
all
this
kind
of
stuff
that
people
need
to
know,
but
then
you
have
to
remember,
you
know
something.
I'm
learning
anyway
is
with
eda.
It's
not
just
it's
not
just
for
us.
You
know
it
isn't
just
for
technical
people,
you
know
and
and
business
people
and
non-technical
people.
Also.
B
You
know
an
email,
I
don't
know,
use
a
created
event.
Okay,
what
does
that
mean?
Oh
look.
It's
described
in
a
way
which
I
can
understand
as
a
product
owner.
No,
no,
what's
a
user
created?
Oh,
it
goes
to
the
kafka
and
you
know
so
I
think
well
so
what
I'm
getting
at,
I
think,
yeah.
I
totally
agree
with
what
you're
saying
I
think
there
is
yeah
there'll
be
huge.
I
don't
know,
I
think,
there'd
be
huge
value
in
that,
especially
like
not
mock
servers
right
and
yeah
yeah,
just
to
say.
A
B
B
B
Isn't
it
look
at
gatsby,
for
example,
look
at
their
plug-in
ecosystem,
it's
huge
and
it's
huge
yeah
and
if
you
can
have
plug-in
an
ecosystem
with
plugins
in
a
nice
clean
interface
that
people
can
actually
contribute-
and
you
know
remember
that
30
minute
rule
where
it's
like.
I
want
to
build
a
plug-in
but
you're,
making
it
harder
because
you've
got
no
documentation.
A
What
do
you
think
like
like?
What
does
it
mean
for
sqs
and
sns
and
aws
technologies?
I
know
that
you
are
like
you,
like
aws
technologies,
a
lot.
I
honestly
don't
like
never
use
in
production
myself.
I've
been
lucky
so.
C
A
Just
kidding
no,
but
I
I
never
used
sqs
or
sns,
so
so,
how
do
you
think
this
can
map.
B
I
have
a
event
catalogue:
okay,
the
things
of
event:
catalog.
Is
it's
not
really
tied
to
any
technology
and
it's
kind
of
on
purpose,
so
it's
just
tied
to
the
concepts
of
publishers
and
subscribes
and
all
this
kind
of
stuff
and
services.
B
So,
if
you
wanted
to,
if
you
want
to
document
your
sns
and
sqs,
you
know
your
sns
topics
and
your
sqsqs
or
your
eventbridge
stuff.
There
is
an
eventbridge
plugin
actually
for
event.
Catalog,
then
it's
possible,
for
example,
if
you
could
go
to
your
sms,
if
you
go
to
aws
and
get
all
your
sns
topics
in
the
cli
in
the
terminal,
you
can
generate
markdown
files
for
that
automatically.
You
can
have
it.
B
A
Was
I
was
just
thinking
we
probably
have
to
be
brave
here
and
it's
like
shouldn't.
We
be
asking
aws
folks
to
integrate
their
products
with
event
catalog
as
well.
So
so
they
like
I
mean
integrate
in
the
sense
of
like
you
have
event
bridge,
for
instance,
and
so
they
have
all
the
information
of
the
messages
that
are
flowing
around
and
which
are
the
services
that
are
sending
and
receiving
them.
A
B
Yeah,
I
never
think,
never
think
that
big,
but
if,
if
you
know
you're
talking
about
like
a
studio
kind
of
scenario
where,
if
you
can
generate
a
catalog
using
you
know
give
the
input
and
generate
it
look
at
the
output-
and
that
was
you
know
you
could
integrate
with
that.
Then
I
guess
why
not
because,
as
you
said,
eventbridge
give
an
example
there
and
they
have
the
schema
registry,
so
they
have.
B
They
have
that
you
talked
about
a
minute
ago
earlier,
the
the
gateway,
that's
just
generating
your
async
api
files
and
your
messages,
because
you
can
listen,
they
have
exactly
the
same
pattern
which
they're
listening
for
messages
and
generating
schemas
and
versions
for
you,
but
then
all
that
is
json,
schemas
and
data
that
you
can
just
input
and
output
into
anything,
and
that
goes
the
same
with
you
know:
kafka
schema
registries
or
any
any
any
third
party
system.
I
guess
I
guess
to
get
there.
B
I
don't
know
I
imagine
I
don't
know
you
know,
maybe
it's
possible,
but
to
get
there.
I
think
you
probably
need
more
growth.
I
imagine
you'd
need
more
kind
of
growth
on
the
project
and
and
abilities
to
do
this
and
it'd
be
interesting
to
see
you
know,
reach
out
to
people
in
the
future
and
see.
B
A
I
was,
I
was
actually
thinking
like,
so
we're
always
trying
to
put
more
features
into
into
studio
into
or
into
event
catalog
right,
but
sometimes
the
the
most
powerful
thing
is
that
you
find
users
where
they
are
right.
So
if
they
are
at
aws,
I
think
aws
could
offer
this,
let's
say
way
or
button
write
like
generate
or
end
download
event
catalog
same
for,
let's
say:
confluent
kafka.
C
A
Right
all
the
brokers,
I
think
all
the
all
the
van
broker
vendors
could
be
jumping
in
here
and
and
same
for
not
just
event
catalog
for
for
async
api
like
it
would
be
cool
that,
with
the
baton,
you
can
generate
your
ac
kpi
file
right.
C
A
That
would
be
like,
like
an
enabler
if
you
want,
that
would
be
an.
C
A
The
cool
thing
is
that,
then
you
can
input
this
file
to
studio
and
from
there
start
working-
and
you
know
like
generating
even
catalog
or
doing
more
stuff
right,
not
just
even
catalogs
here
so
yeah.
I
think
I'm
not
sure
what
you
think.
I
I
think
you
were
saying
like
it's.
You
never
thought
that
big,
but-
and
I
get
you
but
yeah,
don't
you
think
it's
a
it's.
The
way
to
go
like
people
should
be
able
to
find
these
useful
tools
where
they
are
right.
B
I
think
so
yeah
I
mean
I
guess
I
was
just
thinking
when
you
were
talking
there.
I
guess:
look
at
look
at
open
api
right
and
look
at
all
this
stuff.
Where
it's
you
can
take
your
open
api.
You
can
put
it
into
placement.
You
can
put
it
into
this
tool.
That's
all
every
tool
same
as
async
api
right,
it's
on
that
projection
and
all
the
tooling
is
coming
out
of
it.
B
A
So
alexander
is
commenting
that
generating
from
aws
is
good
when
there
is
already
the
infra
in
place
with
existing
messages
going
through
it,
but
when
you're
trying
to
design
first
those
async
flows,
he
says
like
you're,
more
naked
right,
so
it's
like
you,
don't
have
you
have
nothing
basically
right.
So
that
means
that
and
it's
a
good
point,
so
it
goes
both
ways
I
think
it
will
go.
Both
way.
Integrations
should
be
in
both
directions.
A
So
from
aws
you
should
be
able
to
generate
an
event
catalog
or
snkp
files
and
so
on,
but
I
think
that
from
studio,
maybe
that
could
be
the
tool
that
you
should
be
able
to
connect
to
to
your
aws
event,
bridge
event,
bridge
instance
and
and
and
deploy
infra.
That
would
be
super
cool,
not
even
bridge
instance,
but
to
your
aws
account
and
start
deploying
infra
right,
that's
like
probably
long
in
the
future,
but
yeah
like
something
to
probably
consider.
A
I
think
I
lost
you.
Maybe
yes,
I
think
so
where
is
boini
so
boini
is
gone
well
folks.
So
while
we
wait
and
let's
try
to
see
if
we
can
get
him,
I
hope
it's
not
my
my
connection.
So
if
someone
can
just
leave
a
chat
message,
so
I
know
I'm
here
live
that
would
be
super
cool
yeah.
Let
me
check.
A
All
right
so
technical
problems
and
at
exactly
one
hour
after
we
started,
I
hope
we're
not
reaching
a
limit.
A
Okay,
so
sergio
is
there,
so
that
means
I'm
live
all
right,
so
we
got
boyney
back.
A
C
A
C
A
So
as
I
was
saying
that
that
yeah,
like
infra
yeah,
integration,
should
go
in
in
two
ways,
right,
not
just
like
as
alexander,
was
mentioning
right.
So
when
you
have
something
that's
cool
because
you
can
generate
your
event
catalog,
but
also
it
will
be
possible
from
studio.
Maybe
yeah.
C
A
You
design
all
your
infra
right
all
how
everything
is
going
to
be
done
and
then
deploy
it
right
like
deploy
to
aws
or
to
confluent
kafka
or
whatever,
whatever
provides
right.
So
that
will
be
super
cool
in
my
opinion,
like
something
super
useful
and
then-
and
not
just
that
like
because
you
have
everything
defined
with
the
same
kpi,
then
after
you
finish
doing
all
the
design
and
deploying,
then
you
can
continue
right.
So
it
goes.
It
will
be
going
both
ways.
A
So
then,
you
update
something
on
aws,
not
on
studio,
but
you
download,
json
gpa
file
and
you
probably
commit
it
to
some
repo,
and
so
things
can
be
revealed.
So
you
know
like
async
pay
can
be
the
glue
there
right.
It
can
be
exactly
the
the
glue
there
in
my
opinion,
so
yeah,
that's
a
good
point,
alexander
thanks
for
commenting.
B
A
A
B
A
B
One
click
deploy
systems
there.
That
would
be
good
yeah.
I
do
I'm,
as
I
said,
I'm
fairly
new-ish
to
the
space.
I
worked
a
lot
in
kind
of
like
synchronous,
stuff
and
mainly
like
a
lot
of
front-end
stuff
in
the
past
building
applications
and
apis
and
various
things
so,
the
last
year
last
two
years,
I
think
I
think
I
think
we've
seen
I
feel
like
we've
seen
a
growth
in
it
right.
I
was
introduced
to
through
it
through
serverless
eda
through
serverless
yeah.
I
don't
I
don't
have.
B
I
don't
have
much
knowledge
about
kafka
clusters.
How
could
how
do
I
manage
kafka
clusters?
I
haven't
got
a
clue
because
that's
kind
of
if
I
felt
like
you
know,
that's
a
completely
different
route
to
what
I
was
into
so
for
me.
You
know.
Where
do
I
see
it
in
five
years?
Where
I
see
it
now
is
the
barrier
I
think
the
barrier
to
entry
is
reducing
yeah.
So
how
can
I
send
an
event
in
amazon
or
google?
Google
will
have
pub
sub
right.
B
So
how
do
I
send
an
event
you
just
kind
of
integrate
with
their
service
and
you
get
it
and
I
think,
there's
huge
benefits
to
having
synchronous
and
asynchronous
architectures.
So
where
do
I
see
it?
I
think
it's
just
going
to
continue
to
grow
right.
I
think
people
are
going
to
continue
to
use
it.
I
think
more
serverless
offerings
are
going
to
come
in
and
I'm
quite
blurry
though,
and
I
serverless
offerings
those
surface
offerings
will
come
and
make
it
easier
in
five
years
time.
I
just
think
it's
yeah,
I
think
it's.
B
I
think
when
you
see
the
business,
what
it
comes
down
to
for
me
anyway,
is
the
business
value
and
it's
the
speed
to
innovation
and
the
speed
to
the
business
value,
and
I
think
I
think
eda
really
helps
that
and
remain
decoupled
at
low
to
scale,
and
I
think
the
message
is
going
to
hone
in
over
the
next
couple
of
years
and
I
think
big
big
companies,
google
amazon,
we
see
upstash
recently
offering
kafka
serverless
solutions
and
it's
kind
of
come
back
to
what
I
said
earlier,
which
is
reduce
the
barrier
to
entry,
reduce
it,
reduce
it
yeah.
B
B
Raised
more
events
and
more
events
and
now
you're
in
the
position
where
you've
got
hundreds
of
events,
and
how
do
you
document
that?
How
do
you
scale
events
and
then
that's
where
racing
kpi
come
in?
You
know
and
all
these
all
these
specifications
that
are
emerging.
So
it's
just
an
interesting
space
to
be
in
it's
yeah.
It
feels
like
it's.
B
It
feels
like
it
just
naturally
feels
right,
some
of
it
so
the
next
five
years.
I
have
no
idea,
but
there
is
a
good
book
on
it.
Actually,
if
you
want,
if
you're
interested
called
around
here
somewhere,
I'm
I'm.
B
This
talks
about
the
future
of
eda
and
if
you
read
it,
it's
interesting
talks
about
just
talks
about
things
like
imagine
the
world
where
we
have
events
going
not
just
around
our
system
but
outside
our
system
and
how
data
you
know.
Data
is
important
to
everyone,
but
also
organizations
and
cross
data
streams,
and
when
you,
when
you
go
to
work
for
companies,
more
and
more
companies
are
interested
in
real-time
data
and
real-time
data
was
events.
But
how
do
you
like,
for
example,
fran?
You
know
if
I
want
to
integrate
with
your
business?
B
B
A
The
yeah:
that's
the
definition
like
it's
going
to
keep
us
like.
Damn
it,
it's
like
everything
is
yet
to
be
built.
So
so
yeah,
that's
a
lot
of
work.
While
you
were
speaking
there
is,
there
was
two
more
comments.
There
were
two
more
comments,
one
from
jonah
saying,
like
one
click
system,
deployment
and
alexander
saying
also,
you
could
compare
your
design
to
the
generated
infrastructure
and
detect
wrong
message
or
other
things
like
you
know
what
I
like
about
this
like
this
is
really
thinking
out
loud.
What
we're
doing
here!
A
This
is
really
thinking
out
loud,
like
we're
thinking
in
public,
and
we
have
the
people
joining
us
to
think
in
public,
and
I
think
that's
awesome
so
yeah
before
we
finish
because
we're
already
over
an
hour.
So,
let's,
let's
start
packing
already.
A
I
wanted
to
ask
you
like.
A
What
tool
or
what
thing?
Let's
say:
that's
it
yeah!
Let's
just
stick
to
the
tool:
what
tool
do
you
think
we
should
be
building
next
or
improving
like
what's
your
or
like
top
priority
that
you
need?
You
need
it
now.
B
B
I
would
say
literally
what
we
spoke
about
earlier,
which
is
just
make
if
we
can
make
eda
easier
to
to
deal
with
and
to
integrate
with
and
to
understand,
free,
tooling,
that's
where
we
should
focus
right
and
like
maybe
that
is
just
sending
a
test
payload
to
a
bus
or
listening
in
to
to
event
streams
or
different
ways
to
visualize
stuff.
B
I
think
that's
that
yeah.
I
think
for
me.
If
I
had
to
pick
one
it'd
be
more
different
ways
to
visualize
this
stuff,
so
you
know,
for
example,
you
know
a
quick
example
like
open
api.
I've
not
done
I've,
not
looked
too
much
at
the
tools
in
that.
But
when
you
look
at
standard
open
api
document,
it
has
standard
document
right.
You
have
the
puts
and
the
gets
whatever
else,
but
you
know
I
want
to
see
what
I
want
to
understand.
What's
the
next
evolution
of
that,
I
want
to
say,
okay,
what
else?
B
B
Why
can't
we,
as
I
said
to
you
earlier,
I
have
real
events
going
down
a
river
on
the
screen
or
something
I
don't
know.
You
know
this
is
where
you
know.
That's,
that's.
That's
the
stuff
that
gets
me
excited
is
just
bridging
the
gap.
I
think
there's
a
lot
of
value
to
be
had
and
I
think
tools
can
help
people,
so
we've
got
to
understand
where
to
focus
but
yeah.
I
don't
know
if
I
answered
that
question,
but
yeah.
A
A
Yeah,
I
think
so
things
of
what
we
can
do.
I
I
I
agree
with
that.
So
thanks
mate,
it's
been
like
really
cool
thanks
a
lot
for
joining
me
today.
A
Yeah,
I
hope
you
enjoyed
this
and
I
hope
the
audience
also
enjoyed
it.
We'll
keep
working
on
this
on
thinking
out
loud
and
async
api
only
event,
catalog
on
anything
that
pushes
us
towards
this
future
of
event,
driven
architectures
for
sure
and
and
yeah
before
I
before
I
we
say
goodbye.
A
I
would
love
to
to
mention
that
next
week,
at
the
same
time,
wednesday
same
time
right,
we'll
I'll
be
hosting
I'll,
be
having
around
the
big
and
only
the
one
and
only
lukas
gornicki
with
us
right.
So
so
you
probably
have
heard
about
lucas
from
our
community
and
and
yeah.
A
So
don't
miss
this
episode
as
well,
because
we're
going
to
be
discussing
stuff
and
thinking
out
loud
about
how
to
improve
our
community
and
and
how
to
make
our
community
grow
as
well,
but
not
just
in
growing
numbers
but
growing
quality
and
and
so
on.
Right.
So
so,
yeah
thanks
a
lot
everyone
for
watching
and
for
participating
and
see
you
next
week,
cool
cheers.