►
From YouTube: GraphQL Working Group - 2022-10-06
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/
B
B
C
Yeah
sure
likes
to
play
Awards,
so
she
I
took
her
one
room,
because
my
girlfriend
is
sleeping
right
now,
so
I
give
you
a
break,
but
cat
is
so
like
to
play
what
so
she's
running
around
and
destroying
Quake
to
get
scratching
posts
and
hiding
in
them.
Like
background,
oh,
my
you
actually
were
good
at
getting
guessing
like
a
cat
by
by
noise.
B
B
C
No,
it's
like
I
would
call
this
Breed
Street
cat,
Ukrainian,
Street
yeah.
C
A
Yes,
that's
right
and
Lee's
asked
me
to
run
tonight
tonight's
meeting
and
on
that
topic,
I
think
we
have
settled
down.
So
yes,
hello.
Everyone
welcome
for
Welcome
to
my
word
starting
well
welcome
to
this
graphql
working
group
meeting
thanks
for
coming
by
joining
the
meeting,
you
will
have
already
agreed
to
the
specification
membership
agreement
to
the
participation
guidelines,
the
contribution
guide
and
the
code
of
conduct,
all
of
which
are
linked
in
the
agenda.
A
Perfect
thanks
a
van
okay
thanks,
everyone
I
wonder
if
we'll
have
a
few
more
people
drop
in
in
half
an
hour
at
the
normal
meeting
time,
but
as
for
now,
that's
everyone
who
has
added
themselves
to
the
agenda.
A
Speaking
of
there
is
two
more
meetings.
This
month
coming
up,
they're
called
secondary
meetings,
there's
one
which
is
on
Wednesday,
and
that
is
going
to
be
in
the
afternoon
Pacific
time,
which
makes
it
the
morning
in
the
Asia
Pacific
time
zones,
and
there
is
one
on
the
I
believe
the
20th,
which
will
be
the
same
times
as
this
meeting.
So
if
we
do
happen
to
run
over,
we
can
always
push
some
items
into
those.
A
Is
anyone
able
to
take
notes
for
us
today?
Any
volunteers.
A
A
Helpful
thanks,
Alex,
okay,
next
up
is
reviewing
the
agenda,
so
I
see
on
the
agenda,
which
I
will
just
refresh
I'm
gonna,
see
if
there's
any
pending,
pull
requests
which
there
are
not
and
we're
reviewing
the
previous
meetings.
Action
items
like
we
do
every
month
we'll
be
discussing
the
defer
and
stream
stuff
which
Rob
is
here
for
and
then
Alex
will
be
giving
us
an
update
on
client
controlled
nullability
by
the
looks
of
it
could
be
quite
a
short
meeting.
A
No
fantastic
all
right!
Well,
let's
have
a
look
at
the
action
items.
I
notice
that
none
are
marked
ready
for
review.
Does
anyone
have
an
action
item
that
they
think
is
ready
to
be
marked
as
done.
D
Yeah,
so
I
have
a
a
few
things
that
I
want
to
discuss.
First
off
spec
VR
is
open.
It's
up
to
date
with
all
of
our
discussions
so
far
still
encourage
everyone
to
review.
It
I
believe
that
I've
addressed
all
the
comments
that
were
left
there
up
until
now,
but
let
me
know
if
that's
not
the
case.
D
So
the
the
reference
implementation
right
now
and
the
spec
PR
does
have
support
for
subscriptions
with
defer
and
stream.
But
I
do
think
that
there's
a
lot
of
details
that
would
benefit
from
some
deep
dive
discussions
and
just
I
think
in
the
interest
of
moving
the
rest
of
deferent
stream
forward
more
quickly.
I
want
I'm,
proposing
that
we
drop
support
for
deferred
stream
for
this
spec
proposal,
and
then
it
could
be
Revisited
later
I.
I
do
think
that
one
thing
that's
important
is
allowing
shared
fragments
between
queries
and
subscriptions
and
mutations.
D
So
especially
with
relay
it's
very
common.
You
co-locate
your
fragments
or
your
components.
They
include
a
lot
of
other
fragments.
You
may
have
a
defer
somewhere
I,
don't
think
it
should
just
be
a
validation
error
if
one
of
these
fragments
is
included
in
a
subscription
operation,
so
instead
I
think
that
we
should
allow
it
if,
if
that
defer
is
disabled
with
the
if
argument,
so
that
would
mean
that
we
can't
use
a
validation
error,
because
very
we
don't
have
access
to
variables
during
the
validation
stage.
D
So
I
proposed
raising
a
field
error
if
you
encounter
a
defer
or
stream
that
is
not
disabled
with
its.
If
argument
during
execution,
I
have
PRS
for
that
for
graphql.js
and
I
have
a
change
ready
to
go
in
the
spec
PR.
If
you
all
agree,
I've
had
this
discussion
open
for
a
while
and
I
pinged
a
couple
people
about
it
and
I
haven't
heard
any
any
descent.
D
Basically
so
I
I
want
to
bring
it
up
again
here
and
see
if
there's
any
other
thoughts
or
if
I
should
move
forward
with
this.
C
Just
to
clarify
by
a
problem
with
subscription,
do
you
mean
like
discussion
that
I
opened
or
or
there
is
also
other
like
active
discussion
or
disagreement?
It's
about
subscription.
D
The
way
yeah,
the
way
that
I
had
it
implemented,
is
that
each
each
deferred
or
stream
payload
for
a
subscription
event
would
have
to
come
before
the
next
event
and
I
think
that
is
somewhat
controversial.
I
think
that's
related
to
the
one
that
you.
C
D
I
I
mean
I've.
I've
also
heard
some
feedback
about
like
exactly
if
I,
I,
guess,
I
I
feel
like
they're
all
kind
of
related.
It's
like
should
they
be
multiplexed?
Should
there
be
additional
fields
for
handling
multiplexing
and
I?
Also,
don't
think
that
we've
spent
a
lot
of
time
discussing
it
so
I'm
I'm
sure
there
will
be
more
and
I
think
that
this
is
a
pretty
big
issue,
so
I
I
don't
know
if
it.
D
C
D
Yeah
I
I
definitely
think
it's
solvable
and
if,
if
I
thought
that
this
was
just
like
a
small
thing,
that
in
like
one
or
two
meetings
we
could
work
through,
I
would
move
forward
with
it,
but
I
think
it
has
the
potential
to
like
and
I
think
it
deserves.
Like
really
focused
thought
on
how
the
best
way
to
do
it
is
so
that's
why
I'm
proposing
not
including
it
okay.
C
In
initial,
not
included
it
through
wait
to
feel
like
somebody
else
should
Champion
it.
D
D
C
Idea
is
to
shape
with
you
know
like,
so
it's
not
them
butter,
much
or
ideas
to
like
remove
it
from
initial
proposal,
make
with
validation
rules
that
you
suggested
and
right,
because
the
whole
package
like
the
host
back
there
when
the
market
will
be
without
subscription,
but
in
this
with
specific
validation
I'm
like
I'm
I'm,
basically
trust
you,
if
you
think
so,
I
think
subscription
can
be
so.
But
if
you
think
it's
it
will
create
Cascade
cascading
discussion
and
disagreement
yeah.
Maybe
it
should
be
discussed
except
separately.
D
And
and
I
don't
want
the
rest
of
deferred
stream,
which
I
think
we've
made
a
lot
of
progress
on
and
we're
all
get
it
feeling
like
it's
getting
closer
I.
Don't
want
that
to
be
held
up
by
that
cascading
discussion
or
that
did
not
get
the
attention
that
it
deserves,
because
we're
more
focused
on
the
bigger
picture.
A
My
main
concern
with
this,
which
I
think
I've
already
shared
with
you,
is
I.
Don't
I,
don't
like
the
idea
of
just
sort
of
throwing
an
error
in
this
situation
at
run
time,
it
feels
like
a
validation
rule
would
be
cleaner,
but
it's
not.
You
know
it's
not
possible
for
us
to
do
that
in
the
way
that
validation
is
set
up,
because
you
can't
depend
on
variables
to
do
that.
A
There
have
been
discussions
in
the
past
about
having
like
a
second
phase
of
validation
that
validates
once
the
variables
are
known.
But
nonetheless,
your
point
about
sharing
the
fragments
is
a
very
solid
one.
A
I
was
just
looking
at
the
the
types
of
the
directives
and
I
think
it
may
have
been
me
that
raised
before
that,
the
the
ifs
should
be
non-nullable,
which
they
are
now
with
a
with
a
default.
But
I
was
actually
wondering
whether
if
we
made
them
nullable
again
and
removed
the
default,
we
could
actually
change
kind
of
Behavior.
So
if
you
app
stream
something
on
a
query
or
a
mutation,
then
it
would
stream
by
default.
A
But
if
you
outstream
on
a
subscription,
it
would
not
or
something
like
that,
but
I'm
I'm
not
sure
that
that
really
fixes
the
issue
you
still
have
to
handle.
If
someone
says,
if
true
with
a
variable
or
something
like
that,
so
yeah
I'm
uncomfortable
with
this
solution
but
I
think
it's
the
only
one.
If
we
don't
want
stream
and
defer
to
work
on
subscriptions
for
now
and
we
want
to
support
fragments,
then
I
think
it's
the
only
option.
A
I'm
just
really
I,
find
it
a
little
bit
distasteful
to
to
be
throwing
an
error
like
that.
D
Yeah
I
I,
don't
I,
don't
disagree.
I
do
hope
that
it's
that
it
is
temporary
and
that
we
do
see
different
stream
through
with
subscriptions
eventually
and
remove
it.
What
I
I
would
about
changing
the
removing
the
defaults
and
having
different
behavior
for
stream
for
a
subscription
and
query
I
think
that
runs
into
the
issue.
Then,
when
we
do
enable
it,
it
would
be
a
breaking
change
if
we
reverse
that
behavior
and
also
has
the
potential
to
just
be
confusing
of
different
defaults
in
different
scenarios.
C
Oh,
my
good
idea,
I
have
a
just
now,
so
maybe
I
didn't
give
it
a
lot
of
food,
but
so
I
behavior
that
we
have
right
now
in
Spec
pair
one
that
we
already
have
in
the
text.
It's
pretty
conservative,
so
it's
the
stuff
that
anyone
can
support.
It's
just
like
people
have
problem
like
with
performance
and
optimization
it's
preventing
performance
and
optimization
and
stuff.
What?
If
we
leave
every
businesses
and
just
add
the
note
that
in
future
we
can
like
clients
should
not
be
dependent
on
stuff
being
delivered.
A
When
we
change
that
behavior
that
we've
told
them
we're
going
to
change,
but
we
haven't
told
them
what
we're
going
to
change
it
to
I
mean,
for
example,
if
you
do
like
a
subscription
payload
and
then
all
of
the
stream
and
defer
payloads
subsequent
payloads
that
come
after
that,
and
then
you
do.
The
next
subscription
payload,
it's
fine.
F
B
Yeah,
what
if
we
just
say
at
least,
would
it
differ?
What
do
we
just
say?
If
you
don't
support,
we
say
that
it's
optional
to
support
so
at
least
for
the
door.
We
can
say
you
should
the
server
can
just
ignore
it
if
it
doesn't
support
it,
not
throw
it
or
I.
Don't
support
this,
but
ignore,
and
that
brings
me
to
my
other
question.
We
kind
of
skip
the
first
item.
Spec
PR,
discussion
and
I
was
I.
I.
Think
I
raised
it
before
the
the
instruction.
B
If
there
is
defer,
then
the
payload
should
be
deferred,
I
was
I,
believe
I
was
suggesting
to
make
it
it
can
be
deferred.
So
basically
kind
of
defer
operation
is
optional.
The
client
lets
server
know
that
he
needs
certain
things
first
and
marks
this
can
can
be
deferred
if
it
takes
too
long.
B
Basically,
it
means
that
if
you
don't
support
defer,
then
you
deliver
as
usual.
In
whatever
fits
you,
it
means
that,
for
example,
defer
directive
is
kind
of
optional
for
execution.
If
you
don't
support
it,
you
deliver
you
just
ignore
it
and
deliver
it
all,
and
basically
it
means
that
if
the
server
finds
out
that
the
Deferred
payload
is
actually
immediately
available,
why
not
return
it?
B
I
and
I
think
it
fits
well
in
what
we
discussed
here,
at
least
for
defer
when
defer
can
be
ignored
by
the
server
either,
because
it
doesn't
support
it
or
because
default
fragment
is
immediately
available.
D
Yeah
I
don't
want
to
get
too
off
topic
and
what
you're
saying
is
related
to
the
next
discussion
that
I
have
on
on
the
agenda,
but
specifically,
if
I
think
that
if
we
say
that
the
server
should
just
ignore
the
Deferred
directive
on
subscriptions
now,
that
would
mean
that
clients
would
not
be
expecting
anything
to
be
deferred
when
they
execute
your
subscription.
And
when
we
change
it
later,
it
would
be
a
breaking
change
where,
if
it's
an
error
now
then
going
from
an
error
to
a
non-error
would
not
be
breaking.
B
But
again,
why
make
it
required
for
the
server
to
defer.
D
It's
a
it
I
mean
you're
you're,
saying
that
we
changed
the
record.
I
mean
it
could
be
according
to
the
RFC
definition
either
like
must
should,
or
May
and
I
think
you're
proposing
May
when
it
should
right
now
and
and
it's
we've
been-
we
went
back
and
forth
on
it
a
lot
and
the
reason
for
should
was
that
we
don't
we
don't
want
servers
to
like
not
the
server
should
like
it
should
follow
it
or
it
should
consider
the
consequences
of
not
following
it.
D
That's
what
we're
saying
by
should
and
if
we're,
if
clients
like
can't
rely
on
the
server
to
do
it
at
all.
Maybe
a
server
says
it
supports
it,
but
it
just
ignores
it
like
80
of
the
time
that
would
be
more
in
line
with
saying
that
it
may
do
it,
and
that
could
be
bad
because
then
clients
could
potentially
I
mean
developers,
not
clients
could
say
I,
don't
want
to
I'm,
not
even
gonna
use
defer
I'm
going
to
use
multiple
payloads,
multiple
queries
in
a
waterfall
fashion
instead
and
I.
B
D
C
I
actually
think
it
can
work
like
in
a
sense
if,
like
related
to
the
next
discussion
item-
but
it's
related
to
this
one
about
incremental.
If
we
include
entire
stream
before
chunks
in
initial
incremental,
we
don't
have
this
problem
of
like
multiplexing
at
all.
We
don't
need
the
special
validation
Rule,
and
it's
like
quite
need
to
handle
it
anyway,
since
we
discuss
it
as
like,
viable
optimization.
So
and
it's
not
something
like
client.
C
Most
of
the
clients
will
have
code
for
query
and
notation
that
should
handle
like,
but
it
was
being
in
line
inside
ignition,
cremato,
And,
Delay
or
delivery
subsequently,
so
like
in
real
life,
clients
who
have
a
code
to
handle
Pilots
being
in
one
packet
and
in
like
multiple
pockets,
and
we
don't
have
like
this-
we're
validation
rule.
C
So
what
do
you
think
about
spec
Spectrum
say
streaming
different
subscription
award
validation
rule
is
the
same,
but
for
now
everything
should
be
delivered
inside
the
first
first
like
inside
one
chunk
inside
one
response.
C
Ignored
from
a
shape
of
response
will
be
similar
to
stream,
so
data
will
include
only
non-stream
default
part
and
the
rest
of
the
stream
before
chunks
included
in
initial
incremental.
So
it's
so
I
expect
be
here,
so
it's
important,
optimization,
but
just
for
now,
I
say
a
subscription.
Everything
will
work
like
like
that
until
we
figure
out
how
to
do
increment
multiplication
and
I
also
think
for
typing
it
for
code
generation,
it's
also
better
because
for
data
you
will
generate
the
same
way
types
and
the
same
types
for
incremental.
D
Is
it?
Is
it
still
the
same
issue
if
to
move
from
subscriptions
all
inside
of
the
first
payload
versus
breaking
out
later?
That
becomes
a
breaking
change.
C
Realistically
people
will
use
subscribe
stream
and
G4
inquiring
mutation
subscription
and
more
more
oftenly
inquiring
motivation
so
like
they
will
know
that
it
can
be
shipped
as
one
response,
and
this
multiply
responses
it
just
like
happens
that
until
we
figure
out
Multiplex
and
worship
in
one
response.
Thank
you.
A
Yeah,
if
it
seems
to
me
that
the
multiplexing
is
the
is
the
thing
that
causes
the
trouble
here
and
we
don't
have
multiplexing
for
other
situations.
So
if
we
agree
that
when
we
enable,
if
and
when
we
enable
multiplexing,
we
do
so-
maybe
via
an
additional
argument
to
to
stream
and
defer
or
something
like
that,
then
maybe
we
can
just
support
it
as
it
currently
is
without
requiring
this
temporary
workaround,
which
I
think
is
basically
aligned
with
what
Ivan
is
saying
separately.
A
I
was
thinking
about
other
situations
where
we
might
have
this
kind
of
problem,
and
one
is
the
batched
transport
that
is
quite
common
with
Apollo
server,
for
example,
where
use,
rather
than
sending
a
single
graphql
request,
you
send
a
batch
of
graphql
requests
in
an
array
if
they
have
stream
and
defer
inside
of
them.
A
That
would
need
handling
at
some
point
and
it
wouldn't
just
be
by
returning
a
longer
array
of
results
which
is
effectively
kind
of
what
we're
talking
about
with
the
multiplexing
of
the
the
subscriptions
I
think
you'd
solve
that
the
transport
level
by
just
wrapping
each
one
of
them
in
a
in
another
array
and
just
feeding
it
in
through
that
or
something
like
that,
I'm
not
exactly
sure,
but
this
multiplexing
concern
does
feel
like.
It
would
also
relate
to
that
batch.
A
Payload
response,
so
I
think
we,
if
and
when
we
solve
multiplexing
it
won't
just
apply
to
subscriptions,
but
also
to
things
like
those
batched
transports
so
yeah.
If
we
can
just
avoid
the
problem
of
multiplexing
for
now,
can
we
just
go
ahead
with
the
same
behavior
first
for
subscriptions
as
we
do
for
queries
and
mutations.
F
C
A
problem
in
in
that
case
is
like
default.
Behavior
will
always
be
like
if
multiplexing
is
solved
by
client.
People
will
want
to
like
better
performance,
some
multiplexing
enabled
by,
but
by
fixing
like
current
version
as
default
version,
we
will
say
that
default
is
not
performant,
which
is
better
than
one
grand
I'm
like
I'm
I'm,
rather
wait
so
I
agree
with
Rob.
C
In
that
we
should
cut
it
and
since,
like
the
whole
proposal,
took
so
long
yeah,
we
should
cut
it
I,
just
like
discussing
a
way
to
cut
it,
because
I'm
like
why
I
opened
like
an
issue
about
Multiplex
and
I,
think
default.
Behavior
should
be
performant
and
for
like
most
of
the
cases
like
at
least
like
the
phone
Behavior
should
be
what
what
you
want.
What
most
of
the
clients
will
want
so
I'm
like
I'm
against,
like
Flex.
C
Weather
extension,
I
I
will
ask
like
people
inside
the
power
what
they
think
about.
Batching
and
stream
differ,
but
now
people
implementing
extremely
foreign.
C
Craze
I'm
not
sure,
even
like
how,
if
this
feature
is
extensively
used
or
not,
or
just
like
some
features
that
was
added
to
like,
and
nobody
using
it
I,
don't
know
like
I
know
for
sure
it's
like
it's,
not
a
Hot
Topic
inside
the
post.
So
it's
not
button
my
port
ahead.
It's
not
specified
by
spec
difference
in
that
sense
that
the
subscription
specified
by
its
backpack
batching
is
not.
A
It
sounds
to
me
like
there's,
not
a
clear
consensus
on
this
Rob,
even
in
this
relatively
small
group.
Would
you
like
to
move
on
to
the
next
topic
you
wanted
to
discuss.
D
D
This
is
a
Yvonne
opened
this,
as
we
were
saying,
we
do
say
that
defer
and
stream
should
be
the
server.
If,
if
the
server
encounters
the
first
stream,
it
should
follow,
and
that's
what
that
was,
the
this
other
issue,
I
had
open.
D
But
yeah,
but
but
what
evandres
is
difficulties
for
clients
to
understand?
The
response
is
getting
if
the
server
is
ignoring
some
of
the
deferred
directives,
but
not
others.
So
he
is
proposing
that
we
allow
implementations
to
fully
ignore
the
first
stream
or
you
either
have
to
ignore
all
of
them
or
do
all
of
them.
C
Yes,
because,
like
in
a
case
that
some
some
stuff
in
one
and
some
not
online,
it's
really
hard
to
detect
basically
either
like
it
has
next,
is
false
or
absent.
C
Staff
should
be
easy
in
increment,
like
stuff,
should
always
be
in
incremental,
either
like
in
the
first
response
or
like
subsequent
response,
but
always
incrementary.
We
cannot
in
line
stuff
inside
the
data
like
some
of
the
stuff,
so
it's
like
you
can
ignore
stream
differ.
You
can
unwind
everything
in
one
response
and
have
has
next
Force,
but
you
cannot
unwind
stuff
directly
in
the
data
and
have
has
next
true,
so
you
cannot
mix
and
match
basically.
C
C
C
Data
for
particular
components
you
rendered
shaped,
so
it's
not
a
question
of
getting
the
whole
response.
The
whole
idea
for
D4
is
that
when
you
have
like
data
to
render
one
component,
you
actually
start
rendering
and
whole
point
of
this,
like
thing
is
to
our
clients
to
detect
but
more
efficiently,
so
client
can
detect
if
something
is
delivered
or
not
without
like
walking
into
data
and
checking
paths
and
passing
query.
D
Yeah,
so
the
the
nice
thing
about
should
is
that
it's
non-committal
in
a
way
that,
if
clients
like,
are
forced
to
account
for
the
fact
that
every
deferrer
could
potentially
be
ignored,
it
would
not
be
a
breaking
change
if
we
do
decide
to
change
it
to
a
must
or
even
a
May.
D
But
if
that's
impossible
for
clients
to
deal
with,
then
it's
not
a
good
solution,
but
but
I
do
think
that
it's
a
more
General
problem
of
it
being
hard
in
graphql
for
type
systems
to
understand
how
fragments
are
resolved-
and
that's
that's
I,
think
that
was
the
problem
that
that
the
Facebook
guys
were
trying
to
solve
with
either
is
fulfilled
or
with
Alias
fragments.
D
I
think
it
wouldn't
be
a
problem
for
clients.
If
we
had
those.
D
D
C
Yeah
not
only
not
only
fragments
so
like
first,
like
Matt,
said
his
proposal
is
not
the
ones
that
he
recommend.
One
alternative
I
want
to
emphasize.
C
What,
in
my
comment,
a
second
thing
is
not
only
about
fragments
and
unwind
fragments
fragments
make
it
impossible
to
detect
without
fragments
it's
hard
to
detect,
even
if
you
don't
have
any
fragment
or
unwind
fragment
in
your
query,
like
bio
women,
people
to
invite
directly
in
the
data
and
ship
subsequent
incremental
things,
it
Force
clients
to
check
Buffs
constantly
and
if
client
get
like
a
lot
of
data.
It's
like
performance.
It's
like
more
code,
it's
more
complexity
on
a
client,
so
I,
don't
it's
not
fragment
related
in
my
mind.
C
It's
so
I
created
two
ideas
that
clients
like
I,
don't
want
clients
to
have
complicated
my
hand
is
to
detect
if
something
was
in
line
or
not
because
like
to
to
detect
to
add
quietly
to
pass
quietly
and
it's
like
problematic.
It's
not
maybe
not
well
problematic,
far
away
because
otherwise
have
compiler
as
as
a
build
step,
but
for
other
coins
and
it's
more
problematic.
D
Yeah
I'm
not
sure,
if
we'll
be
able
to
get
consensus
here
on
this
issue
either,
but
I
I'll
try
to
get
more
discussion
on
this
discussion
topic.
C
Before
I
switch
because
like
in
this
topic,
nobody
opposed
that
I.
Think,
like
everybody
who
wrote
a
comment
basically
supported,
is
anyone
oppose
it
on
visco
or
like
wants
to
comment
it
with
like
some
some
like
potential
problems
with
it.
D
Yeah
I
want
to
hear
specifically
from
Michael,
because
I
know
that
he
had
talked
about
the
related
issue
in
his
implementation,
so
I
just
wanted
to
get
his
thoughts.
A
I
have
a
bit
of
a
security
concern
with
it
as
well.
I
wonder
if,
if
these
are
your
only
two
options,.
F
A
Think
many
servers
would
then
choose
to
to
do
what
David
suggests
and
put
any
deferred
or
stream
things
directly
into
the
the
incremental
field
in
that
first
payload.
If
you've
already
got
the
data,
the
problem
with
that
I
think
is
that
you
can
use
that
to
multiply
up
the
data.
That's
actually
returned
to
the
client
quite
easily,
so
you
can
imagine
having
a
number
of
deferred
fragments
that
refer
to
another
fragment
inside
of
them.
That's
a
big
one
and
effectively.
A
You
then
have
to
generate
that
many
many
many
times
with
the
paths
for
each
of
them
as
well,
whereas
if
you
were
to
just
inline
that
data,
the
graphql
deduplication
would
actually
just
you
know
squash
it
all
back
down
to
be
the
same
thing,
but
with
with
the
stream
interfer,
we
are
explicitly
enabling
the
the
duplication
of
these
fields
and
I
think
that
that
could
that
could
be
abused.
C
So,
in
which
scenario
server
should
detect
its
denial.
Well,
first
thing:
please
write
a
comment
and
probably
like
I,
have
like
some
question
about
this,
but
but
it's
longer
discussion.
Can
you
please
write
like
your
comment
and
we
continue
discussion
to
move
it
forward
also,
if
anybody
else
have
any
objection
to
this
one,
please
write
it
there
and
I
will
answer
it
and
participate
in
discussion.
D
Yeah,
so
we
have
the
that
has
next
field
on
free
on
responses
that
that's
new
with
different
stream
and
we're
saying
that,
if
you're
going
to
be
sending
multiple
responses
you
have
to
have
has
next
has
next
true
saying
that
the
next
one
is
coming
and
then
the
last
one
needs
to
have
has
next
false
to
indicate
that
it's,
the
last
payload
Yvonne
proposed
that
so
so
right
now
the
spec
for
what?
D
If
there
is
no
deferring
stream,
what
if
all
the
different
streams
are
turned
off
or
with
the
the
spec
says,
it's
not
required
for
graphql
operations
that
return
a
single
response
map
I
even
proposed
that
we
should
more
at
least
more
strongly
recommend
that
servers
that
do
a
plan
to
First
stream
put.
This
has
next
false
on
all
of
their
responses.
If
there's
only
going
to
be
a
single
response,
basically
I
think
just
for
more
consistent
shape
of
a
response
and
I
think
that
is
mostly
okay.
D
It's
just
that
clients,
if
like
if
a
client
is
going
to
be
interacting
with
both
a
a
server
that
supports
the
old
SPAC
into
server
that
supports
it's
new
on.
It
has
to
make
sure
that
it's
not
depending
on
has
next
always
being
there
like
it.
Shouldn't
write
like
something
like
this.
Where
it
has
next
does
not
equal
false,
then
there's
definitely
going
to
be
more
payloads,
because
if
hazmix
isn't
here
at
all,
then
then
you
can't
yeah
you'll
be
stuck
waiting
for
something
that's
not
coming
it
did.
D
We
did
when
we
originally
were
working
on
has
next.
It
started
as
the
opposite.
With
is
final.
That
was
that's
what
Facebook
uses
and,
and
they
had
a
similar
type
of
issue
where
they
had
recommended
that
we
invert
the
meaning
where
they
wrote
some
new
clients
that
I
mostly
interacted
with
the
servers,
and
they
were
putting
is
final.
D
True
on
all
these,
on
the
results
of
operations
that
were
only
giving
a
single
response
and
when
a
client
depended
on
it,
then,
when
it
connected
to
an
old
server
that
didn't
support
different
stream,
it
wasn't
there,
so
they
were
hanging
up
I.
Think
it's
less
likely
to
happen
just
because
of
I.
Think
usually
people
presume
that
something
not
being
there
means
false.
D
Probably
the
correct
code
will
be
written
more
often
than
the
other
one,
but
I
do
just
want
to
call
it
out.
For
this
case.
C
Yeah
and
a
little
bit
of
motivation
why
we
started
this
discussion,
it's
because
I
wanted
in
rackages
I
actually
wanted
to
to.
We
have
a
separate
function:
experimental
execute,
experimental,
incremental,
execute
or
something
and
I
wanted
to
return.
His
next
I
suppose
always
to
simplify
typing
and
to
unify
right
types
for
responses,
so
it
started
as
implementation,
detail
and
graphql.js,
and
we
discussed
that,
like
everything.
C
If
something
is
done
in
a
reference
implementation,
it
should
be
at
least
recommended
Behavior.
If
you
think
it's
like
I
deserve
to
be
informative,
graphic
address,
it
should
be
like
recommended
for
other
implementation.
Otherwise
it's
not
reverse
implementation.
This
is
like
motivation
for
this
issue.
D
To
address
Benji's
comment:
can
we
just
never
add,
has
next
false
that
just
the
only
case
where
that
might
be
weird
is
when
you
have
a
stream
like
like
right
now,
we
support
payloads
that
basically
only
have
has
next
false,
where
you
had
sent
the
last
payload
from
your
stream.
But
you
didn't
know
it
was
the
last
one
at
the
time
the
stream
closes
asynchronously.
C
I
think
if
we
think
one
Crown
in
terms
of
like
a
big
picture,
ideas
that
you
we
are
the
incremental
delivery
into
spark
and
in
future,
like
people,
will
use
graphql
through
protocols
that
support
transport
protocols
that
support
incremental
delivery,
so
in
a
long
run
like
you
will
always
have
has
next
present,
is
a
risk
for
so
true
and
it's
to
support
other
version.
We
will
have
like
optional
the
response
not
having
has
next
at
all
similar
to.
We
already
have
this
president
for
extensions
inside
an
error
like
spec
set.
C
You
should,
if
you
want
to
add
additional
fields,
you
should
use
extension,
but
we
understand
that
there
is
other
client
in
existence
that
don't
was
written
before
that,
but
for
all
newer
implementation,
we
recommend
you
to
use
extensions
inside
errors,
so
it's
the
same
here
so
like
for
all
new
clients,
so
all
new
servers
should
put
has
next
always
but
like
a
client
if
clients
want
to
support
other
servers,
clients
should
should
know
that
the
response
you
can
get
response
without
cast
next
and.
C
B
C
And
I
will
send
in
a
chat
example
of
wording
that
we
haven't
spec
about
extensions
and
we'll
find
the
link.
D
D
D
A
I
mean
I
always
seem
to
be
in
disagreement
of
adding
more
stuff
to
payloads
and
I
seem
to
be
in
the
minority
of
that,
because
everyone's
like
Jesus,
we'll
get
rid
of
it
nonetheless
I
think
adding
has
next
false
to
basically
every
graphql
payload
seems
other
than
the
ones
with
has
next.
True,
of
course,
seems
unnecessary.
It's
just
extra
data,
but
no
real
value.
B
C
C
We
have
like
one
possible
way
how
stuff
is
sent
because,
having
like
in
single
response,
if
you
have
like
you,
can
have
his
next
post
or
you
can
admit
it
and
having
two
options-
is
bad,
so
I'm
like
in
gzip
cam,
but
if
you
think
yeah,
maybe
it's
overdue
yeah
for
every
single
response,
even
small
one
yeah,
like
I'm
I'm
I,
agree
that
we
should
cut
option
and
have
only
one
and
if
everybody
agrees
that
only
one
is
forbidden.
Why
committing
it
I'm
agree
with
it.
D
Okay,
so
should
we
all
right
so
should
we
stick
with
what
we
have
for
now.
C
It's
optional,
I'm,
like
what
we
discussed
right
now
is
reversing
it.
Making
it's
operated
so
like
forbidden
it
to
have
has
next
at
all,
on
single
responses
and
as
a
person
who
suggested
we
think
I'm
like
I'm
joining
benjak
Benji
proposal.
So
I
don't
know
maybe
like
grow
up,
and
it
is
totally
opposite.
Proposal
of
obedient
has
next
on
on
Sim,
wait
single
response.
D
Oh
and
so
so
you
we're
saying
for
a
bit
forbidding
it
in
a
single
response.
We're
also
saying
forbidding
it
on
in
the
cases
where
it's
not
the
it's,
not
a
single
response,
but
you
know
that
the
last
response
is
also
going
to
be
the
last
one.
C
No,
what
what
do
I
if
it's
single
response,
easy
like
stuff
gets
in
one
shipped
inside
the
incremental
or
choir,
don't
have
streamed
before
it's
like
you
cannot
put!
Has
next,
okay
e!
If
it's
multiplayer
responses,
you
can
put
Heads
next
and
it's
up
to
you
to
decide
where
to
put
force
and
true
and
if,
if
you
can,
terminate
and
predict
that
it's
worth
by,
what
you
can
put
has
next
pose.
If
you
cannot
predict
that
you
can
ship
like
empty
object
which
has
next
Force.
C
D
You
right
right,
yeah
right
now.
It
is
mandatory
that
if
it
is
a
multiple
response
that
all
of
them
have
has
next
on
it,
whether
true
or
false
I
think
Benji
was
saying
that
that's
not
technically
required
because
the
life,
if
it's
the
last
one
and
you
know
it's
the
last
one,
then
you
could
still
omit
it
there,
but
but
I
think
that
makes
that
the
incremental
response
shape
more
less
less
reliable,
I
guess.
C
D
F
C
So
so
we
discussed
like
this
proposal
on
a
single
response
result
and
now
it's
award
in
the
spec,
if
I
like,
if
I'm.
C
Yeah,
what
what
I'm
proposing
in
supporting
Benja
proposal
is
to
basically
say
it's
allowed
only
if
responses
incremental
okay-
and
it's
also
my
objection
and
it
will
not
increase
by
what
size
for
for
single
responses
so
no
way.
A
Fantastic,
thank
you
rob
a
lot
of
work
still
going
on.
There
I
see
excellent
work,
keeping
up
the
momentum
there.
Next
up,
we
have
Alex
with
the
client
controlled
notability
update,
Alex.
E
Yes,
hello,
it's
been
in
a
minute,
but
I
want
to
get
client
control
nullability
moving
again
the
last
the
thing
I'm
blocked
on
right
now
is
this
discussion
thread
I've
reached
out
to
some
folks
at
meta
recently
to
try
and
get
get
that
started
out.
I
think
the
the
gist
of
it
is
that
Benji
I
believe-
and
let
me
know
if
I'm
just
representing
this
I
believe
it's
also
been
a
minute.
E
So
I
could
be
forgetting
everything
between
a
client
control,
no
ability,
the
the
assertion
and
a
question
mark
should
be
non-nullable
and
there
are
some
folks
at
meta
who
or
reasons
related
to
relay.
Although
I
don't
remember
if
that
was
the
case,
I
thought
that
that
shouldn't
be
that
everything
should
inherit
the
schemas
and
all
ability
which
isn't
marked
with
a
client
controlled
availability
designator.
E
C
Yeah
small
comment
about
what
one
and
little
bit
of
context.
So
for
a
long
time
since
we
started
discussing
streaming
control,
no
ability,
even
in
the
name
of
control,
no
ability,
it
was
no
ability
to
control,
but
when
it
was
like
and
I,
remember
it's
exactly
because
it
when
a
war
started
in
Ukraine
actually
missed
that
working
group.
For
that
reason,
Alex
suggested
like
options
and
people
out
of
blue
totally
out
of
blue
waited
for
try
catch
scenario
which
we
almost
never
discussed
before.
C
Explanation
why
it
was
90
degree
turn
so
I
might
basically
try
catch
its
it's
like
way.
More
complicated
mechanism
and
I'm,
like
I,
think
Benji
first
raised
that
in
some
other
discussion
inside
some
other
discussion,
but
I'm,
basically
in
support
of,
like
Kevin
Strong
case,
why
we
cannot
make
it
a
simple
non-nowability
and.
F
C
Yeah,
that's
why
I
started
but
Fred
and
please
please
commencer
if
you
have
strong
opinion,
because
it's
like
stuck
and
I
think
it's
like
very
important
for
for
this
feature
without
like
what
discussion.
We
cannot
move
forward
because
it's
like
really
big
big
difference
between
try,
catch
and
simple,
a
no
ability
example
and
inside
the
inside.
My
comment,
I've
wrote
like
explanation:
why
I
think
well,
I
think
like
no
ability
is
enough
and
why
it's
goofy
to
acuraway
use
case,
which
is
understand,
was
primarily
motivated
for
for
what
I
think
yeah.
E
I
think
I
think
the
the
behavior
that
we
landed
on
while
it
was
different
from
a
lot
of
the
stuff
we
discussed
earlier.
It
was
something
that
had
been
discussed
in
in
GitHub
threads
and
whatnot,
and
it
also
got
discussed
quite
a
bit
at
the
meeting
where
we
voted.
I
wrote
up
a
a
decision
log
about
why
decisions
were
made
which,
which
is
hopefully
easier
than
reading.
You
know
a
thousand
comment.
E
E
Is
entirely
possible
that
our
reasoning
was
bad
but
I
don't
think
anything
about
why
we
we
went
the
direction
we
went,
has
changed,
yeah
I,
don't
know,
I
feel
people
feel
like.
We
made
a
wrong
snap
decision
at
that
point,
then
we
can.
We
can
look
back
on
that,
but
but
you
know
I.
Ideally
we
should
be
responding
to
to
the
reasons
that
we
made
that
decision
rather
than
starting
from
scratch
again.
A
So
one
interesting
thing
about
this
is
because
it's
relay
that
wants
this,
and
that
wants
this
behavior
in
particular
relay
is
a
very
smart
client.
It's
it's
a
graphql
service
in
itself
right.
A
So
what
the
relay
team
I
think
have
already
set,
if
I'm
honest,
is
that
they
effectively
plan
to
compile
out
all
the
question
marks
and
exclamation
points.
Send
the
original
query
to
the
server
get
the
result
back
and
then
reapply
their
own
logic
there.
So
I
think
they
can
still
get
the
behavior
that
they
want.
I
mean
originally
I.
Think
they'd
have
been
happy
with
just
having
the
syntax
added,
so
they
didn't
have
to
use
a
directive,
so
so
I
think
that
they
could
still
preserve
this
behavior
that
they
want.
A
The
question
is
well:
first
of
all,
am
I
correct
in
that
and
I'd
have
to
ask
a
relay
person
to
to
be
able
to
actually
judge
that,
but
if
I
am
correct
on
that,
do
we
actually
need
to
have
this
same
relay
style
behavior
for
everyone
else
when
they
don't
have
the
same
kind
of
react,
error
boundaries
as
as
relay
has
or
do
we
just
want
the
simpler
solution
of
literally
just
changing
the
null
ability
and
using
all
of
the
tooling
that
we
already
have,
which
would
be
much
simpler
and
less
for
people
to
learn.
E
E
E
You
know
what
I'm
talking
about
the
things
yeah
fragment
version
yeah
yeah,
so
they
can't
use
client-controlled,
no
ability
because
they
rely
heavily
on
fragments
which
are
not
isolated
at
the
moment,
because
of
the
way
that
they
merge
quantity
control,
no
ability
becomes
basically
useless.
However,
they
eventually
want
to
use
client
control.
E
Nullability,
once
fragment
merging
is
also
available,
and
they
believe
that
eventually,
clients
reach
the
same
conclusions
that
they
have
reached
so
working
around
the
situation
that
they're
in
they
feel
makes
sense
for
everyone,
even
if
they
are
currently
going
to
not
use.
Like
you
said,
they're
going
to
compile
out
from
client
control,
nullability
stuff.
E
We
we
talked
about
when
we
were
talking
about
the
behavior
of
the
exclamation
point,
there's
the
behavior
we
were
going
with,
which
was
bubbling
Bubble,
Up,
nulls
and
then
there's
the
most
popular
behavior
that
they
have,
which
is
throw
to
the
to
the
nearest
error
boundary,
except
that
they're
using
reacts
error
boundaries.
So
it's
different,
but
we
talked
about
like
what,
if
for
everyone
in
the
spec,
it's
air
bubbling,
but
when
they
do
their
thing,
it's
throw
and
they're
like.
E
We
don't
want
it
to
be
different
for
people
who
are
using
relay.
They
thought
that
would
be
confusing.
But
this
try
catch
thing.
E
Sort
of
was
a
compromise
between
the
the
throwing
and
the
the
bubbling
I.
Think
I.
Think
that's
I!
Think
that's
the
summary
of
how
we
landed
in
in
the
place
we're
at.
E
But
yes,
we
we
should
talk
to
some
really
people.
I
was
hoping
that
there
would
be
folks
here,
but
it's
it's
is.
It.
Is
this
the
first
month
that
we're
doing
like
the
split
meetings.
A
It
is
yes,
but
also
it's
Apollo's,
Summit
conference.
So
that's
probably
part
of
the
reason
why
there's
very
few
people
here.
E
E
So
it's
gonna
be
up
to
the
meta
people
to
I.
Guess
I
guess
make
a
convincing
argument
for
because,
because
I
think
I
think
I
don't
know.
I
just
find
myself
agreeing
with
the
last
person
who
spoke
so
we'll
see
we'll
see.
Yeah.
A
One
of
the
the
things
trying
to
think
through
what
the
relay
team
are,
after
exactly
and
I'll
need
to
read
through
the
decision,
a
lot
to
remind
myself
fully.
So
apologies
if
this
doesn't
make
sense,
but
I'm
actually
wondering
whether
they
want
the
fragments
themselves
to
be
the
error
boundaries.
So,
whether
like
adding
a
question
mark
to
a
fragment
spread,
is
actually
more
along
the
lines
of
the
the
behavior
that
they
desire.
E
Yeah
we
talked
about
that
at
whatever
conference.
It
was
oh,
a
graphql,
conf
I,
don't
remember
what
conclusion
we
came
to
I.
Think
I
wrote
some
stuff
up,
but
I
don't
remember
if
I
did
but
yeah.
We
talked
a
little
bit
about
that.
There
I
I'll
try
to
track
down
what
conclusions
we
came
to
because
I
think
I
think
that
does
make
sense
like
that's.
That's
the
closest
thing
to
relays
Behavior.
C
One
thing
we
can
do
to
actually
right,
but
we
can
actually
use
the
number
Chinese
accelerated
with
discussion
if,
if
you
have
time
and
if
Facebook
assume
in
Facebook,
whatever
team
have
like
time
for
it,
we
have
a
next
meeting
European
meeting
this
month,
instead
of
like
doing
it
one
month.
C
If
you
have
time,
you
and
you've
been
quite
relating
somebody
from
relative
and
they
can
show
up,
we
can
show
up.
There
have
a
more
time
for
with
particular
issue
and
the
rich
consensus
before
next
working
group
and
the
next
working
group.
We
can
wait
stamp
on
decision
and
so
I
continue
to
figure
out,
like
small
stuff,
like
validation,
Rule
and
other
stuff
required
for
draft
two,
as
for
stage
2..
E
B
E
I
think
that'll
be
good
I'll
sign
up
to
come
to
that
one
too
and
see
if
I
can
get
some
folks
to
come.
Are
you
you're
gonna,
be
at
that
one
Benji.
C
C
Yeah
and
I'll
place
our
kid
like
big
chunk
of
time,
just
in
case
yeah,
we'll
probably
have
some
discussion
and
especially
if
somebody
from
real,
like
I
mean,
but
it's
all
dependent
on
if
they
have
time
to
show
more
to
join.
A
Okay,
thank
you.
Everyone
Jacob,
you've,
sent
me
a
DM.
Please
do
that
by
a
Discord,
because
the
chat's
gonna
disappear
in
just
a
moment.