►
From YouTube: Growing Up Node by Trevor Livingston, HomeAway
Description
Growing Up Node - Trevor Livingston, HomeAway
A primer on growing the Node.js story in the enterprise. Trevor was a KrakenJS team member and Node.js platform lead at PayPal and speaks from experience on adopting Node.js and growing it to massive scale. This primer is a guide on some initial considerations of such an undertaking.
A
Okay,
that's
showing
yeah.
This
is
this
I
wasn't
originally
scheduled
to
speak
at
Note,
interactive
and
so
I
decided
to
title
this.
How
to
prepare
a
talk
at
the
very
last
minute,
I
think
there's
pretty
critical
skills
for
these
kind
of
last-minute
engagements
I'm.
Joking
of
course,
I
did
want
to
provide
a
little
disclaimer
that
I
didn't
create
any
of
the
pictures
in
this
presentation.
A
A
So
really
this
talk
is
about
how
to
grow
the
nose
story
at
your
company.
You
know
note
is
kind
of
sold
itself.
We
have
these
conferences
for
a
reason,
as
there's
a
lot
of
excitement
around
it,
but
the
reality
of
bringing
note
into
especially
larger
mid-sized
to
larger
enterprises
has
a
lot
of
complexities
and
also
often
doesn't
communicate
up
the
stack
to
or
up
the
the
chain
to
your
your
leaders,
your
VPS
c-level
executives
and
so
forth.
A
So
this
is
a
lot
about
having
kind
of
a
plan
going
into
this
and
and
how
you
kind
of
expect
to
grow
it.
Just
a
little
bit
about
me,
I'm
Trevor,
Livingston
I'm,
a
former
node
platform
lead
at
PayPal,
was
part
of
the
the
crack
nsj
team
there
and
and
currently
is
what
was
just
mentioned-
I'm
now
principal
architect,
at
home
away
and
really
I
kind
of
came
over
to
help
with
the
beginning
of
the
node
journey.
A
A
Really
we
have
over
800
node
engineers,
not
not
just
engineers.
We
have
probably
3,000
engineers
or
had
now
that
I'm,
not
there,
but
800
know
developers
over
a
hundred
applications
in
live
about
1,500
internal
node
modules
that
were
developed
by
internal
developers
and
400
million
requests
a
day.
So
really,
how
do
you
get
there
right?
There's
no
recipe
for
that,
especially
back.
Then
we
really
learned
as
we
went
and
we
actually
had
a
lot
of
help
and
node
has
a
great
community
definitely
use
it.
A
There
are
there
many
out
there
that
have
have
already
encountered
issues
that
you're
going
to
encounter,
as
you
begin
to
scale
development
and
and
they
can
help,
but
really
how
you
think
about
growing
this
project
within
a
company
is,
is
really
gonna
help
and
and
laying
out
a
plan,
and
what
I
really
want
to
talk
about
is.
Is
that
plan
for
growth?
You
know
you're
you're
getting
into
a
new
technology,
but
technology
is
really
supposed
to
solve
problems
and
reap
lat
forming
onto
one
of
these
new
technologies
has
a
has
a
cost.
A
A
If
you
want
your
developers
to
be
able
to
iterate
faster,
if
you
want
to
think
about
things
like
you
know,
running
on
kamar
commodity
hardware
and
scaling
more
cheaply
understand
the
problems
you're
solving
going
into
this,
because
this
gonna
really
help
you
not
only
plan
for
the
future
be
able
to
communicate
that
to
people
making
decisions
regarding
the
financials
out
of
this,
and
really
that
kind
of
becomes
a
focus
on
adding
value.
How
does
node
and
moving
to
node
align
with
not
only
your
own
goals
as
a
technologists,
but
the
business
goals?
A
How
does
that
align
with
what
the
company
is
trying
to
do
or
where
the
company
is
trying
to
go
and
really?
How
are
you
adding
value
to
the
customer?
You
notice
usually
lends
itself
to
web
application
development
and
really
what?
What
is
that?
What
is
that
how's
that
helping
your
develop
your
customers
that
are
interacting
and
then
how
is
it,
helping
the
business
and
really
to
get
there?
This
becomes
really
about
demonstrating
success
on
a
small
scale.
A
It's
a
really
small
win
and
focusing
on
a
single
success
story
should
really
that's
really
kind
of
getting
back
to
how
we
got
node
in
the
door
at
PayPal.
Is
it's
all
about
that
pilot
application
that
that
experiment
that
is
going
to
basically
yield
results
that
allow
you
to
learn
from
it
and
really
think
of
it
as
a
learning
exercise?
This
is
about
being
able
to
recognize.
A
A
This
presentation,
but
the
anti-pattern
when,
when
introducing
node
as
a
new
technology,
is
going
to
be
thinking
in
terms
of
migration,
there
will
be
a
temptation
among
developers,
especially
and
teams
that
have
existing
products
and
are
moving
to
a
new
product.
To
think
of
this,
in
terms
of
like
how
do
I
take
this
Java
class
and
transfer,
you
know
transform
it
into
a
JavaScript
class.
A
How
do
I
take
this
this
JSP
and
convert
it
into
react
or
angular
or
what-have-you,
and
really,
when
you
go
back
to
thinking
about
that
small
initial
success
is
it's
also
about
creating
isolation
and
building
new,
creating
isolation
for
team
that
you
can
reduce
churn?
That's
happening
on
the
day
to
day
of
the
business
and
really
focus
in
on
that
single
experiment.
A
The
other
part
of
this
is
is
from
team
to
team's.
Node
is
that's
the
easy
part,
that's
the
fun
part.
Everybody
wants
to
play
with
node.
Everybody
wants
write,
JavaScript,
but
really
the
people
aspect
of
this
becomes
very
challenging
when
you're
doing
node
by
yourself
as
an
individual
contributor.
That's,
like
you,
know,
you're
having
fun
at
night
and
hacking
away
when
everybody
else
starts
doing
it.
It's
it's
more
challenging.
It
becomes
a
kind
of
a
it's,
not
quite
as
easy
to
make
decisions.
It's
not
as
easy
to
be
agile
and
I.
A
A
It
will
have
to
do
with
things
like
you
know,
being
more
configuration
based
being
able
to
inject
configuration,
providing
framework
that
make
it
easier
for
people
to
develop
on
and
not
just
really
using
open-source,
but
providing
some
sort
of
baseline
for
how
people
are
going
to
be
developing
applications
that
run
within
your
proprietary
ecosystem.
So
if
that's
a
private
data
center
or
if
it's
AWS
or
what-have-you.
A
The
other
really
important
factor
for
teams
is
education,
and-
and
this
you
know,
it's
actually
surprisingly
hard
to
find
a
a
picture
about
education.
That's
that's!
You
know,
that's
not
really
really
boring,
but
this
actually
also
has
a
point,
because
I
think
this
Panda
is
educating
this
night
about
going
over
that
hill
or
whatever
it
is,
and
this
is
actually
this
is
actually
kind
of
it
is
relevant.
A
The
other
aspect
of
building
great
interconnected
teams
is
really
focusing
on
that
engagement
and
bringing
not
only
the
teams
together,
but
sharing
the
experience
and
really
developing
in
the
open
and
making
everybody
a
part
of
kind
of
the
ongoing
knowledge
building.
So
not
having
this
concept
of
a
team
that
is
building
everything
and
kind
of
handing
it
over
to
you
know,
product
teams
that
are
gonna
pick
it
up
and
use
it,
but
having
those
product
teams
really
engage,
there
are
tools
for
this
slack
has
you
know?
Obviously
one
of
them
is
hugely
successful.
A
So
they'll
typically
be
a
temptation
to
wrap
everything
up
in
a
nice
little
box
and
ship
it
off
and
and
when
you
see
the
things
like
these
kind
of
turnkey
frameworks
that
you
know
something
like
electrode,
which
recently
came
out
comes
to
mind.
Is
it
puts
you
in
an
ecosystem
and
it
really
marries
you
to
it,
and
the
problem
with
that
is
this
really
stifles
innovation
and
flexibility
and
being
able
to
move
to
something
new
that
comes
out
building
tooling
internally
and
being
able
to
create
consistency
for
teams
is
really
about
capabilities
and
not
rails.
A
Providing
these
capabilities
allows
people
to
pick
and
choose
override
when
necessary
and
move
to
new
technologies,
as
they
become
available
with
a
lot
less
effort
and
and
kind
of
all
this.
No,
you
have
to
kind
of
keep
in
mind
that
not
only
is
flexibility,
important
innovation,
but
if
you're
building
these
turnkey
solutions
and
in
the
name
of
reducing
the
complexity
is
that
you
can't
really
reduce
complexity
in
a
system.
A
A
So
it's
a
very
different
world
when
people
begin
using
what's
been
built
when
people
go
live,
you
really
get
into
this
kind
of
this
world
of
how
do
you
operationalize
things?
You've
gone,
you've
built
some
prototypes,
you've,
you've,
experimental
II,
put
it
on
on
AWS
or
what
have
you
and
and
then
you
discover
that
it
has
performance
problems
that
the
no
process
is
crashing.
How
do
you
account
for
these
things?
A
The
first
thing
I
want
to
talk
about
is
security.
Has
anybody
ever
seen
this
picture
or
something
like
it
this?
This
is
a
this
is
a
Metal,
Gear,
Solid
and
he's
fighting
a
crab.
I
thought
was
pretty
cool,
but
security
is,
is
gonna,
be
the
number-one
concern
for
the
business
and
if
we
should
be
the
number
one
concern
for
everybody,
who's
shipping,
the
products
to
live,
there's,
obviously
a
lot
of
things
you
need
to
think
about
web
security.
A
Just
kind
of
your
your
internal
connection,
security,
but
really
one
of
the
kind
of
things
that
I
think
is
is
is
often
missed,
is
open
source
coverage,
as
we've
moved
towards
kind
of
a
very
open
source
world.
We
have
things
like
NPM
anybody
can
install
anything.
You
really
need
to
start
thinking
about
security
advisories
that
are
on
open
source
modules.
A
There
are
great
tools
for
this,
like
NSP
I,
think,
there's
a
snick
which
was
talked
about
earlier
today
and,
and
others
is
sometimes
baked
into
things
like
sauna
type
or
artifactory
and
and
understanding
kind
of
the
security
issues
of
applications
that
are
being
used
is
going
to
be
very
important.
But
the
other
interesting
thing
of
is
is
that
it's
not
just
about
things
like
security
advisories.
A
As
things
like,
you
know,
a
GPL
which
is
it's
not
necessarily
a
safe
license,
so
it
becomes
very
important
to
actually
interact
both
with
like
your
security
teams.
As
well
as
legal
to
understand
kind
of
the
ramifications
of
products
you're
using
and
once
again,
there
are
tools
that
they
can
help
with
that
you
can
create
restrictions
and,
and
that's
kind
of
a
important
consideration
to
have
performance.
A
Really,
you
will
learn
to
hate
rendering
on
the
server
as
well
as
SSL,
when
you
finally
start
noticing
that
basically,
all
the
time
you're
spending
is
either
an
SSL
or
rendering,
and
usually
it's
just
a
so
encryption
side
of
that.
But
what
you
will
learn
to
love
is
APM
solutions,
so
application
performance
monitoring.
You
see
things
like
New
Relic,
app
dynamics
in
solid.
Well,
that's
not
really
a
PM,
but
it
tells
you
a
lot
about
performance.
A
You
should
be
as
you're
developing
new
code
running
performance
tests.
They
should
be
hopefully
automated.
You
should
be
able
to
track
these
things
over
time
and
understand
how
your
performance
is
improving.
You're,
degrading
and
kind
of
the
final
item
on
the
operational
side,
and
which
is
very
kind
of
a
sticky
problem,
is
availability
in
node
and
a
lot
of
people
don't
like
to
think
about
this.
But
node
is,
for
all
intents
and
purposes
single
process.
A
A
Even
when
you
think
use
things
like
domains,
you
can
return
error
to
the
user,
but
the
end
of
the
day
you
have
to
crash
because
just
like
this
cat
in
this
box
is
node
is
like
Schrodinger's
cat.
If
an
error
occurs,
that
is
uncaught.
You
no
longer
know
the
state
and
a
lot
of
people
have
said
this,
but
there
seems
to
be
a
lot
of
disagreement
about
how
to
handle
this
within
this
scope
of
a
request.
A
But
the
fact
is,
you
never
know
the
state
anymore
once
you
have
an
uncaught
exception
and
ultimately
you
have
to
crash
and
it's
something
that
you
have
to
plan
for.
So
you
have
to
be
also
aware
of
how
frameworks
handle
these
errors
I'm
a
huge
fan
of
happy
as
a
framework
I
think
it's
amazing
by
default.
It
has
a
domain
handler
and
it
doesn't
crash
which
makes
it
have
a
lot
of
uptime,
but
you
no
longer
know
the
state
of
your
application.
A
The
other
thing
I
thought
I
mentioned
is:
is
promises
when
a
an
error
isn't
handled
in
a
promise.
You
basically
get
a
non-count
exception,
but
it's
actually
just
an
unhandled
rejection,
but
it's
really
the
same
thing
and
so
nothing
will
crash.
But
you
no
longer
know
the
state
of
your
application
and
that
can
cause
to
other
problems
as
well.
A
And
so
the
ante
pattern
here
is
being
single-minded
about
your
approach
and
what
I
mean
by
that?
Is
that
note?
Isn't
a
silver
bullet
and
notice
can
solve
potentially
a
lot
of
problems?
It
can
improve
productivity
may
improve
performance,
but
what
else
is
slowing
you
down
in
development?
You
can't
just
say:
hey
we're
going
to
improve
the
the
iteration
time
of
individual
teams
building
these
products,
but
it
takes
them
a
month
to
ship
it
to
life
right
you're,
not
really
solving
anything
if
you're
not
solving
to
specifically.
A
So
once
you've
kind
of
got
the
operational
aspects
worked
out
and
boy
am
I.
Am
I
over
I
think
I'm
over
I'm
gonna
blaze
through
this
now
I
went
way
longer
than
I
thought
I
would
I
didn't
get
to
the
pictures
of
my
kids,
so
maintenance
do
I
have
another
minute.
Anybody
can
somebody
tell
me:
okay,
talk
faster,
okay,
okay,
I'm
innocent,
it's
gonna
place
through
I
thought.
I
was
gonna,
go
way
too
fast.
Now
I
went
to
way
too
slow,
okay,
design
choices.
A
The
decisions
you
make
today
are
gonna
affect
you
tomorrow.
You
need
to
think
about
things
like
pure
dependencies.
Are
you
putting
peer
dependencies
everywhere?
Don't
because
it's
extremely
painful,
it's
very
hard
to
migrate
away
from
Global's,
obviously
tread
lightly,
really
making
assumptions
about
your
upstreams.
That's
one
way
to
shooting
her
in
the
face
with
this
gun
is
when
you
have
things
like
Express
middleware
and
you
are
having
expectations
on
up
streams.
You
no
longer
have
decoupled
software.
You've
just
created
this,
like
this
coupling
and
really.
A
Why
are
you
doing
that
in
the
first
place,
and
really
I
can't
say
this
strongly
enough
is,
is
if
anybody's
ever
heard
of
continuation?
Local
storage?
Please
don't
use
it.
If
you
haven't
heard
of
it,
don't
look
it
up,
it
is.
It
sounds
like
magic
and
it
is
it's.
It's
total
magic,
it's
black
magic
and
it
is.
It
is
the
worst
thing
and
you
know
no
offense
to
Forrest.
You
wrote
it
it's
amazing
tool.
It's
just
it
makes
things
impossible
to.
Debug
is
performance
it
to
be
a
problem.
Please
think
about
ownership.
A
A
On
that
note,
anti-pattern
do
not
hold
people's
hands.
People
learn
from
failure.
A
failure
is
a
very
powerful
learning
tool
and
it's
very
important
to
establish
a
culture
early
on
that
it's
okay
to
fail
and
that
it's
okay
to
not
know
what
you're
doing,
and
it's
about
educating
I'm,
just
gonna
kind
of
skip
over
a
source.
I
think
I'm
gonna
talk
about
a
little
bit
about
discoverability
on
that
I
think
about
discoverability.
This
is
actually
supposed
to
be
a
picture
of
a
map
and
and
an
actually
I
didn't
Google
image.
A
This
is
this
was
drawn
by
my
daughter
and
that's
her
right
there
and
you
can
see
she
has
a
wistful,
look
on
her
face
she's.
She
just
finished
her
ice
cream
and
she's
kind
of
wondering
what
to
do
next.
There's
my
son,
you
know
I
had
to
throw
him
this
slides,
I'm,
a
dad
if
anybody's
a
parent
they
understand
a
couple
more
notes
on
on
enter
source
is
is
just
and
I
really
wish.
I
could
spend
more
time
on
this.
Is
that
think
about
transparency?
A
Think
about
giving
management
insight
and
to
what
you're
doing
that
is
internally.
Shared
products
tend
to
be
driven
by
requirements
that
are
tied
to
timelines
and
if
developers
are
not
basically
working
on
that
alone,
then
usually
management
and
product
management
is
saying
what
the
hell
is
going
on.
But
the
thing
is
is
that
that
individual
developer
may
be
contributing
to
code,
that
is
shared
by
multiple
teams
and
is
improving
productivity
for
those
teams
and
so
understanding
how
to
provide
that
insight
early
on,
as
you
start
doing,
inter
sources
for
sharing
code
is
really
important.
A
Lts
for
inter
source,
these
were
project
ghost
nouns
people
leave
teams,
people
leave
the
company.
You
need
a
plan
for
this
project.
We
have
over
1500
modules
at
or
had
a
PayPal
I,
don't
know
how
many
of
those
are
actively
maintained,
and
that
becomes
a
problem.
The
ancient
pattern
to
inter
sources
permission
is
going
to
happen,
plan
for
it,
but
provide
good
constraints,
don't
provide
controls
and
that's
it
I'm.
Only
six
minutes
over.
Thank
you.