►
From YouTube: Introducing GraphQL @defer and @stream - Michael Staib, Chillicream & Rob Richard, 1stDibs
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/
Introducing GraphQL @defer and @stream - Michael Staib, Chillicream & Rob Richard, 1stDibs
JW Marriott Austin, Room 402/403
Speakers: Michael Staib, Rob Richard
In this talk, we will explain GraphQL defer and stream. We will start at the top by explaining the basic concepts of the new directives and how you can use them in your everyday projects.
As we have a basic understanding of @defer and @stream, we will drill deep into the inner workings of the GraphQL execution and unpack how @defer and @stream work. In this talk, we will give you some unique insights into the design decisions the GraphQL working group has taken on this exciting new feature.
A
My
name
is
rob.
I
work
at
first
dibs,
I'm
a
front
engineer
there.
If
you
don't
know
first
dibs,
it's
a
online
marketplace
for
very
high-end
furniture,
jewelry
fashion.
You
should
check
it
out.
Yeah
and
I've
been
working
with
the
working
group
for
the
past
couple
years,
championing
the
spec
proposal
for
deferred
stream
and
michael's
gonna
get
started.
B
Yeah,
I'm
michael
stive,
I'm
one
of
the
co-founders
of
chili
cream,
a
company
building,
rashford
tooling,
especially
hot
chocolate,
graphical
server.net
and
other
tools
with
random
names,
and
I'm
also
working
with
lee
and
the
other
tscs
in
the
working
group.
Together.
Okay,
let's
get
started
actually
before
we
dive
into
that.
B
B
B
Okay,
at
this
point,
the
stream
and
defer
directives
that
we
talked
about
six
years
ago
are
slowly
moving
into
the
graphquery
specification,
so
we
are
still
not
there.
Yet.
There
are
a
lot
of
minor
details.
We
are
talking
in
the
working
group
about
and
rob
will
go
into
the
exact
problems
that
we
are
still
working
through.
B
B
But
there's
one
more
thing
here,
because
I
said
we
are
also
fetching
all
the
assets
for
them.
So
we
are
fetching
the
charts
for
the
five
most
important
assets
here
and
that's
where
we
could
further
optimize
our
request
with
something
we
call
the
something
we
call
stream
and
that
allows
us
to
tell
our
nodes
field
to
essentially
say
just
give
me
the
first
asset
and
then
resolve
the
rest
of
the
assets
as
you
see
fit
as
they
become
available.
B
Can
you
see
that
okay,
okay,
this
is
one
of
our
graphql
tooling-
that
we
built
at
chili
cream,
it's
banana
cake
pop
our
graphql
ide,
and
I
tell
you
why
that
is
so
cool.
So
this
is
our
initial
request
and
we
could
maybe
run
it
and
you
can
see
kind
of
takes
a
second
to
resolve
that,
and
that
is
our
what
we
would
do
like
if
we
just
executed
that.
B
B
That
is
three
times
faster
than
my
initial
request
for
the
first
set
of
data
right.
But
let's
explore
that
a
bit,
so
I
can
go
here
into
the
logs
chart
and
then
you
can
actually
see
that
we
fetched
a
lot
of
patches,
so
the
initial
patch
just
get
that
up
here.
The
initial
patch
just
contained
like
the
name
of
my
asset
and
then
a
second
patch
got
actually
the
second.
B
The
second
item
of
my
of
my
list
again
just
the
title
here
and
then
the
third
patch
actually
fetched
like
pricing
information.
So
it's
not
like
there's
no
order
on
the
back
end.
The
one
order
that
we
have
is
that
we
don't
send
a
patch
down
that
we
cannot
apply
to
the
data
that
we
already
have
received
on
the
client
side.
But
apart
from
that,
the
server
would
send
down
the
data
as
it
becomes
available.
B
We
could
do
more
here
because
we
deferred
like
the
price
and
the
expensive
part,
but
we
can
also
like
do
the
first
and
the
first
nested
defers.
Essentially,
so
we
could
put
another
differ
in
here.
We
can
see
that
we
now
have
20
patches
and
then
we
could
optimize
that
more,
and
you
can
already
see
that
now
we
have
30
patches
so
now
it
would
essentially
work
out
the
same.
We
get
patches
but
more
fine-grained,
so
you
can
optimize
that
to
your
component
needs
in
your
application.
B
One
one
thing
before
I
go
back
into
my
slides,
so
this
is
actually
the
actual
training
application
here
now
I
have
like
what
I
want.
I
get
a
fast
response
of
my
application
and
I
just
have
one
graphql
request
and
this
graphql
request.
Actually
you
can
see
here
we
have
a
couple
of
patches
and
it
uses
standard
http.
B
So
when
I
show
this
on
conferences
to
people,
they
think
okay,
are
you
using
web
sockets
or
what
are
you
using
for
that?
Because
web
sockets
are
actually
difficult
to
scale
and
people
then
don't
want
to
use
it,
but
this
is
actually
just
http
and
it
will
work
on
anything
that
you
want
to
use
it
with
and
it's
easy
to
scale,
and
it
essentially
works
with
something
like
these
multi-part
responses
combined
with
chunked
encoding,
but
we'll
talk
on
that
more
in
a
second,
let's
go
back
to
here.
B
B
So
as
that,
as
more
content
becomes
available,
the
server
will
send
us
like
these
new
multi-part
sections
down
as
new
data
patches,
and
you
can
see
that
in
the
second
data
patch
we
have
now.
A
second
field
here
called
pass
and
pass
tells
us
where
we
can
apply
this
patch
to
in
our
original
data
and
again
we
have
more
payloads
until
at
some
point
we
have
no
payload
anymore
and
that's
when
we
are
finished
and
the
client
knows.
B
A
A
A
A
And
if
the
field
is
a
list,
type
it'll
call
complete
value
on
every
item
in
the
list
and
if
the
field
is
an
object
type,
it
starts
this
whole
process
over
again
calling
execute
selection
set
on
the
selection
side.
For
that
object,
and
then
that's,
finally,
how
you
get
the
completed
values
for
your
field.
A
So
when
we
have
deferred
stream
now
we
have
a
new
array
that
we're
tracking
called
subsequent
payloads
and
we
use
this
to
keep
track
of
any
deferred
stream.
Payloads
that
are
executing
as
they're
encountered
so
back
to
execute
selection
set
like
before
we
pass
the
selection
set
to
collect
fields
and
again
it's
going
to
recursively
iterate
through
the
inline,
fragments
or
fragment
spreads.
A
A
A
Just
writing
it
up
in
a
format
of
a
pattern
called
architectural
decision
records
where
explain
the
background
context
around
an
issue.
What
decisions
we
made
with
the
working
group,
the
consequences
of
those
decisions
and
the
current
implementation
status,
and
I
hope
that
this
is
a
valuable
resource
going
forward
that
can
be
preserved,
and
we
can
always
look
back
on
why
we
made
the
decisions
we
did
and
if
you're
working
on
another
large
spec
proposal,
I
think
it's
you
can
take
a
similar
approach
and
I
just
want
to
highlight
for
the
rest
of
the
talk.
A
But
we
found
that
that
caused
backwards,
compatibility
issues
where,
if
a
client
is
communicating
with
a
server
that
doesn't
implement
default
stream,
it's
not
going
to
see.
That
is
final,
because
it's
not
in
the
spec
as
it
is
today
and
I'll
get
stuck
waiting
for
more
payloads.
So
we
decided
to
inverse
it
call.
It
has
next
and.
A
And
yeah,
and
then
so
another
thing
with
has
next
is
that
when
you
have
an
async
data
source
like
in
async
interval,
you
may
not
know
if
they're
going
to
be
any
additional
list
items
until
some
time
is
passed
after
the
final
one
has
been
sent.
So
for
this
use
case,
we
allow
a
payload
containing
only
has
next
false,
no
data
or
any
other
fields,
and
when
your
data
source
eventually
does
indicate
there's
no
more
items,
you
can
send
that
to
the
client
and
they
know
to
close
the
connection.
A
A
another
thing
that
we
talked
about
for
a
while
is
we
only
allow
the
deferred
directive
on
fragment,
spreads
and
inline
fragments.
The
first
experimental
implementation
of
deferr
was
in
apollo
server
and
that
supported
defer
on
fields
and
at
first
dibs.
We
start
we
were
trying
that
out
on
our
code
base
and
we
found
that
most
of
our
use
cases.
A
A
Another
topic
that
we
spent
a
lot
of
time
on
in
the
working
group
meetings
is
non-null
propagation,
so
the
graphql
spec
requires
nulls
on
non-null
fields
to
bubble
up
to
the
next
nullable
field.
So
how
do
you
bubble
up
to
a
field
that
was
already
sent
to
the
client?
You
can't
go
back
in
time
and
change
what
was
sent
so
we
decided
that
defer
and
stream
are
going
to
act
as
null
boundaries,
and
so
I'll
show
a
few
examples
to
explain
what
that
means.
A
A
So,
with
stream,
we
originally
said
that
you,
the
data
field
on
a
stream
payload,
would
just
directly
point
to
the
stream
list
item
and
we
decided
and
said
that
we're
going
to
wrap
the
stream
list
item
into
an
array
and
that
allows
us
to
differentiate
between
a
valid
null
result
and
a
null
that
originates
from
an
error
which
would
have
bubbled
up
in
this
example.
The
heroes
field
is
a
list
of
non-nullable
object
types
and
we'll
say
that
the
third
result
errors,
and
so
what
happens?
Is
the
initial
payload
sent
normally
the
second
payload
returns?
A
The
second
list
item
wrapped
in
an
array
and
the
third
payload
returns.
The
errors
field
populated
with
the
non-null
error
and
data
is
entirely
null,
and
so,
if
that,
if
the
type
of
the
list
allowed
null
fields,
it
would
have
returned
an
array
with
a
single
node
value
so
with
both
defer
and
stream.
It's
whenever
a
client
sees
this
data
field
set
to
null
they're
going
to
know
that
that
null
should
have
bubbled
up
higher
and
so
the
spec's
not
requiring
clients
to
handle
that
in
any
specific
way.
A
Yeah-
and
we
also
talked
a
lot
about
batching-
we
want
to
keep
our
proposals
small,
so
I
don't
think
that
will
include
batching
in
the
initial
spec,
but
we
are
thinking
about
how
it
could
be
enabled
later.
We
want
to
ultimately
just
make
sure
that
any
decisions
that
we
make
now
aren't
going
to
make
it
harder
to
implement
batching
in
the
future.
A
A
Or
another
approach
is
that
we
could
just
return
batches
of
the
entire
payload
objects
where
the
graphql
server
will
just
yield
arrays
of
the
payload
format
that
we
talked
about,
and
this
has
the
benefit
of
being
able
to
return
batches
of
both
deferred
data
and
stream
data
from
any
field.
Instead
of
just
the
stream
data
from
a
single
field.
A
Yeah,
and
so
that's
all
that
I
have,
I
hope
that
that
was
a
good
overview,
a
deferred
stream,
a
little
bit
of
why
it
took
as
long
as
it
did,
and
I
encourage
you
to
check
out
the
discussion,
repo
there's
examples
in
there
how
to
get
started
and
feel
free
to
start
new
discussions.
If
you
have
any
questions,
feedback
concerns
yeah.
Thank
you.
B
A
A
Yeah,
I
think
we
do
have
it
supported
in
in
our
proposal.
I
think
it
could
be
useful
in
cases
like
in
relay.
You
might
have
a
subscription
where
you're
putting
a
fragment
on
that
subscription
that
corresponds
to
some
large
ui
component.
That
component
could
have
that
fragment
could
have
a
ton
of
other
fragments
underneath
it.
There
could
be
deferrers
and
streams
in
there,
and
I
think
that
it
would
all
work
with
the
way
we
have
it.
It's
additional
payloads
get
sent
over
that
same
connection.
B
Yeah,
I
think
the
main
difference
for
subscriptions
is
in
subscription.
You
aim
for
smaller
results,
like
only
the
things
that
really
change,
so
you
want
to
have
incremental
small
messages,
because
that
could
be
a
high
frequency.
You
have
a
high
frequency
there,
so,
while
it's
possible
in
most
cases,
you
have
stream
and
defer
on
standard
http
requests
and
graphical
like
query
or
mutation
like
it
will
work
with
any
operation
type.
Like
also,
we
talked
about
mutations
and
there
are
some
limitations
in
mutation,
because
we
cannot
defer
the
root
level,
essentially,
the
mutation
itself.
B
Nesting
under
that
yeah,
exactly
because
in
mutations
like
the
top
level
field,
is
the
mutation.
So
in
the
graphical
spec
we
have
this
secret,
a
sequential
execution
there
and
putting
the
fur
on
that
would
essentially
change
the
order,
but
on
the
lower
level
fields,
these
are
essentially
queries
on
the
changed
state
of
our
server,
so
we
can
put
defer
in
there.
So
there
are
a
couple
of
limitations
depending
on
your
operation
type,
but
in
general
it's
possible.
A
With
subscriptions,
the
payloads
are
coming
over
the
same
channel
as
the
actual
subscription
events,
so
that
has
next
field
could
be
used
to
after
you
get
a
has
next
false.
The
next
one
is
going
to
be
the
next
subscription
event
and
not,
and
they
get
queued
up
behind
you're
not
going
to
get
you're
not
going
to
get
a
patch
from
a
subscription
payload.
That
comes
after,
like
the
next
event.
A
It
might
be,
but
it's
it
shouldn't,
really
block
it,
because
you
could
have
the
the
same
situation
without
deferring
stream.
If
your
resolvers
take
a
really
long
time,
then
those
subscription
payloads
are
going
to
get
backed
up
this.
It
really
should
only
mean
that
you're
going
to
get
the
non-deferred
and
streamed
parts
of
the
payload
sooner.
B
Essentially
the
same
because
like
in
subscription,
you
have
like
your
event
stream
that
essentially
triggers
the
same
query
engine
to
execute
your
request,
so
it
like
there's
no
over
all
additional
complexity.
It's
just
that
you
have
to
think
about
high
frequency
there
so
having
very
expensive
resolvers
in
a
subscription
would
be
counterproductive.
In
many
cases,.
A
It
was
relatively
straightforward
to
implement
and
graph
fuel
js.
It
was
kind
of
just
one
async
iterable
that
you're
getting
the
subscription
events
and
that
event
could
give
you
another
one.
That's
giving
you
the
deferred
stream,
so
it's
kind
of
just
send
that
one
out
drain
this
one
move
on
to
the
next
one.
B
Yeah,
I
think
one
of
the
really
exciting
things
is
that
you
actually
can
use
all
of
this
today,
like
if
you
take
relay.
If
you
take
the
newest
version
of
react,
then
you
can
use
suspenseless,
you
can
use
a
stream
and
defer
with
relay.
There
are
packages
two
packages
for
the
transport
already
that
you
can
plug
in,
so
it
all
works.
B
A
B
So
at
the
moment
we
don't
discuss
it
in
the
working
group,
I
mean
there
were
approaches
towards
life.
There
are
also
a
couple
of
experimental
implementations
out
there.
I
mean
all
these
ideas
actually
spawn
so
many
community
experiments,
but
it
always
takes
like
to
get
it
really
into
the
spec.
You
need
a
champion
that
really
cares
about
like
this.
This
case
rob
is
doing
a
lot
of
work
for
the
last
two
years
on
that
spec
proposal.
B
So
you
need
somebody
who
cares
about,
for
instance,
life
and
says
I
want
to
solve
these
problems,
and-
and
I
push
that
and
I
direct
people
that
also
want
to
work
on
that
so
and
with
deferring
stream.
We
had
this
push.
Actually,
there
were
also
people
from
facebook
in
the
beginning,
and
your
colleague
also
was
working
on
that.
So
there
was
a
big
push
and
like
rob,
is
keeping
a
track
of
all
and
pushing
it
along.
B
A
B
B
Apart
from
that,
it
could
be
that
the
overall
request
actually
takes
a
bit
longer
because
we
spawn
it
off.
It
also
depends
on
how
you
implement
your
execution
engine.
What
we
did
in
hot
chocolate
was
like
you
can
decide
if
the
subsequent
payloads
only
be
only
start
processing
after
we
wrote
the
first,
the
initial
payload
into
the
output
stream,
but
you
can
also
decide
to
start
processing
these.
B
At
the
same
time,
it
depends
on
your
strategy
that
you
have
in
the
back
end,
there's
also
like
the
option
that
is
still
being
discussed
so
that
the
execution
engine
can
also
like
choose
to
skip
the
deferred
directive.
It's
not
recommended,
but
for
advanced
use
cases.
It
could
be
that
the
server
says
oh
you're,
just
deferring
here,
scalars
leaf
types
that
we
anyway
have
already
in
memory.
So
why
deferred?
We
just
send
it
down
right,
there's
a
specific
note
in
the
specification
as
of
yet,
but
that
also
makes
it
backwards
compatible.
A
B
Oh
okay,
I
think
there's
a
so.
Let
me
say
two
things
here.
So
the
graphql
core
specification
doesn't
care
about
transport.
So
it's
there.
We
don't
actually
care
about
these
transport
specifics,
but
there
is
a
graphical
over
http
spec,
where
we
are
specifying
these
kinds
of
things
and
like
in
this
particular
case.
We
have
an
http
request.