►
From YouTube: Catalog your Events with AsyncAPI - David Boyne, AWS
Description
AsyncAPI Conference 2022 - Day 3
5th November 2022
Event Driven Architectures is growing, the usecases are rising and technology is making EDA applications more and more accessible. Businesses around the world are building decoupled, evolutionary based architectures that are providing huge value to organisations. The AsyncAPI spec is a great way to standarise the way we document our events, publishers, subscribers and brokers. This standard allows us to create tooling and new experiences for engineers. Discovering and documenting events always seems like an after thought, but we can a new mindset emerging and the importance of event governance and documentation. In this talk, David will be sharing with you tooling he has wrote around AsyncAPI and ways you can create Catalogs for your Events, Services, Domains using your AsyncAPI files. David will be talking you through EventCatalog, how to get started and setup with your AsyncAPI files.
A
Hello:
everyone
async
kpi
conference.
My
name
is
Dave
Bowen
and
thank
you
for
having
me
today
and
kind
of
watching
this
for
the
next
half
an
hour.
What
I'm
going
to
be
talking
about
is
cataloging
your
events
with
async
kpi,
what
do
I
mean
by
cataloging
and
and
documentation,
and
that's
exactly
what
we're
going
to
be
diving
in
to
today.
So
here's
a
quick
agenda
for
you,
but
we'll
be
looking
at
we'll,
be
diving
into
some
initial
problems.
A
Actually
that
you'll
see
what
I
see
in
the
community
kind
of
talk
about,
and
problems
I've
had
in
the
past,
with
the
initial
setup
of
event-driven
architectures
and
the
problems
you
start
to
see
and
emerge
as
time
goes
on.
So
before
we
dive
in
now
I'm
going
to
introduce
you
to
myself,
my
name
is
Dave
Boyne.
You
can
find
me
on
Twitter
at
boyne123
I'm,
a
senior
developer
Advocate
at
AWS
focused
on
serverless,
Technologies
and
also
event
driven
architectures
I'm,
a
father
of
two.
A
So
you
might
hear
them
scream
in
this
video
how
they
are
in
the
house
and
so
listen
out
for
that
ex-guitar
player
and
previously
before
AWS
I
was
working
in
open
source
full
time
actually
part
of
the
async
kpi
team
for
a
while
and
before
that,
working
in
startups
and
some
large
organizations
mainly
focused
around
tooling
developer
experiences
and
all
sorts
of
things.
I
also
enjoy
kind
of
writing,
open
source
software
and
tools
for
developers
and
focusing
on
event-driven
architectures.
A
So,
let's
dive
into
this
talk
and
talk
about
the
problems
of
the
vent,
driven
architectures
beyond
that
initial
setup
and
things
that
you
might
see-
and
maybe
some
of
these
things
might
resonate
with
you
unless,
as
you
look
around
in
the
community
at
the
moment,
you
can
see.
Actually
the
adoption
of
Avenger
of
an
architecture
is
growing
right.
More
and
more
people
are
using
it
more
and
more
solutions
are
being
developed
with
a
kind
of
this
event,
architecture
in
mind
and
when
you
start
diving
into
the
reasons.
A
Why
is
because
I
believe
technology
is
just
making
it
more
accessible
right?
The
adventure
of
an
architect
has
actually
been
around
for
decades,
so
it's
about
the
technology
and
how
that's
helping
us
do
that,
and
if
we
just
have
a
look
at
some
AWS
Services
as
an
example.
Here
you
know
we
have
things
like
Amazon
eventbridge,
which
is
a
serverless
event,
bus
which
allows
us
to
send
and
receive
events
and
map
them
up
to
other
serverless
kind
of
Technologies
there.
A
We
have
kind
of
Step
functions
that
are
out
to
the
orchestrate
some
workflow
based
on
events
and
even
things
like
Lambda
right,
which
allow
us
to
kind
of
do
some
compute,
based
on
based
on
events.
Funny
enough.
So
you
know
the
the
event.
Architectures
themselves
are
actually
becoming
more
and
more
accessible,
and
then,
when
we
start
looking
at
the
benefits
of
event
architectures,
you
start
seeing
these
kind
of
words
come
up.
You
know
we.
A
We
aim
to
have
Loosely
coupled
systems,
especially
in
this
kind
of
microservices
architecture,
especially
as
we
have
different
teams
doing
different
stuff
event.
Architectures
allow
us
to
kind
of
produce
these
events
and
consume
them
in
different
teams
and
process
them
in
different
ways
right
and
have
this
Loosely.
Coupled
systems
that
allows
us
to
have
this
extensibility,
which
allows
us
to
have
consumers,
come
and
go
as
time
goes
on,
so
as
requirements
change
in
our
organization,
we
can
change
who's,
listening
or
add
more
listeners
and
do
more
and
more
things
and
event.
A
Architectures
just
really
really
help
us
from
just
from
my
own
experience.
You
know
it
just
help
us
get
there
and
then,
when
you
start
getting
into
that
kind
of
flow,
you
start
seeing
this
agility
arise,
which
is
you
know
we
need
to
do
X
when
y
happens.
Well,
if
we
are,
we
are
already
already
publishing.
Why?
Then
we
can
just
do
the
X
anyway,
because
we
because
there's
no
work
that
needs
to
be
done
there
and,
as
you
add
events,
and
you
start
designing
your
architecture
in
this
particular
way.
A
You
start
to
see
this
kind
of
agility
that
emerges
now.
What
tends
to
happen
is
once
you
go
beyond
that
initial
setup
of
your
event.
Architectures,
you
start
to
see
some
weird
kind
of
problems
emerge
right
and
normally
it's
not
around
the
technology,
but
more
around
kind
of
behaviors
and
and
people
in
general.
Really.
To
be
honest,
you
start
to
kind
of
question.
A
Here
we
have
coupling
services
with
events,
so
even
the
event
design
itself
can
actually
couple
you
to
your
producers
without
you,
even
knowing
lack
of
governance
and
standards
as
time
goes
on,
should
you
be
thinking
about
your
event,
design
and
the
impacts
that
actually
has
on
your
organization
even
to
the
point
of
the
the
event
naming
itself
the
unclear
event
in
10?
What
is
the
name
of
our
events?
Are
they
past
tense?
Are
they
things
that
have
happened?
Is
it
very?
Is
it
clear
what
we're
looking
at
exposed
domain
domain
information?
A
Are
you
exposing
too
much
integration
or
internal
information
within
a
particular
kind
of
bounded
context
or
a
particular
service?
Should
you
be
exposing?
What
kind
of
domain
information
should
you
Expose
and
where's
the
line
there?
Finally,
things
like
you
know
focusing
on
implementation
details
rather
than
the
behavior
of
your
system.
Looking
at
the
events
and
things
like
event
storming,
there
can
help
now,
when
you
start
diving
into
event
architectures
and
you
start
reading
books
or
white
papers
or
whatever
it
might
be.
A
You
start
seeing
the
I
started
to
see
this
term
arise,
which
is
producers
should
not
know
about
consumers
and,
although
that's
kind
of
true
technically
you
know,
we
want
to
create
this
decoupled
architectures.
What
I
believe
happens
you
know,
is
we
take
this
too
literally,
and
what
happens
over
time?
Is
you
start
to
ask
you
yourself
who
is
producing
what,
especially
if
we
have
hundreds
and
hundreds
of
events
and
we've
scaled
this
out
in
our
organization?
You
want
to
know
some
basic
stuff
who
is
producing
what
event?
A
What
version
of
the
event
are
they
producing?
Who
can
I
contact?
Who
owns
this
event?
What
is
you
know
what
information
and
context
around
this
event?
Why
was
this
event
created?
It
could
have
been
created
two
years
ago
as
an
example.
So,
as
you
start
to
look
and
come
into
these
issues,
you
start
to
look
and
wonder:
is
there
any
kind
of
event
driven
documentation
that
can
help
us
solve
these
initial
issues
and
these
problems
that
we
have
now?
A
Luckily
for
us,
you
know
this
is
why
we're
all
here
at
the
conference
is
that
and
we
have
the
async
API
specification,
which
is
great.
It
allows
us
to
kind
of
document.
The
producers
and
consumers
are
using
various
different
kind
of
protocols
and
document
our
channels
and
be
able
to
have
a
place
where
we
can
actually
say.
Okay,
here
is
my
service,
and
this
is
what
you
can
do
to
it
as
a
producer
or
a
consumer.
This
is
the
kind
of
stuff
that
it's
work.
This
kind
of
stuff
is
doing
now.
A
The
best
thing
about
this
kind
of
specifications
and
standards
in
general
is.
We
can
actually
create
Tools
around
the
specification
to
help
us
get
to
that
next
level
of
documentation
on
our
next
level
of
like
CLI
tools
or
whatever
it
might
be,
and
that's
what
I'm
going
to
talk
about
next
is
introducing
event
catalog
and
what
is
event
catalog
now
to
explain
this.
A
Now,
over
the
past
few
years,
I've
been
diving
into
event,
architectures
reading
books,
experimenting
playing
and
developing
tools
and
all
sorts
of
stuff
and
I
come
across
this
book,
in
particular,
recommended
to
me
actually
and
by
James
urquhart,
which
is
called
flow.
Architectures
now
James
looks
into
kind
of
the
future
of
event
streaming
and
event-driven
Integrations
within
our
organizations,
and,
if
you
think
about
this
for
a
minute,
you
think
about
data
and
cross-boundary
data
within
your
organization.
We
are
always
integrating
with
third-party
providers.
A
And
how
do
you
get
access?
Well,
obviously,
if
I
can
just
subscribe
to
a
stream
of
data
rather
than
setting
up
all
this
stuff
all
the
time
this
integration
and
testing
and
the
things
we
have
to
do
but
anyway,
but
a
part
in
particular
in
this
book
that
really
stood
out
to
me
was
this
worldly
map
and,
as
you
can
see
here,
I've
highlighted
on
the
left.
A
Is
this
discovery
phase
discovery
of
producer
and
consumer
and
the
need
for
that
and
where
that
is
along
this
whole
life
cycle,
and
because
it's
on
the
left,
it's
kind
of
indicating
that
this
discovery
phase
still
kind
of
needs
more
work,
and
it's
not
really
ready
for
us
to
kind
of
move
along
in
that
sense.
So
it
kind
of
just
got
me
really
thinking
about.
A
I
come
across
Fran
Fran
Mendes
on
on
Twitter
right
and
he
was
like
so
I
was
building
a
tool
and
he
was
like
Hey
would
be
cool
if
you
could
integrate
a
base
in
kpi
I
was
like
what's
asyn
kpi
and
I've
come
across.
You
know
the
async
API
specification,
which
is
great.
It
literally
solves
a
lot
of
the
problems
and
things
that
I've
been
thinking
about
and
things
that
I
kind
of
want
to
want
to
use
and
want
to
explore
more.
A
You
know
the
ability
to
document
the
producers
and
consumers
the
ability
to
go
somewhere
and
see
exactly
what
this
application
is
doing
from
an
event
driven
point
of
view
and
as
I
mentioned
the
great
thing
about
the
specification,
it
allows
us
to
write
tools
and
kind
of
see
what
else
is
possible.
So
I
started
to
look
at
some
tools
and
build
some
open
source
documentation
tools
that
kind
of
really
resonated
with
the
community
and
people
online.
A
That
allows
you
to
take
like
schemas
or
schema
Registries,
for
example,
with
eventbridge
and
generate
some
documentation
for
you,
some
static
content
where
you
can
go
and
host
these
things
and
kind
of
read
and
kind
of
document.
Your
schemas
to
the
next
level
and
I
also
integrate
this
with
async
API,
which
takes
your
far
and
and
transforms
it
into
some
kind
of
101
documentation
and
static
website
as
an
experiment
and
as
I
started.
A
Exploring
this
more
and
more
people
kind
of
found,
it
useful,
which
I
found
very
interesting,
which
kind
of
map
to
that
the
whole
Discovery
phase
of
event
driven
architectures
and
that
need
to
have
something
there
to
help
these
organizations
scale.
Their
adventure
of
an
architecture
is,
in
general,
really
and
as
I
focus
on
on
these
tools
and
focus
on
kind
of
Open.
Source
Tools
in
general
I
spend
a
lot
of
time
diving
into
what
is
a
successful,
open
source
tool.
A
Look
like,
and
it's
kind
of
a
lot
of
emphasis
goes
around
documentation
of
the
tool
itself,
but
also
the
developer.
Experience
that
you
have
and
when
I
start
thinking
about
how
people
make
websites
and
that
experience
with
markdown
files
and
also
MDX
files
which
allow
us
to
have
components
within
markdown
files
to
allow
us
to
custom
render
things
on
the
screen
I
started.
Thinking
about.
A
Now
what
is
a
van
catalog?
It's
an
open
source
project
that
helps
you
document
your
events,
services
and
now
domains.
It
can
actually
take
your
async
API
file
or
files
that
you
have
and
actually
generate
into
a
static
website
right,
and
you
can
also
the
static
website
will
also
host
mermaid,
diagrams
and
schemas
and
all
sorts
of
things
and
3D
node,
graphs
and
all
and
it
and
integrates
with
async
kpi
as
a
plugin.
A
A
So
here
is
the
async
API
plugin.
This
is
how
it
works.
So
when
you
initiate
an
event
catalog,
you
install
the
plugin
and
you
pull
it
the
path
to
your
async
API
file
and
then,
when
you
run
generate
what
it
will
do
is
it
will
pass
the
file
and
generate
your
events,
your
producers
and
your
consumers.
So
what
I'm
going
to
do
now
is
actually
take
you
through
a
demo.
What
we
will
do
is
create
a
new
catalog.
A
We
will
add
an
async
API
file,
install
the
plugin
and
we'll
generate
our
catalog
form,
our
ancient
kpi
file
and
then
look
into
what
else
we
can
kind
of
do
there.
So
let's
have
a
look
now
and
see
that
in
action,
so
what
we're
going
to
do
now,
we're
in
the
terminal
is
actually
create
our
new
event
catalog,
and
we
do
that
by
running
MPX
at
event.
Catalog
create
event
catalog
at
latest
or
without
the
latest
command.
A
If
you
want
and
then
we're
going
to
call
it
my
catalog
async
API,
and
what
I
do
there
is
when
I
press
return
that
will
kind
of
set
up
the
initial
foundations
of
our
event
catalog.
What
I'll
do
for
this
video
is
kind
of
fast
forward
it
to
take
a
minute
or
two
to
do
that,
and
then
I'll
show
you
how
we,
what
it
looks
like
initially
and
how
we
can
use
an
async
API
file
with
the
plugin
that
we
use
cool.
So
now
what
we're
going
to
do
once?
A
That's
done
is
we're
going
to
go
into
our
18,
kpi
event,
catalog
and
then
we're
going
to
run
npm
run
Dev
to
just
start
it
up
and
see
what
it
initially
looks
like
out
of
the
box.
So,
let's
over
head
over
to
the
browser
great
so
we're
now
in
the
browser-
and
you
can
see
we're
on
Port
3000
and
our
application
is
now
running
and
out
of
the
box,
we
get
some
standard
stuff,
we
get
events,
Services
domains
and
visualizer.
If
we
click
on
them,
we
can
see.
A
A
What
is
this
service
doing?
So
if
we
click
on
the
basket
cervix,
for
example,
we
can
see
the
basket
service
itself
is
actually
publishing
these
three
different
events,
as
we
come
down
here,
we're
using
MDX
components
to
visualize
the
basket
service
and
the
corresponding
events
that
it's
raising
and
also
we
can
provide
some
metadata
inside
of
this
page,
which
is
like
the
repository
link
who
owns
the
event,
and
maybe
we
can
view
it
in
the
visualizer.
A
If
we
head
over
to
viewing
the
visualizer,
this
will
allow
the
visualize
of
our
whole
event
catalog,
and
we
can
start
going
down
here
and
exploring
our
events
and
our
domains.
For
example,
the
basket
service
publishes
this
file
publishes
this
event,
which
is
subscribed
by
the
data
Lake.
We
can
just
start
using
markdown
files
to
generate
visualizations
and
documentations
into
event
catalog,
which
is
an
awesome
way
to
kind
of
just
render
some
static
content
around
your
event
driven
applications.
A
So,
let's
take
a
look
at
the
code
and
just
see
exactly
what
it
is
that
we
get
out
of
the
box
before
we
Implement
async,
API
cool,
so
now
we're
over
in
the
code
and
what
happens
outside
the
box.
What
you
get
is
you
get
domains,
folder
events
folder
and
a
Services
folder,
and
all
this
inside
of
those
markdown
files.
So,
as
you
can
see,
we've
got
our
events
and
we
have
an
order
complete
event.
We
have
a
markdown
file
here
and
this
markdown
file.
A
We
have
some
metadata
and
everything
is
documented
online
and
documentation,
but
you
can
say:
okay,
the
name
is
order,
complete.
We
have
a
version.
We
can
put
a
summary
there.
Our
producers
of
these
are
consumers
is
this
service
and
we
have
also
have
some
owners,
and
then
we
can
use
some
custom
MDX
components
that
the
community
has
built
on
top
of
event,
catalog
to
be
able
to
kind
of
render
different
things
inside
of
our
event,
catalog
itself.
A
Now
what
I'm
going
to
do
is
we're
going
to
actually
delete
these
and
I'm
going
to
install
the
async
API
plugin
and
we're
going
to
use
an
async
kpi
file
to
generate
this
document,
this
catalog
ourselves
so
step
one.
What
we'll
do
here
very
quickly
is
just
delete,
domains,
delete
our
events
and
delete
our
services
and
then
what
I'm
going
to
do
is
head
back
over
to
the
terminal
and
we're
going
to
install
the
async
kpi
plugin.
A
Okay,
so
now
we're
here.
What
I'm
going
to
do
is
just
install
the
plugin
for
Ace
and
kpi,
and
we
do
that
by
doing
npm,
install
and
catalog
plugin
generator
async
API.
Let's
go
back
to
the
code
and
set
up
the
async
kpi
plugin
and
the
way
we
do
that
is,
we
go
to
see
event
catalog
config
file,
and
now
we
have
to
actually
install
and
use
the
generator
and
the
way
we
do
that
is.
We
include
the
generators.
A
A
Inside
the
root
of
our
project
and
I'm,
going
to
copy
an
example,
async
API
file
into
here,
so
this
is
using
the
street
lights,
Kafka
API
that
you
can
find
on
the
async
API
project,
an
examples
repo
we're
going
to
use
this
to
generate
our
event.
Catalog,
so
I'm
going
to
do
now
is
go
back
to
the
terminal
and
now
what
we're
going
to
run
is
npm
run
generate.
A
A
So
now,
let's
head
over
to
the
events
folder-
and
we
can
see
here
that
we
have
dim
light,
light,
measured
and
turn
off
light,
which
is
all
version
one
which
is
our
async
API
version.
If
we
click
on
dim
light,
we
get
shown
the
event
itself,
a
commander,
particular
street
light
to
dim
the
lights,
and
if
we
scroll
down,
we
can
see
the
schema,
and
we
can
see
this
nice
diagram
here.
We
can
also
use
event
catalog
to
actually
download
the
schemas
themselves.
A
So
if
we
click
on
that,
it'll
allow
us
to
download
it
locally
to
our
machines.
We
can
also
see
the
producers
here,
so
we
see
the
street
lights
Kafka
apis
the
producer
of
this
particular
event.
So
if
we
go
inside
there
now
we're
in
the
services
folder,
we
can
now
see
the
street
lights
Cafe
API,
which
is
all
documented
for
us
again.
Everything
you
see
here
is
from
the
async
API
file.
A
We
can
see
that
the
AC,
the
API
itself
consumes
this
light
measured
event,
but
also
kind
of
produces
this
dim
light
and
turn
off
event.
We
can
navigate
to
the
events
and
the
producers
over
here
in
the
messages
we
can
also
use
the
visualizer
to
kind
of
scroll
through
the
all
the
events
and
kind
of
visualize
our
whole
landscape.
A
We
can
also
start
using
the
3D
node
graph
as
a
way
to
kind
of
visualize
events
going
to
and
from
this
particular
service.
Now
this
is
great,
but
what
happens
if
we
make
changes
to
our
async
API
file
over
time?
What
happens
to
event
catalog?
Well,
let's
make
some
changes
to
event
catalog
first
and
then
we'll
make
some
changes
to
async
API
and
we'll
see
how
the
two
work
hand
in
hand.
Let's
go
back
over
to
the
code,
and
what
we'll
do
now
is
we'll
make
a
change
to
dim
light
markdown
file.
A
So
maybe
we
want
to
add
some
more
context
here.
This
is
where
event
catalog
can
kind
of
really
help.
You
document
your
event,
driven
architectures
alongside
async
kpi,
for
example,
because
this
is
markdown
we
could
add
any
information
we
want
here.
We
can.
We
could
just
have
a
Hello
World
from
my
dim
light
if
you
are
going
to
use
this,
make
sure
you
follow
the
instructions
found
in
the
project
readme,
whatever
else
it
might
be,
we
can
save
that
and
when
we
go
back
to
the
UI
we'll
see
that
rendered.
A
So,
let's
have
a
quick
look
now,
as
we
navigate
to
dim
light.
We
can
see
here
here
is
our
changes
there.
So
let's
make
some
changes
to
our
async
API
file
and
see
what
happens
so,
let's
head
over
back
to
the
code
in
our
async
API
file,
let's
update
the
version
to
version
1.1.0
and
let's
say
we
want
to
change
dim
light
to
have
some
different
kind
of
summary
commands
of
a
particular
street
light.
Let's
just
say:
let's
have
a
look
at
the
dim
light
payload
and
let's
change
some
stuff
here.
A
Let's
say
the
maximum
is
no
longer
zero
to
100,
but
for
whatever
reason,
as
a
zero
to
a
thousand,
we
save
the
changes
here.
We've
updated
the
version
and
what
we're
going
to
do
now
is
run
generate
again
to
generate
our
new
events
and
what
event
catalog
will
do
with
the
configuration
that
we
set.
It
will
actually
understand
that
the
versions
have
changed
and
it
will
version
the
events
for
us.
So
let's
go
ahead
and
run
this
command
and
then
I'll
go
back
to
the
browser
to
show
you
exactly
what's
happened.
A
So
what
I've
done
here?
I've
run
the
generate
command
again,
which
I
didn't
show
you,
because
it's
just
a
console,
but
what's
happened
here,
is
actually
going
back
to
our
event
and
it's
actually
upped
it
to
version
one
one:
zero.
Now
the
readme
file
hasn't
changed.
It
still
stores
that
information
everything
below
this
line
is
stored,
but
we
regenerate
this
top
bit
using
the
metadata
of
your
event
and
also
what
you
can
do
here
is.
You
can
also
go
back
and
see
previous
versions
of
your
async
kpi
file.
A
So
an
example
here
would
be
dim
light
version
1.00
if
I
click
on
that,
we
can
actually
see
the
old
event
the
old
information,
and
we
actually
get
a
warning
that
we're
currently
looking
at
an
old
version
here
and
the
great
thing
about
this.
We
can
actually
diff
the
changes
and
view
the
changes
using
event
catalog.
So
you
can
see
here.
Schema
version
is
updated
from
one
to
one,
one:
zero
latest
and
even
better.
What
we
can
do
is
we
can
either
change
log
to
this
version
itself.
A
A
We
save
that
we
go
back
to
the
UI
and,
as
you
can
see,
the
change
log
is
now
rendered,
and
this
is
another
way
to
give
developers
and
give
people
in
your
organization
kind
of
just
information
about
why
your
events
are
changing
using
your
async
API
file,
so
another
a
great
addition
there
to
just
help.
You
discover
and
understand
what
is
going
on.
So
the
final
thing
I
want
to
show
you
is
an
addition.
Recent
addition
to
the
event
catalog,
which
is
using
async
API
without
the
plugin.
A
A
Now,
what
I'm
going
to
do
is
put
the
async
copy,
this
async
API
file
and
put
it
inside
this
service.
Now
what
this
component
will
do
is
we'll
render
out
the
ace
and
kpi
file
that's
directly
against
the
service.
So
if
you
have
multiple
services
and
multiple
async
kpi
files,
you
can
start
using
event
catalog
to
render
these
things
side
by
side.
So,
if
I
save
that
I'll
show
you
exactly
what
I
mean
when
we
go
back
to
the
browser.
A
So
now,
if
we
click
on
services
at
the
top,
we
will
see
my
service,
the
one
we
just
created
and
if
we
click
on
this,
he
will
show
us
that
our
new
service,
my
our
demo
service,
what
we
just
defined
and
what
it
would
do,
is
render
this
async
API
file
for
us
using
that
the
async
kpi
tools
from
the
community.
So
you
can
come
down
here.
You
can
see.
Okay,
here
are
the
servers
I
hear
the
different
types
of
operations,
look
at
the
parameters
and
everything
else
like
that.
A
A
So
that's
a
quick
demo
of
how
you
can
use
async
API
files
and
event
catalog
to
generate
static
content
that
you
can
host
anywhere
for
your
development
teams.
You
can
use
event
catalog
to
document
events,
services
and
domains,
use
your
async
kpi
files
to
help
generate
that.
So
hopefully
you
find
it
useful
and
if
you
want
to
get
started
head
over
to
eventcatalog.dev
and
what
we're
going
to
do
now
is
just
quickly
summarize
what
we
spoke
about
in
this
talk
and
extra
resources
to
help
you
get
started.
A
So,
as
I
said
earlier,
the
adoption
event
adventure
of
an
architecture
has
grown,
we
can
sit
in
the
community.
We
can
see
that
with
the
technology
and
what
it's
allowing
us
to
do
with
kind
of
less
really
within
our
organizations.
Again,
you
can
kind
of
see
this
definitely
in
the
AWS
community,
in
the
serverless
community
using
event
architectures
to
kind
of
boost
their
organizations.
A
Here
when
we
look
at
event
architectures
in
general,
you
kind
of
see
these
kind
of
themes
that
emerge
that
it's
allowing
us
to
do
to
have
a
Loosely
coupled
systems
extend
our
systems
with
this
whole
producer,
consumer
relationship
and
I
can
and
that
itself
provides
agility
to
our
organizations.
But
the
problem
is,
as
I
said
earlier,
that
when
you
go
beyond
that
initial
setup
of
event,
driven
architecture's
problems
really
start
to
emerge
in
more.
A
You
know,
often
than
not
it's
not
really
technical
problems,
although
there
are
some,
don't
get
me
wrong,
it's
more
kind
of
behavioral
problems
or
design
problems
or
architectural
kind
of
problems,
and
don't
worry
you
know,
the
great
thing
is
async.
Api
is
actually
here
to
help
there's
a
great
Community
behind
it
and
great
kind
of
passion
and
drive
that
that
that
comes
from
this
project,
so
I
really
recommend
kind
of
scanning.
A
That's
already
hosted
on
the
website
as
a
demo.
Hopefully
it
can
help
you
in
your
organizations
if
you
want,
if
you
want
to
kind
of,
join
the
communities,
come
and
say
hello
or
we've
got
any
feedback
or
ideas
just
get
involved
on
the
left.
Here
we
have
async
API
slack
channels
so
again
scan
that
code
there
and
sign
up
and
then
on
the
right.
We
have
event
catalog
Discord
channel,
so
you've
got
any
ideas
for
plugins
or
any
ideas
or
features
or
problems.
A
We
have
a
small
community
there
kind
of
really
helping
each
other,
which
is
awesome
to
see
and
kind
of
just
exploring
event
catalog
and
just
seeing
how
it
can
actually
help
your
organizations
kind
of
cross,
this
boundary
of
this
Eda
kind
of
documentation
and
Discovery
kind
of
problems
that
we
have
and
thank
you
so
much
for
listening.
If
you
kind
of
made
it
this
far
and
what
haven't
got
to
the
end,
my
name
is
Dave
Boyd
and
again
you
can
find
me
on
Twitter,
boyne123
and
I
just
want
to.