►
From YouTube: GraphQL Fails Modularity / GraphQL Modularity - Variable... Matt Mahoney, Mofei Zhang, & Dave McCabe
Description
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. Get Started Here: https://graphql.org/
GraphQL Fails Modularity / GraphQL Modularity - Variable Providers / How Relay Overcomes the Limitations of Client Controlled Nullability - Matt Mahoney, Mofei Zhang, & Dave McCabe, Meta
JW Marriott Austin, Room 402/403
Speakers: Matt Mahoney, Dave McCabe, Mofei Zhang
GraphQL, the language, works against a typical (Bazel, Buck, etc.) build system’s view of modularity. Problems include Overlapping Fields, Fragment Nullability, Query Level Variables, and Huge Schemas.
At Meta, we’re working through these problems with solutions including:
* Fragment Composition (rather than inheritance)
* Keyed/alias'd fragments
* Variable providers
* Fragment arguments
* Schema composition
These features build towards a world where fragments can accurately describe cleanly composable product needs.
A
All
right,
good
afternoon,
everyone
really
happy
to
be
here.
I'm
really
looking
forward
to
workshops
tomorrow
morning
getting
into
the
nitty-gritty,
with
a
few
of
you,
whoever
will
still
be
here
and
what
I'm
really
excited
about
with
those
workshops
is
getting
into
why
graphql
is
just
not
modular
enough.
A
I'm
matt
mahoney!
I
work
on
our
native
ios
and
android
clients
at
meta
and
helping
me
give
this
talk.
Getting
deep
into
the
weeds
will
be
mophei
and
dave,
who
are
both
on
the
relay
team
at
meta
and
yeah.
So
at
its
core,
graphql
was
built
and
was
designed
to
be
a
modular
system,
and
what
I
mean
by
that's,
like
you,
have
your
requirements
on
the
server
we
didn't
want
to
have
rest
endpoints
that
are
one-to-one
mapping
with
your
every
time.
You
have
a
new
client
usage.
You
have
to
build
up
a
new
rest.
A
A
You
don't
need
to
test
every
single
surface
that
your
component
could
possibly
be
on.
You
just
test
your
change
in
one
location,
and
you
can
trust
that
it's
going
to
work
everywhere
and
if
you're,
using
a
build
system,
when
you
make
a
change
that
changes
fast,
you're
only
modifying
your
local
thing,
you
can
make
your
change
reload
your
browser
and
see
it
immediately
right.
That's
the
ideal!
Dev
developer
experience.
A
On
the
other
hand,
we
can
talk
about
entanglement
right
when
it's
not
modular.
What
does
it
feel
like,
and
you
know
when
you're
in
an
entangled
state?
It's
really
obvious
right.
Your
system
is
just
infected
with
implementation
details.
When
I
go
to
change
one
location
of
code,
I
have
to
do
a
whole
system-wide
refactor,
it
sucks.
A
You
can
silently
have
your
parent
components
break
on
you
right.
Like
I'm
changed
my
component,
I
tested
it
locally.
Everything
looks
good
to
me
and
suddenly
some
view
way
out
in
the
weeds
that
I
didn't
even
know
exist
comes
shouting
at
me
and
it's
like
matt.
Why
did
you
break
our
product
and
another
aspect?
That's
close
to
my
heart
is
that
the
developer
experience
also
stinks.
You
end
up
waiting
on,
builds
that
just
take
minutes
when
you're
only
changing
like
the
color
of
like
a
component.
A
It
sucks
not
to
be
modular,
it
sucks
to
have
an
entangled
system.
As
I
said
earlier,
graphql
was
built
to
enable
modularity
to
disentangle
the
problems
of
the
server
from
the
problems
of
the
client.
You
should
be
able
to
have
your
server
expose,
what
its
capabilities
are
and
build
products
based
off
those
capabilities
without
having
to
go
to
a
server
engineer
every
time
and
ask
them
hey,
I'm
trying
to
make
this
change.
It
doesn't
quite
work.
Can
you
fix
your
system?
A
A
B
B
So
relay
is
our
graphql
client
for
javascript
and
react
and,
like
matt
said,
graphql
is
supposed
to
be
all
about
making
things
modular
and
separating
out
components
so
that
they
can
be
developed
independently
and
there's
just
a
few
things
that
are
or
it's
falling
short
and
if
we
fix
those
things
we'll
actually
have
this
really
ideal
developer,
developer
experience
where
things
are
really
modular,
so
this
is
sort
of
the
how
we
think
about
modularity.
What
the
definition
of
it
is
is.
B
First
of
all,
if
you're
making
a
change
to
some
code,
your
changes
should
be
local
to
the
thing
that
you're
working
on
you
shouldn't
have
to
go
change
unrelated
stuff
when
you
make
a
change.
Okay,
so
that's
sort
of
the
obvious
thing.
Also,
when
you
make
your
change,
you
shouldn't
have
things
break
right.
You
shouldn't
have
some
runtime
problem
in
a
different
product
because
of
your
changes
right.
You
should
have
confidence
that
you
make
the
change.
B
You've
tested
your
stuff
and
everything
else
is
fine
right,
because
it's
modular
it's
separated
out
and
then
a
less
obvious
aspect
of
modularity,
though
that's
equally
important,
is
that
when
you
make
a
change,
if
it's
a
small
change,
it
should
be
a
fast
build
step
if
you're
doing
any
type
of
builds.
If
your
build
system
is
like,
oh
of
the
size
of
the
code
base,
that
is
because
it
there's
some
interdependency
between
different
things
in
your
code
that
your
compiler
or
whatever,
is
having
to
check
right.
B
So
if,
if
there's
something
that
can't
be
incremental,
it's
because
it's
not
modular
and
that
will
result
in
a
slower
and
slower
developer
experience,
so
the
way
that
okay,
the
promise
of
the
clicker,
is
somewhat
like
the
the
promise
of
modularity
and
graphql.
So
I'm
going
to
go
back
up
here.
This
will
work
suppose
that
you
are
developing
a
component
to
show
the
details
about
this
conference.
Talk
so
you've
got
the
talk,
description
and
you've
got.
B
You
know
the
different
presenters
like
matt
said.
The
graphql
is
very,
very
effective
at
step
at
making
the
server
and
the
client
modular
with
regards
to
each
other.
So
you
don't
have
to
like
make
a
new
server
endpoint.
Every
time
that
you
are
developing
a
new
feature,
you
can
just
take
the
things
that
the
server
already
does
and
recompose
them
together,
but
also
we
want
our
user
interface
to
be
broken
up
into
different
components
that
are
separate
from
each
other
and
then
we
can
compose
those
into
a
tree.
B
We
might
have
a,
for
example,
a
react
component
and
it
is
comprised
of
a
couple
of
sub-components
a
title
and
an
item
picture
right,
but
all
of
these
need
to
get
the
data
about
the
presenter
from
somewhere.
So
the
way
that
this
api
looks
in
relay
is
we
have
a
react
hook
called
use
fragment
and
you
put
a
graphql
fragment
in
there
now
what's
beautiful
about
this.
Is
that
that
component
is
self-contained?
B
It
says
what
data
it
needs.
It
needs
the
name
which
is
being
used
directly
in
this
component
and
then
whatever
item
picture
is
using,
you
take
its
fragment,
you
compose
it
into
yours,
and
so
you
can
just
in
this
one
component.
If
you
want
to
add
some
other
information
about
the
presenter,
you
just
put
it
in
the
fragment.
You
put
it
in
your.
B
You
know
in
your
react,
output
and
you'd
be
done.
It's
like
totally
local
self-contained.
We
call
this
data
co-location,
and
that
is
what
we
would
like
to
have,
but
it's
sort
of
like
not
it's
not
actually
as
beautiful
as
this
to
where
you
can't
break
any
other
components
here,
like
you'd
like
you'd,
like
to
think
that
you
can
remove
name
or
add
something
else
without
breaking
anything.
That's
not
true.
Now,
just
some
context
for
where
these
problems
come
up
is
that
fragments
are
going
to
be
used
frequently
in
many
different
operations
or
queries.
B
Similarly,
any
given
query
could
have
a
huge
tree
of
components
that
it
is
serving
they're
just
getting
put
into
it
right,
so
you
could
have
your
fragment
that's
supposed
to
be
self-contained
sitting
along
other
fragments
that
you
didn't
expect,
because
they're
actually
part
of
completely
different
products
right.
So
that's
kind
of
where
you
start
to
have
some
issues
so
just
to
illustrate
this.
The
way
that
fragment
composition
actually
works
in
graphql
is,
if
you
have
a
query
with
a
couple
of
different
fragments
spread
into
it.
B
Here's
one
is
has
is
selecting
the
name
field
and
one
is
selecting
the
profile
pic
field
in
the
graphql
response.
Those
fields
just
get
inlined
right.
So
whatever
the
context
is
that
object?
There's
no
like
further
nesting
for
the
fragments
in
the
response.
It's
just
you
know,
name
is
in
there
profile.
Pic
is
in
there
right.
So
you
can
already
see
that
this
presents
a
problem,
because
if
we
go
back
to
the
component,
there's
nothing
actually
preventing
us
from
using
whatever
data
was
in
the
like
picture
component
right.
B
So
then,
if
that
component
wants
to
remove
the
field
or
something
if
we're
using
it,
there's
a
problem
now
relay
solves
this
with
what
we
call
data
masking,
where
this
used
fragment
will
just
return
only
the
fields
that
you
actually
directly
accessed
in
your
fragment,
so
we
kind
of
do
some
stuff
on
the
client
to
prevent
that
from
being
a
problem,
but
there's
overhead
to
it.
It's
complex
to
implement.
B
So
it's
not
an
ideal
solution,
but
the
real
problem
starts
when
you
have
different
components
composed
different
fragments,
composed
into
the
same
query
that
are
selecting
the
same
field
right
so
here
we've
got
two
different
fragments
that
are
composed
into
this
query:
they're
both
selecting
profile
pick
but
with
different
arguments.
So
one
is
like
size.
32
one
is
size,
64.
right,
so,
according
to
you
know
what
how
things
would
normally
work.
B
B
What
should
now
happen
is
that
your
app
should
crash
right,
because
this
is
an
invalid
query,
and
so
the
server
is
is
required
to
just
return
an
error
for
this
query,
because
it's
invalid,
and
so
what
can
happen
is
because
remember
this
could
be
in
a
product
that
you
don't
write
like
you're
working
on
small
pick
and
you're.
You
know
doing
something,
and
you
add
this
profile,
pic
field
in
your
product
that
you
work
on
no
problem.
Some
totally
different
thing
is
also
using
small
pick
and
big
pick,
and
it
starts
crashing
right.
B
So
this
is
violating
everything
that
we
want
for
modularity
right.
It
is
something
where
you're
going
to
change
something
and
you
have
these
unpredictable
runtime
errors
right.
That's
not
modular
at
all!
Now
relay
it's
not
baby's
first
graphql
client.
So
what
we
do
is
we
actually
have
in
our
compile
step.
We
check
for
every
possible
way
that
fragments
could
be
combined
and
if
any
of
them
have
a
conflict.
It's
a
build
time
error.
Okay,
so
that's
like
way
better
than
a
runtime
error,
but
the
problem
with
that
is
that
it
is
very
slow.
B
B
B
You
have
to
go
and
change
some
other
product
like
you
have
to
go
arbitrarily,
alias
some
field
or
whatever,
so
that
they're
not
in
conflict.
So
it
violates
the
idea
that
your
changes
are
local
right.
You
could
have
something
come
from
ci
and,
like
you
know,
these
there's
there's
just
no
locality
of
changes
right
when
you
have
conflicting
fields.
Another
place
this
can
come
up.
Is
this
client
controlled
nullability
proposal
right?
So,
going
back
to
this
example,
let's
say
that
you
have
the
profile
pic
component
and
it's
got
its.
B
C
B
Going
to
turn
into
null
so
you've
maybe
expected
just
the
picture
to
go
away,
but
actually
like
it
goes
out
further
and
potentially
the
rest
of
your
component
was
fine.
You
could
still
render
the
name,
but,
like
somebody
else's
change
broke
your
component.
That's
not
modular!
That's
not
what
we
want
right.
So
the
thing
that
we're
proposing
to
solve
all
these
different
issues
is
what
we
call
fragment
response
keys.
So
looking
at
that
client
controlled
nobility
example.
B
B
The
thing
that
would
be
turned
null
is
null,
but
it's
under
another
key.
The
key
that
you
provide,
so
it
doesn't
propagate
out
to
the
entire
fragment
like
the
spread,
is
now
an
entity
in
the
in
the
response.
So
going
back
to
that
example,
where
we
had
the
two
fields
that
were
selecting
the
same,
the
two
fragments
that
we're
selecting
the
same
field
if
we
have,
if
we
just
give
them
keys
now
in
their
response,
they're
separated
out
from
each
other
right,
so
they
cannot
conflict
and
you
can
have.
B
Basically,
this
creates
boundaries
where
nothing
that's
happening
inside
that
named
keyed,
fragment
spread
could
possibly
affect
anything
else.
Now
we
don't
want
to
get
rid
of
the
existing
fragment
spread
because
we
want
to
maintain
backwards
compatibility,
but
with
just
a
few
judicious
keyed
fragment
spreads,
you
can
create
boundaries
between
products,
so
that
actually
bounds
your
build
times
and
it
bounds
sort
of
error
propagation
right
wherever
you
might
have
an
error
boundary
in
your
user
interface.
C
B
So
not,
it
doesn't
have
to
check
anything
outside
of
that
boundary,
and
so
you
can
get
reasonable
build
times
without
having
to
introduce
this
everywhere,
just
in
a
few
places
in
your
product.
So
this
is
kind
of
a
small
change
that
would
make
us
way
closer
to
the
ideal
of
actually
things
being
fully
modular
in
graphql.
All
changes
are
local.
You
can
never
break
other
parts
of
the
product.
There's
one
more
ingredient
to
get
us
there
and
mophae
is
going
to
tell
you
about
it.
C
So
let's
take
a
step
back
and
imagine
a
language.
That's
not
graphql!
Someone
told
you
about
a
really
great
programming
language.
It's
new
someone
just
came
up
with
it.
It's
really
expressive
for
all
forms
of
graphic
data
allows
decoupling
between
the
client
server.
Here's
the
caveat.
You
can
only
use
global
variables
in
this
language.
C
C
What
would
using
such
a
language
look
like,
and
would
it
be
modular?
So,
let's
write
an
example
program.
So
imagine
you're.
Writing
this
language.
It's
similar
to
javascript,
not
javascript
and
you're
writing
print
reading
already
this
is
starting
to
look
strange
print.
Greeting
is
unable
to
accept
arguments.
No
local.
C
C
From
another
perspective
within
a
component
tree,
a
single
component
may
be
reused
many
times.
So
let's
look
at
this
following
code.
We
have
a
fragment
called
item
picture,
it's
probably
used
with
an
item
picture
component
and
we
have
a
overall
query
to
talk
details
that
spreads
item
picture.
So
this
is
drawing
the
modularity
picture,
as
you
see,
as
well
as
each
of
the
presenter
pictures,
but
I
might
want
to
fetch
those
pictures
with
different
sizes.
C
C
And
because
of
those
things,
it's
impossible
for
item
picture
to
be
fully
customizable.
We're
used
reusable
the
way
to
get
around
this
with
graphql's
current
syntax.
Is
that
I'll
need
to
copy
and
paste
item
picture?
Becomes
another
fragment
item
picture
too,
and
I'll
have
a
second
global
variable
called
size,
not
exactly
ideal.
C
We
can
solve
this
by
introducing
fragment
level
arguments.
This
looks
very
similar
to
arguments
in
a
function
context,
so,
first,
every
fragment
should
be
able
to
specify
its
own
arguments
and
an
argument.
Definition
here
item
picture
declares
that
it
needs
a
variable
called
size
and
everywhere
that
spreads.
This
fragment
can
now
pass
in
the
desired
size,
which
can
be
either
a
known,
constant
literal
as
we're
using
here,
operation,
level,
variable
or
another
fragment
if
the
fragment
spread
is
happening
from
a
parent.
C
Fragment
relay
currently
allows
developers
to
use
fragment
level
arguments,
but
the
way
it
does
it
is
very
expensive.
The
compiler
will
generate
a
different
version
of
item
picture
named
some
gibberish
like
item
picture,
two
three,
four:
five:
six
by
discovering
all
fragment,
spreads
sites,
a
fragment
picture
and
generating
a
whole
bunch
of
definitions.
This
is
a
super,
inefficient
workaround
and
this
should
be
supported
by
the
graphql
spike
itself,
so
fragment
level
arguments
allow
us
to
reuse,
fragments
within
a
single
query,
but
we'll
quickly
run
into
issues
when
multiple
operations
use
the
same
fragment.
C
C
So
let's
look
at
how
this
could
be
an
issue.
Let's
say
that
you're
on
a
team
that
works
on
graphql,
conf
ui
and
someone
on
your
team
is
working
on
the
item
picture
component.
They
have
a
wonderful
idea.
Maybe
users
would
love
it
if
every
single
picture
was
blue,
yeah
you're
like
well.
Let's
hold
off
on
that
thought.
Maybe
that's
not
the
best
idea.
Let's
do
an
a
b
test,
see
user
engagement
based
on
whether
pictures
are
blue.
C
C
C
So
the
fundamental
issue
here
is
that
graphql
only
allows
for
two
types
of
values:
constant
literals
and
variables
defined
on
the
operation
level.
If
we
were
able
to
add
another
value
type,
this
could
solve
the
problem.
So
in
relay,
we've
added
variable
providers
available
actually,
today
in
relay
version,
14.
C
C
A
Yeah,
I'm
super
excited
that
relay
managed
just
a
few
hours
ago
to
release
variable
providers,
perfect
timing,
so
great,
we
have
a
lot
of
the
modularity
pieces
built
into
relay
and
built
into
our
complex
clients,
but
this.
But
there
is
a
limit.
We
are
trying
to
get
these
concepts
of
modularity
into
the
spec
at
its
core.
A
The
spec
itself
describes
how
we
are
forced
to
entangle
both
fields
and
variables
across
fragments
and
operations.
So
in
spec
5.3.2
we
have
field
selection
merging
which
says
that
any
time
within
an
operation
that
you're
on
the
same
object
and
your
response
key
is
going
to
be
the
same.
You
use
the
same,
alias
or
the
same
field
name.
That
field
must
be
identical,
so
it
needs
to
be
identical
in
a
lot
of
ways,
as
as
dave
was
pointing
out,
needs
to
have
the
same
arguments.
A
A
The
ability
to
to
pass
in
different
arguments-
and
we
do
have
client
solutions
for
this
right
relay
and
other
client
frameworks
can
fake
modularity.
We
can,
as
moffe
said,
we
can
have
our
fragments
and
basically
create
templated
graphql,
so
that,
when
we're
passing
in
arguments,
our
compiler
actually
magically
creates
every
possible
version
of
that
fragment.
That
which
is
fine,
I
guess,
but
it
bloats
the
app
size.
A
A
A
You
don't
need
to
check
beyond
you,
don't
need
to
check
my
parents
or
you
don't
need
to
check
below
me
right.
Having
fragment
arguments
could
or
having
fragments
in
the
response.
Key
itself
could
help
establish
those
boundaries
so
that
we
can
start
iterating
on
top
of
those
assurances.
So
the
end
result
of
all
this
is
that
we've
got
a
few
spec
suggestions
really
two
one.
I
really
really
want
fragment
response
keys.
We
want
something
where
we
can
say
this
fragment
is
at
this
point.
You
don't
have
to
worry
about
that
field.
A
Entanglement
problem,
we're
not
saying
every
single
fragment
spread
should
always
do
it,
but
we
do
think
that
providing
a
way
for
clients
to
say
where
they
want
modularity
is
high
value.
Additionally,
allowing
fragment
argument.
Definitions
gives
fragments
the
ability
to
act
closer
to
functions
so
that
we
can
actually,
you
know,
have
a
picture
of
different
sizes
within
the
same
view,.
A
This
allows
us
to
stack
additional
goodies
on
top
right.
It's
provided
variables
is
something
I
am
incredibly
excited
about.
I
am
going
to
start
telling
all
the
teams
at
meta
to
use
it
like
it's
super
high
value,
we've
seen
it
explode
in
usage
and
allowing
clients
to
stack
these
features
that
depend
on
some
element
of
modularity
is
again
high
value.
A
We
don't
want
to
have
to
walk
every
field
every
time
across
an
entire
operation
in
order
to
know
whether
what
we're
producing
is
valid
code.
We've
got
a
github
discussion
that
we've
seeded.
If
you
want
to
get
involved,
please
jump
in.
I
am
really
excited
about
this.
I'm
really
excited
to
dig
in
in
workshops
tomorrow,
work
with
whoever
is
interested
in
this
space.
A
C
A
A
Yeah,
so
aliases
don't
work
at
our
scale.
It's
the
same
basic
premise
that
you.
So
when
you
have
a
fragment
you
can
use
aliases
so
like.
When
you
run
into
problems,
you
can
always
use
aliases
to
get
out
of
them.
So
if,
if
we
didn't
have
aliases,
we
would
be
screaming
for
fragment
modularity
right,
so
aliases
at
least
give
product
teams
a
way
to
get
out
of
the
bad
state
they're
in,
but
they
don't
learn
that
they're
in
that
bad
state.
A
Until
the
whole
compilation
has
happened
and
on
our
code
base,
that's
like
a
10
minute
process,
sometimes
so,
or
they
don't
even
get
to
that,
build
step
until
they
put
their
code
up
for
review,
and
then
we
have
a
ci
job.
That
does
it
and
that's
like
a
pretty
bad
experience.
There's
no
way
to
like
see
right
at
your
code
that
you're
causing
a
problem.
You
can't
put
it
in
the
ide,
because
it's
not
fast
enough.
A
Yeah,
so
that's
that's
a
very
good
point.
The
I
it's
not
necessarily
true
right,
like
having
global
constants
is
like
a
normal
thing,
and
it's
fine
to
so.
We
would
probably
there
probably
is
a
future
where
internally
we're
going
to
invert
the
default
so
that
you
have
to
explicitly
say
this
variable,
like
you
have
to
say,
here's
a
variable
on
the
fragment.
Yes,
I
have
a
fragment
argument
for
it,
but
I
every
single
operation
that
uses
it
has
to
know
what
this
value
is.
It's
that
important
so
put
it
there.
A
Yeah
so
next
step,
we've
got
the
graphql
working
group
discussion.
It's
the
next
step
is
probably
on
me.
I've
been
sitting
on
this
for
a
little
while
to
so
the
next
thing
for
for
fragment
arguments,
I
need
to
put
up
validation
rules
so
that,
when
you
use
fragment
arguments,
you
can
have
the
right
validation
rules,
it's
kind
of
unclear
exactly
what
that
will
look
like
there's
a
few
different
options,
there's
also
yeah.