►
From YouTube: WebAssembly in Kong using WasmX - User Call
Description
Get a technical preview of the upcoming support for WebAssembly in the Kong Gateway leveraging WasmX, a project created by Kong that adds WebAssembly support into Nginx. You will learn:
• WebAssembly and what kinds of multi-language development it allows
• WasmX and how it extends Nginx capabilities to support WebAssembly in a way that is Virtual Machine agnostic
• Proxy-Wasm, the emerging standard for gateway extensions using Wasm, allowing filters to be written once and used in different gateways or meshes that support the format
• How WasmX integrates into the Kong Gateway, enabling the execution of Proxy-Wasm filters as easily as Kong Plugins
A
Hello,
everyone
good
morning,
good
afternoon,
good
evening
from
wherever
you're
joining
us.
My
name
is
Dalia
and
I
work
on
the
developer
marketing
team
here
at
calm,
I'm
very
happy
to
welcome
you
all
to
our
November
user
call.
The
topic
for
today
is
webassembly
in
Kong
using
wazimex.
We
got
a
lot
of
questions
for
this
topic
for
quite
some
time
now,
so
I'm
very
happy
to
have
Hisham
here
who
will
walk
you
through
this
very
interesting
topic?
A
B
Thanks
Dalia
yeah
happy
to
be
here
and
hi.
Everyone
Hisham
and
I've
been
a
Kong
since
2017
we're
working
on
the
K20
team
and
now
I'm
involved
with
the
was
the
next
project.
So
I'm
excited
to
tell
you
all
about
it.
B
This
is
the
next
cool
thing
that
we're
developing
here
at
Kong,
and
so
this
is
a
presentation
that
I
gave
at
Kong
Summit
2022
we've
got
a
lot
of
great
feedback
around
it,
so
yeah,
so
Dahlia
invited
me
to
join
the
user,
call
and
talk
to
your
folks
about
it.
So
yeah,
let's
get
started
if.
A
B
Can
see
my
screen
so
yeah
so
for
this
one
we're
going
to
be
starting
like
from
the
very
beginning
to
make
sure
everyone's
on
the
same
page
I
will
start
with
a
recap
of
what
is
webassembly,
because
there's
a
lot
of
hype
around
it.
There's
a
lot
of
people
talking
about
it
and
like
it's
almost
always
in
the
context
of
web
browsers
and
such
so
like
what
is
it
doing?
You
know
and
the
Gateway.
B
What
does
it
have
to
do
with
Kong,
so
I
hope
to
make
that
connection
clearer
so
and
then
we'll
procedure
with
what
what
is
was
a
Max.
So
all
right
so
like
what
is
the
the
connection
and
how
are
we
approaching
webassembly
in
the
context
of
Kong
and
that
will
be
leveraging
something
called
proxywasm,
which
I
will
tell
you
folks
about
it
as
well
and
explain
what
it
is
and
we'll?
Then
we
will
get
to
how
it
all
fits
together
in
the
Gateway
and
finally,
with
a
very
quick
demo
of
our
Tech
preview.
B
That's
upcoming!
So
that's
a
little
spoiler
for
you
to
Soldier
here
to
the
end
of
the
presentation.
So,
let's
go
bit
by
bit!
So,
let's
start
with
the
beginning
web
assembly,
okay,
the
first
part
that
is
the
virtual
machine
that
we'll
be
using
so
first
super
quick
primer
on
Virtual
machines.
So
what
are
they
like?
Are
they
they
allow
us
to
make
for
extensible
software?
So
we
have
a
program
in
the
case
the
Gateway
and
we'll
run
little
programs
inside
of
the
pro
right.
B
So
this
is
what
happens
in
the
web
browser,
which
is
also
an
extensible
piece
of
software
in
which
we
run
JavaScript
or
scripts
and
in
the
context
of
the
Gateway
we
already
have
that
so
where
in
browsers
you
have
JavaScript
and
the
Gateway.
You
currently
have
Lua
and
then
there's
a
distinction
between
the
language
and
its
implementation,
which
is
something
that's
interesting
to
keep
in
mind
so
for
different
web
browsers.
We
have
different
JavaScript,
VMS,
right,
VM,
V8
and
chrome,
JS,
core
and
Safari
spider,
monkey
and
Firefox,
and
so
on.
B
The
implementation
of
the
lower
language
that
we
use
for
running
plugins
is
lewandt,
so
that
luigit
is
our
VM
for
running
Lua
inside
the
Gateway
right
and
that
the
extensibility
that
we
get
from
that
is
like
all
of
the
plugins
that
that
we
know
and
love,
but
soon
enough,
people
tend
to
find
that
a
single
scripting
language
is
often
not
enough,
and
when
you
start
to
want
to
expand
the
scope
of
what
you
can
do
with
with
a
piece
of
software
like
other
avenues
for
extensibility
start
to
come
up
so
in
the
world
in
the
context
of
web
browsers,
like
as
the
limitations
of
JavaScript,
became
evident
right,
people
started
doing
like
other
add-ons,
like
remember,
Flash,
and
all
that
remember,
Java
applets,
you
know
like
they
become
like
rather
unwieldy
ways
of,
like
you
know,
trying
to
connect
like
additional
VMS
into
the
environment.
B
So
for
the
Gateway
we
we
went
to
a
similar
path
at
one
point
in
time
right
in
which
we
started
experimenting
with
the
idea
of
adding
like
additional
pdks,
where
we
would
run
like
a
plug-in
server.
That
would
add
a
VM
as
a
sidecar.
So,
in
the
end,
it
felt
kind
of
clunky.
It
felt
like
very
similar
to
the
way
that
Java
applets
were
sort
of
bolted
on
into
the
web
browser
and
yeah
and
at
first
the
result
was
not
ideal,
like
as
it
was
not
ideal
for
the
browser
right.
B
So
it
was
a
very
similar
experience,
so
enter
webassembly
right
so
just
like,
when
the
browser
folks
realize
that
that
that
way
of
doing
things,
that
way
of
extending
it
like
with
flash
and
and
Java
like
that,
didn't
work
as
well
as
it
should
so
they
came
up
with
webassembly,
which
was
called
wasm
right.
It
really
appeared
as
like
it.
It
came
along
as
a
you
know,
as
an
alternative
to
JavaScript
right.
So
in
that
sense
we
want
to
have
in
the
in
the
browser
a
virtual
machine.
That's
generic!
B
That's
not
tied
to
a
single
language
right,
so
something
that
supports
multiple
languages
and
the
way
since
that
needed
an
HR
probability
across
browsers
that
has
been
developed
as
an
open
standard,
so
webassembly
itself.
What
it
does.
It
defines
a
binary
code
format
right
like
in
in
Java
parlance.
That
would
be
like
a
bytecode
format
and
a
specification
of
a
virtual
machine.
So
this
is
like
that.
You
need
to
have
like
this
library
that
appears
as
a
virtual
machine.
B
That's
able
to
run
this
binary
code
format
and
no
matter
how
you
compile
and
you
get
to
that
binary
code
format.
That
means
like
whatever
language
you're
using
as
long
as
you
build
to
that
binary
format,
then
you
should
be
able
to
run
that
on
that
virtual
machine
and
then
any
application
like
any
browser
originally
that
it's
able
to
and
that
that
virtual
machine
will
be
able
to
run
that
binary
format.
B
So
that
means
that
you
can
have
several
implementations
and
in
fact,
like
many
of
those
JavaScript
VMS,
they
were
extended
to
become
webassembly
VMS
right
so
because
you
can
pretty
much
reuse
like
all
of
the
backend
and
then
instead
of
a
front
end,
that's
designed
for
compiling
JavaScript.
Instead,
you
make
a
front
end
that
consumes
this
binary
format,
and
then
you
use
an
external
compiler
from
your
favorite
language
to
build
to
that
format,
which
would
be
like
a
DOT
wasm
file
and
that
file
could
then
run
in
the
virtual
machine.
B
So
that's
how
the
whole
webassembly
story
started
in
the
context
of
a
browser.
So
well.
So
if
things
as
soon
as
things
were
built
that
way
like
it
became
possible
for
it
to
to
use
it
in
other
contexts
as
well.
So
that's
what
we're
doing
here.
So
why
webassembly
in
the
context
of
Kong?
B
Well,
because
just
like
browsers
used
it
as
an
alternative
to
JavaScript,
we
can
use
it
as
an
alternative
to
Lua
and
and
then
we
get
like
a
lot
of
the
advantages
that
became
apparent
for
the
browser
they
can
apply
for
us
as
well
right,
starting
with
supporting
multiple
languages,
we
can
leverage
several
different
implementations
as
opposed
to
being
tied
to
a
single
implementation
of
a
virtual
machine
and
plus
then
we
have.
B
We
have
additional
Advantage
is
that
in
that,
for
instance,
web
assembly
and
virtual
machines
were
designed
from
the
get-go
with
very
powerful
sandboxing
capabilities.
After
all,
they
they
need
to
run
in
browsers
right,
and
since
it's
based
on
this
abstracted,
like
binary
format
in
which,
like
any
language,
can
as
long
as
it
builds
to
it,
it
can
run.
It
means
that
we
instead,
we
don't
need
to
implement
multiple
pdks
like
multiple
plug-in
development
kits
and
do
the
whole
integration
of
a
language
one
by
one.
B
As
long
as
soon
as
we
support
webassembly,
and
we
have
integration
of
our
functionality
web
assembly,
then
that
becomes
available
for
every
supported
language.
So
that's
a
very
interesting
proposition
and
that's
why
we
started
looking
at
web
assembly
in
the
context
of
Kong
in
the
context
of
the
Gateway
right.
B
So
all
right
so
now
that
we're
convinced
that
webassembly
is
a
good
idea
for
the
Gateway
okay.
How
do
we
go
about
it
right
so
now
we
need
to
start
talking
about
the
architecture
of
the
gateway
to
understand
how
do
virtual
machine
fit
in
that
scenario,
and
how
would
we
go
about
to
integrating
webassembly
virtual
machine
into
that
right,
so
in
turbozymx,
so
to
get
towards
the
max?
B
We
need
to
start
understanding
the
the
architecture
first
and
the
architecture
of
the
of
Kong
is
that
it
is
built
on
top
of
nginx
and
nginx
itself
is
built
as
a
series
of
modules
right.
You
can
think
of
them
as
the
Lego
bricks
of
your
server
right
and
an
nginx
binary,
which
is
the
things
that
you
know
your
your
con
container
is
ultimately
running.
It's
built
from
several
modules
right
and,
and
you
can,
you
can
build
nginx
by
mixing
and
matching
them
right.
B
So
this
is
this
is
essentially
what
open
resty
is
so
when,
when
we
think
of
an
abstracted
view
of
the
architecture
we
think
about,
we
often
say
that
oh,
we
have
nginx
with
openresti
running
on
top
and
then
Kong
is
built
on
top
of
that.
So
this
is
a
bit
more
of
a
detailed
view
of
how
things
are
are
constructed.
B
So
when
we
get
to
that
point
where
okay,
so
what
is
was
a
Max?
Well,
it's
another
one
of
those
Lego
bricks
right.
It's
an
nginx
module
that
just
like
open,
resty
embeds
the
legit
virtual
machine
was
a
Max
is
an
nginx
module
that
can
embed
a
webassembly
virtual
machine
right.
This
module
is
developed
by
Kong,
it
runs
a
wasn't
VM
inside
nginx
and
and
it
supports
multiple
VMS
right.
B
We
have,
we
have
done
attribution
work
for
supporting
different
VM,
so
at
compilation
time
you
can,
you
can
we
can
choose
which
VM
will
run
in
there.
So
currently
we
support
Verizon
time,
plasmer
and
V8,
which
is
the
virtual
machine
used
in
Google
Chrome.
B
So
there
are
two
parts
to
this,
which
is
one.
Is
that
the
task
of
embedding
the
VM
inside
nginx
and
having
run
that
and
but
then
like
evm
running
along,
like
a
isolated
in
its
little
world?
It's
of
no
use
the
points.
The
whole
point
of
the
integration
is
to
connect
nginx
functionality
into
wasn't
code,
so
exposing
interfaces
so
that
the
wasn't
that
runs
in
there,
like
those
dot,
wasn't
files
that
were
compiled
in
like
your
language
of
choice
and
then
load
it
into
the
VM.
B
So
how
was
Max
fits
into
the
picture?
B
Well,
essentially,
it
is
compiled
into
the
nginx
binary
and
inside
it
you
will
have
a
wasn't
VM,
which
is
compiled
as
a
library
loaded
into
the
wazonex
module
and
ultimately
in
the
in
the
nginx
binary
that
that
will
be
running
itself
and
if
that's
a
bit
of
foreshadowing,
yes,
you
can
run
both
at
the
same
time
and
and
get
an
nginx
binary
which
has
the
open
resting
module
loaded
in
and
it
was
a
next
module
and
having
both
VMS
running
at
the
same
time.
B
That's
the
nature,
that's
the
modular
nature
of
of
nginx
coming
into
play.
B
So
so,
as
I
told
you,
the
first
half
of
the
story
for
was
the
next
release.
The
integration
with
the
VM,
but
just
as
important
is
that
bit
about
how
it
connects
to
Gateway
functionality
right
how
you
can
actually
do
a
network
oriented
things
with
it
and
get
those
apis
available
for
you,
so
the
API
that
is
exposed
for
once
in
code
to
actually
do
useful
things
when
running
inside
was
Max
is
called
proxywasm.
B
So
that's
the
bit
that
we
will
be
looking
at
next,
and
so
it's
always
useful
to
start
thinking
about.
Like
what
is
an
API
anyway
right,
because
so
in
a
sense,
the
API
is
the
developer's
user
interface
right,
it's
okay.
What
do
I
have
available
in
order
to
do
things
right
if
you're
thinking
about
like
a
graphical
program?
Okay,
the
your.
B
Is
like
the
you
know,
the
places
that
you
can
click
the
buttons
that
you
have
like,
so
when
you
can
like
poke
the
application
in
order
to
make
it
two
things.
So
when
you
think
about
a
an
extensibility
platform,
the
way
that
wasn't
Max
is
in
which
okay
I
can
write
code
and
and
load
that
code
in
and
that
code
instead,
like
and
on
its
term,
will
poke
the
application
and
do
things
so
essentially
like
the
way
it
does.
B
That
is
through
the
API,
and
so
in
that
sense
the
API
is
the
user
interface
and
and
when
so,
when
we
think
about
that
user
interface
in
current
com
right.
One
thing
that
we
always
try
to
make
a
point
of
is
that,
like
home
users
shouldn't
have
to
deal
with
those
nginx
like
little
Lego
bricks
directly
right.
B
So
so,
even
though
Kong
runs
on
top
of
nginx
like
yeah,
you
don't
you
can
access
that
if
you
want
to,
but
you
don't
have
to
in
order
to
be
productive,
like
you,
don't
have
to
like
look
at
it
as
a
as
an
nginx
instance
like
you
can
look
at
it
and
see
a
Kong
instance
which
has
like
its
own
configuration,
which
does
everything
that
it
needs
right
and
at
the
same
time,
you
don't
have
to
go
deep
into
open
resting
in
order
to
be
effective
using
call.
B
But
you
can
still
just
look
at
it
and
and
see
like
okay.
These
are
like
Kong,
Lua,
plugins
right
so
and
you
don't
have
to
deal
with
openrest
callbacks
directly.
B
You
can
use
the
Congo
apis
so
and
at
the
same
time,
open
resty
exposes
those
like
very
lower
level,
like
nginx
or
arrest
called
like
resty
apis,
like
the
resty
name
space
in
the
lower
jet
VM,
but
instead,
but
we
also
provide
you
a
higher
level
like
the
Kong
plug-in
development
kit,
which
offers
like
much
higher
level
functions
which
which
are
defined
in
terms
of
the
domain
of
an
API
Gateway
right
and
not
just
like
a
a
low
lower
level,
like
reverse
proxy.
B
So
so,
with
that
in
mind,
when
we
progress
into
the
web
assembly
context,
we
need
to
think
okay.
So
what
will
be
exposed?
What
will
be
available
for
a
programmer
to
use
When
developing
an
elbow
assembly
extension,
so
that
is
proxy,
wasn't
and
just
like
webassembly?
Is
this
agnostic
application,
agnostic
implementation,
agnostic
definition
of
a
virtual
machine
for
running
this
file?
Format,
which
is
webassembly
proxywasm,
is
a
gateway
agnostic
API
for
proxy
filters
of
of
different
kinds
right,
so
just
like
webassembly
itself
is
a
binary
format.
B
The
proxy
wasm
is
a
language
independent,
ABI
right,
so
here's
a
little
difference
from
an
API
duplication,
programming
interface.
Here,
we're
really
talking
about
an
application
binary
interface,
so
that,
like
as
long
as
you
have
an
implementation
of
the
proxy
as
an
SDK
which
generates
a
webassembly
module
file
right,
a
little
library
that
does
the
correct
calls
following
that
binary
specification,
then
it
will
be
compatible.
So
that
way.
A
B
Can
have
sdks,
which
provide
like
very
natural
native
looking
interfaces
for
whatever
language
you're,
using
which
all
of
them
will
generate
code.
That's
compatible
with
a
proxy
wasn't
enabled
host
so,
which
was
an
X
is
so
we
have.
B
There
are
all
no
various
third-party
proxy
wasn't
as
the
case
implemented
for
different
languages.
Already
right,
such
as
for
rust,
for
go
for
SQL
Plus
for
assembly
script.
Assembly
script
is
pretty
much
a
dialect
of
typescript,
which
is
itself
a
dialect
of
JavaScript,
which
has
like
little
changes
so
that
it
can
be
compiled
efficiently
into
webassembly
right.
B
So,
basically,
if
you
know,
if
you
know
JavaScript,
if
you
know
typescript,
then
you
pretty
much
know
assembly,
script
and
proxy
wasn't
so
as
such
is
an
evolving
specification
so
that,
as
proxies
get
more
and
more
sophisticated
and
how
they
use
it,
they
will
want
like
okay,
I
need
this
extra
function
there,
and
so
the
the
the
standard
itself
is
evolving
and,
as
are
most
things
in
the
web
assembly
space
right,
that's
everything's,
very
Cutting
Edge
at
this.
B
Time
there,
which
is
very
exciting
and
an
opportunity
to
help,
shape
those
standards
and,
most
importantly,
when
we
say
Gateway
agnostic,
we've
really
made
it
because
it's
Gateway
independent
it
was
originally
implemented
for
Envoy
and
it's
being
implemented
in
plus
MX.
So
essentially,
what
you
have
is
that,
once
you
write
a
webassembly
module,
that
is,
that
implements
a
proxy
filter
you
following
the
proxy
wasm
API
and
which
generates
code
that
follows
the
proxy
wasn't
API.
B
That
means
that
you've
built
a
module
that
can
run
as
an
Envoy
filter
and
as
it
was
an
x
filter
right,
one
of
them
and
like
running
on
invoy
proxy
and
the
other
one
in
con
Gateway-
and
this
is
this-
is
a
super,
exciting
proposition,
so
I
think
at
this
point
it
becomes
clear
like
why
proxy
wasn't
right,
because
we
didn't
have
to
necessarily
adopt
these
this
API,
but
there
are
several
benefits
in
doing
so
right.
B
B
We
get
support
for
all
of
those
different
language
sdks,
which
is
very
different
from
how
it
was
from
the
for
the
plugin
server
pdks
that
we
were
trying
to
do
one
by
one
for
Kong
and
the
story
for
interoperability
becomes
very
interesting
because
on
one
side
we
have
con
Gateway,
which
is
based
on
nginx
technology.
But
on
the
other
side
we
have
con
match
on
mesh,
which
is
built
on
Envoy
technology.
B
So
the
idea
of
being
able
to
write
filters,
write
extensions
that
could
potentially
in
the
future
run
in
both
is
super
interesting
and
then
again,
as
I
said,
like
the
idea
of
supporting
and
evolving
industry
standard
and
give
our
contributions
to
it.
There's
also
is
also
very
interesting,
so
we
went
with
proxywasm
as
state
the
programmer
API
for
that
and
then-
and
we
we've
done
so
by
implementing
the
Avi
and
into
was
a
mix.
So
whenever
you
build
was
a
Max.
B
What
it
does
is
that
it
embeds
webassembling
virtual
machine
and
then
connects
it
to
all
of
those
proximals
and
entry
points
to
make
any
like
was
a
module
that
you
load
into
it
support
those
entry
points.
B
So
now
that
we
have
our
new
LEGO
brick,
that
is
webassembly
enabled
right,
we
have
to
start
thinking
about
how
to
get
everything
all
the
pieces
together
right.
So
so,
then
we
get
to
the
tech
review.
The
tech
review
was
originally
announced
at
conch
Summit
a
couple
of
months
ago,
so
it's
still
pretty
new
and
at
the
end
of
a
presentation,
I'll
I'll
give
you
links
so
that
you
can
get
your
own
hands
on
it
and
play
with
it.
B
B
B
And
inside
the
namespace
of
that
VM,
that's
where
you
have
all
of
the
Lua
code
running.
So
if
I,
you
know,
if
I
blow
up
the
view
of
what's
running
like
inside,
that
legit
VM,
so
I'm
painting
everything,
that's
like
Lua
and
blue
here
in
the
diagram.
We
can
see
that
we
essentially
we
have
a
lower
core
which
are
like
bits
and
pieces
that
make
up
the
Gateway,
such
as
the
router,
the
balancer,
the
admin
API
and
a
bunch
of
plugins
right.
B
So
many
of
them
come
bundled,
but
you
can
also
load
in
custom
plugins
of
your
own.
But
essentially
this
is
this
is
how
you
know
all
of
the
lower
parts
of
the
Gateway
are
constructed,
and
once
you
interface
with
the
with
the
Gateway
via
I,
mean
API
or
via,
like
your
like
declarative,
config
files,
and
all
that
like
this,
these
are
the
or
the
con
configuration
file.
This.
B
These
are
the
things
that
you're
configuring
and
so
your
interface
with
Kong
itself,
as
as
an
administrator,
is
through
those
those
little
parts
right
and
as
a
plugin
developer,
is
by
developing
a
Lua
extensions
that
will
be
loaded
as
plugins
into
the
Luigi
VM.
So
once
we
extend
that
model
to
add
webassembly
into
the
picture,
how's
that
going
to
look
like
right
and
yeah
I
had
another
slide,
just
to
say
that
besides
the
plugins
that
come
with
Kong,
you
can
like
load
additional
plugins
over
your
own.
B
So
so
in
the
end,
this
is
like
a
more
accurate
depiction
of
a
typical
Kong
installation
with
custom
plugins,
so
yeah.
So
that's
then,
okay!
So
now,
let's
move
into
talking
about
fitting
was
the
next
intercon
right.
So
we
start
with
that
build
of
the
Conqueror,
including
was
the
max.
B
But
at
this
point,
when
we
look
at
this
picture
that
orange
module
there
with
was
a
Max
and
there
wasn't
VM,
which
is
the
top
of
the
purple
one,
the
bright
purple,
one
that's
running
inside
it,
that's
not
really
connected
with
all
of
those
other
parts
that
make
the
Gateway
the
Gateway
right.
Like
so,
how
does
it
interact
with
all
of
the
other
parts
of
the
of
the
execution
which
are
all
written
and
Lua?
B
So
we
need
to
make
a
connection
with
that
part
as
well,
because
wasn't
X
itself
is
a
an
nginx
module.
It
really
knows
about
nginx.
It
doesn't
know
about
open
rest
here
or
legit
or
the
like,
so
we
actually
need
to
add
like
an
additional
Bridge
into
that
and
so
for
the
tech
preview.
B
Well,
it's
it's
pretty
logical
when
you
think
about
it
like
when
well
how
to
extend
the
con
Gateway
well
via
lower
plugins
right.
So
what
we
really
want
to
do
here
is
extend
a
little
gateway
to
make
it
webassembly
enabled
right.
So
so
the
way
we're
doing
it
here
in
the
tech
preview
and
really
there
are
two
ways
about
it.
Right,
like
you,
had
to
either
extend
the
Concord
so
have
that
bridging
or
you
have
to
extend
it
by
uploading
so
for
the
tech
preview,
what
we're
doing,
because
it's
it's!
B
Well,
it's
the
tech
preview!
After
all,
and-
and
this
is
how
like,
we
are
first
approaching
and
proving
the
concept
and
demonstrating
the
concept
for
to
you
all-
is
by
adding
a
Lua
plugin
that
interfaces
the
lower
core
with
wasn't
X,
so
there,
like
in
in
Darker
blue
I,
added
a
new
plugin
to
the
picture,
called
proxywise,
because
that
is
the
API
that
is
being
exposed
to
end
users.
B
So
with
that
proxy
was
a
plugin
once
you
do
that
now,
you
can
load
proxy,
wasn't
filters
which
are
essentially
a
new
way
of
extending
Kong.
Besides
extending
it
with
lower
plugins,
you
should
now
be
able
to
extend
it
with
proxy
wasn't
filters
which
are
themselves
written
in
any
language.
That's
supported,
like
any
language
that
happens,
to
have
a
proxy
wasn't
SDK,
which,
on
its
turn,
implements
the
proxy,
wasn't
binary
interface
for
webassembly
right,
so
all
of
those
languages
that
I
mentioned
earlier
would
pretty
much
apply
right.
B
A
B
In
place
now,
let's
yeah,
let's,
let's
get
even
walking
great
and
go
for
for
the
demo-
and
let
me
get
my
terminal
on
screen-
should
be
able
to
see
it
and
well
since
everybody
loves,
like
the
tense
moments
of
you
know,
praying
to
the
demo
gods
and
hoping
that
everything
looks
fine
and
people
like
watching
you
make
all
sorts
of
typos
and
such
I'm
gonna
avoid
that
by
doing
the
way,
we're
actually
doing
real
life,
which
is
automating
things
so
that
you
don't
excellent
mistakes.
B
So
for
here
what
I
do
have
like
is
a
small
script
which
which
looks
like
essentially
like
what
I
would
type
in
the
demo.
So
so,
what
are
we
doing
here?
So
first
I'm
going
to
get
an
proxy
was
an
SDK
from
a
third
party
and
just
to
really
bring
the
point
across
that
this
is
Gateway,
agnostic
and
standard,
and,
and
it
adds
the
possibility
of
running
third-party
filters
which
were
not
even
designed
for
Kong.
So
that's
what
I'm
going
to
do
here.
B
I'm,
just
gonna
get
one
of
the
examples
out
of
the
go
SDK,
which
is
a
Json
validator
filter,
I'm,
going
to
compile
it
I'm
going
to
use
a
tiny
go
compiler,
which
is
a
compiler
original
design
for
embedded
systems,
which
is
a
go
compiler
for
embedded
systems
because
Asian
rates
much
smaller,
binaries
and
and
it
has
a
target
for
webassembly
formats,
and
here
it
targets
what
is
called
Wazi,
which
is
the
webassembly
system
interface,
so
essentially
like
when
you
think
about
like
the
standard
C
library
like
okay
I,
want
to
you
know
all
we
do
like
file
operations,
read
sockets,
read
environment
variables,
all
those
sort
of
stuff.
B
They
just
like
things
that
you
usually
any
language,
relies
on
the
systems
libraries
like
since
we
are
on
an
abstracted,
sandbox
environment
like
this
as
the
abstracted
system,
interface
called
Wazi.
So
this
is
what
we're
targeting
when
we
run
a
go
file
when
we
compile
a
go
file
into
a
webassembly
module
right.
So.
B
Going
to
copy
it
over
put
here
and
it
wasn't
folder
and
then
I'm
gonna
start
a
Docker
container
here.
So
if
you're,
if
you've
ran
a
company,
it
should
be
a
familiar
with
all
that
and
then
I'm
gonna
load
in
a
volume
which
is
like
just
a
declarative
config
for
Kong
I'm,
going
to
show
you
what's
inside,
that
declared
config
file
just
like
a
very
vanilla
way
of
configuring.
B
Con
and
I'm
gonna
add
to
the
container
as
well
that
wasn't
folder
containing
the
wasn't
file,
which
is
the
the
filter
right
and
also
a
bit
of
a
spoiler
here,
because
we're
going
Kong
incubator
going
to
be
loading
this
container
here
in
order
to
run
an
instance
of
the
Gateway
which
was
loaded
with
the
with
the
wasmer
webassembly
virtual
machine
connected
via
wasn't
X
right.
So
just
gonna
show
you
guys
that
the
configuration
and
then
run
a
couple
of
requests
here.
The
idea
of
the
Json
validator.
B
You
will
see
in
the
configuration
that
it
will
try
a
request
that
should
fail
and
another
one
that
should
pass
just
to
so
I
can
show
you
the
the
execution
going
right,
and
so,
let's
run
down
so
we're
here,
compiling
the
wasn't
file
now
yeah.
Let's
give
it
a
couple
of
seconds
for
it:
okay,
it's
compiled.
So
now
we
have
started
the
docker
container.
B
With
with
that
wasn't
file
we
just
compiled
loaded
so
I'm,
just
showing
it
as
a
configuration
here
just
making
like
a
mock
bin
route
here
and
yeah,
give
it
10
seconds,
but
it
was
not
enough
to
describe
it.
But
okay,
it's.
B
One
service
one
route,
and
then
we
load
it
one
plug
it
into
it.
Here
the
proxy
wasn't
one:
it
supports
loading
multiple
filters
into
it,
we're
just
loading
one
filter
right
now,
which
is
the
Json
validation
filter
and
we're
giving
it
a
config
for,
for
this
plugin
in
particular,
the
config
is
a
Json
string
and
we're
saying
that
we
have
a
required
key,
which
is
my
key,
so
that
is
necessary
for
validating
the
request.
So
what
happens
when
we
first
run
HD
Pi
here
and
try
to
run
it
without
the
required
Key
Well.
B
And
we
do
give
it
my
key,
which
was
the
required
key
here
in
the
configuration
of
the
plugin.
Then
let's,
let's
pass
where,
where
we're
heading
mappings
Echo
endpoint,
when
that
endpoint,
basically
Echoes
back
what
was
the
input
and-
and
this
was
the
input
we
gave
it
and
what's
the
input
we
gave
it
contain
the
required
key
that
the
proxy
wasn't
filtered
checked?
Well,
we
got
a
200
okay
out
of
it,
so
yeah.
B
So
so
you
can
see
like
the
configuration
is
pretty
simple:
it's
not
that
different
from
like
loading
any
custom,
plugins
and
or
are
configuring
them
like
for
the
tech
preview.
We
just
do
it
through
the
proxyguaza
Lua
plugin
and
then
we
can
load
whatever
proxy
wasn't
filters.
You
want
like
as
long
as
they
you
know
they
they
match
the
API
of
what's
currently
implemented
in
the
you
know
in
the
in
the
was
a
Max
implementation
of
the
proxy.
Wasn't
API
right!
B
So
that's
so
that's
it
from
the
demo
and
well,
as
you
saw
there
in
the
Kong
incubator
description.
Well,
this
this
container
is
now
available
as
part
of
our
incubator
project,
where
the
upcoming
pieces
of
tag
that
we
are
developing
is
there
for
you
to
check
out
and
for
to
give
us
feedback.
B
Of
course,
we're
looking
forward
to
hear
all
the
feedback
you
got
around
this
feature
and,
of
course,
designs
and
compatibility,
and
all
that
so
I
continues
to
evolve,
as
we
are
hard
at
work
into
continuing
to
build,
was
a
Max
and
and
to
eventually
get
it
ready
to
GAA
and
get
it
integrated
into
the
con
Gateway
in
a
future
release
right.
So
so,
to
recap:
what
have
we
learned
was
a
Max
it
embeds.
B
It
wasn't
VM
that
you
get,
for
example,
here
in
the
example
I
just
ran,
it
was
called
vasmer,
but
we
also
support
V8
and
other
ones.
Wozmax
implements
proxywasm,
which
is
the
interface
that
which
is
what
you
call
it
towards
right,
which
is
essentially.
If
we
look
at
the
the
you
know,
if
you
look
at
the
code,
I
mean
okay.
Let
me
provide
the
bit
here
so
when
we
look
at
those
examples,
let's
see
the
example
where
we
just
ran
like
this
was
the
code
right
proximosum
go
SDK,
Json
validation.
B
So
here's
like
the
validation
of
like
that's
just
standard,
go
code
and
you
have
things
like
plug-in
context,
new
HTTP
context.
These
are
things
from
the
proxy
wasn't
API,
and
just
what
I
wanted
to
show
here
is,
like
you
know,
like
you,.
A
B
The
proxy
wasm
SDK
for
for
the
language
that
you
want
to
use
and
then
you
get
like
all
sorts
of
things
like
this,
and
if
we
were
running
like
in
rascal,
it
would
look
a
little
different,
a
bit
more
native
towards
rust,
but
you
would
have
essentially
the
same
functionalities
and
once
you
do
that,
you
know
you're
able
to
write
code
that
can
be
compiled
and
run.
You
know
and
executed
into
was
an
X
so
in
the
current
con.
B
So
to
finish,
our
recap
like
for
the
con
Gateway
attack
preview,
it
includes
was
a
Max
and
the
proxy
was
a
plugin
in
there,
so
that
you're,
ready
to
go
and
and
to
play
with
it
and
and
run
proxy
awesome
filters.
So
once
you
enable
the
proxy
wasn't
plugin
in
Chrome
you're,
then
now
able
to
load
those
proxy
wasn't
filters.
So
this
is
how
all
the
pieces
fit
together
in
the
tech
preview
that
we
currently
have.
B
B
B
So,
okay,
let's
see
so
first
one
from
Leandro
says:
okay,
proxylizer
is
a
standard
right.
It
means
that
it
was
plugged
from
cone
Gateway.
It
would
work
Flawless
if
executed
on
Envoy,
okay
yeah.
So
that's
that's
a
great
question
and
in
theory
yes,
but
reality
has
more
Nuance
than
that
which
is
the
same
as
happens
on
every
like.
You
know,
industry-wide
standard
with
multiple
implementations,
as
you
can
imagine
right,
because
we
have
we've
all
seen
like
how
it
is
with
web
standards.
B
For
instance,
right
like
supposedly
like
everything
should
work
exactly
the
same
on
on
every
browser,
but
often
it
doesn't
because
of
different
specifications
and
different
interpretations
of
the
specification
or
because
things
are
under
specified.
Paroxysm
itself
is
a
standard
that
is
evolving
over
time.
Some
of
the
things
are.
A
B
Fully
fleshed
out
in
the
documents-
and
we
we've
done
a
bit
of
guessing
here
and
there
on
like
what
should
our
implementation
do
in
terms
of
what
makes
sense,
what
matches
the
other
existing
implementations
and
all
that?
So
the
intention
yes,
is
for
it
to
be
compatible
and
I
think
we
should
all
work
together
as
an
industry
to
make
sure
that
the
specification,
the
documentation
of
the
specification
evolves
so
that
the
implementations
match
as
well
right,
so
so
yeah.
B
So
in
theory,
yes
in
practice,
we'll
see,
but
I've
just
shown
you
an
example
of
of
that
already
working
and
yeah.
So
we
we
expect
to
get
this
like
any
rough
edges
that
appear
like
Smooth
out
over
time.
B
B
Think
I
think
this
does
have
implications
for
the
Hong
Kong
ecosystem,
like
you
know,
including
you
know,
the
Gateway
eventually
mesh
and
connect,
and
and
all
that
yes,
so
merch
says
as
far
as
I
understand
any
programming
language
code,
I
write
is
considered
to
bytecode
and
run
in
the
browser
I've
been
here
about
webassembly
for
years,
but
I
haven't
seen
an
example
used
like
why
no
explosion
like
okay,
why
no
explosion
like
node.js
or
Dino
for
this
technology
on
one
hand,
I
think
it's
yeah
I've
heard
about
it
for
years,
but
then
I
think
what
web
assembly
is
trying
to
do
is
like
it's.
B
It's
a
much
taller
order,
because
targeting
a
single
language
is
much
easier
than
you
know,
making
something:
that's
language,
agnostic
and
targets
every
language
and
make
sure
that
you
know
that
it
works
for
all
of
them
and
well
and
plus
webassembly.
Is
you
know
it's
it's
part
of
the
VMS
that
runs
in
our
browsers
today
already
but
I.
Think
at
one
point
as
it
becomes
more
successful
it,
it
will
really
be
sort
of
invisible
in
the
context.
B
The
Gateway
will
be
a
lot
more
noticeable
because
well,
the
administrator
have
to
bring
in
the
accessibility
points
in
there,
but
but
yeah,
but
I
think
I
I
think
it's
an
inevitable
Direction
because,
like
every
Everybody,
Wants,
multi-language
support
and
and
extending
like
Beyond
just
JavaScript
in
the
browser
or
Beyond
just
you
know
a
single
language
and
a
proxy.
You
know
whether
it's
like
Lua
and
Kong
Gateway,
or
it
was
like
C
plus
filters,
originally
in
Envoy
as
an
extended,
you
know,
by
adding
webassembly
and
getting
support
for
for
more
and
more
languages.
B
So,
let's
see
next
question:
that's
at
the
top
here
our
go.
Plugin
is
considered
a
bad
way
to
go
for
custom
plugins.
One
of
the
earlier
slides
seem
to
suggest
this.
B
The
current
implementation
of
the
of
the
off
the
go
pdk.
It
has
some
significant
limitations
that
were
all
very
aware
of
in
terms
because
of
the
the
current
architecture
of
when
it
when
you
have
languages
which
were
not
designed
for
sandboxing,
like
implementations
that
were
not
designed
for
sandboxing.
The
way
to
get
a
safe
execution
was
through
the
sort
of
like
that
sidecar
approach.
That
does
have
implications
in
terms
of
latency
and
things
like
that
and
the
extent
of
the
the
pdk
that
was
implemented
for
that.
B
So,
if
like,
if
the
current
state
of
of
go
plugins
solve
your
problem
and
and
and
present
sufficient
performance
right,
that
would
be
no
reason
to
not
not
to
use
them
today,
but
for
many
of
the
scenarios
that
we
see
people
using
the
Gateway
and
reaching
out
for
extensibility.
We
see
that
people
ultimately
currently
they
almost
always
go
towards
lower
plugins
because
they
give
the
ultimate
performance
and
they
have
like
all
of
the
extensibility
points
available.
B
So
in
that
sense,
our
our
current
approach
for
gold
at
what's
what's
on
GA
right
now
like
for
for
gopdk
and
such
it
has
significant
limitations
and-
and
we
see
that
the
feedback
that
we
get
is
that
people
most
often
end
up
gravitating
towards
Lua.
For
that
reason,
and
what
we
hope
is
that
for
with
wazamax,
we
should
get
a
different
avenue
for
extensibility,
there's
cross-language
that
does
include
goal
and
but
will
have
much
tighter
integration.
It
runs
as
part
of
the
nginx
binary.
It
has
sandboxing
out
of
the
box.
B
B
Let's
Let's
see
we
have
another
one
from
from
lands,
we're
here
at
the
top
I'm
going
to
talk
to
bottom
I.
Don't
know
if,
if
Dahlia,
if
you're
like
sorting
them
or.
A
B
I've
seen
the
list
move
around
so
yeah,
okay,
so
let's
go
another
one
from
Leandro
here
it
says
all
come
plugins
have
their
own
weight
and
the
weight
is
useful
to
create
a
plug-in
pipeline
to
tweak
the
repair,
the
request
or
response.
Since
we
have
this
proxy
wasn't,
since
we
have
persuasm
as
another
plugin
to
Google
wasn't
together.
Does
that
mean
that
the
weight
is
fixed?
B
Oh
okay,
it
by
the
you
I
think
I
did
a
clarification
question
you
can
even
answer
in
chat
like
by
weights.
Do
you
mean
the
priority
right?
Because,
because
that
affects
like
the
ordering
right
like
when
you
say
plug
in
fact,
yes
priority?
Okay,
thanks
Andrew!
Well
that
that
means
that
if
you,
if
you
look
at
the
way
that
I
showed
the
configuration
of
the.
B
I'll
show
a
different
demo
here,
like
a
different
demo
configuration
just
because
you
can
have
multiple
filters
in
there
and
the
list
of
filters
here
is
the
one
that
determines
the
ordering
right.
So,
instead
of
because,
since
proxy
wasn't
filters,
do
not
declare
like
a
cone
priority
right.
What
you
have
instead
is
that
the
order
that
you
describe
your
chain
of
filters
here
like
it
indicates
the
order
that
they
will
run
so,
if
I,
if
I've
done
this
oops.
B
If
I've
done
this,
then
that
will
change
the
order
right
and
yeah
so
to
clarify
the
question
yeah,
if
I
like
to
use
request,
transform
proxy
awesome,
in
course.
Yes,
so
the
proxy
wasn't
plugin
itself
has
a
priority.
I
think
it
currently
runs
last,
but
then
again
you
you
will
still
have
them
like
all
of
them
run
for
each
for
each
phase
of
the
request
right,
like
access
phase,
then
header
filter
phase
that
body
filter
phase.
B
So
if
you
add
filters
that
runs
on
different
phases,
they
will
all
run
at
their
correct
phases
right
so
probably
like
in
your
example.
Like
course,
we
run
first,
and
then
you
know
like
if
you
have
a
response
transform
that
will
run
at
the
end,
because
it's
it's
dealing
with
with
with
the
transformation
right
so
for,
depending
on
what
your
proxy
wasn't
filter
does
like.
B
If
it
extends
you
know
some
sort
of
like
health
or
indication
and
callback
that
would
run
at
the
beginning
but
say
if
you're
extending
like
logging,
that
could
run
at
the
end
right.
So
that
depends
so.
B
Your
your
wasn't
code
would
run
would
depend
more
on
which
callbacks
you
you
implement
in
that,
but
in
the
context
of
the
blocks,
wasn't
plug-in
there,
which
is
a
driver
right
yeah.
It
has
a
fixed
priority,
so
yeah
that
that
ended
up
pretty
technical
but
I
I,
I
I,
hope
the
the
explanation
makes
sense.
B
So
yeah,
let's
see,
let's
see
our
questions,
so
are
you
going
to
release?
Was
an
X
as
open
source?
Well,
honestly,
I
don't
have
a
I.
Don't
have
an
exact
answer
at
this
point,
depending
on
on
what's
going
to
happen
as
it
goes
to
GA
but
yeah
right
now,
it's
going
it's
right.
Now
it's
going
to
the
incubator,
Pipeline
and
and
we'll
see
as
the
project
evolves.
You
know
what
what
really
is
going
to
happen
with
it
next
one.
Is
it
a
plan
in
the
future?
Is
it
a
decommissioned?
B
Legit
in
favor
of
was
anx
no
I
like
for
for
this
one
I
will
just
give
you
like
my
very
personal
answer,
like
not,
of
course,
the
whole
company
but
like
I,
think
that's
like
extremely
unlikely
giving
the
update
them.
B
You
know
the
amount
of
stuff
that
we
have
developed
on
top
of
a
type
of
fluid
yet
and
like,
and
especially
like
the
wealth
of
like
custom
plugins
and
things
that,
like
our
community,
has
built
over
the
years
right,
so
I
I,
don't
I,
don't
think
it
will
make
like
any
sense
for
for
that
to
be
thrown
away
so
yeah.
So,
let's
see
how
next
one
interesting
one
like
how
how
do
wasn't
plugins
compare
in
terms
of
performance
to
the
Lua
plugins
right
at
the
stage
at
this
stage
of
the
project.
B
B
This
case
is
that
first
well,
different
plugins
have
very
different
performance
characteristics
like
so
even
for
low
plugins
right,
so
you
will
have
little
plugins
that
run
super
fast
and
all
the
ones
that
run
super
slow,
depending
on
like
how
they're
written
or
what
they
do
right
like
some
of
them
are
just
like,
naturally,
heavier
than
others,
but
what
I
can
say
is
that
web
assembly
give
gives
you
like
yet
another
variable
to
consider
on
top
of
that,
because
you
will
be
using
different
languages
and
each
of
the
different
these
different
languages
have
different
compilers,
and
these
languages
have
different
performance
characteristics
themselves
and
the
compilers
that
Implement
them
also
have
right
just
like,
if
you
think
about
it,
like
c
c,
is
fast
right:
okay,
but
then
there
are
different
C
compilers
and
some
of
them
are
generate
faster
code
than
others
right.
B
So
so
you,
so
you
get
you
get
that
layer
of
complication
as
well
right.
So
when
you
think
about
when
you
say,
okay,
what's
the
difference
of
performance
of
a
lower
plugin
versus
like
a
plug-in
running
on
wasn't
okay,
like
I,
expect
a
wasn't
plug-in.
That's
written
in
Rust
versus
one
that's
written
and
go
depending
on
what
it
what
it
does
like
I,
I
I
would
expect
them
to
have
different
performances
as
well.
B
So,
if
you're
like
aiming
for
the
ultimate
performance,
if
you
really
need
that
like
like
that,
that
would
be
another
variable
to
be
taken
into
consideration.
B
Let's
see
like,
is
there
a
market?
A
next
question
from
Dennis
like?
Is
there
a?
Is
there
a
Marketplace
or
a
hub
for
wasn't
plug-ins
or
filters?
B
Well,
not
at
this
point
in
time
like
not
come
from
Congo
at
this
point
in
time,
but
I
definitely
think
that,
like
eventually
as
we
start
to
develop
like
a
an
inconsistent
of
proxy,
wasn't
filters
developed
like
by
Kong
by
the
con
community
and
all
that,
like
I
I
could
I
could
I
could
very
much
see
that
happening
right
and
something
something
like
that
in
the
future,
but
yeah,
but
at
the
stages
like
it's
it's
it's
too
early
to
tell
like
which
you
know,
shape
or
form
that
will
that
will
end
up
having
right
but
yeah,
but
it
will
be
nice
too.
B
It
will
be
nice
to
have
yeah.
There's
a
there's
clarification
there
saying
that
was
referring
to
go
pdk,
I,
think
I
covered
that
so
yeah,
like
so,
okay
fell.
There
you
have
Phil,
has
a
high
fell.
There's
a
question
there
about
the
advantage
of
was
a
Max
over
the
other
pdk
languages
that
Kong
supports
yeah,
I,
I.
Think.
B
B
The
very
fact
that
you
know
there
are
third
parties
like
as
knew
like
the
next
flavor
of
the
month
in
terms
of
language,
becomes
popular
and
decides
to
implements
approxy
awesome
SDK.
We
will
get
support
for
that
for
that
out
of
the
box
and
and
then
again
like
going
back
to
that,
go
pdk
discussion
that
I
I
mentioned
earlier,
like
the
very
fact
that
this
is
built
as
an
nginx
module
and
not
as
a
plug-in
server
sidecar
right.
That
should
give
us
like.
B
We
expect
performance
advantages
like
a
tighter
integration,
so
so
yeah.
So
we
are
we're
we're
excited
about
that
as
a
pass
moving
forward
right,
let's
see
another
one:
okay,
there's
there's
two,
therefore
from
Andrea
that
says:
okay
Microsoft
has
a
Blazer
server
technology.
How
can
we
integrate?
Wasn't
mixed
with
it?
Okay,
fortunately
I'm
not
familiar
with
with
blazer
I'll
I
will
check
it
out
and
see.
B
How
exactly
does
it
relates?
So
what's
the
max
is
in
itself
is
designed
as
an
extensible
piece
of
technology
in
terms
of
supporting
different
VMS.
So,
if
like,
if,
if
that's
a
webassembly
VM
from
Microsoft,
we
currently
do
not
support
it,
but
we
could
in
the
future
if
it
proves
like
advantages
in
terms
of
you
know,
functionality
of
performance
or
something
like
that
yeah.
So
Dennis
asked
about
performance,
okay,
I
think
I.
B
Think
that's
a
repeat:
we've
already
covered
that
one
yeah
I
think
the
other
ones
are
already
repeats
like
okay
runtime.
No,
like
that's,
that's
not.
You
know
like
in
any
roadmap
and
the
last
one
was
also
like
benchmarks
asking
about
performance
so
yeah
that
one
has
a
little
bit
of
a
clarify
like.
Are
there
still
like
best
practices,
things
to
do
not
to
do
so,
I
think
it
would
be
useful
to
touch
on
that.
A
bit
like
we
once
was
the
next
gets
to
GAA
and
we
get
to
the
Gateway
integration.
B
We
will
definitely
have
documentation
and
best
practices
and
examples,
and
all
of
that
you
know
where,
at
this
point
it's
it's
very
early
like
even
like
even
the
incubator,
one
like
it
has
like
instructions
on
how
to
you
know
how
to
get
likes
demos
running
and
play
with
it,
but
when
once
we
get
to
GA
like
we're
trading
documentation
very
seriously,
and
we
really
wanted
to
you-
know
to
to
get
those
best
practices
and
and
examples
and
and
and
really
guide
you
on
how
to
make
the
best
use
of
the
technology
right
well
that
well,
those
were
like
a
lot
of
questions.
B
I
think
was
the
most
questions
I've
ever
had
and
in
a
user
call
presentation
here,
so
that
was
super,
exciting
and
yeah.
So
we're
really
happy
the
way
this.
This
turned.
A
Up
yeah,
of
course,
thank
you
so
much
for
the
great
presentation
for
answering
all
the
questions
and
thanks
to
everyone
for
joining
us
today.
We
hope
to
see
you
at
our
next
user
call
on
December
13th,
where
we're
going
to
talk
about
new
plugins
in
con
Gateway
3.1,
so
make
sure
to
be
there
thanks
one
more
time:
shasham
thanks
everyone
and
see
you
soon,
bye.