►
From YouTube: Modern JavaScript Infrastructures - Maël Nison, Datadog
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi
everyone
I'm
incredibly
excited
to
be
here.
My
name
is
Mel,
and
today
we
are
going
to
talk
a
bit
about
fronting
infrastructure,
which
is
something
I've
worked
on
on
for
the
past
few
years.
More
specifically,
we'll
start
by
discussing
what
it
actually
is
then
go
over
its
core
parts
and
finally,
we'll
get
a
more
abstract
discussion
about
how
to
be
efficient
when
you're
part
of
a
frontal
infrastructure
team,
which
can
be
surprisingly
tricky.
My
hope
is
that,
by
the
end
of
this
talk,
we'll
have
a
better
idea
of
how
to
improve
the
heat
tooling.
A
You
actually
use
every
day.
So
the
first
question
we
should
ask
ourselves
before
going
further
is
what
is
actually
fronting
in
front.
We
all
have
this
picture
of
infrastructure
being
maintaining
Network
edges.
Kubernetes
clouds,
sometimes
data
centers.
So
what
does
it
mean
in
the
context
of
firms
up
front?
An
infrastructure
is
about
building
the
platform
that
will
leverage
your
developers
strengths,
it's
about
giving
them
the
tools
to
focus
on
the
core
proposition
of
your
project.
A
Rotten
infra
is
made
up
of
two
equally
important
pieces.
They
aren't
even
three
but
we'll
come
to
that
later.
In
the
abstract
part,
the
first
piece
is
developer
experience.
How
do
we
make
it
so
that
on
jaian
ears,
don't
have
to
spend
their
time
tweaking
the
tooling
that
we
use
B
to
webpack?
Yes,
lean,
Babel
time
strip
jest
or
any
other
tool,
we
fancy?
How
can
we
let
them
fix
bugs
and
develop
new
features
as
fast
as
they
can?
So
that's
the
first
piece,
but
it's
not
the
whole
story.
A
An
equally
important
part
lies
in
stability.
How
can
we
make
sure
that
front-end
developers
don't
have
to
worry
about
their
changes?
How
can
we
be
confident
that
the
next
deployment
work
just
as
well
as
the
previous
one?
You
need
to
have
strong
answers
to
both
of
these
questions,
because
otherwise,
we'll
eventually
run
into
a
wall
which
is
never
a
great
experience.
A
Turn
your
project,
making
it
very
approachable,
be
it
an
open
source
project
which
often
needs
external
users
to
survive
or
accompany
product
which,
on
boards
new
developers
every
year
Paris
even
month,
awakes
automating
processes
decreases
the
amount
of
knowledge
that
one
has
to
have
before
being
productive
and
makes
it
much
easier
to
evolve
procedures
on
the
time
to
reach
this
perfect
onboarding
state.
The
first
rule
is
to
make
sure
that
workflows
only
require
an
as
few
commands
as
possible.
A
If
installing
a
repository
requires
to
first
setup,
the
database
important
fixtures
build
the
templates
and
finally
stop
the
dev
server.
Then
why
not
abstract
it
order
a
single
image
and
start
cutting?
You
can
even
have
a
fee
nice
visual
interface,
to
see
the
very
step
that
the
script
is
playing
at.
If
you
want
to
the
point,
is
it
needs
to
be
dead,
simple,
there's
just
no
reason
nowadays
to
gauge
working
on
the
product
behind
the
technical
implementation
of
your
infrastructure.
You
shouldn't
assume
that
people
will
know
how
to
use
it.
A
The
second
rule
of
automation
is
that
you're
in
front
needs
to
be
the
source
of
truth.
We
have
so
many
great
tools
today
we
should
use
them.
We
can
enforce
a
common
formatting
with
pressure.
We
can
validate
the
semantics
of
your
code
with
transcripts.
We
can
check
for
dangerous
patterns
which
yes
fit.
My
point
is
that
we
can
and
we
should
automate
as
much
as
possible
the
detection
of
most
problems.
A
First,
it
makes
sure
that
whatever
lens
in
master
is
right
by
your
standards,
but
it
also
makes
it
much
easier
for
any
new
contributor
to
jump
to
the
call,
knowing
that,
if
anything's
wrong
the
system
will
catch
it.
This
slide
is
an
example
of
what
we
do
in
Europe.
We
have
a
dedicated
get
of
action.
That
simply
runs
all
the
sanity
tests
we
can
think
of.
Some
are
very
basic.
Some
are
more
complex.
Some
are
security
checks.
A
Some
are
linting,
not
one
of
them
run
every
time
only
if
they
are
actually
relevant
to
the
changes,
but
in
general
the
idea
is
that
they
can
catch
a
good
deal
of
the
problems
you
might
head
into
while
working
on
your
pull
requests,
and
on
top
of
that,
they
also
indicate
to
you
how
to
fit
them.
No,
that's
only
the
first
iteration
and
we
are
still
working
on
it,
so
the
next
evolution
will
be
to
automatically
fix
the
problem
as
much
as
possible.
A
Let's
continue
with
Claude
and
go
so
I
use
this
term
to
explain
that
we
want
developers
to
be
able
to
just
jump
to
the
project
and
be
immediately
productive.
As
you
can
see,
it's
a
direct
follow-up
to
what
we
discussed
with
automation,
but
it
a
really
good
father,
where
automation
means
that
we
want
to
execute
card
without
user
interaction.
Cronan
go
means
that
we
don't
actually
want
to
execute
god
at
home.
A
Interestingly,
trongo
goes
even
farther
than
the
card
itself,
because
the
exact
same
thing
can
be
said
about
the
editor
tooling.
Of
course,
everyone
in
your
company
as
their
favorite
editor,
but
usually
you
can
find
the
top
three
and
perhaps
even
the
top
one.
In
certain
cases,
most
of
those
IDs
now
offer
the
ability
to
store
project
settings
directly
within
the
repository,
and
by
leveraging
this,
you
can
be
sure
that
everyone's
on
the
same
page,
whether
use
editor
config
crate
your
ears,
lint
all
those
extensions
critical
to
the
developer.
A
A
A
You
don't
really
want
the
ingenious
to
have
to
remember
to
do
this
at
the
same
time,
you
can't
really
run
it
automatically,
because
it's
just
too
slow,
even
the
fastest
installs
of
a
few
seconds,
will
still
make
it
a
pain
to
work
with
reading
anything
but
the
zip
workers.
You
don't
have
a
few
seconds
to
spare
when
you're
checking
a
new
branch.
A
Yawn
comes
with
a
solution
to
this,
so
I
won't
get
too
deep
into
the
specifics
here.
But
the
idea
that,
by
mirroring
your
dependencies
archives
into
your
repository,
you
never
have
to
worry
about
running
yarn
style
ever
again,
even
when
switching
branches
I
expect
this
kind
of
integrations
to
become
more
and
more
important
in
the
future,
because
something
we
noticed
in
computer
science
is
that
to
make
things
faster,
we
sometimes
had
to
make
that
run
in
parallel.
A
The
same
is
actually
true
for
developers
working
on
features
because
by
giving
them
the
ability
to
jump
between
branches,
by
removing
the
contacts
which
cost,
then
your
developers
can
capitalize
their
time
efficiently
and
produce
more.
Finally,
good
developer.
Experience
is
a
lot
about
the
feedback
loop
when
it
comes
to
the
development
itself.
How
can
developers
see
if
their
challenges
work?
You
will
often
be
tempted
to
use
pre-commit
hooks
to
run
various
sanity
checks,
but
if
I
can
give
you
an
advice,
do
it
sparingly?
A
We
were
something
hard
to
design
on
tight,
ripped
on
pre-commit
inside
our
own
conveys
because
it
was
causing
unnecessary
slowdowns
that
prompted
a
genius
to
entirely
disable
procurements.
Keeping
it
light
makes
it
actually
more
likely
that
early
mistakes
will
be
spotted,
especially
since
IDs
are
now
so
good
and
surfacing
type
errors.
As
far
as
the
product
development
goes,
I
found
very
important
to
make
sure
that
the
ultra
node
story
works.
If
product
engineers
have
to
refresh
the
page
between
each
charge,
they
will
lose
momentum,
retrieving
the
state.
A
Speaking
of
this,
the
react
team
unveiled
a
few
months
ago,
a
project
called
react
refresh,
which
aims
to
fix
most
of
the
long-standing
flows
in
previous
incarnations
of
our
tree.
Node
next
year's
integrated
in
their
offering
not
too
long
ago
or
the
generic
web
pack
plug-in,
is
now
almost
stable.
So
now
is
probably
a
good
time
to
start.
Looking
into
that,
once
the
developer
is
done,
we
want
to
see
the
churches
in
production
before
I
show
deploying
them.
We
want
to
share
it
with
your
project
manager
or
designers
or
Corbin
tailors.
A
To
do
that,
you
will
need
a
deployment
service
that
supports
deploying
any
brush
repeatedly.
Thankfully,
most
providers
like
Virgil
Ornette
if
I,
now
support
this
kind
of
workflow
out
of
the
box.
But
even
if
you
have
your
own
deployment
pipeline,
you
can
still
easily
implement
this
kind
of
logic.
The
only
thing
you
really
need
is
a
way
to
tell
your
back-end
to
load
the
assets
based
on
the
branch
name
ashing,
the
name
and
storing
it
into
a
static.
A
Subdomain
is
more
than
enough
in
most
cases
without
need
for
more
complex,
stuff,
I
think
we'll
stop
there
for
the
developer
experience.
There
are
a
lot
of
other
areas
of
improvements
we
could
list,
but
my
goal
here
was
to
highlight
the
main
one
and
show
you
some
easy
wins
that
often
go
unnoticed
before
we
move
on
to
the
next
point.
One
last
thing
I
want
you
to
note:
is
that
the
principles
with
discus
fear
or
as
important
for
open
source
projects
as
they
are
for
the
company
as
mint
a
nurse?
A
Our
role
isn't
necessarily
to
write
all
the
pull
requests,
but
rather
to
put
our
contributors,
which
often
includes
ourselves
in
a
position
where
they
can
be,
they
can
easily
work
on
the
projects
without
being
burdened
by
all
the
maintenance
aspects
of
things.
Sometimes,
it
can
be
as
simple
as
just
making
sure
that
running
on
tests
will
actually
run
with
us
anyway.
A
Let's
keep
going
and
discuss
about
the
second
pillar
of
front-end
infrastructure
stability.
Stability
is
critical.
Its
goal
is
to
make
you
confident
it
leads
to
faster
bug,
fixing,
because
you
know
that
your
infrastructure
is
responsible
for
them
and
it
makes
you
sleep
easier
at
night,
knowing
that
your
fellow
teams
won't
need
to
page
you
just
because
something
unexpectedly
broke
and
deploy
is
don't
go
through
any
more,
but
how
do
we
get
there?
The
first
step
for
stable
infra
is
a
very
simple
one:
control
your
dependencies.
A
Don't
rely
on
external
one
that
can
change
at
any
time,
but
I.
Don't
only
mean
JavaScript
dependencies
take
the
network.
The
network
is
a
dependency
like
any
other.
If
you
suddenly
lose
access
to
it,
your
deployments,
we
stop
if
your
registry
lose
access
to
it
same
thing.
Of
course
you
can
just
stop
relying
on
the
network,
not
when
so
many
of
our
deployments
occur
in
the
cloud,
but
we
certainly
can
decrease
its
surface.
In
particular,
don't
install
your
packages
from
external
registries,
that's
about
Eileen.
A
They
often
get
out
and
when
they
do,
they
completely
block
you
unless
you
were
prepared
for
it.
Thankfully
solutions
exist.
Jana.
This
concept
of
offline
mirror
to
again
basically
cause
of
issues,
but
even
if
you
use
something
else,
you
can
still
use
the
like
of
where
that
show
to
set
up
a
local
registry.
There's
actually
I'll
talk
about
virtue,
and
this
very
conference
and
I
really
recommend
you
to
check
it
out.
A
So
that's
for
the
network,
but
in
stalls
in
general
or
tricky
by
Murphy's
Law
Erica
that
you
need
to
run
is
a
code
that
will
eventually
fail
so
to
be
really
safe.
You
need
to
cut
down
the
amount
of
code
that
needs
to
cut
it
down.
In
Stiles
is
a
fairly
new
concept,
so
there
isn't
a
lot
of
support.
Yet
you
want
to
course
it
with
this
zero
in
cell
mode.
We
talked
about,
but
that's
pretty
much
it
at
the
moment.
A
Still
it's
really
something
you
should
consider
for
production
settings
where
installs
are
responsible
for
so
much
of
the
CIA
time.
Removing
insults
altogether
brings
very
significant
improvements,
both
in
in
terms
of
speed
and
user
experience
and
finally,
one
last
piece
of
advice
about
dependencies:
don't
use
native
Develin,
C's
or
any
dependencies
with
personnel.
Scripts
really
buzzing
says
scripts
outside
of
the
security
aspect
of
running
external
car
have
a
high
tendency
to
fail.
Sometimes
it's
a
remote
URL
but
gets
rate
limited
that
actually
happened
in
one
of
my
pipeline
not
too
long
ago.
A
Sometimes
it's
a
local
library
that
isn't
there,
sometimes
it's
literally
just
a
Monday
and
the
person's
a
script
isn't
made
to
work
on
Monday.
That's
a
true
story.
I
talked
about
our
code.
That
runs
is
the
code
that
fails.
This
is
especially
true
for
persons
on
screens
that
you
don't
control
at
all,
so
be
mindful
of
what
you
use.
Try
to
prefer.
Webassembly
packages,
instead
of
native
ones
in
their
pre-compile
and
avoid
packages
with
pass
inside
scripts,
stable
infrastructure,
aren't
only
about
deployment.
You
also
need
to
be
sure
that
your
tool
chain
works
and
writing.
A
It's
in
tight
ship
is
a
very
good
way
to
help
in
this
regard.
It's
funny
because
is
often
found
in
front-end
cardinalities,
but
I
still
find
a
lot
of
infrareds
written
in
Gia's.
I,
don't
know
if
it's
because
the
scripts
don't
deserve
the
same
level
of
attention,
but
I
found
that
too
bad,
because
they're
quite
critical
to
the
cut
that
we
are
writing
to
the
product.
A
Something
to
realize
is
that
you
don't
actually
need
to
transfer
to
a
trip
into
JavaScript
before
being
able
to
run
it.
You
might
have
heard
about
Dino
lately,
but
even
going
as
far,
we
can
already
have
pretty
good
solutions
in
that
world.
Babel
can
add,
support
for
executing
JavaScript
files
directly
into
not
TS
not
can
do
that
as
well
and
together
with
the
official
touch
field,
compiler
that
can
type
check
without
transpiling
resources.
I
think
we
have
all.
We
need
to
make
sure
the
code
we
write
for
our
tool
chain.
A
A
I
could
go
on
and
on
and
keep
telling
you
particular
pain
points
that
are
often
true
today,
but
the
fact
is
that
the
impact
of
those
changes
will
vary
from
one
project
to
another,
so
I,
rather
than
keep
inheriting
a
fixed
list,
I
think
we
should
now
check
out
how
to
find
our
own
additional
items
and
with
that
we'll
turn
a
more
abstract
part
of
this
talk
called
monetary.
The
idea
is
simple:
there's
only
so
much
time
in
the
day,
and
only
so
many
resources
to
spend
of
an
infrastructure
right.
A
So
how
do
you
pick
the
tasks
that
will
have
the
most
impact
for
your
team?
You
will
also
need
to
measure
whether
your
project
actually
improved
things
so
that
you
can
iterate
and
refine
your
approach
over
time.
One
problem
is
that
infrastructure
is
how
to
measure
really
hard,
as
we
previously
saw.
A
good
part
of
the
throttle
infrastructure
is
the
developer
experience
at
the
developer.
Experience
is
driven
by
a
loose
concept
of
happiness,
and
how
do
you
measure
happiness?
There
are
a
few
tricks
for
that.
A
The
first
strategy
is
called
passive
because
you're
waiting
to
see
the
data,
you
aggregate
all
kind
of
objective
data
points
and
look
for
trends
that
emerge
to
good
tool
for
that
or
unit
webpack,
which
both
offer
looks,
allowing
you
to
retrieve
accurate
usage
metrics
of
a
type.
The
second
strategy
is
active.
This
time
you
directly
go
to
your
users
and
ask
them
what
they
think
you
can
do.
This
is
am
a
sweep
with
company-wide
phones
or
you
can
schedule
one
one
with
your
colleague.
But
the
point
is
you
need
to
go
to
them?
A
Finally,
the
first
approach
is
to
be
reachable.
It
won't
be
enough
to
get
your
peers
feedback
one
every
bloomin.
You
will
need
to
make
sure
they
have
the
proper
channels
to
share
their
own
ideas
by
experience,
something
that
works
quite
well
or
github
issues.
Infrastructure
tasks
are
often
long-lived
and
it
can
become
hard
to
track
progress.
Good
old
fashioned
issues
are
a
good
way
to
let
everyone
share
their
problems,
avoid
a
recurring
one
and
subscribe
to
progress
on
the
one
they
are
care
about,
I'd
like
to
go
over
the
passive
strategy,
a
bit
more.
A
What
you
can
see
on
screen
is
the
number
a
duration
of
the
type
check
command
runs
in
the
type
data
log
or
everyday.
We
have
a
young
plugin
that
collects
this
kind
of
information
and
sends
it
straight
to
our
dashboards.
Through
this,
we
get
a
good
sense
of
what
programs
the
ajay
nears
may
face
quickly,
detect
regressions
and
triage
feedback.
We
do
this
together,
many
metrics,
which
strips
are
used
what's
the
size
of
the
code
base
of
any
ESP
disabled
or
their
what's
the
size
of
the
bill.
A
What's
its
duration,
all
these
automated
information
gathering
helps
paint
a
kind
of
real
like
real
nighttime
picture
of
our
work.
So
we
have
found
ways
to
gather
metrics
but
the
others,
an
important
question.
We
need
to
answer.
We
shove
that
better
and
that's
the
question
between
you
and
your
users,
see
metrics
are
an
insight.
They
give
you
a
snapshot
of
data,
but
the
way
you
will
interpret
them
will
be
affected
by
your
users.
Perception
of
that,
for
example,
you
might
think
that
let's
say
the
deploy
time
is
too
high
because
it
appear.
A
That's
actually
what
fertile
infrastructure
is
a
repeated
cycle
of
interpret
validate
track.
First,
you
find
candidate
problems.
Then
you
validate
them
with
your
users,
and
then
you
find
a
metric
that
will
be
impacted
by
the
fix
and
you
can
finally
track
them.
The
key
is
to
validate,
because
without
it
you
run
the
risk
of
working
on
an
idea
that
you
will
find
useful,
but
that
won't
be
perceived
as
such
for
the
people
it
was
supposed
to
help
which
is
good
for
anyone.
A
Okay,
so
I
talked
a
lot
and
there
are
so
many
thing
about
front-end
infrastructure.
I
think
this
is
only
the
first
of
many
ties.
We
could
make
it
into
subjects.
To
recap:
by
investing
or
developer
experience
of
stability,
you
get
to
have
a
multiplying
effect
of
the
team's
you
support
to
do
that
efficiently.
You
will
need
to
plan
your
work
ahead.
Really
you
will
need
to
have
a
long
term
vision
while
still
stay
flexible
enough
to
be
able
to
add
up
for
new,
okay
or
that
will
appear
in
your
rudder.
A
Finally,
you
will
need
to
make
sure
that
everyone's
aware
of
the
value
your
work
will
bring
what's
completed.
If
they
aren't,
it
will
be
the
sign
that
you
haven't
communicated
well
enough
or
perhaps
that
the
value
just
isn't
there.
It
happens,
and
it's
not
a
big
deal.
The
key
is
to
use
that
to
find
out
more
about
what
you
could
do.
That
would
have
more
impact
on
your
users.
A
I
hope
you,
like
this
talk,
I've
experimented
a
new
approach
on
first
design,
the
plan
using
ex
cathedra
a
platform
and
a
way
to
build
graphs,
with
an
emphasis
on
the
code
rather
than
the
visuals
I
mean
sure
to
plan
on
Twitter
after
the
talk.
So
if
you
forgot
to
take
notes,
feel
free
to
join
me
there.
A
Finally,
here
are
some
links
that
you
can
look
into
to
find
more
information
about
various
topics
we
discussed.
I
will
leave
it
here
from
a
few
seconds
that
you
can
take
a
screenshot
like
right
now,
for
example,
yeah
now
is
the
time
and
I
will
join
you
for
a
Q&A
right
after
so,
please
feel
free
to
share
what
you
thought
of
this
talk.
It's
the
first
time,
I've
done
it
so
I'm
kind
of
in
uncharted
territories
there.
So
I
would
really
appreciate.
Having
your
input,
thanks
for
everyone
for
listening
and
have
a
great
day.