►
From YouTube: Lightning Talk: Migrating from JS to WASM in production and living to tell the ta... Corentin Godeau
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Lightning Talk: Migrating from JS to WASM in production and living to tell the tale - Corentin Godeau, Lumen
Here at Lumen, we develop software to help video streaming platforms scale to millions of viewers and provide top-notch quality to audiences. As video streaming soared last year, we embarked on a journey to improve the performance of one of our core offerings - a client-side CDN load balancer. In this talk, we explain how we migrated our legacy JavaScript codebase into C++ targeting WASM for the web. We discuss how we overcame the differences in paradigm between JS and WASM. We explore the constraints WASM presented when ensuring compatibility with native and how that shaped our code architecture. We also look at the tooling we used to debug the code that went into production and share some practical insights into memory management and the battle scars that you can avoid if you plan to take on this kind of project yourself.
A
A
However,
I
won't
mention
wasm
outside
of
the
browser,
and
I
want
you
to
keep
in
mind
that
what
I
will
be
presenting
is
not
a
magical
recipe.
It
works
in
our
case
and
is
simply
a
feedback
from
our
experience.
But
first
let
me
do
a
bit
of
history.
Le
mans,
formerly
known
as
centurylink,
is
a
technology
company
providing
infrastructures
and
platforms
for
companies,
one
of
our
projects,
cdn
mesh
delivery,
leverages
peer-to-peer
technology
to
improve
qos
and
reduce
cdn
bandwidth
in
the
video
delivery
pipelines
of
our
clients.
A
A
Talking
about
motivations
here
are
additional
key
points
that
convey
stats
to
migrate
from
javascript
to
c
plus,
plus
and
target
wasn't.
First,
we
wanted
to
have
a
single
code
base
targeting
the
majority
of
platforms,
including
web.
Then
we
wanted
to
be
able
to
fully
exploit
the
hardware
capabilities
of
native
platforms
and
finally,
some
of
our
algorithms
were
pretty
complex
and
compute
intensive
for
the
rest
of
this
tool.
A
Now
that
I
did
the
introduction,
let's
dive
more
on
the
technical
side,
javascript
and
wasm
have
pretty
different
paradigms,
and
here
are
the
key
differences
between
them
on
one
side.
Javascript
is
an
interpreted
high-level
language,
strongly
asynchronous
and
internally,
based
on
an
event
loop,
it's
very
popular
and
deeply
integrated
in
modern
browsers.
On
the
other
side,
bosum
is
presented
as
the
web
equivalent
of
native
assembly
language.
Thus
it's
very
different
from
javascript.
A
It's
a
very
low
level
language,
targeting
a
stack-based
virtual
machine.
It's
designed
to
be
called
from
javascript
in
synchronous
manner.
These
main
differences
have
strong
implications
on
how
we
should
approach
a
code
based
design
concerning
the
differences
between
compiling
to
wasm
and
compiling
to
native
platforms.
Here
are
the
key
differences
due
to
the
way
that
most
javascript
engines
work,
a
mismodel,
threaded
and
non-preemptive
all
caused,
wasn't
function
or
blocking
and
must
return
before
letting
any
other
javascript
code
to
execute.
A
On
the
contrary,
native
platforms
can
be
mondo
or
multi-threaded
and
are
almost
always
preemptive,
meaning
that
threads
of
execution
can
stop
in
the
middle
of
a
function
and
continue
execution
later
letting
time
for
other
processes
to
run.
As
you
can
imagine,
this
will
also
have
strong
implications
on
how
you
should
approach
your
code
based
design.
A
A
Now
that
you
have
a
clear
understanding
of
the
differences
between
our
target
platforms,
I
will
be
giving
some
advice
that
successfully
helped
us
deploying
wasn't
mean
production.
Let's
start
with
the
project
architecture
advanced
in
the
case,
you
have
a
modular
design.
You
want
to
have
an
agnostic,
interface
and
platform,
specific
implementations.
That
way
you
will.
You
won't,
have
to
be
aware
of
the
platform
you're
running
on
when
working
on
the
core
part
of
your
project.
A
One
way
to
achieve
this
is
to
leverage
the
power
of
your
build
system
to
automatically
dispatch
to
the
correct
implementation,
depending
on
the
platform
you
are
compiling
to
here
is
an
example
from
our
code
base.
This
is
the
module
that
handles
everything
related
to
http
cores.
As
you
can
see,
our
agnostic
interface
is
has
exposed
headers
in
the
include
directory.
A
We
have
the
common
code
in
the
command
directory
and
you
have
one
directory
for
the
native
platform
such
as
android
and
ios,
and
one
directory
for
the
web
platform
when
compiling
to
wasm
our
build
system
automatically
selects
the
web
folder
to
build
sources
now
under
code
based
general
design.
We
suggest
to
to
design
your
common
apis
with
an
asynchronous
mindset.
A
This
may
seem
strange
since
wasn't
called
a
synchronous,
but
disability
resides
in
the
fact
that
most
interaction
you
will
have
with
the
browser
and
the
javascript
apis
will
be
a
synchronous.
You
will
be
called
back
later
with
the
result
of
what
you
asked
for,
but
first
you
need
to
return
from
the
wasm
function.
A
Designing
your
apis
around
callbacks
is
a
good
way
of
achieving
this
goal.
Please
note
that
even
if
on
native,
these
apis
behave
in
a
synchronous
manner,
it's
not
really
an
issue
in
practice,
and
you
want
to
add
that
to
the
more
constrained
platform
still
on
the
code
based
design
aspect,
we'd
suggest
you
to
take
inspiration
from
the
actor
model
to
design
the
main
modules
of
your
project.
A
In
a
nutshell,
the
actor
model
is
a
way
of
designing
your
code
base
around
the
idea
that
each
module
has
its
own
state
and
communicates
with
other
modules
using
messages.
What
made
it
really
suited
for
our
constraints
is
that
it
can
easily
be
adapted
to
fully
exploit
the
hardware
capabilities
of
the
various
platforms
we
plan
to
target.
A
A
Now,
let's
talk
about
debugging,
if
you
have
the
possibility
to
do
so,
we
strongly
suggest
you
to
do
your
debugging
on
native
platforms,
even
though
the
beginning
was
them
on.
Chrome
is
possible.
If
you
build
your
project
with
debug
flags,
the
support
is
still
young,
not
verbal,
and
rely
on
an
extension
to
work
properly.
A
A
Finally,
here
is
a
small
list
of
useful
flags
to
use
when
compiling
using
gmc,
which
is
the
em
script
and
c
and
c
plus
plus
compiler
dash
aussie
to
optimize
for
code
size,
wasn't
binary,
have
the
bad
reputation
of
being
bigger
than
their
javascript
equivalent
and
that's
true
in
practice,
there's
just
profiling.
This
will
keep
the
function
names
in
the
output
binary
and
let
you
do
profiling
on
chrome,
using
the
dev
tools
dash
dash
memory
profiler.
A
This
will
add
an
overlay
to
the
page,
giving
very
interesting
information
on
memory,
fragmentation,
biggest
allocation
set
and
most
frequent
allocation
sites.
If
memory
footprint
is
a
concern
for
you,
this
will
be
very
helpful
and
finally
dash
closure
1.
This
will
enable
the
closure
compiler
to
optimize
the
javascript
blue
code
generated
by
em
scripter.
A
In
conclusion,
I
present
a
few
key
points
that
help
us
successfully
deploy
the
wasm
in
production,
but
this
list
is
far
from
exhaustive.
I
simply
kept
the
more
important
ones.
Please
keep
in
mind
that
wasm
is
still
a
very
young
target
and
thus
moves
really
fast.
The
unscripted
documentation
is
not
finalized
and
you
will
often
have
no
other
other
choice
than
finding
the
correct
solution
by
trial
and
errors.