►
Description
Building idiomatic Envoy SDKs for Rust and Go - Yaroslav Skopets, Takeshi Yoneda
Support for WebAssembly is slowly coming into upstream Envoy.
Eager to get our hands dirty, we've embarked on a journey to develop our very first Envoy extensions in Rust and Go - languages beloved by the Cloud Native Community.
It's been a bumpy ride and we're happy we've made it :)
In this session we will share our learnings from building Envoy SDKs for Rust and Go:
* what challenges we've met
* what issues remain open
* what makes SDK ergonomic
We will give a demo of practical extensions that have been made possible so far and, most certainly, will beg Envoy folks to give us even more features we miss so much :)
Our goal is to raise awareness in the community about the current state of Wasm, and to invite everyone to collaborate on the SDK for the language of their choice.
A
Hi,
my
name
is
jaro,
I'm
software
engineer
at
trade
and
envy
contributor.
My
co-speaker
today
is
takeshi,
who
is
author
of
the
engineer
at
trade
and
contributed
to
proxy?
Wasn't
in
this
session
we'll
present
you
the
work
that
we've
been
doing
to
enable
new,
more
accessible
way
to
develop
extensions
for
envoy.
A
First,
we
will
explain
why
webassembly
out
of
all
these
things,
what
is
a
problem
then
we'll
talk
specifically
about
webassembly
in
anyway,
and
next
we'll
introduce
you
ando
sdk
for
us
that
we've
been
working
on
and
our
primary
focus
will
be
on
lessons
learned
because
they
are
not
limited
to
rust
and
go.
We've
picked.
A
A
So
this
is
informational
component,
but
there
is
also
inspirational
one.
We
want
to
inspire
you
to
give
up
assembly
a
real
try,
not
in
a
year
from
now
when
you
might
think
it
will
be
finally
production
ready,
but
today
so
give
it
a
try
to
extensions
that
we've
been
developing
and
that
will
show
you
later
in
the
demo
section
try
to
develop
a
new
extension
of
your
own,
try
to
develop
nysdk
for
your
favorite
language
and
ultimately
join
the
community
and
help
us
to
develop
all
these
things
together.
A
So
as
attendee
to
this
conference,
you're,
probably
familiar
with
the
status
quo
of
invo
extensibility,
you
have
to
develop
custom
extensions
in
c
plus,
plus,
statistically
link
them
into
invoice.
Binary,
maintain
a
custom
build
of
envoy
keep
up
with
upstream
changes,
keep
up
with
security
releases.
Overall,
there
is
a
lot
of
burden
involved
when
you
decide
to
extend
envoy
in
such
a
way.
A
That's
why
another
community
has
been
asking
for
a
long
way
for
different
for
a
long
time
for
a
different
extensibility
model,
where
extensions
could
be
loaded
into
android
dynamically,
and
ideally
it
would
be
possible
to
develop
extensions
in
languages
other
than
cpus
plus
and
webassembly
is
an
answer.
Is
technology
that
makes
it
all
possible.
A
So
webassembly
is
a
virtual
machine
and
compilation
target
for
general
purpose
programming
languages.
What
it
means
is
that
you
can
develop
applications
in
programming
languages
like
cpus
plus
or
as
to
go,
but
when
it
comes
to
compilation
compile
into
webassembly
code
instead
of
machine
code,
envoy
plays
a
role
of
assembly
host,
it's
responsible
for
loading
and
loading
webassembly
based
extensions
at
runtime
for
exporting
apis
that
such
extensions
can
use
and
integrating
such
extensions
into
its
regular
request,
processing
flow.
A
The
final
piece
of
the
puzzle
that
you
need
to
know
is:
proximation
abi.
It's
a
specification
of
a
low
level
interface
between
proxy
and
webassembly,
based
extension,
as
its
name
implies.
It's
not
limited
to
envoy
and
it's
meant
to
allow
the
same
extension
to
run
inside
various
proxies
compatible
with
this
spec
very
ambitious
goal.
A
A
We
prepared
a
table
and
we
suggest
you
to
try
to
make
the
decision
to
try
to
answer
the
phone
questions.
Can
you
use
features
of
this
language
all
feature
source
language
and
all
its
standard
library?
If
you're
going
to
compile
it
into
webassembly,
will
you
be
able
to
reuse
as
a
library
ecosystem
and
will
the
language
retain
its
original
performance
characteristics
if
compiled
into
webassembly
instead
of
machine
code?
A
A
So,
to
be
fair,
there
are
sdks
available
for
envoy
simplesplash,
sdk,
assemblyscript,
sdk
and
even
rust
sdk.
So
why
do
did
we
decide
to
develop
yet
another
one?
So
after
looking
into
all
the
sdks,
we
came
up
with
a
slightly
different
set
of
requirements.
First
of
all,
we
want
our
extension
model
to
be
independent
from
work.
A
Proximation
ebi,
as
we
mentioned
proxibus
api
tries
to
be
compatible
with
all
proxies
out
there,
which
means
that
it's
not
really
aligned
with
envoy
so
when
we
develop
http
filter,
often
for
and
we
want
to
call
this
to
filter
and
not
http
context.
When
we
develop
http
filter
factory,
we
want
to
call
it
this
way
instead
of
root
context,
and
when
we
develop
access
logger,
we
want
to
call
it
this
way
instead
of
well.
A
A
So,
let's
work
through
the
issues
we've
met
while
developing
this
sdk
the
lessons
we
learned
and
some
random
notes
on
the
current
status
of
proximation,
api
and
envoy
error.
Handing
is
a
crucial
to
every
application.
This
is
why
the
very
first
question
you
might
want
to
ask
is
what
happens
when
things
go
wrong.
So
what
happens
when
extension
fails
at
runtime?
A
So
what
happens?
If
you
try
to
run
this
code,
you'll
find
out
that
until
there
is
recently
nowhere
was
completely
crashing
after
such
a
bug
in
extension
code.
So
apparently
webassembly
sunbox
wasn't
a
true
sandbox
right
now,
android
behavior
has
changed
and
it
doesn't
crash
anymore,
but
it
doesn't
work
either.
A
So
if
we
look
into
the
cost
of
this
error,
it
happens
that
when
panic
is
happening
inside
webassembly
code,
its
execution
gets
terminated
abruptly
without
doing
stack
unwinding.
It
means
that
memory
and
heap
and
locks
are
not
released
and
consequently
it's
not
longer
it's
no
longer
safe
to
use
not
only
a
single
hdb
filter
instance.
A
A
First
of
all,
without
proper
support
for
stack
unwinding
that
should
be
implemented
by
webassembly
engine
and
your
programming
language?
It's
not
possible
to
handle
this
station
gracefully
until
then,
until
such
support
is
implemented,
avoid
panics
in
the
source
code
of
your
extension
and
your
sdk
as
an
example,
we've
designed
envoy
sdk
for
us
to
never
panic.
A
A
A
This
method
itself
return
result
type
instead
of
panicking
and
inside
this
method
we
called
one
of
apis
provided
by
anyway
yeah
like
get
request.
Headers
there's
one
thing
that
you
need
to
know
about
calls
from
extension
into
an
envoy
is
it
all.
Such
calls
can
end
up
with
an
error
and
you
need
to
handle
them
in
some
way.
A
So
as
long
as
your
extension
returns
error
and
not
panic,
we
will
be
able
to
provide
proper
error
handling
logic.
So
for
hd
filters
we
will
reply
with
http
status,
500
internal
service
error
and
for
network
filters.
Ideally,
we
would
close
the
connection
entirely.
However,
it's
not
possible
right
now,
because
proxy
wasn't
abi,
doesn't
support,
closing
connections
just
yet.
A
A
A
So
the
problem
is
that
when
you
with
things
like
http
header,
values
are
not
required
to
be
utf-8
encoded
so
anyway,
we'll
happily
pass
these
values
into
your
extension
and
your
extension
will
crash
while
trying
to
tube
them
as
utf-8
encoded
and
the
problem
is
it's
security.
Vulnerability
attacker
can
crash
your
envoy
or
make
extension
non-operational
by
sending
specific
request
data
so
as
a
solution
in
android
sdk
for
us
we're
using
a
custom
type
bytestream
to
be
very
specific,
very
explicit
about
those
places
where
utf
encoding
is
not
guaranteed.
A
A
A
A
A
Next,
we
want
to
notice
that
we've
gone
a
great
length
to
support
unit
testing
of
extensions
to
test
individual
methods
functions
in
isolation.
We
provide
some
fake
implementations
like
fake
stats,
fake
http
client
for
extreme
info.
On
top
of
this,
we
also
provide
test
framework
that
simulates
in
a
way
request,
processing
flow.
It
might
seem
to
too
much-
and
it
probably
is,
but
it
allowed
us
to
catch
some
blanks
in
proxy
wasn't
spec
and
some
bugs
quirks
in
real
and
way
implementation.
A
So
after
reverse
engineering
and
resources,
we
were
finally
able
to
offer
much
more
friendly
api
for
the
users
of
our
moa
sdk.
For
us,
yeah
like
like
in
this
example
when
you
we,
we
are
now
able
to
provide
strongly
type
api
to
get
from
android
information
about
single
request,
for
example,
connection
id
request,
id
plugin
name
and
finally,
final
thought
about
ergonomics
of
sdk.
A
A
A
So
I've
been
telling
you
how
great
rust
is
how
great-
and
why
is
the
case,
but
now
you're
probably
wondering
like
okay,
show
me
the
code
yeah
just.
Are
there
any
real
extensions
that
has
been
developed
this
way,
and
this
is
like
proud
moment
where
we
can
finally
share
with
you
some
work
that
we've
been
doing
at
the
trade.
So
at
a
trade
we
care
a
lot
about
enterprise
use
case
and
so-called
legacy
software.
A
So
we've
been
working
on
on
something
called
can
be
called
enterprise
suite,
which
consists
of
extensions
and
extensions
that
are
not
cloud
native
they're,
not
hot
technologies,
but
still
they
can
be
quite
useful
in
device
environment
as
an
example.
It's
sncp,
filter
and
ldap
filter
and
more
will
follow.
So
in
the
demo
I
will
show
you
a
smtp
filter,
but
if
you
prefer
ldap
filter
more,
you
can
check
it
out
on
your
own.
A
A
A
A
A
To
envoy,
instead
of
sending
them
directly
into
sntp
server,
and
then
we
will
start
and
avoid
with
our
extension
pre-configured,
so
we're
using
get
new
tool
to
start
and
avoid
with
webassembly-based
extension
in
it.
Getting
away
is
one
of
the
tools
open
source
tools.
We
developed
a
titrate
to
help
you
getting
started
with
developing
webassembly
based
annual
extensions.
A
A
A
A
A
A
Finally,
let's
take
a
look
into
the
source
code
of
invoice
on
cp
filter
itself.
As
you
can
see,
it's
indeed
developed
in
rust
and
it
has
a
structure
hell
well
resembling
structure
of
native
extensions.
We
have
configuration,
we
have
stats,
we
have
filter
itself
and
we
have
it
it's
factory
and
a
filter.
It's
a
network
filter
and
we
override
callbacks
for
to
handle
new
connection
downstream
data
data
from
ctp,
client
and
upstream
data
data
from
sncp
server.
A
B
In
this
part,
I'm
going
to
talk
about
go
sdk
for
proximism
and
its
current
status
and
challenges
in
the
future
commands.
My
name
is
takishi
from
tetrad.
So
let's
begin
with,
why
go
for
proximism
go?
Is
the
one
of
the
most
widely
used
languages
in
the
cloud
native
world
right
and
being
able
to
use
existing
gold?
B
Libraries
or
packages
is
a
very
good
developer
experience
for
western
extensions
and
also
the
number
of
developers
writing
onboard
extension
will
increase
dramatically,
which
is
really
great
for
both
for
convoy,
community
and
the
gold
compiler
community
from
western
perspective.
That's
why
I
started
working
on
this
project,
and
so,
let's
talk
about
compilers.
B
There
are
two
compilers
out
there
which
comply
with
go
language
specification
and
speaking
about
proximism.
It's
not.
The
official
compilers
cannot
be
used
for
producing
proxy,
wasn't
compatible
wineries
yet
because
we
cannot
control
export
sections
and
also
it
assumes
that
the
running
hosting
environment
is
kind
of
ghost
specific
javascript
environment.
B
B
There
is
some
repository
named
proxy,
wasn't
go
sdk
in
patriot
labs.
It
started
as
my
personal
project
and
then
moved
to
the
detroit
labs
and
it
depends
on
tanego
and
also
all
the
examples
in
c
plus
plus
and
the
rust
can
be
re-implemented.
So
it's
usable,
and
so
please
give
it
a
try
and
also
it
supports
envoy
host
emulation
for
unit
testing,
so
which
means
you
can
use,
go
test
command
for
testing
your
filters
or
extensions
without
running
onboard
processes.
B
This
is
really
great
for
developers
because
we
can
develop
on
our
extension,
just
like
you
do
with
the
native
applications.
So
what
are
the
challenges
we
are
facing?
And
the
first
is
that
our
some
of
the
existing
libraries
are
not
supported.
Yet
there
is
several
reasons,
but
the
some
of
the
system
codes
are
not
not
available
in
tangio
or
proxy,
wasn't
c,
plus
plus
host
and
for
example,
you
cannot
use
script
run
package
or
you
cannot
use
os.getm
and
also
time.now.
B
These
are
the
they're
not
available
currently,
but
they
will
be
supported
and
also
reflection.
Packages
is
not
free,
it's
not
fully
supported
by
tango,
so
you
cannot
use
json
package,
but
this
is
highly
demanded.
So
I'm
going
to
work
on
this
and
also
garbage
collection
is
re-implemented
in
tanio,
which
is
totally
different
from
the
official
garbage
collection
and
it
uses
simple
conservative
merchant
sweep
and
it
needs
to.
I
think,
it's
necessary
for
us
to
assess
performance
impacts
on
fluxivism.
B
Maybe
we
gotta
develop
our
own
gc
algorithm
tailored
for
proxy
version
and
also
goroutine
is
almost
unavailable.
Taningo
uses
another
vm
called
routine,
but
no
schedulers
runs
by
default
in
the
event
driven
and
the
thread
local
vms
in
envoy.
So
you
could
use
go
keyword,
but
no
one
can
predict
when
this
go
routine
will
be
run
or
things
like
that.
B
So
what's
next
contributing
back
to
tanigo
and
the
reflection
package,
implementation
or
other
system
core
support
in
order
to
in
order
to
be
able
to
use
existing
goal,
libraries-
and
also
we
need
to
do
some
gc
performance
analysis
have
been
working
on
this
and
also
may
we,
as
I
said
we
may
be,
we
have
to
have
custom
gc
for
proxy
western
and
also
google
routine
support.
In
order
to
do
that,
we
must
answer
questions
like
how
to
deal
with
go
routine
and
the
thread
local
wasn't
vm
executed
in
the
event
driven
manner.
B
B
There
are
four
languages
out
there,
and
also
you
can
contribute
to
the
community
by
developing
sdk
for
your
own
favorite
languages,
and
also
there
is
get
amber
project
that
you
can
use
that
you
can
easily
get
started
with
wasm
extension.
We
accumulated
lessons
learned,
so
please
give
it
a
shot
and
also
join
our
community
and
give
us
your
feedbacks.