►
From YouTube: Gasket: Framework Maker - Andrew Gerard, GoDaddy, LLC
Description
There is no one-size-fits-all framework, but there is a way to assemble frameworks in a common fashion. All that's needed to seal the junction between multiple technologies is a gasket.
Gasket is the pluggable tooling that GoDaddy developed to create a standardized framework with robust plugin system for our own apps. Learn how we use Gasket to bridge together technologies such as Next.js, Express, and Redux along with our internal services. Get a first look at Gasket as we open source it for others to start composing and sharing their own pluggable frameworks.
A
A
So
before
GoDaddy
I
was
a
technical
artist
in
game
development
as
a
tech,
artist,
I
would
build
tools
and
processes
for
artists
to
build
the
craft
and
integrate
their
assets
in
the
games.
Now,
as
a
software
engineer,
at
GoDaddy,
I
have
a
similar
role
and
that
is
to
help
build
tools
and
processes
for
for
web
developers.
A
A
It's
a
really
cool
project,
we're
announcing
and
releasing
today
as
open
source,
which
we
call
a
gasket
now
before
we
get
into
the
nuts
and
bolts
of
what
gaskey
is
when
I
lay
some
some
groundwork
and
for
the
structure
of
the
talk
I'm
going
to
first
describe
the
problem
that
we're
going
to
answer
with
gasket
today
and
then
point
you
to
some
ways.
You
can
use
gasket
yourselves
and
get
involved
with
this
new
open
source
project.
A
Is
a
framework
before
we
dive
into
this
consider
what
a
framework
is
according
to
merriam-webster,
it's
a
basic
conceptual
structure
as
of
ideas
or
a
skeletal
open-open
work
or
structural
frame.
To
summarize
that,
for
our
purposes
as
software
engineers
that
give
you
said,
frameworks
provide
foundation
for
software
developers
to
build
applications
in
a
streamlined
way.
A
A
Okay
and
in
general,
you
could
consider
basically
you've
made
yourself
a
framework,
and
let
me
let
me
walk
you
through
kind
of
this
process
and
just
to
kind
of
see
where
I'm
coming
from
here.
Okay,
so
I'm
a
visual
person
I
put
together
some
some
visuals
to
help
illustrate
the
concepts
I'm
speaking
about
during
this
talk.
So
to
start
with
to
see,
we
have
a
box,
and
this
box
represents
our
app
okay.
Now
we're
going
to
build
a
front
front-end
web
app
and
let's
pick
out
some
libraries,
we
want
to
use.
A
Okay,
maybe
reason
react
for
our
renderer,
maybe
we're
using
webpack
for
our
bundler
express
for
our
survey
engine
so
on
and
so
forth.
Okay.
Finally,
we
need
to
get
all
these
integrated
together,
so
we
write
some
code
tie
them
all
together.
The
implementer
app
and
we'll
say
this
is
our
app
okay.
Now
we've
been
tasked
to
build
another
app
okay,
instead
of
doing
all
this
work
again,
probably
what
we'll
do
is
just
make
a
copy
of
that
app
and
change
up
some
of
the
application
code
and
bam.
A
We
have
another
app
okay,
so
we
repeat
this
project
in
this
process
because
we
are,
you
know,
app
making
machines
now
and
but
let's
look
at
some
of
the
problems
with
this
approach,
who's
taken.
Okay,
say
we
find
a
bug
over
in
this
application
somewhere
in
the
integration
code
and
say
we
make
that
fix
now
I
deal
we
make
that
same
fix
across
our
other
different
apps
that
we
have
created.
A
Okay,
we
go
through
and
do
that
and
now
it's
kind
of
hard
to
see
in
my
visuals
where
the
changes
were
made
and
if
I've
missed
an
app.
The
same
thing
is
true
with
our
with
our
code
in
our
real
absence.
If
this
is
the
approach
we
take
going
in
and
touching
loose
code
within
our
apps
to
to
get
these
things,
work
to
to
fix,
to
make
a
bug
fix
another
thing
to
kind
of
point
out
it's
hard
to
tell
integration
code
and
framerate
code
from
your
application
code.
A
It's
all
living
there
in
the
same
the
same
pool
the
same
mess.
Okay.
So
let's
look
at
a
problem
or
a
way
to
kind
of
solve
this
problem.
What
we
can
do
is
take
our
libraries
that
we've
chosen
and
introduce
a
new
framework
package.
Okay,
this
would
be
like
it.
You
know
just
a
standalone,
NPM
module.
Okay,
that
our
app
depends
on
all
our
libraries
are
part
of
this
package.
All
their
integration
code
lives
in
this
package.
So
now
we
have
a
clear
separation
of
where
application
code
ends
and
where
our
framework
code
begins.
A
Okay-
and
with
this
we
can,
we
can
separate
our
framework
from
our
application
and
it's
much
easier
to
spin
out
multiple
applications
using
that
same
framework
package.
This
time,
if
we
find
a
bug
in
our
integration
code,
it's
just
in
that
framework
package
we
make
the
fix
and
from
there
we
simply
update
our
apps
with
that
framework
change
and
it's
very
clear
which
apps
are
on
which
version
of
the
framework
okay,
so
frameworks
are
useful
in
a
variety
of
ways.
A
What
we've
been
talking
about
is,
you
know,
centralizing
our
common
code,
so
we
don't
have
it
scattered
through
all
our
apps
and
this
it
also
allows
us
to
standardize
what
features
and
libraries
go
into
our
app
okay,
another
benefit.
It
gives
us
a
uniform
way
to
developer
apps.
We
have
a
common
patterns
in
place
that
we
can
we
can
build
from,
and
this
ties
in
to
cross
team
collaboration
see
same
team.
A
A
is
tied
on
a
deadline
and
team
b
has
some
availability,
so
they
can
send
a
developer
over
to
help
out
with
team
a
that
the
developer
of
team
B
already
knows
the
framework
already
knows
how
the
apps
are
built
with
a
framework.
It's
very
easy
for
him
to
onboard
and
and
help
out
with
this
other
app,
and,
of
course
you
can
air
it
to
the
dry
principal,
don't
try
to
solve
the
same
problem
multiple
times
all
right.
A
So
let
me,
let
me
tell
you
a
little
bit
about
how
frameworks
play
a
part
at
GoDaddy,
but
before
I
do
that?
Let
me
let
me
start
with
back
when
I
was
a
tech
cart
a
set
of
games
to
do
okay,
so
as
a
educational
game
company,
we
develop
a
pattern
for
assembling
games
quickly
and
to
end
and
part
of
that,
which
was
my
responsibility
was
to
build
a
a
framework
for
a
web-based
game
editor
which,
depending
on
the
game,
different
game
features,
could
be
tied
into.
A
A
Besides,
besides
the
editor
itself,
you
know
we
had
the
game
engine
part
and
the
server
parts
too.
They
all
kind
of
followed
the
same
principle,
okay,
and
so
then,
one
day,
my
former
manager
who
I
had
worked
with
on
this
game
development
pattern
called
me
up.
He
had
left
a
while
back
and
was
now
working
at
GoDaddy,
and
what
he
wanted
to
do
is
bring
me
on
to
help
build
a
web
app
framework
to
tie
different
hosting
products
into
I.
A
Think
my
first
response
to
him
was
like
what
GoDaddy
what
I
want
to
want
to
forego
Daddy,
but
after
a
while
one
thing
led
to
another
and
I've,
been
Charlie,
came
around
to
the
idea
and
GoDaddy's
been
great
I'm,
not
building
games
anymore,
but
there's
plenty
of
problems
and
challenges
to
solve
which
makes
the
work
interesting
and
I
get
to
work
with
a
lot
of
really
smart
people.
Some
of
them
are
in
this
room
today
and
when
I
started,
there
I
was
with
my
firmer
boss.
A
Now
my
new
boss,
and
we
were
in
Go,
Daddy's
hosting
organization.
Okay,
go
dia
has
several
hosting
products
and
the
Web
Apps
for
these
different
products
were
scattered.
The
experience
was
scattered.
They
were
built
with
different
tech
stacks.
You
know,
teams
weren't
really
communicating
with
each
other.
So
it's
just
a
bad
experience
for
customers.
A
Basically,
they
were
all
in
different
technology
islands,
and
so
what
we
wanted
to
do
is
try
to
break
those
down
and
have
one
pattern
in
one
process:
one
framework
to
build
our
hosting
web
apps
with.
So
what
we
did
is
similar
to
what
I
described
before
we
started
with
an
app
shell
built
our
or
framework
package.
Go
Daddy
was
standardizing
on
react
at
this
point.
A
So
react
was
one
of
the
libraries
we
chose
and
internally
we
also
had
a
team
working
on
yoicks
components
with
react,
so
we
use
that
and
help
contribute
to
that
as
well.
We
use
web
web
pack
for
bundling
and,
as
part
of
this
framework,
we
had
a
way
to
tie
in
the
different
hosting
products,
so
they
could
develop
their
user
experiences
independently,
but
still
tie
into
this
cohesive
application
all
right.
So
this
worked
well
and
we
soon
had
other
apps.
A
A
We
were
excited
by
this
shift
as
our
small
team
and
eager
to
take
our
framework
to
other
teams
across
GoDaddy
to
build
their
front-end
web
apps,
but
what
we
found
is
that
other
groups
had
done
some
other
things,
building
their
own
frameworks
for
their
own
apps.
Okay-
and
this
looks
familiar
right
if
you
zoom
out
from
just
where
we
were
at
at
hosting
old
GoDaddy,
was
essentially
on
these
different
technology
islands.
A
A
Imagine
it's
common
to
all
companies,
anybody
that
builds
multiple
apps.
It
has
multiple
teams.
Okay,
you
know,
teams
need
frameworks
to
build
their
apps
okay
and
we
just
saw
there's
there's
many
benefits
of
doing
so.
So
how
are
we
were
gonna
handle
this
ago?
Daddy?
What
did
we
do?
What
we
did
is
identified
the
three
most
commonly
used
frameworks
and
we
took
a
few
people
from
each
of
those
teams
and
we
formed
a
tiger
team
within
GoDaddy
cross
organization,
just
kind
of
try
to
bridge
that
bridge
that
gap
across
organizations
this
one.
A
Okay,
so
we
didn't
just
do
this
in
isolation,
just
in
this
Tiger
team.
What
we
did
is
we
started
out
with
requests
for
comments
process
with
proposals
gathered
questions,
gathered
feedback
from
other
developers
who
were
going
to
be
using
this
new
framework,
and
you
know,
ideas
and
opinions
or
like
armpits,
everybody
has
more
than
one
they
all
stink
right.
So
we
worked
through
that.
We
started
to
sign,
which
frameworks
to
keep
which
ones
to
not
use
what
features
to
use
and
during
this
process
is
when
we
learned
about
next
GS
now.
A
Next,
yes,
is
great
it.
It
took
care
of
a
lot
of
wriggles
tying
react
in
with
server
rendering
with
web
pack
bundling
and
gave
us
a
routing
solution,
and
but
it
didn't
solve,
it
was
one
piece
of
the
puzzle,
but
it
didn't
solve
the
whole
thing
we
still
had
to
handle
authentication,
particularly
to
GoDaddy.
We
still
had
to
tie
in
our
UX
platform,
the
yokes
component,
so
I
was
talking
about.
A
A
Honestly
I
was
hesitant
with
this
notion
of
first,
we
already
had
a
pattern
like
I
just
demonstrated
visually
for
for
building
frameworks.
Why?
Why
do
we
need
to
do
this
different?
Are
we?
Are
we
override
engineering?
This
whole
thing,
however,
as
we
continue
to
work
on
it
with
our
new
cross
team
request
organization
tiger
team,
it
clicked
we
weren't
just
building
another
framework.
We
were
building
the
the
tools
to
actually
build
frameworks,
and
I
will
illustrate
that
shortly.
A
A
There
are
some
essential
elements
used
to
compose
frameworks
and
I
will
walk
you
through
those
next
okay,
so
there's
six
key
elements:
the
CLI,
which
has
the
plug-in
engine
plugins
themselves,
commands
life
cycles
hooks
and
presets.
To
start
with.
Let's
look
at
the
CLI:
this
is
the
entry
point
into
creating
apps
and
interacting
with
apps
okay,
so
you
type
Gasquet
the
name
of
the
the
CLI
and
the
first
thing
it
does
is
loads
plugins
configure
for
the
app
or,
if
it's
a
new
app,
it
has
some
some
built-in
ones.
A
Built-In
plugins,
okay,
plugins,
are
the
building
blocks
of
an
app
framework.
Okay,
they
provide
the
scaffolding,
the
circuitry.
They
really
use
to
integrate
libraries
and
the
communicate
together,
which
we
will
see
in
a
little
bit.
Okay
plugins
also
make
the
commands
available
to
the
CLI.
Okay,
you
can
plug.
You
can
use
plugins
to
add
commands
to
your
to
your
CLI
in
this
case.
A
These
aren't
your
typical
event
matters
either
these
can
be
executed
in
various
ways
and
they
can
be
handled
in
order,
okay,
very,
very
important,
and
but
what
handles
life
cycles
are
hooks
hooks
also
are
made
available
by
the
plugins
that
you
plug
into
your
app
and
hooks
can
also
execute
additional
life
cycles,
hooks
for
where
you
implement
your
integration
code
and
your
feature
code
that
you
want
to
use
a
crust
across
your
app
okay.
So
this
kind
of
this
kind
of
high-level.
A
Let
me
give
you
some
some
concrete,
a
little
bit
more
concrete
examples
with
the
create
command.
We
have
a
prompt
life
cycle
that
gets
executed,
prompt,
for
example,
when
you're
running
running
creates.
It
allows
plugins
to
ask
the
user
questions,
for
example,
when
you're
creating
your
app.
What's
the
name
of
your
app,
do
you
want
a
git
repo
initialize
with
your
app?
Do
you
want
a
test
suite
installed
with
your
app?
Do
you
want
to
use
yarn
or
NPM
things,
and
things
like
that?
A
A
Those
are
things
along
those
lines
and
then,
at
the
end,
we
have
a
post
create
lifecycle.
This
gives
the
plugins
the
final
layer
to
do
any
fine-tuning
to
the
app
that,
as
it's
being
created,
for
example,
with
the
lint
plugin,
you
can
run
es.
Let
fix
it'll
match
up
all
the
generative
files
to
the
to
the
lint
code
style
that
you've
chosen
with
that
plugin.
A
Okay.
So
the
last
element,
key
element
with
gasket-
are
p-sets,
so
presets
are
basically
collections
of
plugins,
some
additional
configuration
as
you
need-
and
these
are
loaded
by
the
the
CLI-
make
plugins
available
and
basically
presets
become
your
framework
they're
the
chosen
set
of
plugins
or
features
that
you
want
to
have
in
your
apps,
and
you
share
presets
across
your
apps,
which
I'll
point
out
a
little
bit
better
shortly.
A
A
Ok,
plugins
layer
together
and
they
can
have
dependencies
on
other
plugins
and
for
here
next
depends
on
the
web
pack
plug-in
and
I'll.
Explain
that
a
little
bit
later,
but
let's
say,
let's
say,
for
example,
we're
not
just
building
a
web
app
here
with
with
next.
Yes
say
we
want
to
build
just
micro-service
or
some
kind
of
API
REST
API.
You
know
you
can
remove
those
other
layers
of
plugins
and
just
have
HTTP
weak
with
Express.
Okay,
plugins
are
also
decided
to
be
interchangeable,
say
I.
A
Don't
want
to
use
Express,
say:
I
want
to
use
pacify.
You
know
which
was
recently
announced
as
part
of
the
open
GS
foundation.
You
can
do
that.
You
can
swap
these
out
and
you
know
I
could
use
fafsa
phi
back
with
next
GS
and
my
web
pack
plugins
okay,
so
plugins
can
be
interchangeable
and,
besides,
just
that,
you
know
think
about
what,
if
you
know
GoDaddy
as
a
reaction
shot.
That's
fine,
that's
great,
but
as
we
open
sources,
we
expect
to
see
things
like.
A
A
Well,
let
me
take
a
step
back:
here's
right:
let's,
let's,
let's,
let's
go
back
to
Go
Daddy's
current
stack
stack,
so
we
have
Express
next
web
pack
redux.
This
is
what
most
of
our
apps
are
using
right
now
these
are
library
plugins.
You
guys
know
these
names,
but,
as
I
mentioned
before,
we
had
internal
needs
as
well
our
auth,
our
our
UX.
What
we
have
is
internal
plugins
for
for
those
as
well.
Okay,
so
plugins
aren't
necessarily
just
for
tying
in
a
library
that
you
want
to
use.
A
You
know
from
the
open
source
world
into
your
app
you
can
you
can
build
your
own
plugins
for
your
teams
for
your
companies
and
integrate
them
with
the
with
the
gaskets
set
up
okay.
So
when
teams
have
settled
on
what
features
they
want
to
have
in
their
apps,
what
you
would
do
is
stamp
those
into
a
preset.
So
now,
whenever
I
go
to
create
a
new
app,
I
would
say:
okay
I
want
to
do
gasket
create
with
the
Go
Daddy
preset.
That's
how
we
spin
up
apps
at
GoDaddy.
A
Now,
with
with
that
team,
presets
can
also
represent
smaller
sets
of
plugins
that
make
sense
together.
So,
for
example,
if
there
is
an
XJS
preset
which
we
have
in
our
open
source
packages
right
now,
so
you
guys
can
kick
the
tires
on
it
on
gasket
quickly
and
say
we
have
a
preset
for
just
progressive
web
apps,
the
different
plugins
we
need
for
for
that.
Those
are
available.
Apps
can
be
composed
of
presets
like
I'm,
depending
on
to
here,
and
presets
can
also
be
extended.
A
A
So,
as
you
can
see
here,
what
was
once
a
framework
package
that
could
not
be
changed
could
not
be
played
around
with
experimented
with.
You
know,
trying
out
fast
fly
instead
of
Express,
you
can
now
with
gasket
piecemeal
these
together
and
build
your
frameworks
and
the
form
of
presets
okay.
So
this
is
probably
question
you're
thinking
right
now.
Is
this
just
another?
App
generator
is
this?
Like
you
know,
besides,
is
this
more
like
llaman
or
something
yeoman?
A
The
answer
is
no
gasket
is
also
used
for
runtime
integrations
in
your
app
as
well
I've
been
talking
about.
You
know
how
you
create
your
app,
but
let's
look
at
some
examples
of
how
you
use
the
gasket
life
cycles
during
your
app
or
when
your
app
starts.
So
we're
gonna,
look
at
the
start
command
and
let's
just
walk
through
this
now.
A
So
we
we
have
the
gasket
CLI
in
a
context
where
app
is
going
to
load,
plugins
and
we'll
see
the
the
start
plugin
is
is
made
available
start
plug-in,
gives
us
the
start
command
when
I
execute
the
start
command.
It's
going
to
fire
off
the
first
life
cycle,
which
is
the
start
life
cycle.
Okay,
next,
the
HTTP
plug-in
hooks
the
start,
life
cycle
and.
A
It
executes
a
create
stirrers
life
cycle
which
allows
plug-ins
to
say:
ok,
this
is
what
I
want
to
go
into
the
the
server
that's
created
in
our
case
here.
With
that
GoDaddy
stack,
I
showed
you,
we
have
Express,
ok,
Express,
Hooksett
Express
says
I
want
to
be
the
handler
for
the
server
and,
as
you
know,
Express
can
be
used
with
middleware,
and
you
know
you
can
step
your
routes
and
one
up
for
it.
A
A
The
next
GS
plugin
then
hooks
the
express
lifecycle
and
it
sets
up
the
routes
for
the
pages
of
your
of
your
next
step.
Ok,
this
plug-in
then
initializes
web
pack,
which
is
hooked
by
the
web
pack,
plug-in
ok
when,
when
you
do
that
that
allows
that
allows
other
plugins
to
either
use
the
web
pack
chain,
lifecycle
to
assemble
web
pack
chain
or
web
pack
in
a
channel
way
and
there's
also
another
web
pack,
lifecycle
plugins
to
return
webpack
partials
that
get
merged
in
or
you
tape
the
web
packet
fig.
A
Okay,
so
once
the
next
j/s
plugin
has
gotten
its
whip
pack
and
fig,
it
then
execute
the
next
config
life
cycle.
This
allows
you
or
your
plugins
to
add.
You
know
manipulate
the
next
config
use
some
other
configuration
plugins
like
annex
a
sore
necks
s,
CSS
that
kind
of
stuff
or
CSS,
and
so
that's
that's
example
of
a
flow
with
the
the
start
command.
A
There's
there's
several
more
life
cycles.
You
can
make
Yousef
epi
in
your
apps.
As
you
add
plugins,
you
can
add
your
own
life
cycles
and
you
can
create
your
own
commands.
Okay,
we've
been
talking
about
start,
there's
other
commands
available
and
again
you
can
build
your
own.
You
can.
You
can
see
what
what's
available
today,
if
you
go
to
our
our
gasket
devs
dock
site
and
speaking
of
docks,
let's,
let's
talk
about
that.
A
A
The
your
documentation
should
be
clear
and
since
gasket
allows
you
to
build
your
frameworks
in
the
form
of
these
plugins
and
from
of
these
little
individual
components
that
you
compose
together.
How
are
you,
how
are
you
going
to
present
docs
for
your
apps
for
this?
What
we've
introduced
with
with
gasket
is
a
Doc's
plugin.
Now
the
docs
plug-in
makes
available
a
Doc's
command.
A
So
when
you
run
this
command,
what
it
will
do
is
collate
all
the
files,
all
the
documentation
files
of
the
plugins
installed
for
your
app
put,
those
in
a
central
place
fix
up
the
the
links
between
read,
Me's
and
there's
also
a
Doc's
of
5
plugin,
which
will
then
give
you
a
nice
web
view
of
your
documentation.
So
this
would
be
the
documentation
for
only
the
plugins
and
presets
and
what's
available
in
the
app,
not
just
not
the
whole
ecosystem.
A
So
it's
pretty
cool,
if
you,
if
you
guys,
have
played
around
with
rust
it's
against.
This
is
kind
of
like
cargo
cargo
docks.
Okay,
it
just
gives
you
the
documentation
for,
what's
in
that
app
that
you're
working
on
okay,
so
who
is
gasket
for
I,
was
saying
it's
for
developers.
If
you're
an
app
developer,
you
can
use
gasket
to
get
at
the
life
cycles,
integrating
your
own
features
tie
in
with
other
with
other
plugins.
It's
also
for
for
teams.
A
Okay,
if
you're,
building
multiple
apps,
you
have
multiple
teams
working
on
these
apps
coming
down
with
a
a
tech,
stack
you're
happy
with
a
pattern
of
development,
you're
happy
with
put
those
into
a
preset
share
those
across
your
team
and
you're
good
to
go
yeah.
It's
also
important
for
communities.
I
mentioned
you
know
next
year,
sigh
throughout,
it's
felt
you
need
any
of
this
kind
of
communities
that
the
build
up
libraries.
They
want
their
libraries
to
be
able
to
interact
with
with
other
libraries
out
there
if
they're
in
the
form
of
a
gasket
plug-in.
A
Next
question:
how
do
I
get
started
so
to
get
familiar
with
gasket
the
gasket
prize
project
and
what's
available
today?
They
might
you
to
visit
our
website
gasket
dev.
This
is
a
doc
suffice
site
using
get
help
ages
generated
with
the
gasket
Doc's
command.
Okay,
so
you
can
kind
of
get
a
feel
of
how
that
works.
We
have
a
nice
splash
screen
on
the
front,
but
it
will
give
you
an
idea
there,
and
the
best
way
to
get
to
try
it
out
is
the
to
kick
the
tires
with
it.
A
You
can
install
the
gasket
CLI
today.
We
just
push
that
to
MPN
last
night,
so
so
give
it
a
run.
The
help
command
will
show
you
what
what
you
can
do
with
the
different
commands,
and
so
just
as
a
quick
recap
developers
need
frameworks
to
build
our
apps
effectively
and
quickly.
Right
Gasca
provides
the
tooling
and
fully
to
build
fully
featured
frameworks,
Docs
starting
app,
not
just
creating
nap,
ok
and
the
gasket
ecosystem.
A
Is
it's
ready
to
grow
with
through
contributions
to
the
open
source
world,
help
us
out,
join
it
in
to
the
fawn,
and
let's
this
make
gas
get
a
real
thing,
not
just
for
for
GoDaddy,
but
for
everybody
out
there,
and
if
you
have
any
questions
you
can
grab
me
on
the
hallways
or
or
hit
me
up.
My
name's
on
twitter
is
caneta
fix
and
then
put
it
on
the
slide,
but
just
just
fire
me
or
want
to
let
er
go
daddy
guys
and
we
can
get
you
going.
So
thanks.