►
From YouTube: Customize and Extend Envoy Proxy with WebAssembly
Description
Envoy Proxy is the go-to proxy for cloud-native environments for its speed and extensibility which has made it a popular choice as a proxy at the edge and as sidecars for service mesh.
Envoy proxy’s extensibility comes in the form of filters which are written in CPP and compiled directly into an instance of Envoy. This limits the accessibility to developers who know CPP and requires maintaining and shipping different versions of the Envoy Proxy code. WebAssembly support is working to make this process easier and accessible to more people by allowing filters to be built in your favorite language (CPP, Rust, TinyGo and more), precompiled into WASM, and then run in a WASM vm inside of Envoy.
This webinar will cover:
* Overview of WebAssembly, use cases and benefits
* How to build, share and use Envoy filters with WASM
* Overview of WebAssembly Hub
* Live demo
Download the slides
https://speakerdeck.com/soloio/customizing-envoy-proxy-with-webassembly
https://webassemblyhub.io
https://slack.solo.io
https://www.solo.io
A
My
name
is
Betty
Jenna
and
head
of
marketing
over
here
at
solo
and
we're
very
excited
to
have
you
join
us
just
before
we
get
started
here.
This
session
is
being
recorded,
and
so
we
will
then
share
that
back
out
with
you,
as
well
as
posted
on
our
YouTube
channel,
so
that
you
can
share
with
your
colleagues.
We
will
have
a
version
of
the
slides
available
as
well.
A
So
if
you
have
a
colleague
that
couldn't
attend,
don't
worry,
they'll
get
it
and
we're
happy
to
have
you
shared
this
out
and
with
that
we
will
have
the
the
chat
and
the
Q&A
widgets
are
open.
So
please
type
in
your
questions
as
we
go
as
you
know,
as
our
speakers
are
presenting
and
we'll
handle
them
all
at
the
end
and
to
kick
this
off,
we've
got
Christian
Costa
our
global
field,
CTO
and
Scott
Weiss
principal
engineer
talking
today
about
extending
envoy
proxy
with
webassembly
Christian
Scott.
B
Yeah
thanks
all
for
joining
and
I
want
to
give
a
heads
up
that
I
am
in
the
middle
of
and
hopefully
coming
down
from
the
flu,
so
my
voice
might
be
a
little
raspy.
My
head
might
be
a
little
cloudy,
but
I
did
not
want
to
miss
this
webinar.
This
is
exciting
stuff,
that's
happening
in
the
in
the
application.
Networking
ecosystem
and
Scott
and
I
are
here
to
kind
of
show
you
what's
happening
and
explain
why
it's
important,
why
it's
exciting
and
and
show
you
what
we've
been
doing
to
enable
this?
B
B
We'll
take
a
look
at
on
boy
proxy
and
some
of
the
application,
networking
components
that
can
be
used
to
build
service,
mesh
and
and
various
patterns
with
a
with
a
service
mesh
and
then
we'll
look
at
how
those
same
components
can
also
be
used
to
solve
problems
at
the
edge
and
at
the
boundaries
of
our
architecture,
with
with
with
ingress
and
API
gateway,
and
what
the
differences
are
between
those
two
and
then
we'll
well
under
it
would
try
to
dig
into
what
it
means
to
extend
these
capabilities.
Some
of
the
challenges
of
doing
that.
B
Some
of
the
reasons
why
you
might
want
to
do
that
and
then
we'll
get
into
where,
where
things
are
going
in
the
community,
especially
focused
on
web
assembly
so
before
before,
we
dive
in
I
just
want
to
give
you
a
quick
level
set
of
what
we're
doing
here
at
solo.
We're
heavily
involved
in
these
various
communities
that
we'll
be
looking
at
these
open
source
communities
that
we'll
be
looking
at
today.
But
what
we're
doing
in
solo
is
to
try
to
help
people
along
their
journey
of
modernizing
their
application
architectures.
B
So,
in
the
way
we're
looking
at
it
is,
as
people
start
to
go
to
a
micro
service
to
start
stop
architecture
where
they
have
existing
investments
in
their
in
their
and
their
various
technology.
Vintages
that
are
used
to
support
the
business,
probably
very
successful,
making
a
lot
of
money,
and
so
on
there
they're
going
to
slowly
and
iteratively
move
to
micro
services.
They
need
to
start
solving
some
of
the
challenges
of
well
when
you
break
things
up
into
a
bunch
of
different
services.
What
is
the
entry
point
to
those
services?
B
How
do
we
define
what
that
API
looks
like
and
so
for
that
we've
built
API
gateway
on
top
of
on
top
of
on
boi
proxy
cause,
we're
trying
to
call
Lu
now,
as
people
get
to
micro
services
and
start
to
scale
out
and
have
a
bunch
of
different
types
of
programming,
languages
and
frameworks
deployed
and
they're
in
their
application
architecture?
They
need
to
solve
some
of
the
challenges
of
service
or
service
communication.
B
You
know
panes
of
glass
to
write
rules
that
makes
sense,
especially
if
you're
doing
multi
clusters
across
a
on-premises
deployment
and
a
cloud
deployment
and
so
on.
So
what
we're
building
is
a
way
to
manage
that
complexity,
reduce
the
complexity
and
and
make
it
so
that
people
can
actually
adopt
service
mesh
and
be
successful
with
it.
B
So
things
like
understanding
the
traffic
patterns
and
controlling
the
routing
right.
So
we
need
to
be
able
to
adapt
when
traffic
patterns
change
and
effectively
adapt
the
routing.
So
we
need
to
build
some
control
loops,
something
that's
watching
something.
That's
using
these
service
measures.
Api
is
to
do
that.
Things
like
canari
automation,
things
like
chaos,
experimentation
things
like
debugging
tools.
B
And
so
we
see
this
as
a
as
a
way
to
simplify
the
adoption
of
some
of
this
technology
to
enable
you
to
be
able
to
easily
build
build
powerful,
abstractions
and
automation.
On
top
of
your
network,
things
that
we
we
haven't
been
able
to
do
in
the
past
that
bring
a
tremendous
amount
of
value,
especially
when
we
go
in
to
end
up
deploying
into
cloud
platforms.
So
that's
what
we're
doing
it.
Solo
now,
jumping
right
in
to
the
presentation
we're
going
to
start
to
look
at
sort
of
the
underpinnings
of
this
architecture.
B
B
B
So
when
we
start
going
down
the
path
of
well,
how
do
we
solve
service
to
service
communication
challenges?
Services
need
to
build
for
a
dynamic
and
constantly
changing
infrastructure.
So
if
we're
talking
about
kubernetes
or
other
cloud
platforms,
where
the
compute
is
ephemeral,
it
can
be
auto
scaled.
We
need
to
build
their
applications
in
such
a
way
that
we
can
react
and
adapt
to
those
those
environments
and
we
need
to
solve
for
things
like
service
discovery.
B
We
need
to
solve
for
things
like
timeouts
and
retries
and
circuit
breaking
distributed,
tracing
telemetry,
observe,
observe
ability
and
so
on,
while
in
the
past
we
did
this
in
a
very
language
and
framework
specific
way,
as
I
outlined
in
a
previous
slide,
using
proxies,
we
can
offload
some
of
that
implementation
detail
into
a
proxy
well-suited
to
be
able
to
handle
the
application.
Networking
concerns
on
behalf
of
the
application
and
in
a
service
architecture's.
B
Once
we
started
going
down
that
path,
we
we
see
that
we
deploy
these
proxies
next
to
each
application
instance,
which
there
we
implement
the
networking
capabilities
so
and
any
of
those
things
that
we
were
doing
in
the
past
service
discovery
and
routing
and
circuit,
braking
and
so
on.
We
can.
We
can
do
that
in
the
proxy
outside
of
the
application
and
and
apply
apply
these
policies,
regardless
of
how
we
wrote
D
D
application.
B
So
you
can
think
these
these
service
proxies
as
a
personal,
proxy
or
personal
gateway
into
and
out
of
the
workloads,
and
you
know
it
working
together.
We
can
better
reason
about
the
system,
its
behavior
and
so
on,
and
we
get
consistent,
telemetry
and
and
security
like
I
said,
regardless
of
how
the
service
was
written
now
in
a
service
mesh
that
service
proxy
gives
us
a
bunch
of
different
control
points
all
right,
so
add
the
granularity
of
the
application
instance.
B
We
can
control
what
services
are
allowed
to
talk
with
which
we
can
control
the
the
transport
and
secure
and
encrypt
the
transport.
We
can
give
certain
services
routing
rules
to
and
from
and
around,
maybe
in
some
cases
failed
services.
So
we
need
a
point
where
we
can
define
these
rules
and
define
these
policies
in
a
way
that
fits
in
with
our
existing.
You
know
the
organization's
have
a
lot
of
assumptions
built
into
the
way
that
they
run
their
processes,
the
way
their
workflows
are
organized
and
so
on.
B
We
need
a
way
to
influence
those
configurations
at
the
service
proxy
level
in
a
way
that
fits
nicely
within
our
organization,
and
we
need
to
do
that
from
a
centralized
location,
centralized
API
right.
We
don't
want
to
login
to
each
one
of
these
proxies
for
each
instance
of
a
service
and
try
to
configure
it
by
loading,
so
yeah
mo
files
and
hot,
restarting
the
service
and
or
the
or
the
proxy
and
so
on.
So
what
we
lack
is
a
centralized
way
of
managing
this
configuration
and
in
in
a
service
Metro
architecture.
B
B
Of
that
boundary
now
envoy,
I've
alluded
to
is
is
very
well-suited
for
the
service
proxy
or
service
mesh
pattern,
and-
and
I
also
lose
you
that
envoy
is
being
used
kind
of
as
a
framework
or
the
underpinnings
of
this
type
of
technology.
There's
another
example
of
unvoiced
versatility
in
being
able
to
solve
these
problems
at
the
edge,
as
well,
with
a
little
bit
more
focus,
because
the
problems
at
the
edge
are
not
always
exactly
the
same
as
those
when
we're
solving
east-west
traffic.
Alright,
the
clients
are
unknown,
the
bow
and
the
things
outside
the
boundary.
B
B
As
a
realistic
example
of
all
the
protocols
we
might
have
services
implemented
in
soap
or
even
older
vintages
of
technology,
and
so
what
we
expose
outside
the
boundary,
we
might
not
want
to
expose
those
implementation
details.
We
might
want
to
have
a
nice
stable,
maybe
REST
API.
Maybe
we
want
to
use
graph
QL
and
we
want
it.
We
don't
want
to
expose
the
implementation
details
of
what's
what's
running
within
the
boundary.
We
might
have
a
very
specific
and
customized
security
requirements,
things
that
we
want
to
support
outside
the
boundary
versus
inside
and
so
forth.
B
So
the
API
gateway
and
the
edge
solve
a
different
problem,
but
envoy
provides
the
kernel
you
could
say,
or
the
core
framework
for
being
able
to
build
that
type
of
solution,
so
it
API
gateway
and
a
service
mesh
complement
each
other
very
well.
They
in
some
cases
may
use
the
same
underlying
technology
in
this
case
envoy,
and
the
examples
that
were
looking
at
here
are
Sto
as
an
open
source
service
mesh
and
glue
as
an
open
source.
Api
gateway
both
built
on
envoy,
where
we're
a
glue
could
be
solving
the
edge
and
boundary
a
concern.
B
B
So,
for
example,
if
we
needed
to
add
some
new
protocol
support
alright,
so
right
now
we
have
HTTP
1
&
2.
We
support
G,
RPC
support
things
like
Redis
and
dynamo
and
my
sequel
and
so
on,
Kafka,
just
as
support
just
landed
and
if,
but
if
we
needed,
like,
we
implement
this,
an
organization
that
has
maybe
certain
bespoke
TCP,
based
protocols
or
soap
and
and
so
on.
We
can
add
these
as
filters
to
to
undo
and
extend
the
behavior
of
the
data
plane
now.
B
The
way
that
works
in
envoy
today
is
that
you
need
to
build
your
extensions
or
your
filters
in
the
same
language.
That
envoy
is
written
in
and
envoy
is
written
in
C++,
which
is
great
for
a
proxy
like
this.
It's
great
that
it's
written
in
C++.
It
just
makes
it
a
little
bit
more,
the
bars
a
little
higher
in
terms
of
contributing
customizations
to
it,
and
when
you
do,
you
have
to
statically,
compile
this
into
the
Envoy
binary
and
then
use
that
binary
as
your
proxy
right.
So
you
deviate
from
the
upstream
now
this
is.
B
This
is
not
like
insurmountable.
We
do
this
at
solo,
and
we've
built
a
lot
of
extensions
to
improve
our
ability
to
support
the
API
gateway
use
case
for,
for
example,
glue.
But
it's
not
ideal.
It
would
be
nice
if
we
could
enable
folks
to
write
these
extensions
in
in
a
language
that
they
prefer
and
be
able
to
still
contribute
that
to
envoy.
B
Now
webassembly
is
a
binary
instruction
format
that
was
originally
developed
to
be
used
in
a
JavaScript
engine
inside
the
browser.
So
how
do
we
build
a
compact
and
very
efficient
running
piece
of
code
that
would
outperform
what
was
being
run
in
in
the
browser
for
high
compute
type
tasks?
Now
it's
it
was
written
and
developed
from
the
position
of
being
a
compiled
target
right,
so
you
can
use
C
and
C++.
You
could
use
some
of
my
rust.
You
could
use
something
in
the
few
in
the
few
not-too-distant
future.
B
Things
like
go
or
other
garbage
collected
languages
to
be
able
to
compile
down
then
into
web
assembly
and
then
run
that
in
in
in
a
particular
target.
Now
start
it
off
originated
in
the
browser,
but
whistling
this.
This
applicability
well
outside
the
browser,
and
especially
in
proxy
technologies
like
envoy
now
envoy
proxy
has
begun.
The
community
has
begun
introducing
this
web
assembly
or
allows
them
support,
and
it
should
be
upstream
fairly
soon,
but
but
I
just
caution
that
it's
not
it's
not
there
yet,
but
it's
it's
very
soon.
It's
coming.
B
So
what
that
looks
like
for
extending
envoy
is
you
write
the
filters
and
the
codecs
and
the
extensions
that
you
want
for
your
organization
or
reuse
existing
code
that
you
might
already
have
and
compile
that
down
into
web
assembly?
Now,
once
you
once
you
compile
it
down
into
web
assembly,
you
can
dynamically
and
safely
and
securely
load
that
into
Envoy
Wrentham.
B
So
what
this
means
is
you
need
a
tool
chain
to
be
able
to
support
this,
to
be
able
to
support,
creating
the
new
modules,
compiling
them
down
correctly
against
the
specific
API
is
that
envoy
might
expect
and
so
on,
and
then
a
a
workflow
to
to
get
them
into
on
envoy
itself
and
configure
them
alright.
So
what
this?
What
this
gives
the
community
is?
B
You
know
it
opens
the
door
to
developers
beyond
C++
right.
You
can
use
the
base
envoy
distribution
without
having
to
customize
it.
You
know
to
do
differently
from
what
happened
what's
happening
upstream,
so
you
can
just
whatever
those
differences
are.
You
can
combine
them
and
assemble
them
at
a
deployment
time
or
at
runtime,
and
still
be
on
the
base
ongoing.
B
So
what
we're
doing
a
solo
is
worth
we're:
we're,
observing
and
excited
about
the
this
potential
from
both
a
service
match,
as
well
as
an
API
gateway
standpoint.
But
what
we
want
to
focus
on,
like
we
focus
on
with
the
rest
of
our
products,
is
how
do
we
simplify
this
experience?
How
do
we
make
this
approachable
for
for
everyone?
B
C
Christian
give
me
a
sec.
Let
me
share
my
screen:
okay,
cool
hi,
everybody
thanks
for
the
intro
Christian,
so
I'm
going
to
show
you
today
using
the
glue,
API
gateway
with
envoy
and
how
we've
actually
were
using
this
new
feature
in
web
assembly
to
dynamically
extend
the
proxy
at
runtime.
So
there's
no
need
to
rebuild
no
need
to
redeploy
everything.
Is
you
can
customize
your
proxy
without
having
to
actually
change
your
cluster?
Let
me
show
what
that
means.
So
this
is
all
running
on
kubernetes
right
now,
all
I
have
installed
is
glue.
C
If
you're
not
familiar
glue
is
an
API
gateway,
it
comes
with
a
control,
plane,
components,
and
then
we
have
this
proxy
here,
which
is
Envoy.
We
can
actually
see
if
we
want
to.
We
can
check
out
like
the
Envoy
route
table.
Currently
what
glue
is
giving
it
I
won't
get
too
deep
into
the
weeds
there.
Maybe
if
we
have
some
time
left
over,
but
one
of
the
things
that
I'll
show
is
I'm
going
to.
Let's
see,
I'm
gonna
create
a
route
to
this
pet
store
application
that
I
have
deployed
just
a
basic
JSON
web
service.
C
This
is
the
this
virtual
service
is
the
glue
equivalent
of
an
ingress
if
you're
familiar
with
kubernetes
ingress,
which
is
basically
a
way
of
defining
some
routes
for
external
clients
using
llamó.
So
I
can
apply
this
and
then
I
should
be
able
to
say
to
run
curl,
and
you
can
see
I
can.
I
can
hit
this
slash
api
pets
through
my
own.
This
is
all
running
on
zk
by
echo
that
URL,
you
can
try
this
at
home.
If
you
want,
please
don't
ddos
my
server
okay,
so
we
can
see
we
have
some.
C
We
just
sent
the
request
using
curl
that
actually
went
through
envoy,
and
we
can
see
that
with
this
server
envoy
header
that
we
received
yeah,
so
anyone
who's
not
familiar
with
this.
Essentially,
this
is
output
from
this
curl
command,
which
sends
requests.
We
see
the
request
headers
and
then
the
response
fact
that
we
got
from
envoy
which,
which
went
through
envoy
to
our
pet
store.
C
So
if
I
clear
that,
let
me
show
you
how
we
can
actually
extend
the
functionality
nano
of
that
of
envoy,
so
one
of
the
things
I'll
avoid
is
doing
is
manipulating
headers.
That's
like
a
common
use
case
there
all
sorts
of
different
custom
cases
where
we
want
to
check
a
header
set
something
else
so
I'll
show
you
a
basic
demo
of
how
we
can
do
that
with
webassembly.
So
I'm
gonna
use
this
CLI
tool
that
we've
built
for
ease
of
use.
C
Oh
the
Oise
me
and
say
waz
me
in
it
test
glue,
filter,
okay,
I'm,
going
to
create
a
directory
called
test,
move,
filter,
I'm,
targeting
the
glue
platform
that
we
can.
We
could
do
it
interactively
right,
just
move,
filter
choose
my
languages,
C++
will
build
the
fur
glue
and
we
can
see
the
in
Tibet
directory
and
we
see
it's
created
some
files
for
us,
specifically,
the
one
that
we
only
care
about.
Is
this
filter.
C
That's
DC,
the
rest
of
it
is
boilerplate
that
we're
going
to
use
to
build
this
in
a
second
just
to
show
you,
the
content
of
that
filter,
see
see,
there's
a
lot
of
boilerplate
in
this
which
we're
working
on
boiling
away.
But
essentially
this
is
in
C++,
as
Christian
mentioned.
We
have
support
for
more
languages
coming
and
web
is
simply
itself
anything
that
compiles
to
web
assembly
will
work.
C
So
it's
just
a
matter
of
creating
the
bindings
which
we've
been
working
on
with,
with
with
help
from
people
in
the
uncle
community,
so
you'll
see
here.
What
we're
going
to
do
is
we're
going
to
actually
add
a
header
to
the
response
that
just
says
new
header
and
it's
gonna
pull
the
value,
so
the
key
is
new
header
and
the
value
is
going
to
be
something
that
the
user
can
specify
in
configuration.
So
let's
check
that
out.
We're
gonna
build
this
filter,
because
that
takes
some
time.
C
I
am
going
to
show
you
another
terminal
where
I
already
did
it.
This
is
what
the
end
of
that
command
looks
like
and
I
built
this
filter
here.
This
whoa
want
that
three,
so
being
just
to
give
a
little
context.
The
way
that
we
have
designed
the
hub
the
web
assembly
hub
is
that
these
filters
are
stored
as
OCI
images
just
like
docker,
so
I
can
actually
run
Waze
me
list
and
I
see.
These
are
all
the
filters
that
I
built
with
Waze
me
on
my
local
machine.
C
I
can
run
Waze
b.push,
and
let's
do
that
now,
just
like
pushing
a
docker
image,
so
we're
gonna
push
that
1.5.
It
got
pushed
to
the
hog
we
can
see.
That
is
there.
If
we
do
Waze
me
list
published,
this
will
show
things
that
have
been
pushed
rather
than
what's
on
your
local
and
we
should
see
I
know
it's
a
little
cluttered,
but
we'll
see
that
glue
hello
and
the
1.35
got
pushed.
So
it's
going
back
to
what.
B
He's
gonna,
yes,
he's
got
just
while
you're.
This
is
Christmas.
So,
while
you're
at
this
point
right
here
and
you
just
pushed
and
as
you
start
to
go
into
the
the
publish
part,
there
was
a
question
on
the
on
the
chat
and
it
said
why
why
why
why
Waze
me,
however,
or
webassembly
hub
instead
of
a
more
generic
repo
like
artifactory
and
so
on?
So
just
keep
that
question
in
mind.
C
It's
it's
primarily,
so
our
implementation
is
based
off
of
an
existing,
so
we
use
OCI
images
which
are
the
same
way.
Docker
images
are
stored
and
there
are
other
projects
now
started
to
use.
Oci
helm.
My
help
charts
can
be
stored
as
OCI
images.
You
just
need
a
compatible
registry.
Essentially
so
those
artifactory
doesn't
have
the
the
only.
We
basically
had
to
build
our
own
because
none
of
the
existing
registries
out
there
support
the
like
a
more
custom,
OCI
image.
A
C
I'm
gonna,
open
up
a
new
I
meant
to
say,
is
I'm
going
to
open
a
new
terminal
window,
and
let
me
it
was
me
in
my
path
and
I
say:
I
was
me
list
make
sure
my
my
image.
Is
there
verify
that
103?
Okay,
now
I
want
to
try
my
curl
again
whoops
URL,
so
my
URL
try,
my
curl
I
can
see
that
I
am
not
seeing
that
header.
Okay,
so
let's
see
our
filter
in
action,
let's
actually
deploy
that
thing.
So
all
we
have
to
do
is
write
them.
C
Waze
me
deploy
say
it's
for
the
the
target
is
glue
and
Waze
me
does
support
other
targets
depending
on
how
you're
running
envoy
there's
a
different
way
of
configuring.
This,
but
Waze
me
automate
stuff,
for
you,
I
specify
my
image,
give
it
a
unique
ID
and
then
I
can
provide
configuration
for
the
filter
itself
and
I
know
that
could
think
because
I
happen
to
write
it,
but
it's
just
arbitrary
JSON.
C
We
can
deploy
that
and
we
should
see
pretty
quickly
that
are
now
our
header
just
got
added
I
was
able
to
actually
add
a
filter
dynamically
to
onboarding
to
this
pod,
that's
running
without
having
to
change
any
redeploy.
Anything
modify
my
kubernetes
deployments:
zero
downtime
everything
done
live
on
the
wire,
which
is
really
nice.
You
know
enables
us
to
basically
develop
extensions
for
our
proxy.
You
know
whether
they're
there
applications
are
for
security
monitoring
traffic
control
and
do
that
without
having
to
manage
the
deployment
lifecycle
of
in
itself.
C
So
that's
pretty
neat.
We
have
the
waz
me
so
I
can
actually
change
this
configuration
pretty
easily.
So
if
I,
it's
another
benefit
that
this
automation
gives
us.
So
if
I
curl
again
now,
you
could
now
you
can
see
I've
got
the
might
be
a
bug
in
my
filter.
I,
take
no
responsibility,
looks
like
I
added
a
header
twice,
but
you
can
see
that
I'm
updating
the
config
dynamic.
Oh
no,
nine
I
think
I
know
what
it
is,
but
I
won't
start
debugging
that
now
it
was
me
on
deploy
and
I.
B
C
B
B
B
B
B
No
I
don't
see
it.
Oh
here
we
go
okay.
So
there
was
a
question
about
what
type
of
extensions
that
you
would
find.
People
would
want
to
write
for
envoy
now.
I
mentioned
a
couple
in
the
in
the
presentation.
But
if
you
go
to
web
assembly
hub
dot,
il
and
click
on
explore,
you
can
see
it's
seated
with
a
few,
a
few
extensions
already
we're
in
in
the
process
of
building
more.
But
this
can
give
you
a
couple
of
ideas,
at
least
so.
The
the
three
that
we
see
here.
B
Actually
all
all
of
them
that
we
have
here
are
available
in
in
Glu
today
is
part
of
our
API
gateway,
but
they're
they're
built
using
the
way
of
statically
linking
into
the
binary
of
Envoy,
and
so
that
makes
up
our
the
proxy.
But
what
we're?
What
we're
doing
is
we're
making
those
filters
that
we've
written
and
statically
compiled
in
LinkedIn
into
web
assembly
modules
so
that
those
can
be
reused
at
the
gateway
or
in
any
Envoy
proxy.
B
B
So
we've
built
functionality
to
be
able
to
do
web
application
firewall
to
be
able
to
screen
responses
that
are
going
back
and
and
eliminate
or
mask
certain
pieces
of
data
like
credit
card
numbers
or
social
security
numbers
or
so
on
able
to
do
trance
translations
between
their
specific
protocols
and
so
forth.
So
this
is
a
there's
a
set
of
examples.
The
actual
examples
are
limitless,
as
we
find
when
we
work
with
with
our
our
customers
and
partners
to
adopt
either
gateways
or
service
mesh.
We
we've
run
into
this
quite
quite
frequent.
C
Magnified
to
add
a
little
bit
to
that
yeah
yeah.
So
one
of
the
things
that
we've
seen
we
actually
have
already
had
a
contributor
for
a,
even
though
we're
still
kind
of
building
out
the
infrastructure
for
the
webassembly
hub.
We've
had
our
first
contribution
for
a
user
who's,
building,
a
filter
and
rust,
and
basically
they
want
there's
a
lot
of
users
who
have
a
custom
use
case,
which
is
maybe
possible
using
the
Envoy
filters
in
their
complex
arrangement,
but
there's
something
very
specific.
B
Awesome
yeah
so
go
to
lab
assembly
hub
diode
check
check
that
out.
We
see
here,
I'm,
gonna,
I'm
gonna
put
the
links
up
so
that
you
all
can
see
that
and
then
I'm
gonna
get
to
the
next
question,
which
is
what
limitations
are
there
with
the
waz
Amon
boy
filter,
for
example,
if
I
have
C++
filter
today,
I
want
to
change
to
the
Waze
and
filters
that
promise
that
all
symbols
used
in
C++
will
have
analogous
interfaces
in
the
laws,
Azam
interface,
and
the
answer
is
so
the
first
of
all.
B
This
is
still
evolving,
and
so
as
of
right
now
the
answer
is
no,
but
it
is,
it
is
still
evolving.
I
can
I
can
link
to
the
the
file.
The
basically
contains
all
the
functions
that
are
available
and
in
in
wasum,
but
there
wasn't
filter.
Let
me
just
put
that
in
the
chat
that
was
for
Dan,
who
asked
that
question
I
can
I
can.