►
From YouTube: GraphQL Working Group (Secondary, EU) - 2022-11-17
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/
A
C
A
C
A
Template
like
my
GitHub
handle,
is
the
longest
one
in
most
of
the
meeting,
so
I
need
to
adjust
like
a
table
Yeah
like
horizontally,
so
I
think
like
and
I'm,
not
the
only
one.
Some
people
probably
have
a
function:
I'm
assafi,
so
I
game,
maybe
make
it
right
either.
D
E
C
E
D
E
Some
parts
of
Canada
it
is
mandated
by
law.
Our
Province
doesn't
do
that,
but
what
they
do
is
if
you
basically
you'll,
get
a
reduction
on
your
insurance.
If
you
say
you'll
use
them
type
of
thing,
but
the
province
beside
us,
it
is
mandated
by
law,
Quebec
and
that
you
have
to
have
winter
tires
and
unfortunately,
what
that
means
is
people
are
so
annoyed
that
that's
a
law
they
buy
winter
tires
and
then
they
drive
with
them
all
year
long.
E
D
Because
it's
not
made
for
wet
that's
it.
B
D
E
E
C
B
E
C
He
can't
make
it
today
so
he's
asked
me
to
facilitate
the
meeting
so
I'll
kick
us
off.
I
mean
we
all
know
this,
but
nonetheless,
we
by
attending
here
we've
all
agreed
to
the
membership
specification,
membership
agreement,
the
participation
and
contribution
guidelines
and
the
code
of
conduct.
We
have
all
added
ourselves
to
the
agenda
and
we
all
know
that
this
is
being
recorded
and
we'll
go
out
on
YouTube.
C
So,
first
of
all,
hi
everyone,
I'm
Benji.
If
you'd
like
to
introduce
yourselves
in
the
order
in
the
agenda.
E
Hi
Hugh
from
Apollo.
C
Perfect,
that's
merged.
Okay.
Ideally
someone
would
take
notes,
please
normally,
that
would
be
me,
but
I
will
probably
be
busy
today.
C
C
Is
apparently
not
the
thing
that
I
thought
I'd
added
earlier
is
the
defer
and
stream
topic,
and
let
me
just
merge
this
item,
which
I
forgot
to
merge.
C
Also
mentioning
the
TSC
elections.
Is
there
anything
else
that
anyone
would
like
to
add
to
the
agenda
for
today.
C
No
excellent
I
would
like
to
mention
that
the
graphql
Foundation
conference
videos
are
now
live
on
YouTube,
so
you
can
track
those
down
through
the
playlists
on
there.
We
shall
move
on
to
the
action
items.
C
Okay,
we
can
always
return
to
that
later
on
in
the
meeting
in
the
meantime,
breezing
through
all
these
items.
At
the
moment,
gender
items,
the
TSC
elections
are
coming
up.
So,
as
you
all
know,
we
have
the
TSC,
which
is
Lee
plus
10
others.
They
work
in
a
cycle
of
a
two-year
stints
offset
by
one
year.
So
five
people
start
one
year.
Five
people
start
the
next
year.
Everyone
serves
a
two-year
term,
so
this
year
we
have
five
people
coming
up
for
the
end
of
their
term.
C
C
We've
been
a
little
late
running
this
compared
to
usual,
so
we've
pushed
the
time
frame
back
for
this
by
a
month,
so
those
that
would
have
ended
their
term
on
the
31st
of
December
now
actually
end
their
term
on
the
31st
of
January
and
I.
Think
the
vote
will
take
place.
C
The
very
beginning
of
January,
so
if
you'd
like
to
put
yourself
forward
for
that
or
if
indeed
you
are
expiring-
and
you
would
like
to
come
back
again-
please
do
fill
out
the
self-nomination
and
if
there's
anyone
that
you
think
in
the
community
would
make
a
great
TSC
member.
Please
again,
let
them
know
that
this
is
going
on
any
questions
on
that.
C
Okay,
excellent,
in
which
case
on
to
you
rob
with
to
fair
and
stream.
G
Hey
so
at
the
last
meeting
we
talked
about
deferring
stream
and
subscriptions
and
potentially
not
shipping
that
feature
as
part
of
this
initial
spec,
pushing
it
off
to
later
and
I
think
there
was
General
consensus
on
that.
G
G
So
yeah,
so
so
we
we
agreed
that
we
that
we
weren't
going
to
support
different
support
subscriptions
as
part
of
this
initial
spec
Tech
is
something
that
we
can
come
later
and
the
main
reason
is
so
that
we
could
have
more
in-depth
discussions
on
multiplexing
and
that
sort
of
thing,
so
I
was
hoping
that
we
could
get
consensus
on
exactly
how
we're
going
to
disable
it
now.
G
Basically,
the
two
options
are
disabled,
with
the
validation
rule
or
disable
with
a
field.
Error,
validation,
rule
is
pretty
clean,
but
that
basically
means
that
you
can't
have
any
defer
or
stream
directive
in
the
subscription
query
at
all.
I
brought
up.
That
could
be
a
problem
if
you
want
to
share
your
fragments
between
a
query
and
a
subscription
or
a
mutation
and
a
subscription,
so
the
other
option
would
be
disable
via
a
field
error
which
would
happen
during
execution.
G
G
I
I
was
in
favor
of
moving
forward
with
option
two,
even
in
my
code
base
we
use
relay
and
where
components
are
coupled
with
fragments
and
they're
shared
in
a
lot
of
places,
and
even
our
use
of
subscriptions
isn't
really
about
like
rapid
fire.
G
Small
changes
but
kind
of
like
someone
made
an
update
to
like
a
pretty
large
document
and
we'll
get
that
update
back
in
so
I
could
very
easily
see
us
running
into
the
situation,
and
I
would
imagine
that
other
people
do
as
well
so
so,
yeah
and
and
I
think
that
it
would
just
be
a
shame
not
to
take
advantage
of
defer,
because
this
fragment
also
happens
to
be
used
in
a
subscription.
It's
not
easy
to
refactor.
If
this
fragment
is
like
many
fragments,
deep
and.
G
Yeah
and
Matt
brought
up
that
a
compiler
could
remove
it.
If
you're
using
relay
relay
compiler
could
do
that,
but
a
lot
of
a
lot
of
clients
don't
have
compilers,
so
it
wouldn't
always
be.
You
wouldn't
always
have
that
option.
G
So
I
I
would
like
to
move
forward
with
the
field
error
approach,
but
is
it
so?
Is
there
any
dissent
against
that.
E
I
I
can
chime
in
for
Apollo.
We
agree
with
that
approach.
Most
of
those
thumbs.
Ups
are
folks
that
are
working
on
both
the
web
and
mobile
client
at
Apollo.
So
we
agree
with
it.
H
H
But
that's
like
that's
just
because
I
for
people
that
use
compilers
having
the
error
come
earlier
is
better,
but
that's
super
easy
to
add
on
that's
like
not.
That
should
not
block
this
at
all.
A
Yeah,
like
I'm,
also
always
but
just
for
like
protocol
just
for
to
mention
like
as
a
potential
problem,
one
big
down
one,
not
big
like
one
downside,
is
that,
like
potentially
you
need
to
test
like
during
development
cycle
application,
you
need
to
to
ensure
that
all
the
flux
you
test
all
combination
of
all
Flags,
to
be
sure
that
you
not
have
a
runtime
error
when
somebody
do
something
like
I,
don't
think
a
lot
of
queries
have
Flags
based
on
user
data,
but
if
somebody
have
like
a
fox
set
up
by
user
data
for
some
reason
like
tomato
includes
I,
think,
and
they
have
like
a
bad
testing
procedure,
that
they
can
run
into
situations
when
they
deploy
something
and
they
will
have
a
unexpected
errors.
G
A
Yeah,
and
especially
like
you,
you,
like
your
your
Fox,
based
on
which
like
skip
include
Works,
is
based
on
like
user
data,
for
example
like
based
on
some
stuff,
that
user
like
choose
in
a
form
for
example,
or
like
based
on
type
of
user,
or
something
so
because
of
where
to
exactly
Fields
executed
and
not
executed
a
different
situation,
and
we
you
did
it
without
like
fully
covering
oh,
like
possible
permutations
and
one
of
permutation
is
triggering
default
stream
in
in
subscription
yeah.
A
H
Yeah
on,
if
we
had
fragment
arguments
we
could
like,
we
could
make
it
that
the
validation
is
even
now.
We
could
make
it
that
you
must
have
a
variable
defined
on
your
subscription
that
defaults
to
false,
and
if
we
had
fragment
arguments
we
could
be,
you
have
to
that.
C
So
I
think
we
can
definitely
add
a
validation
rule
that
makes
sure
that
any
defer
or
stream
that
is
used
has
an,
if
condition
and
that
that,
if
condition
is
either
the
constant
false
in
which
case,
why
have
you
added
it
or
is
a
variable
right?
C
That
should
be
fine
for
this,
then
we've
only
got
the
situation
where
someone
passes
that
variable,
but
sets
it
true
and
I.
Think
at
that
point.
That
is
something
that
the
user
is
probably
triggering
for
themselves.
I
think
most
users,
when
they
use
defer
and
stream,
aren't
going
to
add
conditional
arguments.
That
would
be
my
my
guess.
C
So
if
we
have
the
validation
rules
that
forbids
those
from
being
used
in
subscriptions,
the
fact
that
it
has
an
argument,
I
think
is
going
to
convey
a
lot
of
intent
to
the
developer,
that
this
should
be
something
that
is
turned
off
in
some
situations,
probably
subscriptions,
probably
because
of
what
they've
named
the
variable,
let's
hope,
but
yeah
I,
think
I,
think
a
validation,
Rule
and
the
option
to
field
error
work
well
together.
D
Yeah
I
I,
like
that
compromise,
that
that
would
be
great
because
then
you
also
educate
the
users
with
the
error
message
with
the
validation,
error,
message
and
yeah.
That
would
I
think
that
is
really
the
way
forward.
G
H
B
E
Awesome,
so
do
we
so
what's
next
for
the
first
stream,
then
Yakov
I
know
I
know
you
had
some
discussions
that
we
tried
to
get
some
time
to
talk
about
in
past
meetings
and
I.
Don't
know
if
we
ever
work
through
them
fully,
but
are
those
still
things
that
are
outstanding
before
we
start
to
talk
about
moving
to
First
stream
further
ahead
in
the
stages.
F
So
I
think
I
think
what
you
must
be
referring
to
is
my
suggestion
to
you
that
we
use
aliased,
yes,
that
we
demand
Alias,
fragments
and
that
basically,
but
I
want
to
take
a
step
back
from
that
exact
suggestion.
That
was
basically
to
solve
a
problem.
F
If
I'm,
remembering
back
that
Yvonne
raised
about
how
we
can
how
we
can
ensure
that
that
the
client
knows
that
when
we
are
quote
unquote,
not
honoring
the
first
stream
meaning
when
we,
when
the
server
has
determined
that
it's
more
efficient
to
just
send
all
the
data,
how
we
can
signal
to
the
client
that
the
data
has
been
sent
in
in
an
initial
payload.
So
that's
a
problem
that
we're
trying
to
solve,
and
so
that's
kind
of,
I
guess
the
outstanding
problem.
F
Where,
with
with
my
with
that
suggestion
being
one
one
approach
to
solving
it,
but
but
I
think
that's
basically
the
outstanding
problem.
One
option
is
to
ship
it,
as
is
so,
you
know
and
and
solve
it
later.
You
know
just
check
it,
but
you
know
I'm
I'm
gonna
be
a
the
thought
that
it
you
know
we
can.
You
know
we
waited
this
long,
we
might
wanna.
We
wanna
make
sure
that
we've
thought
thought
that
went
through.
F
F
You
know
this
initial
rollout
I
mean
that
could
just
be
a
different
approach,
especially
because
it
comes
with
its
own
trade-offs
in
terms
of
managing
status
to
which
which
Fields
have
already
been
sent.
So
that's
another
thing
that
I
have
been
working
on
and
there's
been,
you
know
very
little
movement,
but
some
in
terms
of
a
proposal
to
get
that
forward,
but
I
don't
think
that's
going
to
hold
up
but
I.
If
the
Avon's
issue
is,
is
what
I
think?
E
He's
is
the
issue.
Yvonne
Ivan
is
irishu
Broken
Out
In.
The
discussions
board.
I
didn't
see
that
one
there.
A
Yeah
I
think
I
created
I
can
quickly
refresh
like
the
whole
purpose
of
defer,
is
to
is
to
avoid
incremental
and
then
at
least
like
most
people
like
have
this
use
case
they
wanted
to
to
like
partially
render
something,
and
when
you
partially
around
this
one
yeah
yeah,
you
need
to
know
if
it's,
if
it's,
if,
if
you
got
it
or
not,
and
and
like
it's
stupid
to
have
like
his
opinion,
spinner
or
like
some,
oh
I-
can
render
it
stuff
until,
even
though
it's
like
shipped
but
have
something
spinning
until
you
get
the
right
cost.
A
Last
white
package
so
and
I
basically
show
like
Edge
case.
My
main
idea
is
not
only
about
education
edge
cases
like
heart
problem
like
it's
like
I,
can
prove
it's
a
problem
in
current
approach,
but
there
is
like
another
most
other
issues
that,
if
stuff
is
unwind
client
need
to
do
like
more
work.
It's
need
to
pass.
A
query
understand
like
where
stream
and
G4
is
placed
and
understand
that
something
is
in
line
like
in
most
clients.
A
I
I
never
used
three
way,
but
I
expect
you
get
some
like
callback
or
something
when
before
when
differs
like
shift
when
you
get
different
or
default
part
from
a
server,
something
that
gets
code
and
in
current
approach
when
we
allowed
to
unwind
stuff,
it's
mean
like
quite
need
to
constantly
check
like
responses
and
wait
at
least
like
first
response
and
see
or
if
sub
gets
annoying
or
not,
which
is
quite
especially
for
for
dynamic
clients,
one
that,
like
don't,
have
compilation
except
it's
hard.
They
need
to
like
parse
query.
A
B
H
Sure
in
interesting
thing
here
that
kind
of
it
brings
up
is
like
we
could
so
as
Michael
stud
was
pointing
out
like
what
he's
doing
is
basically
adding
these
fulfilled,
defer
labels,
and,
if
that,
that's
what
we
do
in
relay.
That's
what
we
do
like
my
client
that
isn't
relay
does
as
well.
The
that
seems
like
if
we're,
if,
basically
every
smart
client
is
going
to
end
up
putting
those
anyways.
H
It
might
just
make
sense
to
essentially
have
that
label
be
itself
a
fragment,
alias
in
which
case
and
like
the
things
that
that
would
produce.
It
probably
should
just
produce
a
key,
but
not
necessarily
like
a
key
and
a
triple
or
something
that
isn't
necessarily
the
type
name
or
the.
But
just
like
key
and
oh
this
fulfill
like
the
server
is
deferring
or
the
server
has
already
completed,
or
the
server
like
basically
provide
a
hook
of
some
form
to
say.
G
H
Yeah
yeah
yeah,
so
we
we
are
experimenting
with
having
something
like
that.
It
makes
some
things
clean,
but
I,
don't
I,
don't
love
it
as
a
like
solution
for
different
stream.
Just
because
it's
like
we
would
would
basically
need
the
server
to
know
that
a
fragment
Alias
or
an
at
defer
with
label
or
whatever
means
that
it
must
push
in
that
key.
H
So
that's
fine-ish,
but
really
I
think
that
we
need
some
way.
Yeah.
The
as
yaakov
just
put
the
reference
proposal
like
we.
The
reference
proposal,
I
think,
is
a
little
bit
cleaner.
Where
we
like
can
say
hey
this
spread.
Give
me
tell
me
what
the
reference
is
either
it's
here,
it's
going
to
be
in
some
deferred
payload
with
some
label
or
it
like.
Never
even
it's
never
going
to
be
fulfilled,
so
it's
null
or
unsaid,
or
something
like
that.
C
I
think
we've
got
another
slight
problem
as
well
right,
so
there
is
knowing
whether
or
not
a
fragment
is
complete,
but
there's
also
knowing
whether
or
not
a
list
has
been
completed
so
in
say,
like
a
Facebook
feed,
you
might
have
a
bunch
of
posts
and
then
comments
on
each
of
those.
If
you're
pulling
down
a
stream
of
comments
under
each
of
them,
once
one's
pulled
down
all
three,
we
need
to
know
that
that,
like
substream,
is
complete,
even
though
all
the
other
ones
may
still
be
streaming.
C
G
G
It
was
like
we,
we
did
I
remember
the
last
discussion
we
talked
about
like
has
next
and
has
next
refers
to
the
entire
graphql
stream
of
requests,
and
there
was
like,
should
it
all
in
I
think
that
we
decided
that
we
wouldn't
want
to
reuse.
That
name
has
next
to
also
indicate
that
this,
like
specific
stream,
was
done,
and
we
would
put
another
the
way
to
solve.
This
is
to
have
another
field
somewhere.
There
stream
has
next
or
something,
but
in
the
previous
discussions
it
it
was.
B
A
Understand,
like
people
want
to
get
stuff,
and
wine
and
data,
but
yeah,
like
I,
have
simple
proposal
requiring
everything
incremental,
but
the
issues
of
people
Rises
like
about
education
and
not
like
during
and
doing
like,
can
we
have
like
efficient
just
to
stop
somebody
to
think
and
I
will
try
to
think
myself
about
it.
Maybe
we
should
have
like
a
mechanism
signaling
with
set
of
the
first
finished
explicitly
not
inside
the
data
but
somewhere
and
same
way.
A
A
A
E
So
Rob,
would
you
mind
jumping
back
to
just
the
full
list
of
discussions
for
a
second,
so
is
that
that's
the
one
main
one
that's
here
that
we
think
has
that
has
to
be
resolved.
E
G
G
E
So
I
I
guess
I
mean
you're
going
to
add
some
more
content
into
the
one
main
discussion
and
we'll
have
some
more
discussion
there
and
we'll
figure
out
how
we
want
to
handle
that.
But
then,
what's
next
for
the
first
stream.
E
Do
we
like
Yakov,
do
you
think
the
the
extra
things
that
you
had
added
in
here
need
to
be
considered
before
we
start
trying
to
push
to
get
to
First
stream,
push
further
ahead
in
the
stages
or
do.
F
F
I
I
think
this
inlining
I
mean
I'm,
not
sure
how
other
people
feel
about
it.
I
think
the
inlining
discussion,
meaning
like
how
does
a
client
know
what
to
expect
I
I
think
we
we
may
have
to
Tool
around
with
solutions
to
that,
but
you
know
I'm
sure
we
can
find
it.
You
know
we
can
find
a
solution
that
works,
that
we
can
sort
of
add
on
later.
I'm,
not
sure
you
know,
I'm,
not
sure
you
know,
but
you
know
there
are
guest
pros
and
cons
to
to
waiting
and
I.
H
So
I
I'm
I,
know
Lee
probably
has
strong
thoughts
on
this,
but
yeah
I'm
of
the
opinion,
if
we
are
like
deferring
stream,
would
be
way
better
if
we
had
these
like
inline
labels
in
the
data
itself,
and
that's
just
like,
we
have
a
very
strong
opinion
on
that.
I
think
it
might
be
worth
basically
rushing
some
form
of
inline,
fragment,
Alias
or
like
fragment
key
I,
don't
want
to
say,
like
the
fragment
Alias
thing.
H
That
means
that
the
fragment
like
result
is
all
a
like
separate,
a
completely
separate
thing,
although
with
deferring
stream,
it
kind
of
ends
up
that
anyways
so
but
having
some
form
of
like
we
can
know
in
line
whether
this
fragment
actually
happened.
H
B
F
I
mean
I
think
going
back
to
some
of
the
things
in
the
comments
just
to
make
sure
they're
in
the
the
live
stream.
I
think
Benji's
point
from
earlier.
F
You
know
we
do
have
a
problem
with
about
stream,
also
being
an
issue
that
possibly
all
the
results
might
be
in
lines
or
might
not
into
an
original
response,
and
references
or
or
you
know,
is
fulfilled
type
or
even
fragment
real
fragment
aliases
wouldn't
wouldn't
solve
that.
I
guess
my
initial,
my
initial
thinking
about
it
I
think
that's
a
good
point.
So
I'm
not
sure
if
we
need
to
have
the
exact
same
solution
for
that,
but
we
I
think
we
do
need
to
keep
that
in
in
mind.
H
Yeah
there
might
be,
there
might
be
a
way
to
have
the
aliasing,
the
like
Alias
rapper
thing
that
we
do
apply
to
fields
to,
in
which
case
it
might
also
be
able
to
apply
to
stream.
But
I,
don't
know.
F
I
mean
I
I
would
definitely
be
interested
in,
like
you
said,
iterating
and
I,
like
you
know,
rapid
Pace
sounds
sounds
really
exciting.
Actually,.
A
So,
just
to
qualify
a
problem
with
stream.
It's
a
question:
if,
if
like
I
put
an
initial
count
of
10,
there
is
like
100,
but
server
decided
that
it
can
ship
like
100
immediately
and
it's
in.
Why
not
10
but
100-
and
this
is
like
a
question
right-
is
the
stream
is
like
finished
by
unwinding
like
the
whole
array.
Instead
of
an
inviting
like
a
small
area
right
with
yeah.
C
H
And,
and
specifically,
if
you
have
any
other
like,
if
you
have,
if
the
only
thing
in
your
request
is
that
one
stream,
then
you
can
differentiate
it
with
the
has
next,
but
it
has
next
in
the
initial
payload
right,
but
if
there's
any
other
defer
or
stream
anywhere
else,
you
don't
know.
Okay,
so
you
have
has
next
true.
Does
that
apply
to
the
stream?
Does
this
apply
to
some
other
defer?
Does
this
like
yeah?
You
just
can't
do
anything
like
you.
A
Basically,
if
I
have
front
page
and
I
have
like
a
news
feed
and
like
messages
so
like
and
both
are
streams,
it's
mean
like,
even
though
that
I
got
like
no
new
messages,
but
until
like
I
get
the
whole
news.
Feed,
like
my
messages,
will
show
like
a
spinner
I,
also
think
it's
pretty
critical
in
the
same
idea.
It's
like.
A
Basically,
it's
create
a
corner
case
for
for
a
problem
that
stream
is
trying
to
solve
and
I
I
expect
like
QA
Engineers,
like
or
after
my
so
I
expect,
like
people
testing
this
corner
case
and
come
up
like
is,
is
there
like
doing
full
coverage
of
the
product?
They
come
up
with
test
case
and
every
company
is
that
you
use
like
stream
having
discussion
what
to
do
and
eventually
deciding
is
probably
not
what
the
big
issue,
but
like
Western
ton
of
time
for
every
company
to
figure
out.
H
Yeah
I
I
agree
yeah,
we
I
I,
think
we
probably
have
already
considered
this,
but
it
now
that
we
have
the
incremental
key.
It
might
be
the
case
that
we
should
really
just
for
stream
and
maybe
even
defer
we
should
have
which
ones
have
been
fulfilled
in
the
initial
payloads
incremental
and
yeah.
It
looks
like
yeah
yeah
exactly
exactly
like
what
yaakov
has
on
the
chat
where
it's.
A
Yeah
and
that
just
now
benefits
it
provides
it's
a
war
like
dumb
clients
without
so
I.
Imagine
you
have
a
dumb
coin
that
don't
pass
a
query.
It
will
always
want
to
understand
like
what
it's
waiting
for.
Basically,
so,
if
I
didn't
look
into
Oracle
or
some
other
simple
quants
but
expect
Oracle
probably
is
not
parsing
query
so,
and
somebody
tried
to
build
callback
to
like
go
back
to
a
label
saying
like
one
was
labels
for
Phil.
A
A
To
understand,
because
if
one
just
have
a
label
send
greases
for
field,
it's
you
need
to
pass
acquire
to
understand,
what's
fulfilled,
but
here
is
why
you
pop
so
I
think
it's
ideal
solution
in
a
sense
except
one
point
that
bench
arise
about
like
explosion,
about
like
creating
too
many
like
entries
inside
the
incremental,
but
I
think
it's
it's
like.
Then
our
service
prevention
should
be
done
awake
by,
like
validation,
validation,
limit,
saying
you
don't.
You
should
not
have
more
than
like
a
bad
number
of.
B
H
That's
so
this
was
something
Michael
stay
brought
up,
which
was
that's
really
hard,
because
if
you
as
soon
as
you
have
nested
streams,
you
can
end
up
having
just
an
explosion
of
incremental
responses.
H
But
that's
that's
hard.
I,
don't
know
like.
C
C
Potential
solution
to
that-
and
that
is
just
don't
allow
nesting
them
not
as
in
a
validation
rule
just
in
terms
of
only
allowing
one
level
of
defer
or
or
only
require
one
level
of
it
and
then
have
the
server
just
ignore
anything
beyond
that
in
the
default
implementation.
H
I
mean
we
could
also
make
it
very
clear
that
servers
are
allowed
to
just
like
Drop
Like,
You,
Can
Have,
a
stream,
and
the
server
can
give
you
an
error
of
like
hey.
I
was
able
to
give
you
three
elements
in
the
Stream
and
I.
Can't
I
can't
keep
going,
which
kind
of
solves
that
too.
It
is
really.
It
would
be
like
really
annoying
from
a
client
perspective
on
how
to
handle
that,
but
like
at
least
from
the
server,
and
you
could.
B
G
Yeah
I
mean
we
do
have
that
in
this
fact
that
the
server
should
do
it
and
there's
a
note
about
Advanced
use
cases
you're
allowed
to
ignore
it,
which
is
kind
of
what
brings
up
the
whole
discussion
that
Ivan
brought
up
about
distinguishing
weather
was
actually
deferred
or
not,
but
but
I
think
it
does
rule
out.
The
proposed
fix
that
original
proposed
fix
of
either
you
have
to
defer
everything
or
not
def.
You
have
to
defer
and
stream
everything
or
not
and
the
allowing
the
top
level
one,
but
not
the
nesting.
H
The
other
thing
with
the
I
noticiakov
was
really
so
much
like
the
other
thing.
With
the
incremental
metadata
is
you
only
have
to
put
what
has
not
completed,
which
is
kind
of
nice
also,
because,
presumably
there
should
be
less
things
cued
up
to
batch
in
a
general
sense,
so,
like
the
amount
of
items
in
incremental,
should
tend
towards
being
pretty
small.
H
But
but
you
are
allowed
to
send
some
like.
Basically,
if
a
server
has
the
data
ready
for
the
initial
payload,
it's
allowed
to
not
even
include
that
in
the
incremental
piece,
and
the
client
knows
that
it
like
yeah
I,
am
at
streaming
this,
but
because
it's
not
under
the
incremental
at
all.
That
means
that
it
is
like
it's
done.
I
don't
need
to
worry
about
it
anymore.
B
A
Can
you
like
post
it
in
in
threat
yeah,
so
we
will
have
other
people
commenting
the
solution.
A
C
Excellent
I
have
to
say
one
of
my
main
concerns
about
stream
interfere
is
still
this
potential
explosion
of
the
payloads.
We
already
have
enough
people
that
say
you
know.
Graphql
is
dangerous
because
of
this,
that
and
the
other
and
we're
effectively
giving
them
another
crank
to
turn
to
explode
things
further.
C
So
this
this
could
be
a
potential
security
issue.
Denial
of
service
issue.
C
That
kind
of
thing
so
going
into
this
with
eyes,
open
I
think
is,
is
critical
when
not
rushing
it
out
before
then
I
I,
wonder
if
we
can
put
wording
in
the
spec
where
the
server
should
defer
or
stream
the
first
layer
and
should
not,
or
it
is
recommended
that
you
don't
stream
or
defer
any
further
levels
you
still
may
you
can,
but
for
if
we
put
a
note
next
to
it
as
we
should,
whenever
there's
a
should
or
should
not,
we
can
put
a
note
that
says
this
could
lead
to
much
larger
payloads.
C
So
we
recommend,
against
it
kind
of
thing.
I
think
that
for
the
majority
of
use,
cases
and
I
may
be
wrong
on
this,
but
I
feel
that
the
majority
of
use
cases
you
want
something
that
renders
now
and
then
stuff
that
comes
along
later
and
I.
Don't
think
you're
really
worried
about
the
nested
later
for
within
those
and
later
for
within
those
there's,
certainly
like
widget
Pages,
where
it
might
be
useful
for
but
I
think
for
the
majority
of
use
cases
we
don't
care
so
much
about
it.
That's
my
personal
belief.
H
Think
that
that's
true
for
defer
and
stream
as
they
exist
today
like
today,
defer
and
stream-
are
not
like
how
do
I
reduce
the
cost
to
my
server,
but
instead,
how
do
I
push
the
cost
of
getting
an
interaction
up
quickly
to
my
server
and
there's
another
world
where
the
question
is,
how
do
I
on
the
client
explain
to
the
server?
What's
okay
to
leave
out
and
I
can
get
later
in
that
in
that
world?
H
You
actually
do
want
the
server
to
not
give
you
the
nested
stuff,
so
that
only
when
you
actually
like
reach
that
point
in
the
tree
on
the
client.
Do
you
actually
start
like
telling
the
server
hey
I
hit
the
fourth
element
in
the
list?
Now
you
need
to
give
me
the
information
in
it
within
that
list.
I
hit
the
fourth
element
in
the
nested
list,
so
get
me
that
one
like,
but
but
with
different
streams
they
exist
today.
That's
not
they're,
not
yet
a
tool
that
you
could
really
use
for
that.
C
Correct
so
in
a
in
a
database
we
have
things
like
cursors
right,
which
kind
of
do
this
same
thing.
You
you
ask
for
a
certain
number
and
then
you
get
a
cursor
that
you
can
continue
to
to
pull
from
later.
This
is
more
complex
because
it's
multi-dimensional
but
yeah.
E
Just
a
quick
question
about
defer
and
stream
support
and
graphql.js
right
now.
The
graphql
JS
readme
is
pointing
people
to
the
experimental
Dash
stream.
Dash
defer
mpm
tag,
that's
pointing
to
a
16.x
version
of
graphql.js.
Is
that
accurate,
still
I.
G
F
One
point
back
on
the
explosion
of
payloads:
at
some
point
we
may
be
able
to
right
now
whenever
you
use
stream
updates
will
be
pushed
one
at
a
time,
but
we
we
do
have
the
ability.
Now
that
we're
you
know,
pushing
those
single
updates
inside
an
array.
We
do
have
the
ability
to
batch
them,
and
so
then,
if
you
have
like
defer
nested
under
that
stream,
presumably
you
would
have
the
ability
to
to
batch
those
mean
the
client
could
specify
that
they
want
their.
F
You
know
an
impotential
future
argument
that
they
want.
You
know
the
first
initial
10
items
and
then
they
want
every
next
set
of
ten
items
as
as
they're
ready,
and
so
then,
if
you
have
a
set
of
deferred
fields
on
those,
you
know
they
would
presumably
meaning
a
nested
defer
under
that
stream.
Presumably
those
nested
Fields
would
only
come
in.
We
would
retain
that
same,
you
know
grouping,
and
so
they
would
also
be
sent
10
at
a
time
and
so
that
could
significantly
reduce
payload
explosion.
F
Once
that
you
know,
you
know,
you
know
feature
if
it
passes
muster
is
is
added.
C
I
think,
if
you
think,
with
the
the
black
hat
on
as
it
were,
you
know
the
head
of
the
attacker.
Even
in
that
situation,
it
would
be
very
easy
to
have
those,
even
though
you're
you're
batching
the
execution
of
those
things.
If
we
still
require
that
the
payload
for
each
of
the
Deferred
chunks
comes
out
in
a
particular
format,
you
are
requiring
that
the
same
content
is
repeated
over
and
over
again
in
the
same
payload.
Even
if
it
only
differs
each
one
only
differs
by
one
field.
C
It
can
still
have
a
very
large,
then
sub
selection,
where
it
maybe
pulls
in
another
fragment
so
I
think
as
an
attacker.
You
could
make
the
server
do
a
lot
of
work
this
way
and
it's
it's
partly
because
we
re
we
don't
do
the
field
merging.
We
don't
say
all
of
this
is
just
going
to
come.
Late.
I
mean
if
we
just
saw
this
as
a
patch
system,
and
we
didn't
have
labels,
and
we
didn't
say
that
this
was
kind
of
consistent.
We
just
sort
of
said
anything.
C
You
defer
we're
going
to
send
you
a
patch
with
those
fields
in
later.
Anything
that
you
know
has
already
been
served,
will
just
give
it
to
you.
Then
the
amount
of
data
being
transferred
would
be
much
less,
but
that's
not
what
we're
doing,
and
that
does
lead
to
this
ballooning
problem.
B
F
Well,
I
mean
I,
mean
I,
think
I'm.
Maybe
we
should
talk
about
it
offline
because
I
think
I'm
missing.
Let's
say
let's
say:
there's
a
thousand
member
list
and
you
know,
and
the
client
has
a
validation
rule
that
they
want
to
be
strict.
So
they
only
ask
for
an
initial
set
of
500
and
then
they
can
ask
the
second
set
be
sent
in
you
know
also
with
a
size
of
500.
F
If
they
want
I
mean
so
the
client,
so
you
could
set
up
whatever
validation
rule
you
want
or
whatever
complexity
rule
you
want
to.
You
know,
reject
you
know
anything
that
the
server
feels
is
you.
F
Know
potentially
abusive,
so
that
that's
what
I
mean
I
mean
if
we
think
about
the
most
strict
form
of
of
stream.
You
know
you
could
even
say
that
you
just
want
the
data
in
terms
of
two.
You
know
very
large,
payloads
I
mean
so,
but
but
we
could
talk
about
it.
Offline
and
I
might
gain
a
better
understanding.
C
F
Oh
man,
I
guess
what
I'm
saying
is
those
nested
defers?
You
know
we
could
also
retain
that
same
level
of
grouping
and
that
same
level
of
batching.
You
know
with
that
feature.
Yeah
I
mean
again.
This
is
all
in
advance.
You
know
we
don't
have
such
a
feature
now.
So
I
see
your
point
very
well
for
the
current
state.
C
Wonderful
discussion
we're
about
an
hour
in
so
if
we
want
to
keep
it
going,
we
can,
but
otherwise
I
suggest
that
we
draw
the
meeting
to
a
close.
H
A
Yeah
one
small
thing
before
we
finish
and
do
we
have
like
a
separate
discussion
about
all
the
whole
denial
of
service
thing
with
like
response
explosion,
because,
like
it's
discussed
in
context
of
like
things
that
can
potentially
make
it
worse
like
like
the
discussion
thread
that
I
started,
can
make
it
worse.
But
it's
not
the
way.
A
It's
not
like
the
root
cause
for
for
this
problem.
So
it's
problem
on
its
own,
but
we
discussed
it
in
only
in
context
of
like
stuff
that,
like
totally
another
solution
that
now
we
have
like
Jacob
proposed
solutions.
That
is
not
make
it
worse.
So
it's
like
now,
it's
like
car
talk
and
our
discussion
so
like
to
continue
it
offline.
Maybe,
since
Benji
you
you're
proposing
it
like
how
separate
discussion-
or
you
already
started,
one
right,
okay,
so.
C
Yeah
I,
don't
think
I've
laid
it
out
quite
as
strongly
as
a
security
thing
is
how
I
feel
about
it
and
maybe
putting
some
stronger
wording
in
there
or
opening
a
a
specific
discussion
with
regard
to
security
would
be
wise,
but
yeah.
There
is
that
that
original
discussion.
F
I
guess
we
do.
We
do
have
an
action
item
on
on
sort
of
iterating.
You
know
quickly
on
that
suggestion,
but
that
Matt
suggested
I.
Guess
we
should
you
know
we
could
do
that
offline,
but
we
should
remember.
We
should
remember
to
like
arrange
that
follow-up.
H
Yep,
oh
and
for
people
not
in
the
US
next
week
is
a
three-day
week
for
most
of
us,
so
yeah.
We
should
get
that
in
so
that
we
can
probably
buy
early
December
have
something
like
figured
out.
E
C
Matt
I've
described
it
terribly
in
the
notes.
So
if
you
could
polish
that
up
for
me,
that
would
be
great.
Thank
you
awesome.
Thank
you.
Everyone.