►
Description
Serverless Front-End Deployments Using npm - Charlie Robbins, GoDaddy
Front-end operations is the first line of defense between your customers and the bugs that impact them the most: user experience bugs. Yet front-end deployments almost always require deployments from their associated server-side services. Given the huge presence that npm in the workflow of front-end developers it is only natural then that these deployments be handled using an "npm publish" workflow. In this talk we will discuss such a system, Warehouse, as well as the associated challenges in Node.js for automating builds of front-end packages: - Automating "npm install" - Distributed systems & microservices - Proxying npm requests & the npm wire API - Unsung features of npm: "npm dist-tag"
About Charlie Robbins
Charlie is the Gold Director of the Node Foundation, and a Director of Engineering at GoDaddy where he is leading convergence around JavaScript and Node.js across several products through the UX Platform. Charlie was previously the founder and CEO of Nodejitsu (acquired by GoDaddy in 2015). An open source enthusiast and community builder, he is the author of many popular Node libraries, the creator of the EmpireJS and EmpireNode conferences in New York City, and an advisor to several technology startups. Charlie is a graduate of McGill and holds a Master's degree from Columbia University.
A
A
So
this
exists
about
six
hours
west
of
here
in
a
place
called
Marfa
Texas
is
actually
a
Prada
store,
actually
in
Marfa
Texas
actually
involved
in
the
act
of
serving
right
deployment
is
all
about
serving
new
functionalities
to
your
visitors.
Now
most
node.js
front-ends
work
in
the
following
way.
You
have
some
code
asset
that
you've
written,
probably
your
react
or
angular,
or
you
know
whatever
jQuery
app
that
exists
somewhere
and
you
push
that
onto
your
server
and
that
is
co-located
with
the
actual
server
right.
A
So
if
anybody
knows
what
I'm
talking
about
they've,
probably
seen
things
that
look
like
this,
you
have
some
Express
app.
You
serve
up
the
static
middleware
inside
of
your
HTML
somewhere.
You
have
a
link
to
you
know
something
that
is
relative
to
your
URL
write
that
slash.
There
is
significant,
and
the
problem
with
this
is
that
any
change
to
your
front-end
requires
a
server
change.
So
you
need
something
like
this
and
I.
A
Don't
actually
mean
a
low
orbit
ion
cannon
of
some
sorts,
although
ion
cannons
very
useful,
it
makes
using
a
CDN
imperative
to
get
any
sort
of
service
deployment
going,
because
otherwise
your
assets,
your
actual
code,
front-end
assets,
are
associated
with
your
back-end
project,
they're
totally
coupled
every
deployment
you
deploy
both
of
them.
So
a
simple
change
would
take
our
old
app
that
has
that
app
dot,
min
dot
J's,
that's
relative
to
our
URL
and
replace
it.
A
A
So
what
does
a
version?
2
asset
look
like
well,
you
could
think
of
something
like
semantic
versioning,
which
you
use
every
day
with
node.
You
can
use
that
another
way
to
think
about.
It
is
to
use
some
sort
of
sha
compiled
from
the
asset,
and
this
turns
out
to
be
the
best
way
to
version
your
assets,
because
it's
almost
always
unique.
A
It
doesn't
have
to
change
over
time,
and
it
also
can
be
really
useful
when
you're
trying
to
find
assets
like,
for
example,
if
you
have
10
assets
and
one
of
them
didn't
change
it
between
two
versions.
Now
you
can
use
the
same
CDN
location.
You
can
use
the
same
cache
that
exists
in
your
users,
browsers.
You
don't
have
to
change
that,
just
because
you've
incremented
the
version
of
your
application.
A
So
with
this
in
mind,
how
do
we
approach
serverless
deployments?
Well
that
diagram
we
had
before
looks
a
little
bit
differently.
You
push
your
assets
into
your
CDN
and
at
some
point
your
app
queries,
something
to
say,
hey
well
what
assets
should
I
serve
right
now?
What
should
I
put
in
my
scripts
and
linked
tags
that
exist
on
the
page,
and
then
you
ship,
those
down
to
your
customer
and
instead
of
getting
those
from
your
server
they're,
getting
them
from
the
CDN.
But
the
real
question
is:
how
does
the
server
receive
new
versions?
A
A
But
in
order
stand
this
in
sort
of
a
philosophical
sense,
you
know
feel
the
force
you
you
have
to
know
what
production
means
and
there's
a
lot
of
things
about
production,
but
the
end
of
the
day,
most
apps
on
the
web
end
up.
Looking
like
this,
that
is,
they
were
beautiful
at
one
point,
but
you
had
to
ship
it,
and
so
you
know
the
bird
poop
piles
up
over
time
and
that's
fine.
A
lot
of
reasons
why
you're
gonna
get
that
sort
of
stuff
is
internationalization,
which
introduces
a
very
complex
problem.
A
You
know,
no
matter
how
good
your
automated
build
system
is.
Once
you
introduce
a
large-scale
internationalization
process
into
your
application
deployment,
you
are
going
to
need
some
sort
of
visual
verification.
I,
don't
care
how
good
of
a
developer
you
are.
You
do
not
speak
tunnel
I,
don't
speak!
Tamil
I,
don't
speak
Chinese!
You
need
translators,
so
we're
gonna
go
over.
Do
the
verification
make
sure
your
translations
are
correct?
A
You
can
automate
that
to
a
certain
extent,
but
you
need
some
sort
of
verification
process
there,
so
that
by
definition,
means
that
you're
going
to
have
multiple
environments.
You're
gonna
have
some
dev
or
test
environment
that
your
app
lives
in
for
a
short
period
of
time.
Hopefully
you
know
on
the
order
of
minutes
or
hours
and
you're
also
going
to
need
to
support
some
sort
of
promotion
or
rollback.
So
you
know
digesting
all
of
this
in
your
head.
A
That
means
that
serverless
front-end
deployments
requires
an
external
service,
knowing
what
versions
should
be
running
in
what
environments
for
any
or
all
locales?
So
that's
a
lot
to
grok
I
get
it,
but
we're
gonna
keep
going
at
this
point.
You
might
be
feeling
a
little
bit
like
this
and
you
know
we're
getting
there.
We
are.
We
are
getting
there.
So
let's
talk
a
little
bit
about
NPM
right,
so
how
many
people
have
used
NPM
here,
everybody
should
be
raising
hands.
A
So
what
you
might
not
know
is
that
the
actual
NPM
registry
was
written
by
this
gentleman
and
that
exists
today
in
a
thing
called
NPM
registry
couch,
app
aka.
This
thing
that
I
hacked
together
in
a
weekend
according
to
Michael
and
he
did
hack
it
together
in
a
weekend.
I
remember
happened
and
that
is
all
running
on
cache
DB,
but
that's
not
super
important.
What
is
important
is
understanding
the
protocol
that
it
exports
and
the
best
source
for
that
is
actually
still
in
that
document.
A
So
what
you
have
here
is
the
rewrites
for
the
couchdb
app
so
you'll
notice
that
there
are
things
like
/
:
package,
/
attachment,
that's
how
you
fetch
attachments
friend
p.m.
today
right
you
would
go
and
say
get
I,
don't
know
my
module
/
/!
You
know
1.2.3
dot,
T,
GZ
and
you'll
fetch
that
asset,
that's
how
that
works.
So,
if
you're,
looking
for
good
documentation
on
how
the
wire
protocol
works,
the
NPM
registry
catch
app
is
still
probably
the
best
documentation
out
there.
A
That
rewrites
file
today
is
still
the
gospel
is
still
how
NPM
works.
I
haven't
found
a
better
source
of
documentation.
You
can
also
try
it
out
yourself.
So
if
you
run
this
NPM
cset
log
level
info,
you
might
want
to
turn
off
your
spinner,
because
it's
gonna
be
a
lot
of
output.
You'll,
be
able
to
see
all
the
HTTP
requests
that
NPM
is
making
behind
the
scenes.
So
walk
you
through
a
few
of
those.
If
you
right
and
can
view
package,
that's
gonna
call
get
package.
A
If
you
run
and
Tim
view
package
at
version,
you're
gonna
get
package
at
version.
If
you
do
and
compact
package
that'll
I
should
download
the
tarball
for
you,
so
that's
gonna
fetch
the
attachment.
You
can
also
use
dist
tag,
which
I
don't
think
most
people
are
familiar
with.
Anyone
familiar
with
this
tag
raise
your
hand.
Okay,
that's
about
what
I
expected.
A
Npm
diss
tag
is
a
very
underutilized
feature
of
NPM.
So
every
time
you
publish
something
to
NPM
that
becomes
the
dist
tag
of
latest
and
when
you
try
to
install
something
from
NPM,
it
goes
and
it
tries
to
install
the
latest
diss
tag.
So
if
you
have
any
say,
you're
gonna
install
react,
CLI
or
ember
CLI
globally,
it's
gonna
always
install
the
latest
disk
tag
so
NPM
themselves.
They
actually
have
multiple
disk
tags
for
their
deployments
or
I
should
say
versions.
They
have
three
latest
latest
latest
and
that's
how
they
manage
multiple
trees.
A
You
can
think
of
them,
sort
of
like
I,
don't
know
get
tags
or
get
branches,
it's
not
a
perfect
analogy,
but
it's
a
good
way
to
think
about
it,
and
that
is
probably
the
most
complicated
URL
that
exists
there.
There's
also,
of
course,
and
can
publish,
which
is
just
a
put,
but
what's
inside
the
put
is
what's
actually
most
interesting,
because
when
you
dig
underneath
the
covers
the
NPM
publish
payload,
which
you
can
view
yourself.
A
If
you
want
to
understand
it
a
little
more
by
installing
this
thing
called
registry
echo
I'll,
let
anybody
who's
interested,
go
and
visit
that
page
and
check
it
out.
You
will
see
something
like
this,
so
this
is
an
actual
publish.
This
is
a
test
publish
that
I
did
the
other
day,
just
to
make
sure
that
all
of
this
was
still
the
same
in
the
correct
and
so
you'll
notice
that
you
know
there's
the
name
of
my
package
test
published
0
3,
which
is
the
same
as
the
name
has
a
description.
A
It
has
a
disc
tag
of
latest,
which
is
the
same
version
that
I'm
publishing
inside
of
that
there
is
a
versions
object
which
has
only
one
version,
one
and
always
one
that's
getting
deployed,
and
that
has
the
same
version,
which
has
some
duplicated
information
there.
It
has
all
the
other
things
that
you'd
expect.
You
know
the
author,
the
scripts,
the
truncated
readme,
but
it
also
has
some
really
interesting
meta
properties.
A
So,
if
you're
running
npm
publish
inside
of
a
git
directory,
it
gives
you
the
get
head
so
that
Shaw's
included
every
time
that
a
publish
comes
to
you.
It
also
includes
the
entire
asset
so
down
there
at
the
bottom,
where
it
says
big,
base64
tarball,
that's
the
actual
tarball
that's
getting
published
at
NPM.
It
all
gets
included
in
one
JSON
document.
This
makes
this
an
incredibly
useful
deployment
tool.
If
you
wanted
to
do
things
with
this,
so
what
can
we
do
with
this?
A
You
know:
how
can
we
turn
this
into
an
assembly
line
of
things
that
become
a
pretty
useful
developer?
Workflow?
So,
let's
suppose
that
you
wanted
to
build
something
right
going
back
to
what
we
talked
about
before
you
need
to
think
about
rollback.
You
need
to
think
about
new
environments.
You
need
to
think
about
triggering
builds,
so
all
of
these
things
can
be
modeled
as
individual
NPM
commands.
So
if
you
want
to
trigger
a
new
build,
you
can
NPM
publish
if
you
want
to
promote
or
rollback
a
build.
You
can
dis
tag
right.
A
A
Lastly,
if
I
wanted
to
see
what
bills
were
in
what
environments
to
make
sure
that
you
know
one
point
two
point
three
was
in
production,
but
one
point:
4.0
was
in
test
because
we're
gonna
deploy
that
tomorrow,
I
can
run
NPM
diss
tag,
LS
every
got
it
workflow
makes
sense.
Okay,
so
that's
what
we've
built
so
this
project,
warehouse
AI,
enables
serverless
deploys
of
your
front-end
code
by
providing
automated
builds
push
to
any
s3
compatible
CDN
through
that
NPM
workflow
that
we
just
talked
about.
A
So
what
does
this
look
like
underneath
the
covers
to
talk
about
real
software
looks
a
little
bit
like
this.
So
warehouse
is
an
end,
cam
publish
proxy,
which
means
that
it
receives
all
your
publishes.
You
publish
to
it.
It
then
will
put
that
into
any
NPM
registry
behind
the
scenes.
So
it
is
not
a
private
registry.
It
is
a
proxy
to
a
registry.
A
It
then
triggers
a
build
for
your
asset
that
you
want
it
to
publish
and
it
will
trigger
that
in
any
locales
that
you've
configured
so
at
GoDaddy
we
run
about
about
500
builds
a
day
using
this
it
we
have
to
build
and
I
think
38
locales.
So
every
time
we
push
something
out,
there's
38
builds
that
are
triggered
a
lot
of
that
has
to
do
with
how
a
Croma
402
works.
B
A
So
it's
back
by
Cassandra,
so
if
you
haven't
run
Cassandra,
it's
a
little
bit
tricky,
but
that's
one
of
the
things
that's
on
our
roadmap
is
to
make
it
work
with
leveldb,
because
the
way
that
we're
indexing,
all
these
files
is
actually
really
not
tied
to
Cassandra.
It
just
happens
to
be
the
database
back-end
that
we
run.
A
We
store
metadata
about
your
packages
that
are
running
in
what
locales
things
about
your
dist
agz
things
about
the
actual,
build
assets
beyond
that,
though,
it's
running
a
couple
of
services,
there's
three
services
to
run
one
more
than
the
diagram
I
had
back
there.
They
spin
up
pretty
quickly.
We
literally
just
put
this
out
today,
so
getting
it
to
run
easily
for
folks
like
you
and
the
audience
is
probably
our
top
priority
as
an
open
source
project.
So
if
you
have
problems
running
it,
we
want
to
hear
about
it
want
to
make
that
easier.
B
D
So
it
seems
like
it
might
be
possible
for
for
your
server
version
and
your
JavaScript
versions
to
have
some
kind
of
coupling
like.
Let's
say
if
you
bootstrap
data
from
from
the
server
version
on
to
the
page
four
to
be
available
for
the
JavaScript
right
away.
Is
there
ever
scenario
that
you
guys
have
had
to
deal
with
where
you
have
to
rollback
your
server
to
a
specific
version,
and
that
also
requires
kind
of
matching
that
version
to
particular
JavaScript
assets?
We.
A
A
Have
not
we
do
a/b
testing
a
little
bit
differently.
We
have
another
system
that
this
is
part
of.
That
does
that
if
you
wanted
to
a
be
in
this
there's
some
thup
stuff
we're
thinking
about
doing
so,
instead
of
just
locales
being
the
only
type
of
variation
you
could
do
for
your
asset,
you
could
also
programmatically
define
other
types
of
variations
like
color
sets,
or
things
like
that.
So,
if
that's
something
that's
interesting,
I'd
love
to
talk
to
you
more
about
it
later.