►
From YouTube: Knative March Community Meetup/ The magic of Knative In and Event Driven Application by Gabriel F.
Description
The magic of Knative In and Event Driven Application
Testing apps locally is easy, but migrating to production ready scenarios is a different picture. Come see Gabriel using Knative + React + Knative for developing a ready-to-deploy Web Chat application
A
I'm
going
to
exp
talk
about
a
little
bit
the
magic
of
gay
native
in
an
event-driven
architecture.
So
a
little
bit
about
me.
This
also
said
the
most
part
of
this.
I'm
gabriel
freitas,
I'm
a
computer
engineer
from
venezuela,
I'm
currently
working
at
vmware
as
a
member
of
the
technical
softree
and
my
twitter
handle
is
gabby.
If
you
want
to
talk
about
anything
that
I
talk
here
in
this
chat,
so
welcome
all
so
in
this
chat
we
are
going
to
see
what
is
an
event
driven
architecture.
A
How
does
k
native
and
other
open
source
tools
can
help
us
to
build
it,
because,
starting
with
an
even
driver
architecture
and
with
cluster
kind
of
development
is
not
always
easy,
so
it's
a
good
way
to
start
since
I'm
also
starting
in
this
world.
I
have
like
10
or
8
months
or
so
working
with
gay
native
and
all
of
the
ecosystems.
A
That
is
the
event
source
that
is
going
to
communicate
with
with
your
application,
you
have
generally
some
kind
of
event
broker
and
even
broker
is
an
intermediary
software
that
gets
event
per
system
and
make
sure
to
send
them
to
the
ms
consumer
and
the
advanced
consumer.
The
other
consumer
is
any
application
that
is
consumed
from
that
kind
of
events.
A
So
as
here
you
can
see
it's
clear
that
you
have
like
a
pathway
like
a
pipeline
from
the
event
producer
to
each
even
consumer,
so
this
path
generally
generally
are
micro
services
that
consume
these
events
and
react
to
them.
So
it's
pretty
easy
and
pretty
straightforward
to
like
separate
the
microservices
on
each
event
pipeline.
So
you
can
process
individual
events
in
each
microservice
and
we
will
see
how
to
do
kind
of
that
with
a
with
a
pet
project
that
I
have
on
github,
I'm
going
to
share
the
code
at
the
end
of
the
presentation.
A
So
let's
begin,
what
tools
am
I
using
I'm
using
also
all
open
source
tools
or
they
are
free?
They
you
can
install
it
locally
and
they
also
simulate
pretty
pretty
good
cluster
environments.
So
I'm
using
golang
the
open
source
glow
language
go
a
tool
that
does
not
require
a
docker
to
build
golden
images
in
a
closer
environment,
I'm
using
khan
that
is
kubernetes
in
docker.
I'm
cheating
right
here,
because
I
wanted
to
avoid
docker,
but
for
the
presentation
I
use
the
docker
tool
to
run
with,
can
and
can
simulate
local
clusters
using
docker
nodes
react.
A
A
So
the
the
reason
that
I
choose,
the
chat
architecture
or
a
chat
project
is
because
the
chat
can
be
as
simple
or
as
complicated
as
you
can.
You
can
possibly
imagine
this
is
like
the
let's
start
of
the
project
I
wanted
to.
Do.
I
always
want
to
learn,
learn
things,
and
the
best
approach
that
I
have
found
is
to
build
a
chat
while,
while
learning
that
stuff,
so
I
was
learning
golang,
I
was
learning
kurnetis
and
I
was
learning
key
native
and
web
sockets.
A
So
the
best
way
that
I
I
thought
was
like,
let's
with
this
pep
project,
to
be
a
column
based
chat,
I
I
already
knew
react.
So
that
was
the
easy
part,
but
connecting
all
together
was
the
the
challenge.
The
real
challenge,
so
basically
the
server
is
calling
is
communicating,
is
serving
a
react-build
application
for
them
and
is
communicating
between
the
front-end
and
the
back-end
using
web
sockets.
A
So
this
is
the
base.
This
is
like
where
I
started,
and
this
is
basically
what
he's
doing
the
servers.
Listen
for
external
cloud
events.
I
will
explain
what
cloud
events
are
in
the
next
slides
the
server,
then
listen
for
incoming
local
websocket
connections
and
all
messages
and
communication
and
including
red
format.
So
I
can
react
practically
the
same
to
local
communication
cloud
events
as
to
external,
send
clients.
So,
let's
see
a
little
bit
more,
I
define
my
event.
Taxonomy,
basically,
is
the
events
that
I
consider
are
enough
to
run
the
application.
A
In
this
case
we
have
the
event
source.
That
is
the
application
to
know
that
the
events
are
coming
from
from
my
chat
application.
Then
we
have
this
event:
feature
connection
user,
reconnected,
new
user,
connected
user,
disconnected
message
from
user,
get
users
external
users
and
get
connected
users.
So
that's
basically
what
I
needed
to
build
the
application.
A
So
why
I'm
doing
this
talk
is
because
kubernetes
was
hard.
Really
is
something
that
is
not
as
simple
as
front-end
or
back-end
normally
is
to
learn.
So
there
is
a
first
first
step
learning
curve
and
this
stock
is
aiming
for
you
or
for
the
new
developers
to
know
how
to
deploy,
build
things
and
start
breaking
things
locally
because
k
natives
level.
A
Some
of
those
first
steps,
but
canadian
is
still
hard
has
a
lot
of
things
that
you
have
to
discover
and
to
get
into
to
really
know
what
is
happening
underneath
and
also
clusters
cost
money,
and
maybe
not
all
the
companies
or
developers
are
willing
to
pay
money
or
to
break
something
and
get
the
aws
surprise.
Billing
party,
that
is
a
little
not
so
pleasant
surprise.
So
testing
locally
is
key
for
getting
new
developers
and
this
chat.
A
This
talk
is
aiming
to
new
developers
like
to
know
how
to
build
their
ecosystems
and,
from
this
start
point
go
on
and
on
and
on
so
for
this,
I'm
going
to
present
the
first
demo.
Here's
a
little
demo
to
show
a
little
bit
of
the
project
structure,
run
the
project
locally,
using
kind
on
a
local
cluster,
using
code
to
build
the
images
and
test
the
chat
in
a
single
instance
scenario,
because
after
this
demo,
I'm
going
to
complete
a
little
bit
more
things
and
we're
going
to
build
something
interesting
using
the
event
driven
application.
A
So
here
is
basically
the
code.
It's
a
simple
go
repo
that
I'm
sharing
the
end
of
the
slides
as
a
link
where
you
have
an
entry
point
domain,
where
you
start
getting
the
variables
you
serve
http.
You
start
listening
for
cloud
events.
We
are
using
here
cloud
events
and
packages
and
libraries
to
help
us
with
with
all
of
the
configuration,
and
basically
here
we
have
a
web
part
of
the
of
the
project.
A
A
That
is
basically
here
that
are
the
static,
json
and
javascript
files
to
render
the
front
end
nothing
too
interesting
there,
and
basically
here,
is
where
all
the
magic
happens.
We
have
the
controller
where
we
start
like
using
the
basic
golang
listeners
and
handlers
of
the
http
server
and
the
clients
and
servers.
Also,
here
we
serve
the
front
end,
and
here
we
are
listening
for
glory
events,
and
if
you
can
see
yes,
I
have
to
refactor,
but
basically
we're
seeing
okay.
This
is
the
time
of
the
event.
A
Then
we
do
something
with
it
and
in
this
we
are
handling
the
websocket
cloud
events
in
the
same
manner.
This
is
a
little
bit
more
organized,
so
we
process
the
messages
we
center
events
create
and
react
cloud
events,
that's
basically
so,
let's
first
this,
you
can
watch
it
a
little
bit
more
closely
after
the
meeting,
so
we,
let's
start
with
the
with
the
samples,
basically
we're
going
to
run
this
single
instance
example
where
we
are
using
a
namespace
we're
using
time.
A
I
miss
like
a
cluster
simulator
for
local
clustering
docker
using
docker
nodes,
as
I
said
so.
I
have
already
created
a
cluster
named
k
native
as
I'm
running
here
with
all
the
native
dependencies
already
installed,
and
I'm
going
to
create
this
service.
That
is
our
application
using
go.
Go
is
a
image
builder
image
container
builder
that
works
with
golan
without
needing
a
docker
or
any
image
running
container
environment
to
work
anything
to
work.
So
we
are
just
saying
this
like
this
is
the
package.
This
is
the
the
tier
that
I,
that
is
the
entry
point.
A
I
want
you
to
build
this
in
these
this
cluster,
so
we
set
all
docker
repo,
it's
kind
of
local
co
work,
go
works
with
kind
pretty
well,
so
we
have
its
own
like
key
values
to
make
it
work
with
the
local
gang
cluster
and
finally,
the
kind
cluster
name
that,
as
we
saw,
is
native
so
to
build.
The
application
is
as
simple
as
go
apply,
samples
and
single
instance,
and
it's
going
to
build
the
namespace
and
the
chat
service.
A
This
is
without
needing
docker,
I'm
using
docker,
I'm
cheating,
as
I
say,
as
I
told
you,
because
I'm
using
the
docker
desktop
to
run
kind,
but
this
is
this
can
run
with
without
this
and
without
any
docker
tools
installed
on
your
computer.
So
let's
wait
for
it
to
build
and
we
will
see
no
notes,
only
closer
kind,
probably
export
game
cluster
name,
k
native.
That
was
my
bad.
A
A
The
service
that
has
been
created,
as
we
can
see,
we
have
I've,
cheated
a
little
bit
because
I
already
created
some
of
the
resources
that
I
need
to
have
ready
for
the
next
example.
But
this
is
the
thing
that
we
created.
We
have
the
namespace
that
is
single
demo
demo,
and
we
have
here
the
that
k
native
created
for
us,
the
routes
and
all
of
the
services
needed
to
expose
the
application.
This
is
basically
the
chat
application.
It's
a
simple
chat.
A
What's
up,
and
here
is
like
the
login,
where
I
can
log
in,
as
god
was
myself
and
start
chatting
with
me
if
I
wanted,
or
with
anyone
that
have
the
same
link,
let's
try
with
another
login,
okay
native,
as
you
can
see,
it's
c
is
like
I'm
connected,
so
I
can
send
unless
it
took
out,
and
if
I
go
to
the
other
tap,
I
can
see
that.
Can
you
talk
to
me
and
I
can
talk
to
katie
as
simple
as
that.
A
That
is,
we
will
see
that
it's
practically
a
real
cluster
environment
with
all
of
the
caveats
that
it
can
have
so
now
that
we
have
this
running,
let's
complicate
a
little
bit,
because
this
is
a
basic
chat
project
and
I
say,
as
I
told
you
I
can
complicate
or
we
can
complicate
the
chat
as
much
as
we
want.
So
when
we
have
a
single
instance
is
pretty
easy
because
all
the
connections
are
handed
by
the
same
server.
One
connection
is
leaving
there
and
the
service
is
serving
as
an
intermediary
between
client,
one
two
or
three.
A
So,
okay,
let's
go
to
the
tools
decision,
as
I
said
before,
I'm
going
to
to
complicate
things
a
little
bit
so
for
that
I'm
going
to
use
kinetic
certain
for
the
auto
scaling,
because
now
we're
going
to
have
multiple
instances
of
the
of
the
front
end
running
and
we're
going
to
use
eventing
for
this
communication
disk
class.
This
cloud
with
a
question
mark
in
there
is
going
to
have
kafka
rabbitmq
or
any
other
message
queue
that
you
want
to
use.
We
are
going
to
use
cloud
event
for
communications.
A
Our
events
is
an
open
forum
for
communicating
with,
but
okay,
I
choose
cloud
events
for
communicating
between
instances
of
the
application
cloud.
Events
are
an
open
standard
that
has
been
developed
for
exactly
that,
because
it's
easier
to
communicate
between
cloud
systems.
If
you
had
a
like
a
general
or
a
common
standard
and
protocol
to
communicate
between
them
and
the
other
tools,
I
already
told
you
I'm
using
react
for
the
front
end
column
for
the
backend
and
go
for
building
images.
A
Okay,
let's
see
global
and
local
events
now
that
we
are
like
dealing
with
local
instances
or
connection
between
websockets
in
the
same
separate
instance
and
new
instances
that
can
be
in
other
namespaces
other
clusters
or
any
other
event.
That
is
consuming
our
our
events.
Now
we
need
to
know
that
we
are
using
global
and
local
events.
The
local
events
are
basically
events
that
enter
via
websocket
and
don't
leave
the
current
instance
and
global
events
are
events
that
are
coming
from
other
instances
of
the
chat
to
our
intent.
A
A
A
Let's
see
a
little
bit
more.
For
this
example,
I'm
going
to
also
use
the
one
of
the
benefits
of
the
event
driven
architecture.
You
can
like
extend
your
application
pretty
easily.
We
are
going
to
extend
the
application
by
creating
another
trigger
that
is
going
to
forward
the
events
on
the
broker
to
a
service
called
sokai.
This
service
is
a
service
that
lets.
A
A
It
could
be
seen
like
a
different
cluster
or
basically
we're
communicating
with
different
instances
there
and
we're
going
to
test
communication
between
instances
using
brokers
and
triggers
and
after
that,
we're
going
to
test
just
how
easy
it
is
to
deploy
a
k
native
application
on
a
glass,
a
real
gigantic
glossary.
Okay.
So
let's
go
here
now.
A
Let
me
build
the
chat.
As
I
told
you,
I
did
a
little
bit
of
cheating
because
I
created
some
of
the
resources
listed
here.
Basically,
we
need
a
rapid
mq
cluster
in
we're
using
a
general
instance.
We
need
the
brokers
to
be
ready
before
the
chat
is
ready,
so
the
messages
can
arrive
there
and
don't
get
lost
on
the
way.
So
I
created
this
broker
and
this
broker
on
the
default
namespace
and
I
created
the
sync.
So,
let's
see
yeah
at
least
k
native
service
that
we
got
here,
we
had
sokai.
A
A
As
I
told
you,
this
chat
demo
should
send
cloud
events
to
the
default
default
demo
broker
that
is
already
created,
so
this
chat
demo
should
not
see
any
events
because
they
are
local
events
for
him
in
its
own
broker
or
in
its
own
society
instance,
but
the
other
broker
and
the
other
soccer
instance
should
see
these
chat.
Demo
events:
let's
try
that,
with
the
chat
service.
A
And
if
we
can
see
when
this
is
going
to
be
ready,
we
are
going
to
see
events
on
the
default
entries.
If
we,
if
we
recall
we
are
creating
the
the
chat
on
the
chat
demo
and
name
says,
I'm
doing
this
step
by
step
for
it
to
be
clear
what
is
happening
on
on
all
these-
and
this
is
still
using
kind
local
after
that,
I'm
going
to
be
using
a
gk
cluster
that
I
have
created.
So
basically,
this
is
created
now
for
at
least
the
k
native
services
in
the
chat
demo
namespace
I
have
soca.
A
A
So
it
tells
you
okay,
this
event
is
called
get
users
from
other
cluster
broker,
but
we
right
now
don't
have
any
other
instance
of
the
of
the
chat
up
ready.
So
if
I
connect
a
scale
here,
I
just
see
myself,
because
I
just
have
this
chat
demo
instance,
I
can
connect
a
screen
native
here
and
I
see
me
and
gao
in
the
same
in
the
same
name
space
if
I
go
to
the
default
name,
space
not
ready
yet
because
because
I
haven't
created
the
app,
so
let's
create
the
app
this
time
on
the
default
namespace.
A
So
in
the
sample
default,
namespace
400
chat
service.
Let's
wait
for
it
to
run
a
good
like
a
hint
when
it's
ready
is
because
we
are
going
to
get
the
same,
get
user
event
on
the
others.
Okay,
in
this
case,
we
are
also
sending
events
of
new
user
connected
to
the
other
broker
when
we
and
new
users
is
getting
connected
on
the
chat
demo
namespace.
A
Let's
wait
for
this
to
create
and
we
will
see
we
will
start
seeing
even
getting
here,
basically
with
get
we're
seeing
they
get
users,
so
the
application
is
already
up,
and
here
we
see
that
we
are
sending
this
message-
that
okay,
k,
native
and
gabo
are
connected
on
the
other
broker.
That
is
the
response
for
the
default
for
the
chat
demo
namespace
application
instance.
A
So
now,
if
I
go
here
in
the
default
namespace
and
I
reload-
I
see
that
the
chat
app
is
already
running,
and
here
I
can
test
it
and
I'm
seeing
users
from
other
instances
of
the
application.
So
I
can
chat
with
myself
in
this
case
hey
in
the
same
name
space,
and
I
can
chat
with
cal
in
another
another
namespace.
So
and
if
I
go
to
gabo's
chat,
I
will
see
test
in
the
other
namespace
tommyhegalo,
yes
and
yep.
That's
basically
it.
A
We
are
communicating
right
now
between
multiple
instances
using
brokers
and
triggers,
and
we
also
expanded
the
application
for
it
to
be
capable
to.
We
are
now
capable
to
see
all
the
events
that
are
getting
like
sent
between
namespace
brokers
and
triggers.
So
after
that,
the
only
thing
left
is.
Let
me
show
you
what
I
have
here:
ucl
config.
A
A
A
A
We
are
translating
for
our
local
environment
to
a
real
cluster
environment,
so
we
could
have
been
testing
the
fernand,
for
example,
in
in
local,
and
now
we
are
saying
like
okay.
Let
me
test
it
in
a
kind
of
production
environment.
It's
really
there's
nothing
too
different
from
what
I
was
doing
locally
and
I
was
doing
here.
But
now,
let's
see
that
worked
now
we
have
a
ready
revision
and
I
have
a
chance.