►
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Adopting JavaScript on WebAssembly at Shopify - Saúl Cabrera, Shopify
Server-side WebAssembly is at the core of platform extensibility at Shopify. It enables third-party developers to extend the platform with synchronous custom business logic. Programming language support is one of the fundamental pieces to get right for a platform that is built on top of WebAssembly. The programming language options available are constrained by the use-case requirements. In Shopify's case, developers should be able to write programs using familiar tooling (Node and TypeScript), programs should be safe and their execution should be extremely fast: merchant's complex code needs to be able to run in 5ms or less. In this talk, Saúl will share Shopify's language support journey and showcase how they used Wizer (https://github.com/bytecodealliance/wizer) and QuickJS (https://bellard.org/quickjs/) to make it possible to run JavaScript on WebAssembly while meeting Shopify's performance requirements.
A
Hello,
I'm
saul,
and
I
work
at
shopify
in
the
scripps
team,
making
commerce
extensible
with
webassembly
in
this
talk
I'll,
walk
you
through
our
adoption
of
javascript
as
the
primary
language
for
the
scripts
platform
before
getting
into
any
other
technical
details
or
I'll
briefly
explain,
shopify's
use
case
and
the
role
that
web
assembly
plays
in
it
webassembly
power,
shopify
scripts
platform.
This
platform
is
responsible
for
enabling
third
synchronous,
third-party
business
customizations
to
shopify.
A
From
this
definition,
we
can
highlight
three
main
concepts
that
come
into
play:
synchronous,
third-party
and
portability
and
developer
experience
synchronous,
because
script
customizations
are
synchronous.
This
means
that
they
are
normally
executed
in
the
context
of
an
already
existing
request.
This
means
that
they
need
to
be
extremely
fast
in
order
to
avoid
delaying
the
request
that
they
are
executed
in.
In
fact,
one
of
our
slos
is
to
execute
scripts,
execute
the
most
complex
scripts
in
five
milliseconds
or
less.
Then
we
have
third
party
by
definition.
Customizations
are
written
by
third-party
developers.
A
This
means
that
their
code
isn't
safe
and
untrusted,
so
this
code
needs
a
sandbox,
and
then
we
have
the
concept
of
portability
and
developer
experience.
We
want
to
ensure
that
developers
writing
scripts
can
use
the
tools
that
they
are
most
familiar
with.
All
these
concepts
make
webassembly
a
perfect
fit
for
shopify's
use
case
now.
Most
of
our
research
to
support
javascript
was
fueled
by
the
desire
to
improve
developer
experience
to
maximize
developer
experience.
A
A
The
second
one
are
languages
that
are
designed
exclusively
for
webassembly
and
then
the
third
one
are
languages
that
require
the
language
runtime
to
be
compiled
to
webassembly.
So
let's
look
at
each
of
them.
Languages
that
offer
native
support.
These
normally
are
languages
that
are
considered
system
programming
languages,
and
you
can
think
here
of
languages
like
go
c,
plus,
plus
c
rust,
sig,
etc.
These
languages
have
pros
and
cons
in
terms
of
developer
experience
and
and
performance,
so
the
process
in
terms
of
of
performance
is
that
they
offer
good
performance.
A
They
offer
native
support
for
web
assembly
and
they
are
mature.
Then
the
con
is
that
they
have
sometimes
a
high
learning
curve.
This
means
that
they
are
not
as
approachable
for
developers
that
just
want
to
write
general
purpose
apps.
For
example,
then
we
have
languages
that
are
designed
exclusively
for
web
assembly.
They
normally
offer
some
sort
of
decent
performance,
but
they
have
some
cons
in
terms
of
developer.
Experience
like
they
lack
editor
support,
libraries,
debugging,
etc,
and
the
other
con
that
can
affect
developer
experience
is
maturity.
A
A
The
pros
in
this
bucket
are
that
they
are
these
languages
are
often
mature
and
that
they
offer
a
lot
of
developer
experience.
Many.
They
are
widely
known
by
most
the
developers
out
there,
but
the
disadvantage
is
that
they
are
probably
not
as
performant,
especially
when
embedded
in
a
context
like
web
assembly.
So
this
means
that
choosing
these
kind
of
languages
generally
involves
assuming
some
sort
of
performance
trade-off.
A
Now,
let's
talk
about
the
road
to
javascript
and
how
these
buckets
come
into
play
as
a
team,
we
started
seeing
that
the
languages
in
the
third
bucket
in
which
you
near
runtime,
might
be
the
best
bet
if
we
were
to
maximize
for
developer
experience
and
if
we
were
to
have
a
calculated
risk
on
the
amount
of
performance
trade-offs
that
we
could
make
so
in.
In
theory,
when
we
started
exploring
this
a
bit
less
of
performance
might
mean
more
gains
in
other
areas
like
developer
experience,
and
then
it
comes.
A
In
order
to
make
javascript
possible
in
our
platform,
we
had
to
rely
on
two
essential
tools:
the
first
one
is
quick
js,
which
is
a
small
and
embeddable
javascript
engine.
This
means
that
it's
performant
in
environments
that
don't
support
just
in
time
optimizations
like
wasm.
So
that
was
one
of
the
main
reasons
why
we
chose
it.
A
Then
there
are
other
minor
reasons
like
it's
written
in
c,
and
its
code
base
is
easily
compiled
web
assembly,
but
in
the
future,
it's
likely
that
we
want
to
experiment
with
other
engines
like
spider,
monkey
or
v8
other
alternatives
to
engines
that
could
be
compiled.
Web
assembly
which
are
targeted
for
you
know,
embedded
systems
or
smaller
places
are
the
hermes
engine.
Is
the
one
responsible
for
making
react
native
possible,
but
that's
gonna,
see
that's
gonna,
be
something
that
we're
going
to
see
in
the
future.
A
The
second
tool
that
is
essential
to
make
javascript
work
is
wiser,
which
is
defined
as
the
web
assembly.
Pre-Initializer
wiser
is
a
tool
that
improves
startup
latency
of
webassembly
modules.
The
overall
idea
behind.
Why
is
to
record
the
state
of
a
module
instance
and
rewrite
that
state
into
a
new
module?
So
let's
take
this
example,
we
have
module
8.wasm.
A
Some
expensive
work
that
we
don't
want
to
run
every
time
that
we
have
to
execute
the
module
when
that
function
executes
the
state
of
the
current
module
8.1
in
this
example,
changes
when
that
state
changes
that
state
gets
recorded
and
gets
rewritten
into
a
new
module
in
this
case
b,
dot
wasn't
so.
There
are
important
things
that
we
need
to
consider
here.
A
The
exported
function
is
crucial
to
make
wiser
work
so
that
function.
It's
it's
a
function
that
exports
work,
that
you
know
that
can
be
done
ahead
of
time
and
then.
The
second
point
that
it's
important
to
note
is:
what's
the
state
of
a
module
normally
wiser,
looks
for
globals
memories
and
instances
as
the
state
of
the
module.
A
Now,
let's
look
at
more.
Let's
look
to
a
more
concrete
example:
let's
assume
that
we
have
this
piece
of
rose
code
that
is
doing
some
expensive
operation.
In
this
case,
we
are
calculating
fibonacci
of
12.,
and
let's
assume
that
we
already
know
beforehand
that
we
want
to
calculate
fibonacci
of
12
every
time
so
by
using
wiser,
we
could
export
a
function
called
init,
that's
going
to
be
renamed
to
wise
or
initialized
when
it
compiles
to
webassembly
that
is
going
to
calculate
fibonacci
of
12..
A
So
when
we
execute
wise
from
this,
weisser
is
going
to
execute
this
block
of
code.
When
this
block,
when
this
block
of
code
gets
executed,
expensive
value
is
going
to
get
assigned
to
a
fibonacci
of
12
to
the
result
of
fibonacci
of
12.,
and
then
the
state
is
going
to
change
and
that
state
is
going
to
get
rewritten
to
a
new
module.
Now,
when
you
execute
a
new
module,
expensive
value
won't
need
to
be
recalculated
again.
A
Now,
let's
go
a
bit
more
into
detail
so
by
inspect,
let's
inspect
the
two
modules,
eight
or
wasm
and
v
dot.
Wasn't
I
mentioned
before
that
state
is
composed
of
globals
memories
and
instances
we're
going
to
look
into
instances
because
that's
mostly
related
to
module
linking
and
it's
something
that
we
are
not
dealing
with
at
shopify
at
the
moment.
So
the
global
software
doesn't
look
like
this.
They
are
three
and
now
we
have
the
globals
of
b.
Wasn't
they
are
the
same?
A
A
Segments
in
web
assembly
are
elements
that
are
used
to
initialize
the
memory
either
manually
through
an
instruction
or
at
instantiation
when
we
do
one
or
the
other,
it
depends
on
the
type
of
segment
if
it's
active
or
passive.
In
this
case,
they
are
active,
so
they
are
used
to
initialize
the
memory
on
instantiation.
So
before
applying
wiser
to
a
webassembly
module,
we
can
see
that
we
have
one
segment
that
is
pointing
to
a
specific
location
in
memory.
Once
we
do
apply
wiser,
we
can
see
that
wiser
created
a
new
segment.
A
This
segment
is
recording
the
work
that
was
done
when
the
initialized
function
was
executed.
So
this
means
that
when
the
webassembly
module
is
initialized,
this
segment
is
copied
into
the
module
memory
and
is
already
accessible
for
the
program
to
use
it
without
having
to
rerun
that
expensive
operation.
Again
now
you
might
ask
yourself:
how
does
this
apply
to
javascript?
A
So
these
are
two
things
that
we
know
ahead
of
time
that
need
to
happen
every
time
that
you
execute
a
javascript
program,
for
example.
So
these
are
the
two
things
that
we
could
use
wiser
to
optimize
and
how
it
looks,
let's
say
in
a
pseudo
code
manner:
it's
like
this,
so
we
have
a
js
engine
variable
global
variable
that
is
going
to
be
set
to
initializing
a
default
engine.
That
could
be
anything
in
our
case.
It's
quick
js,
and
then
we
run
this
wiser
initialize
function.
A
That
would
make
sure
that
this
engine
is
initialized
correctly
when
we
want
to
execute
code.
This
means
that
when
we
want
to
run
code
that
the
user
has
given
us,
we
go
to
the
run
function
and
we
just
get
the
engine
that
has
already
been
initialized
and
then
evaluate
whatever
code.
We
want
to
evaluate.
So
with
this
approach,
we've
seen
a
50
performance
improvement
in
start
time
by
using
wiser
and
quick
js.
So
this
is,
you
know,
pretty
impressive,
given
that
all
rslos
are
very,
very
aggressive,
so
by
benchmarking,
a
simple
fibonacci
program.
A
A
Here
we
can
see
that
we
have
some
development
development
dependencies
which
are
pretty
normal,
and
then
we
have
a
couple
of
scripts.
The
first
one
is
compile,
which
would
only
trigger
typescripts
compiler,
and
then
we
have
build
this
build
compiler
invokes
webpack
webpack
will
do
all
its
magic
to
transform
our
project
into
a
single
javascript
file.
A
A
A
Now,
if
we
go
back
to
our
package
solution
file,
we
can
see
that
after
invoking
webpack,
we
invoke
something
called
javi
and
then
we
pass
in
the
final
index
file
and
we
pass
it
a
location
where
to
output
the
final
wasm
file,
so
javi
is
the
tool
chain
that
will
build
that
wraps,
quick
js
and
then
that
is
in
charge
of
taking
the
user's
code
and
bundling
that
into
a
webassembly
file.
So,
let's
see
what
the
code
looks
like.
A
A
A
A
A
After
having
take
a
look
at
the
demo,
let's
now
talk
about
trade-offs,
talking
about
trade-offs
is
important,
because
not
everything
is
roses.
I
mean
there
are
several
things
that
we
are
giving
up
in
order
to
gain
other
things,
and
here
is
many
performance
like
if
your
use
case
requires
to
be
the
most
performant
use
case,
and
you
don't
care
about
developer
experience,
then
javascript
is
probably
not
the
fastest
option
available.
It's
probably
not
the
best
option
for
you
in
fact,
most
instances
of
of
our
benchmarks.
A
We
saw
a
performance
impact
of
400
to
600
microseconds,
so
this
means
that
our
javascript
programs,
where
around
400
or
600
microseconds,
is
lower
than
those
written
in
assembly
script.
This
is
still
fine
for
us,
because
everything
is
running
under
our
slos
to
be
a
bit
more
concrete.
There
are
several
aspects
that
we
know
that
developers
are
going
to
use
in
in
the
programs
that
they
write
for
the
shopify
platform
that
we
wanted
to
inspect
and
assembly.
Script
was
faster
in
things
like
floating
point,
arithmetic
and
string
operations.
A
Now
not
everything
is
bad.
We
also
had
games
us
and
mainly
those
gains
where
around
tooling
language
features.
Now
we
can
access
all
the
most
recent
features
of
typescript
or
javascript,
and
then
we
have
a
huge
community
in
ecosystem
from
the
javascript
and
typescript
world.
So
this
is
important
and
also
not
surprising.
We
had
some
gains
in
terms
of
performance
too.
It's
important
to
note
that
javascript's
regex
implementation
was
almost
twice
as
fast
than
the
one
that
is
currently
written
in
the
same
script.
A
To
conclude
the
talk,
I
would
like
to
end
up
with
this
general
idea:
we've
been
after
exploring
with
javascript
and
webassembly.
We've
been
seeing
that,
by
doing
this,
by
having
this
approach
in
use
cases
that
can
afford
it,
the
mix
of
high-level
languages
plus
web
assembly
gives
a
result
of
more
secure,
more
performant
and
better
developer
experience
in
apps
again,
I'm
making.
I
have
here
this
start
just
to
remind
myself
that
this
statement
is
relative
to
our
use
case,
but
could
be
evaluated
for
other
use
cases
too.