►
From YouTube: GraphQL Working Group (Secondary, EU) - 2022-10-20
Description
Starts around 21 minutes in.
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
D
A
Benji,
you
are
a
Graphica
Foundation
today.
Wait
what.
B
E
Oh
guys,
yeah,
that
is,
that,
is
something.
A
A
I
but
because
I
was
now
three
weeks
in
Sydney
because
of
conference
there
and
I
have
to
really
get
adjusted
to
the
to
our
time
zone,
so
I'm
fighting
to
at
least
stay
up
until
10
tonight,
and
that's
why
the
work
group
meeting
is
excellent
because
it
keeps
me
from
falling
asleep.
A
And
some
differ
stuff
so
sounds
interesting
by
the
way
we
had
last
I.
Think
last
week
we
had
the
first
Australian
work
group
meeting,
which
was
quite
nice.
A
F
A
A
G
G
I
was
was
hectic,
it
was.
It
was
good,
though,
a
lot
of
fun,
absolutely
yeah.
G
Was
very
surprised
that
yeah
given
kovid
that
so
many
people
are
just
like
yep
Tech
conference,
let's
go
but
yeah,
it
was
a
really
really
good
turnout,
absolutely
just
incredible
yeah!
No,
it
was
fun
for
sure.
A
B
A
E
I
I
wasn't
expecting
to
oh
okay,
surprise.
G
G
I
heard
good
things
about
your
host.
You
hosted
a
couple
weeks
ago,
I
wasn't
on
but
seems
like
it
went
really
well.
Oh.
E
That's
good
I
was
not
very
well
that
day.
Oh.
G
E
I
think
Lee
is
coming.
He
pushed
the
meeting
back
to
this
time
about
eight
hours
ago.
So
I
guess
his
previous
commitment
might
be
running
a
little
late.
Yep
makes
sense.
E
I'm
at
least
merging
a
few
of
the
pull
requests.
G
A
little
activity
really
well
yeah.
So
far,
so
great
people
love
it
just
love
the
functionality
being
able
to
use
deferries.
As
we
all
know,
we've
all
been
talking
about
it
for
a
while.
So
it's
really
exciting
to
just
get
more
of
it
out
there,
so
people
are
really
liking.
It
so
far,.
A
Did
did
you
guys
know
because
I
I
looked
two
weeks
back,
he
was
still
using
the
old
payload
structure.
Have
you
have
you
changed
that
now.
H
You
looked
two
weeks
ago,
we,
what
do
you
mean
by
old?
We
put
a
big
effort,
a
couple
like
a
month
or
two
ago
into
yeah.
A
Like
when
I
looked
at
the
Apollo
studio,
for
instance,
it
it
was
explicitly
sending
the
header
for
the
August
commits.
H
H
Which
would
be
super
interesting
to
know
yeah
I,
I
didn't
think
anything
had
changed
since
what
we
implemented
in
August,
because.
H
That's
not
please
reach
out
to
me,
for
example,
or
to
you
or
that's
appropriate,
but
yeah
that
yeah
I
mean
basically
a
few
months
ago.
Over
the
summer,
like
some
of
us
noticed
like
oh
there's,
all
this
new
stuff,
we
should
make
sure
we
do
it
and
we
made
sure
all
the
teams
got
together
and
upgraded
to
doing
that
and.
H
Actually
emerged
yet
it
might
change
more
or
less
like
just
like
write
down
the
current
date
and
have
that
be
the
thing
and
it
hopefully
won't
change
too
much
more.
Our
goal
is,
you
know,
not
be
embracing
and
extending
the
format.
Our
goal
is
to
you
know,
hopefully
that
we
can
get
the
the
into
the
spec
as
soon
as
possible
and
if
there's
any
changes,
we'll
update
it.
It's.
G
E
In
fact,
let's,
let's
kick
it
up
if
you're
all
happy
I'll
I'll
take
over
hosting
until
Lee
arrives,
awesome,
hello!
Everyone
welcome
I,
think
we
all
know
each
other
anyway,
but
by
joining
this
meeting,
as
you
know,
you've
agreed
to
the
specification
membership
agreement,
the
participation
guidelines,
the
contribution
guide
and
the
code
of
conduct,
we'll
just
go
through
a
quick
round
of
introductions.
Hi
everyone,
I'm
Benji.
Let's
do
it
in
a
gender
order.
Please
so
next
would
be
yaakov
who
is
coming
back
in
25
minutes.
E
A
Hi
I'm
macca
I'm,
one
of
the
chili
cream
team
and
we
are
mainly
working
on
the.net
graphql
server,
hot
chocolate.
G
Awesome
Hugh
from
Apollo
working
on
various
things
like
our
open
source
projects.
G
F
Still
here
right
here
me:
yeah
I'm,
Alex
I'm
at
prano,
AI
I'm,
talking
about
client
control,
nullability.
H
I'm
David
also
at
Apollo
I
work
primarily
in
Apollo
server.
I've
been
also
sort
of
like
the
liaison,
along
with
Ivan,
between
making
sure
that,
like
the
various
teams
at
Apollo
that
are
doing
the
first
stuff
know
what's
going
on
in
Spec
world
and
vice
versa.
B
B
H
J
Exciting
and
and
I'm
Stephen
at
Netflix
I,
just
added
my
name
to
the
agenda
and
I
added
a
quick
agenda
topic.
If
there's
time
in
the
end.
G
Awesome
Derek's
here
now:
Derek
we're
doing
intros
and
we
just
skipped
your
name.
C
Glad
I
pinged
y'all,
we
we
were
in,
we
have
two
zooms
set
up.
This
is
oh
nice.
We
were
yeah,
Derek,
Mark
and
I
were
sitting
in
the
other
Zoom
being
like.
B
F
G
G
It's
very
efficient.
We
just
handled
things
in
parallel,
so
great.
C
Are
we
all
caught
up
on
that
yep
I
think
so?
Okay,
sweets.
Thank
you
guys
for
taking
the
lead.
I
think
the
plan
was
to
reuse
the
notes
dock
that
we
had
used
from
the
previous
meeting.
Rather
than
create
new
ones.
We'll
have
a
note
stock
per
month.
C
I
can
get
that
back
added
to
the
agenda
file,
but
one
sec
I'll
drop
a
link
in
the
chat,
so
everybody's
got
it
we're
Zoom
chat.
There
we
go
foreign.
C
C
We've
got
three
things
on
the
docket
for
today.
Is
that
right,
or
only
two
things,
two
things
on
the
docket
for
today:
I,
don't
think
we
need
to
go
over
action
items
I
think
we
can
probably
do
that
in
the
primary
meeting,
unless
there's
something
specific
that
is
up
and
ready,
which
I
don't
think
that
there
is
I
looked
earlier,
there's
still
not
okay,
for
the
sake
of
time,
we'll
jump
straight
into
things.
C
Which
is
Yakov,
I
think
the
first
one
is
Yakov
here
yet.
E
Yeah
is
gonna
have
to
rejoin
about
half
past
so
20
minutes
time.
C
Mark
we'll
start
with
you,
then,
when
Jacob
joins
we
can
get
to
him.
I
Cool
okay,
so
this
was
like
very
last
minutes
addition
to
this
agenda.
I
we've
been
thinking
about
stuff
and
then
I
was
messaging.
Benji
and
I
was
like.
Oh
there's
like
this
proposal,
we
have
the
meeting
today
you
should
join
Okay,
so
the
topic
is
server
driven
UI,
which
is
I'm
assuming
most
people.
I
Everyone
here
is
sort
of
Vaguely
Familiar
with
what
that
is
so
I'm
not
going
to
cover
that
and
then
there's
various
companies,
Yelp
included,
who
have
tried
to
encode
a
server
driven,
UI
response
for
a
page
in
graphic
ul
and
there's.
Obviously
you
know
lots
of
people
who
have
lots
of
opinions
about
this
and
there's
different
levels
of
abstraction
that
you
can
do
this
at
to
be
honest
at
any
level
of
abstraction.
I
If
you
do
it
sort
of
at
enough
scale,
if
you
try
to
do
a
whole
page,
we
kind
of
run
into
challenges
which
is
kind
of
what
we're
facing
internally.
At
the
moment,
you
could
imagine
if
you're
having
to
like
recursively,
select
all
possible
union
members
for
all
possible
types.
You
know.
Basically,
your
client
queries
just
blow
up
in
size
and
you
have
to
either
co-gen
them
treat
graphql
like
a
compile.
Target
also
lose
your
mind
trying
to
keep
it
in
sync,
and
you
know
client
developers
are
like
well.
I
Is
it
really
server
driven
for
having
to
request
things
that
so
that's
kind
of
like
the
the
problem
space
and
honestly,
it's
got
to
the
point
where
it's
it's.
I
You
know
we're
really
struggling
with
it
right
to
the
point
where
the
kind
of,
in
some
cases
just
entirely
just
sending
things
down.
It's
like
a
Json,
untyped
Json
blob.
Because
of
this
problem
and
I,
don't
know
it
seems
like.
Maybe
the
two
could
still
remain
married.
Somehow
Lee
I
know
there's
like
a
prior
opinion.
Piece
about
you
know,
describe
the
data,
don't
describe
the
view,
so
there
may
be
some
elements
of
What's
the
phrase
I'm
looking
for
you
know,
split
brain
that
needs
to
happen
to
sort.
B
I
Let
this
work
through
graphql,
or
maybe
you
know
the
stance.
The
official
stance
is.
Actually
we
don't
want
to
do
this
in
graphql,
and
you
know,
this
type
of
thing
is
just
not
a
good
fit
for
graphql
go
use
some
other
transport
layer,
which
is
totally
fine
as
well,
but
this
discussion
is
in
the
context
of
if
we
did
want
to
do
it
through
a
graphql
Benji
brought
up
his
structs
proposal
and
I,
don't
know
like
reading.
I
That
seems
like
if
you
had
your
surgery
from
your
eye
response,
basically
like
a
pipes,
Json
blob
encoded
as
a
struct.
That
would
solve
a
lot
of
problems,
and
this
would
be
like
a
huge
benefit
for
teams
trying
to
do
surgery
right
through
graphql.
So
that's
kind
of
the
discussion
topic
and
I
added.
You
know
a
PR
to
amend
the
proposal
with
that
use
case,
and
so
the
question
is:
does
that
change?
How
anyone
thinks
about
this
proposal,
because
I
think
Benji
shared
that
there
was
a
little
kind
of
you
know.
I
C
Honestly
Mark,
your
your
use
case
here,
I
think,
is
the
most
compelling
so
far,
not
to
say
that
there
are
other
ones
haven't
been
compelling,
but
you
know
this
is
not
the
first
time
we've
talked
about
this
sort
of
struct
type,
I
think
Genji's
give
given
the
most
clear
framing
for
it
today,
I'm
trying
to
page
I'm
like
half
six.
C
Sorry,
if
my
brain
is
like
not
fully
on
on
today,
trying
to
page
back
in
why
we
had
skated
away
from
stocks
last
time
to
make
sure
we
had
like
a
clear
set
of
constraints
to
solve
for
or
pitfalls
to
avoid,
but
certainly
like
this
problem
statement
is
very
interesting
to
me.
The
idea
that
you
know
graphql
is
originally
designed
was
meant
to
layer
over
interconnected
data
where,
as
you
navigate
the
graph
you're
doing
incremental
data
fetching
under
the
hood,
such
that
a
sub
selection
is
in
fact
a
performance.
C
Optimization,
which
is
obviously
not
true
for
a
struct
like
a
sub
selection,
is
actually
a
performance
detriment
for
a
struct
or
A.
Struct
would
imply
that
you're
not
doing
incremental
data
fetching
you
have
it's
just
a
you
know
structured
element
of
of
memory,
as
opposed
to
a
thing
that
gets
loaded
which
I
don't
know.
If
we
can
force
that
under
the
hood
necessarily,
but
that
that's
certainly
what
it
implies
like
you
get
all
of
it
or
you
get
none
of
it.
C
You
don't
sub
select
and
therefore
you
kind
of
pay
for
all
of
it
or
you
pay
for
none
of
it
and
I
think
there's
a
lot
of
problems
that
are
shaped
like
that.
Where
having
to
do
the
whole,
like
the
fact
that
graphql
very
intentionally
does
not
have
a
select
star
equivalent
is
because
a
blind
application
of
a
select
star
could
have
potentially
horrific
performance
characteristics.
C
I
Yeah
that
definitely
seems
to
be
sort
of
two
almost
competing
philosophies
for
how
teams
build
pages,
and
we
have
teams
who
want
to
go
this
route
and
there's
there's
also
a
trade-off.
I
mean
I,
think
this
makes
a
lot
of
sense
for
like
a
marketing
page
or
something
you
know
like
the
output
of
the
CMS.
B
I
Maybe
you
don't
care
so
much
about
performance
and
you're,
not
going
to
be
doing
much.
Nested
call
a
whole
bunch
of
Upstream
Services
recursively
and
to
just
kind
of
have
everything,
or
even
in
some
cases,
even
if
it's
not
a
marketing
page,
it
is
actually
like
a
highly
Dynamic
page
like
a
search
results
page
or
something.
I
If
that
is
the
output
of
the
materialized
view,
you
know
or
something
like
that's
like
highly
highly
optimized
on
the
back
end,
and
actually
you
do
just
kind
of
have
this
blob
emitted
from
some
cash
layer
or
an
ml
model,
or
something
like
that
and
you're
not
going
to
be
doing
much
sort
of
nesteds
call
a
bunch
of
Upstream
services
in
that
critical
request
path
anyway.
So
yeah
I
mean
that
that's
kind
of
I
can
only
speak
for
what
I've
seen
current
internally
at
our
company.
C
Maybe
an
interesting
I,
don't
know
if
it's
a
Counterpoint
but
A
variation
on
the
sui
that
maybe
breaks
the
idea
of
using
structs
for
it
I,
don't
think
it
doesn't
evaluate
necessarily
but
to
expand
the
surface.
C
I
know
Facebook
has
a
handful
of
server
driven
UI
framings
that
do
use
graphql
and
an
important
characteristic
to
many
of
them.
Is
that,
along
the
way
of
having
you
know
very
much
view
model,
Style
server
driver
new
eye
kind
of
structures.
C
There
are
back
pointers
to
true
graphql
object
through
nodes,
where
I
think,
just
by
the
nature
of
how
they
use
them,
they
make
sure
they
get
the
type
and
ID
of
those
things,
so
that
if
there
is
needing
to
refetch
subsections
of
the
screen
or
if
elements
change
over
time
that
they
don't
need
to
go
reload
the
entire
view
they
can
have.
The
view
remain
live
on
the
client
based
on
the
real
data
under
the
hood
and
so
I.
Think
that's
just
like
an
extra
layer
of
sophistication.
C
That's
been
added
there
that
should
a
struct
have
the
extremely
reasonable
restriction
that
it
cannot
point
back
to
an
object
like
it
can
only
have
other
kind
of
leaf
types
within
it.
Then
you
can't
do
that
necessarily
without
I
guess
having
an
some
kind
of
struct
that
describes
how
to
refetch
some
piece
of
data,
which
I
guess
maybe
the
Corollary.
C
Benji
I
know
this
was
a
little
bit
orthogonal
to
some
of
the
use
case
you
had
in
mind,
but
you
know
what's
kind
of
interesting
here.
Is
this
struct
proposal
file
is
now
getting
extended
to
start
to
Define
some
use
cases.
E
C
E
Is
kind
of
what
I
was
trying
to
say
about
destruct,
solving
or
potentially
solving
the
the
world
card
problem
the
select
asterisk,
but
only
in
very
specific
use
cases,
so
I'd
love
to
dig
in
a
bit
more
and
find
out,
you
know,
do
do
the
subfields
here
actually
need
their
own
resolvers,
because
struct
is
very
much
like
in
the
way
that
I've
proposed
it.
It's
intended
to
deal
with
a
blob
of
data,
as
in
you
get
that
blob
of
data
from
somewhere.
E
It's
not
something
that
you
resolve
step
by
step
like
you
do
for
the
rest
of
graphql,
and
it's
very,
it
is
literally
like
Mark
said,
is
cause
problems
and
we've
actually
started
resorting
to
using
big
Json
blobs.
It's
there
to
solve
the
big
Json
blob
issue
as
much
as
anything
so
I
think
it
is
it's
another
good
use
case
for
it,
but
I'd
have
to
really
look
into
what
Mark
was
talking
about,
specifically
to
find
out
whether
it
is
a
good
fit
or
whether
there's
you
know
Parts,
where
it
doesn't
work
so
well.
E
I'd
also
love
to
to
hear
more
about
what
you
were
saying
with
the
with
the
Facebook
server
driven
UI
stuff,
where
you
were
saying
about
the
the
linking
back
to
the
object,
types
and
stuff
like
that.
I'd
love
to
to
understand
more
on
that
point,
just
as
a
slight
clarification,
The
struct,
Proposal
optionally
allows
selection
sets.
E
So
you
can
effectively
narrow
if
you
want,
but
it's
it's
there
to
represent
an
object
in
memory.
If
you
want
to
only
have
a
smaller
amount
of
that,
you
can
do
so.
But
it's
a
it's
a
choice
that
you
could
exercise.
C
Is
the
yeah
I
wonder
if
that's
over
design
or
not
like
I
can
see
why
that
could
potentially
be
useful,
but
is
it
a
you
know?
Is
it
more
useful
just
to
take
the
payload
as
it
has,
because
I
can
see
that
adding
like
cash
complexity,
where,
if
you're
trying
to
cash,
Leaf
values
and
reassemble
them
in
some
kind
of
wild
and
crazy
graphql
intermediate
tier,
which
I
know
a
couple,
crews
are
attempting
to
go
build.
Then
this
like
adds
a
complication
layer
to
that
potentially.
But
yeah.
E
You
could
you
could
probably
just
transform
the
query
to
remove
the
sub
selections,
though,
but
I
certainly
don't
need
it
to
support
sub
selections.
E
It
was
more
an
exploration
of
here's,
the
thing
that
we
might
want
in
future
and
I
think
originally,
it
was
proposed
partly
to
solve
the
the
metadata
issue
where
I
imagine
metadata
could
get
quite
big
and
allow
sub
selection
on
that,
because
one
of
the
use
cases
that
I
have
for
metadata
is
the
ability
to
introspect
small,
like
types
A
type,
a
field,
something
like
that
and
get
just
the
information
I
need,
rather
than
the
whole
schema
introspection.
E
So
sub
selection.
There
is
valuable.
C
Yeah
I
think
that
might
be
too
crazy,
usually
better
to
have
the
set
of
things
you
want
than
to
do
the
other
way
around
yeah
I'm,
still
not
100,
convinced
on
the
metadata,
this
being
the
right
opportunity
which
you
know
but
but
I
think
like
listening
out.
The
handful
of
use
cases
that
we're
interested
in
exploring
around
is
certainly
worthwhile
that
that's
really
a
useful
way
to
make
it
proposed
more
concrete
one
thing:
I'll
just
flag
it.
C
We
don't
have
to
talk
about
it
now,
if
it's,
if
it's
less,
if
it's
not
useful
but
how
to
deal
with
unions
within
the
context
of
structs
I
know,
you've
got
to
take
in
your
proposal
Benji,
but
it
does
potentially
complicate
the
use
of
a
union
and
essentially
kind
of
create
two
variations
of
a
union
implicitly,
which
is
maybe
a
little
bit
tricky
and
curious.
If
one
of
is
a
just
a
cleaner
way
to
make
that
work,
I'm
happy
to
talk
more
about
the
the
server
driven
UI
case
Benji.
E
I
That
that
was
definitely
going
to
be
one
of
the
questions.
I
was
going
to
have
like
a
you,
know,
GitHub
issue
or
something
I'm,
pretty
sure
that
everything
is
done
as
a
sort
of
top
level
thing,
but
I'm
not
actually
sure
if
that's
like
my
problem
with
that
is
that
the
developer
has
to
be
sort
of
very
clever
when
emitting
their
payload
from
that
one
top
level,
God
resolver,
to
make
sure
that
that
output
of
that
resolver
matches
a
thing.
I
I
I,
don't
know,
if
kind
of,
like
the
closing
the
door
on
that
would
be
like
it
would
be
nice
to
be
able
to
have
results.
Basically,
four
fields
in
in
the
structs
I.
I
Don't
know
if
that's
like
a
must-have
I'm
struggling
to
sort
of
consider
the
pros
and
cons
I
mean
not
having
arguments
make
sense,
but
to
be
able
to
sort
of
like
override
one
of
the
things
in
your
like
tree
leaf
nodes
of
your
structs
I
mean
if
it
complicates
the
proposal
and
makes
it
just
impossible,
then
I
think
structs
without
per
field.
Resolvers
is
way
better
than
what
we
have
right
now.
So
that's
that
that
that's
fine
if
we
can
still
make
resolvers
work,
that
would
be
kind
of.
C
Nice
having
one
resolver
at
the
top,
makes
it
much
easier
to
Define
as
a
as
a
leaf
type,
like
all
other
Leaf
types
today
kind
of
fit
that
model,
but
it
I
mean
it's
a
new
thing.
So
we'd
have
to
explore
David
I
see
you
got
your
hand.
H
That
is
like
read
from
an
internal
data
structure,
and
it
would
seem
weird
to
me
that
the
level
of
the
graphql
spec
for
it
to
differentiate
between
the
concept
of
like
a
function
is
being
called
versus,
like
a
value
is
being
unpacked.
That
seems
really
implementation
dependent
to
me.
The
only
reason
I
can
sort
of
understand
it
is
the
idea
of,
like
you
know
it's
sort
of
like
like.
Does
it
finish
or
not
like
it?
You
know
it
the
only
thing
that
you
know
can
it
hang.
H
You
know
once
you've
resolved
the
top
level
field.
You
are
confident
that
it
will
not
be
an
infinite
Loop,
but
I
don't
know,
especially
for
the
use
case
of
like
you
know,
of
unpacking
a
recursive
tree.
I,
don't
see
why
you'd
want
to
limit
the
implementations
mechanism
of
providing
like
if
I'm
imagining
yeah
unpacking
a
tree
I,
don't
see
why
I
would
have
to
write
a
top
level
function
in,
like
my
user
code,
that,
like
unpacks
an
entire
three
that
doesn't
seem
helpful
or
relevant
to
like
respect
essentially
yeah.
C
I,
imagine
that,
as
we
would
go
about
assembling
the
spec
text,
let
alone
an
actual
implementation,
some
iteration
of
a
resolver
would
emerge
because
a
very
important
part
of
what
graphql
is
doing
when
it's
creating
Leaf
types
is
ensuring
that
the
raw
value
that
it
got
from
a
service
actually
maps
to
the
expectations
of
that
value.
That
graphql
defines
and
so
there's
just
sort
of
I
guess
you
could
call
it
a
validation
step.
But
it's
really
value
transformed
like
given
some
value
on
from
the
backing
service.
How
does
that
go
through
yeah?
H
I
guess
the
other
thing
is
given
that
we
do
allow
selection
sets.
It
would
seem
really
strange
for
me
to
be
say,
like
you
are
required
to
like
produce
an
entire
infinitely
nested.
You
know
thing
even
if
you're
not
using
the
recursive
field,
like
you
know,
if
you're,
if
you
have
like
you,
know
a
trace
or
something
and
there's
a
top
level
like
ID
field
and
then
there's
a
the
entire
recursive
thing
and
you're
only
selecting
ID.
H
E
Difference
there
there
wouldn't
be
one
right,
so
the
spec
could
still
say
here's
what
you
do
so
long
as
you
can't
observe
the
difference,
then
it's
fine
for
you
to
optimize
that
way
inside
your
own
implementation.
Kind
of
the
the
intent
with
what
I've
sort
of
described
is
that
there
is
no
logic
in
it.
There
is
no,
it
is
just
data,
that's
the
intent!
If
you
want
to
actually
build
resolvers
into
your
graphql.js
implementation
to
build
what
that
data
is
that's
fine,
but
I.
A
I
still
struggle
with
that
that
that
is
being
just
a
blob
of
data,
because
because
that's
one
of
the
the
core
principles
of
graphql
that
you
can
like
say
what
you
want
well
and
and
I
mean
I
discussed
with
energy.
That's
a
while
back
and
I
even
think
it
should
have
like
fragments
and
stuff
like
that.
If
we
go
down
the
strike
round
because
it
would
be
so
foreign,
it's
like
the
same
structure.
A
C
Yeah,
this
is
why
I
think
the
really
understand
the
use
cases
matters
a
lot,
because
if
this
is
simply
a
modern,
minor
variation
on
a
graphql
object,
where
you
just
don't
have
arguments
than
a
bunch
of
things
break
and
it's
part
of
why
the
O
is
the
sub
selection
over
engineering.
I
Want
to
Echo
that,
like
we
have
people
who
are
doing
that
today
at
multiple
companies
and
even
if
that's
not
the
original
intention
of
graphql,
that
is
how
people
are
using
it,
and
you
know
with
like
a
big
Json
blob,
then
that's
like
not
type
80
store
are
gonna,
have
people
doing
more
or
less
the
same
thing
like
you
can
have
like
lots
more
if
statements
and
switch
statements
on
the
clients,
but
we
have
that
right
now,
anyway,
at
least
now
it's
going
to
be
typed
and
you
know
we'll
have
like
more
proper
tooling
around
it
and
like
approved
opinions,
but
again,
I
get
that
this
is
like
a
pretty
big
shift
away
from
the
original
intention
of
graphql
and
this
nice
beautiful,
abstract
data,
so
I
totally
get
the
you
know,
I
totally
get
all
these
on
on
this,
but
yeah.
C
The
the
use
case
very
much
exists
like
I'm,
convinced
that
to
talk
to
plenty
of
people
that,
like
this
is
a
very
common
pain
point
where
there
is
in
fact
structured
data
that
does
not
contain
deep,
asynchronous
resolvers,
but
does
contain
a
fair
amount
of
variability
and
ends
up
being
actually
like.
The
selection.
Steady-Ness
of
graphql
ends
up
being
a
block
and
hinder
to
productivity
rather
than
an
asset,
and
so
like
I,
think
really
kind
of
narrowing
in.
C
I
A
Well,
yeah
the
thing:
the
thing
that
I
fear,
but
is
you
design
your
client
application
for
certain
response
time
and
because
it's
now
a
struck,
you
suddenly
get
more
data,
then
you
really
request
it
because
Suddenly
It's,
it's
the
same
query
shape,
but
you
just
get
more
data.
That's
why
it's
yeah,
when
I
kind
wouldn't
would
want
to
avoid
I.
I
I
think
that
the,
if
you
are
a
client
developer,
writing
a
query
that
can
change
the
structs.
Hopefully
you
know
maybe
calling
will
be
we'll
call
that
out
or
something,
but
it
would
be
your
expectation
of
the
person.
Writing
the
query
that
hey
this
is
sort
of
going
to
blow
up
arbitrarily,
and
you
know
you're
on
the
hook
for
I'm
marshalling
that
yourself,
basically-
and
you
know,
writing
the.
If
statements
and
stuff
and
like
yeah
like
that
that
that
that
is
essentially
I,
think
what
we're
saying
right.
A
Yeah,
it
depends
a
bit
and
that's
that's
where
we
we
don't
know
where
the
line
is
at
the
moment,
so
so
I'm
not
opposed
to
track
I.
Think
it's
very
intriguing,
but
there
is
there's
a
fine
line.
We
have
to
walk.
Is
it?
Is
it
really
a
Json,
scalar
and
yeah
I
talked
also
with
Benji
on
that?
Is
it
really
a
scanner
or
is
it
more
than
than
just
a
type
Json
object.
H
Yeah,
so
so
my
read
on
this
proposal
is
that
it
sort
of
provides
a
couple
things
it.
It
says
there
are
some
data
types
where
you
basically
might
want
to
have
two
features.
One
feature
is
the
ability
to
get
a
default
selection
that
might
expand
later.
So
it's
good.
If
this
is
explicit,
so
your
code
gen
it
all-
can
do
that,
but
in
default
selection,
where
you
don't
have
to
ask
specific
things,
and
also
it
might
be
nice
to
be
able
to
describe
this
both
as
input
and
its
output
automatically
and
in
exchange.
H
There
are
features
of
graphql
like
arguments
and
aliasing
that
you
don't
get
to
use
with
this
I
forgot.
Why?
Just
a
quick
aside,
I,
don't
really
understand
why
directives
aren't
are
some
good
user
I
don't
get?
Why?
If
and
Skip
would
not
be
things
if
you're
gonna
have
selection
sets
I,
don't
see
why
you
wouldn't
be
able
to
have
if
and
Skip
and
so
on
also,
and
that
makes
a
lot
of
sense
to
me.
I
just
want
to
throw
out
a
use
case
that
we
would
use
it
for
in
Apollo's
API.
H
We
have
a
particular
part
of
our
API
that
is
sort
of
a
generic
query
field
for
query
types
for
declaring
our
the
Druid
database
time
series
database
and
one
of
the
main
things
you
do
in
acquiring
this.
Is
you
Group
by
certain
fields
and
when
you're
grouping
by
field
a
query,
and
so
we
may
see
sort
of
like
a
flexible?
You
know
common
things
that
we
use
all
of
our
app.
We
make
specific
fields
that
specifically
do,
but
we
also
have
this
sort
of
generic
thing.
H
That's
really
nice
for
just
like
experimenting
with
the
API
and
if
you
want
to
group
by
a
field,
those
are
basically
going
to
have
to
be
the
fields
you
select,
and
so
the
naive
way
to
do
this
is
you
would
provide
which
fields
of
figure
by
in
an
argument
to
the
like
query
field
and
then
also
select
the
same
sets
of
fields
in
a
in
the
selection
set,
and
we
felt
like
that
was
going
to
be
like
not
really
a
good
experience.
H
So
we
did
the
actually
sort
of
hacky
thing
where
the
actual
query
that
gets
run
at,
like
you
know,
a
certain
level
of
the
of
the
schema
it
depends
on
which
Fields
you
select
in
a
nested
selection
set,
which
has
all
of
the
negative
impacts
you
might
imagine,
and
it
would
be
great
if
we
could
move
to
a
world
where
we
say
which
fields
we
care
about
via
the
arguments.
H
And
then
we
just
say
yeah
give
me
the
fields
I
asked
for,
and
it
just
gave
those
back,
and
so
it
would
be
a
pretty
Dynamic
thing
that
you
get
back,
but
yeah,
that's
a
use
case.
I
don't
know,
is
covered
here.
That
would
be
a
good
fit
for
this
I
feel
like.
F
C
Okay,
I
want
to
be
conscious
of
time.
It
sounds
like
where
we're
at
with
this
is
collecting
more
use.
Cases
is
incredibly
valuable
and
it's
adding
a
lot
of
color
and
Clarity
to
how
we
might
make
decisions
around
this
I'm
very
convinced
this
is
a
real
problem.
I've
talked
to
more
than
enough
people
to
understand.
C
This
is
very
real
problem,
and
so,
let's
kind
of
stay
living
in
the
world
of
collecting
use
cases
to
help
us
guide
decision
all
right,
yeah,
welcome,
I,
know:
you've
got
a
awesome
agenda
item
on
the
on
the
docket,
so
I
want
to
hand
it
to
you.
Next.
K
Awesome
I'm
gonna
share
my
screen
in
a
total
fake
out.
I
want
to
discuss
the
second
item.
I
listed
first,
if
that's
okay,
because
I
think,
probably
incorrectly.
If
past
experience
is
going
to
prove
correct
that
it
might
go
quicker
and
then
we
can
get
to
the
juicier
item
next.
So,
let's
see
basically
I
wanted
to
reopen.
K
So
basically,
the
two
items
that
I
want
to
talk
about
is
how
incremental
delivery
sort
of
inter
interacts
with
bragum,
modularity
or
I'm,
not
sure
what
we
might
want
to
call
it
fragment
Independence
and
the
first
has
to
do
with
one
of
the
decisions
or
really
the
second
in
the
agenda.
But
the
first
item
I
want
to
talk
about,
has
to
do
with
one
of
the
decisions
we
made
in
terms
of
how
deferred
fragments
are
interpreted
when
they're
nested.
K
So
this
is
originally
Benji's,
Benji's
point
and
suggestion
or
problem
or
and
really
discussion
that
I
am
sort
of
reopening,
because
I
think
I
think
we
potentially
jumped.
Potentially
the
choice
we
made
may
have
impact
for
a
fragment.
Modularity
issues
later
on.
I
just
want
to
make
sure
that
we're
you
know
making
that
choice
consciously.
So
basically
this
is
Benji
and
Benji.
Please
feel
free
to
jump
in
if
I'm
mischaracterizing
or
you
wanna
I
wanna.
K
But
this
is
one
of
the
discussions
and
Rob
has
this
great
repository
where
all
of
our
discussions
or
have
been
are
really
not
all,
but
I
I
assume,
as
many
as
possible
have
been
written
down
soon,
hopefully,
all
of
them,
and
so
the
question
here
is
if
we
have
deferred
fragments
like
in
this
example
that
Benji
has
over
here
and
they're
nested
how
this
should
be
interpreted
so
I'm
just
gonna,
you
know.
Basically,
we
have.
K
In
this
example,
we
have
one
deferred,
inline
fragment
that
contains
another
one,
a
name
fragment
later
on
and
it
contains
another
inline
fragment
that
also
has
to
fur
on
it,
which
contains
both
a
field
and,
and
that
name
fragment
and
then
there's
a
third
level
of
nesting
of
the
fur.
So
basically,
the
idea
is
that
you
can
have
nested
fragments
yeah,
obviously,
and
then
what
happens
exactly
when
we
we
put
the
Deferred
directive
on
them.
K
So
when
we
we're
not
using
defer
all
these
are
merged
in
the
collect
field
step,
and
so,
if
you
can
imagine
for
a
second
that
defer
wouldn't
be
here
it
basically,
the
above
would
be
essentially
equivalent
to
what
Benji
has
here
in
his
second
example
below,
where
these
fragments
are
sort
of
separated.
In
the
end
they
all
get
merged
together
anyway.
K
So
it
doesn't
really
matter
whether
you
it
may
matter
to
you
in
terms
of
you
know
how
you
organize
the
fragments
and
where
you
store
them
and
where,
but
you
know,
but
to
grab
to
the
to
the
execution
engine
once
you
know
once
they're
merged
they'll
be
the
same.
So
it
doesn't
really
matter
if
they're,
nested
or
not.
But
the
question
is
the
question
is
potentially
the
just
thinking
about
the
semantics
of
defer.
K
These
two
options
could
have
very
different
behavior
meaning
in
this
example,
we
have
three
fragments
that
are
all
deferred
I.
Imagine
we
had
some
additional
Fields
over
here
on
users
list
that
were
not
deferred,
and
so
all
of
these
three
fragments
would
not
come
in
the
initial
response,
but
otherwise
they'd
all
be
equivalent,
but
you
can
imagine
that
this
semantics,
the
the
first
example-
might
have
sorry.
K
This
syntax
might
have
different
semantics
in
that
you
might
expect
that
that
whatever
was
in
the
initial
response
would
come
first,
just
let's
just
imagine
Benji
has
it
in
a
few
fields
that
that
are
not
deferred
and
then,
secondly,
would
come
whatever
fields
are
in
the
first
fragment
and
then
thirdly,
would
come
whatever
is
in
the
nested.
K
And
finally,
you
would
get
this
and
that
could
be
useful,
because
maybe
you
have
a
component
of
UI
that
you,
you
know
you,
you
know
you
can
defer
loading
it,
but
even
when
you
do
load
it
there's,
maybe
a
sub
component
of
that
that
can
be
further
deferred
and
we
also
have
a
companion
issue.
I
guess
to
this.
K
If
you
want
to
change
the
priority
of
of
one
item,
you
have
to
be
aware
of
all
the
different
arguments.
You
know
values
for
the
different
orders
or
priorities
and
all
the
other
different
fragments
in
the
query.
So
it's
a
fast
forward
a
little
bit.
We
basically
have
cited
in
the
spec
right
now
to
not
respect
this
nesting
and
and
I'll.
Basically,
I
was
thinking
about
the
other
issue
and
about
fragment,
modularity
and
basically
I.
Think
it's
interesting.
K
We
Benji
raised
this
issue
initially
because
he
was
concerned
that
this
could
be.
You
know
potentially
bad,
but
actually
he
writes
over
here,
and
maybe
he
still
feels
this
way
that
that
you
know
potentially
we
have
to
do
this
because
of
the
idea
of
you
know
for
fragment.
Modularity
and
I
would
agree
with
that.
First
initial
concept
and
I
think
a
concerns
about
about
this
potentially
being
an
attack.
K
Vector
are
I'm,
not
100,
clear
on
them
and
I'm
love
to
have
greater
elaboration
from
the
group
about
it.
I
mean
basically
the
way
the
graphql.js
implementation
works.
Right
now
is
that
in
this
query,
meaning
the
one?
What
that's
that's
basically
we're
considering
the
nested
query
to
be
equivalent
to
this
parallel
query:
we
create
repetitive
branches
of
execution
for
each
of
these
deferred,
fragments
in
which
you
know,
field
execution
is
potentially
you
know.
Unless
we're
you
know,
caching,
which
hopefully
we
are
but
potentially
we're.
K
You
know
sending
additional
data
and
burning
additional
C
say
you
know
CPU
cycles.
For
those
you
know,
separate
branches
of
execution
and
all
of
those
are
deferred
using
promises
in
the
graphical
address
implementation
to
come
later
than
the
initial
one.
And
so
the
only
difference
that
I
see
between
this,
which
is
what
we
currently
do,
and
this
which
we
compile
away,
is
that
in
this
example,
the
initial
responses
would
have
an
order,
which
means
we
would
hold.
K
Even
if
the
execution
of
our
one
of
our
deeper
levels
had
completed,
we
wouldn't
send
it
until
the
previous
one
had
had
been
sent
and
other
than
that
I
mean
the
Dynamics
of
actually
how
it's
managed
on
the
server,
because
that's
the
only
observable
difference,
you
know,
I,
don't
think,
would
be
too
different,
and
certainly
we
could
change
it,
because
that
would
be
invisible
to
the
user.
K
If
there
would
be
a
open
up,
an
attack,
vector
and
in
fact
the
idea
of
holding
on
to
a
group
of
fields
and
then
holding
on
to
another
group
of
fields
and
then
as
soon
as
the
first
one
is
free
to
go,
then
we
can
send
the
deeper
ones
that
have
been
ready
for
a
while.
K
That's
exactly
what
we're
doing
right
now
in
stream,
and
so
the
idea
of
holding
on
to
you
know
things
that
are
potentially
ready
to
send,
but
not
sending
it
you
know
is,
is
something
that
we're
doing
already
so
I.
Just
you
know,
I
want
to
reopen
this
discussion
about
fragment
modularity,
just
because
I
think
it's
important
that
we,
you
know
if
we,
if
we
do
reject.
D
What
what
graphql
JS
will
do
is
when
it
does
I
think
collect
fields.
Is
it
would
re
it?
Would
it
would
regards
through
all
these
fragments,
as
long
as
they're,
under
the
same
root
object,
which
would
be
users
list
in
this
case
and
return
that
list
of
these
are
all
the
Deferred
fragments
it
found
and
then
yeah
start
executing
everything
that
wasn't
inside
a
defer
that
did
get
merged
and
then
execute
each
defer
separately.
But
it
does
it's
not
imposing
any
order
on
those
because
they
are
under
the
same
yeah.
D
A
And
more
concrete,
also,
if
you
have
like
lower
level
things,
it
could
be
that
like.
If
you
have
proper
fragments,
it
could
be
that
a
subfield
overtakes,
a
parent,
so
the
order
is
not
guaranteed.
Even
if
you
have
a
deeper
structure
like
the
the
the
the
example
here
is
essentially
the
same
level
and
also
the
same
fragment
right,
it's
very
constructed,
but
if
we
had,
for
instance,
Avatar,
which
has
a
subfield
URL
and
that
would
be
deferred,
it
could
also
be
over
overtake
one
of
the
parents.
A
J
K
Yeah
no
I
I
think
I
agree
with
you.
We
make
sure
that
we
always
send
you
know
we
can't
send
the
child
field
of
Avatar.
Let's
say
if
URL
was
a
subfield
before
we
send
the
parent
field,
because
we'll
never
send
a
path
that
doesn't
make
sense.
K
You
know
we'll
never
send
a
payload
with
a
path
that
you
know
that
hasn't
the
client
hasn't
already
seen.
So,
but
that's
not
what
we're
talking
about
over
here.
What
we're
talking
about
over
here
is
even
under
the
same
path,
meaning
all
these
deferred
fragments
are
under
the
path
of
users
list
right,
we're
talking
about
whether
there
could
be
an
order
we
to
to
to
the
different
fields
and
whether
we
might
want
to
use
nested
defer
to
imply
that
order
with
another
alternative
potential,
potentially
being
in
the
future.
K
Being
something
like
what
this
other
syntax
over
here
of
this
here
I
hear
it.
This
is
a
little
off
because
we
don't
currently
allow
defer
on
field
at
all,
but
the
idea
is
take
a
look
at
this
order
field
you
know.
Is
that
the
way,
if
you
know
we
want
to
preserve
space
for
this,
for
this
possibility,
it
seems
to
me
like
this,
isn't
necessarily
the
way
to
go
to
for
it.
Yeah.
A
You
had
a
better
example:
I
looked
at
one
example
where
you
used
the
Alias
syntax,
the
syntax
on
the
spread.
I
think
it
was
in
your.
She.
K
K
That's
the
other
issue.
They
are
somewhat
linked,
I
I,
think
they're
definitely
somewhat
linked,
and
but
this
this
I
think
is
but.
K
Something
to
think
about
it,
just
to
think
about
no
matter
what
we
say
about
that
other
potentially
much
more
controversial
issue,
I
think
we
we
might
want
to
rethink
this
one.
A
Yes,
I
I,
just
think
the
the
example
you
linked
to
actually
with
the
earlier
syntax,
that's
better
to
talk
about
then.
So
this
is
a
very
constructed
example
and
I
mean
what
Benji
showed
there
is
that
you
and-
and
we
have
said
in
some
customer
use
cases
where
you
can
actually
create
queries
that
have
like
that
defer
stuff,
but
actually
overall,
have
a
worse
execution
time,
and
that
could
be
a
that's
one.
That's
one
argument
why
I
always
want
the
server
to
override,
sometimes
certainly.
K
Yes,
yeah
yeah
I
think
we've
had
a
lot
of
discussion
about
whether
to
allow
optimizing
or
not
I'm,
saying
let's
go
with
that
in
our
current
behavior,
which
allows
a
lot
of
optimizing.
The
only
thing
that
would
change
here
is
the
is
that
later
responses
would
not
be
sent
until
earlier
responses.
K
You
know
and
again
and
and
it
could
be,
that
the
server
then
has
additional
flexibility.
It
could
pre-compute
or
not
the
that's.
You
know,
depending
on
what
it
thinks
is
the
best
thing
to
do,
but
it
would
respect
the
order.
At
least
that
was
indicated
by
this
nesting.
A
David
has
a
sense
up,
but
but
one
thing
here
so
this
is
constructed
and
that's
why
I
think
your
other
example
is
better
like
I
think
there
is
there.
A
There
is
like
when
we
talk
about
fragment
modular,
then
we
want
to
have
like
this
order
thing,
but
this
actually
could
be
optimized
in
this
case
like
actually
what
we
are
doing
here
is
we
defer
user
product
and
then
we're
deferring
Avatar,
URL
and
then
Avatar
bio
from
a
data
standpoint,
because
we
are
repeating
this
fragment
here,
so
that
could
be
optimized,
but
with
the
fragment,
modularity
thing,
I
think
you're
right
there.
We
want
to
have
a
guarantee,
because
the
client
wants
to
know
if
equipment
is
fulfilled.
A
K
They're
definitely
separate
things
for
the
purposes.
This
is
this
example.
You
could
say:
user
fragment
is
different
than
I
mean
you
can
look
at
these
as
as
different
at
different
collections
of
field,
and
they
only
happen
to
be
the
same,
and
this
could
be
an
example.
That's
optimized,
but
that's
true,
no
matter,
you
know
the
fact
that
it
could
be
optimized.
It's
true,
no
matter.
You
know
this
query,
which
we
currently
allow
and
interpret
the
first
one.
As
you
know,
this
also
could
be.
K
F
K
What
the
downsides
really
of
respecting
this
inlining?
Sorry,
respecting
this
nested
level
of
defer,
R
yeah.
A
Because
because
if,
if
you,
if
you
from
a
database
standpoint,
if
you
anyway,
like
let's
say
you
have
mongodb
and
to
anyway
load
the
document,
you're,
not
projecting
things,
and
you
anyway
have
no
bionet
and
Avatar,
you
are
there.
Why
differ?
Why
not
just
put
it
in
the
first
Dipper
and
skip
the
second,
no.
K
But
that's
good
I
mean
that's
exactly
what
this
syntax
would
allow
you
better
to
do.
I
mean
we've
had
discussions
about
whether
you
should
be
allowed
to
do
that,
but
with
this
syntax
of
the
set
of
the
nested
defer
this
second
defer.
If
you
know
if
in
that
scenario,
wouldn't
necessarily
have
to
be
honored,
but
in
this
example
that
we
have,
it
would
be
a
lot
where
all
these
are
happening
in
parallel.
It
actually
would
be
a
little
bit
more
difficult
to
Nest.
You
know
this
second
defer
you
know
defer
within
within
the
first.
K
You
know
so:
I
I,
I'm,
just
I'm,
just
not
quite
sure.
Originally
the
the
suggestion
was
that
allowing
these
nests
to
defer
and
allowing
the
user
through
a
query
through
an
operation
with
NASA
defer
to
an
impose
an
order
on
fields
would
serve
as
an
attack
Vector.
That
was
the
original
claim
and
then
and
then,
within
this
discussion,
we
pointed
out
that
actually,
our
current
implementation
isn't
doing
that,
and
so
it
was
like
a
few
okay,
we're
avoiding
this
attack
Vector,
but
I'm
not
quite
sure
what
the
attack
Vector
is.
H
Sorry
I've
had
him
for
a
few
moments:
I
just
wanted
to
throw
out
there
on
the
one
hand,
despite
what
I'm
about
to
say,
I,
actually
kind
of
think.
The
current
spec
is
pretty
good
and
I'd
love
to
see
it
just
move
forward
and
without
any
big
rethinks.
H
If
we
are
doing
big
rethinking,
maybe
we
could
put
on
the
table
the
idea
that,
like
we
just
don't,
send
the
same
data
twice
and
it's
the
job
of
the
client.
If
the
client
wants
to
be
able
to
present
to
like
the
user
of
the
client
Library,
a
a
an
object
that
matches
a
deferred
fragment
exactly
and
then
it
just
has
to
remember.
H
The
field
that
it
got
earlier
in
the
Stream
like
I,
think
all
of
this
is
Downstream
of
like
the
the
decision
that
the
thing
that's
on
the
screen
now
should
not
be
exactly
identical
to
the
same
query
without
the
nested
dot
user
frags
like
if
we
have
again
I,
would
love
us
just
move
forward
with
our
lives
and
get
this
in
the
spec,
but,
like
I,
don't
understand
why
we
think
it's
more
important
that
the
low
level
bytes
on
The
Wire
that
are
sent
to
the
client
Library
exactly
match
these
sub
fragments
and
I
I
would
like
I
would
be
much
happier
with
the
world
where,
what's
on
the
screen
now
is
exactly
equivalent
to
only
specifying
the
top
level
dot
dot
user
frag.
K
I
I
think
that's
a
great
Point.
That
wider
question,
though,
is
sort
of
why
I
saved
you
know
it's
more
con
I
think
we
can
get.
We
can
sort
of
address
the
narrower
Point
here
before
we
get.
We
bring
that
right
back
in
when
we
discuss
the
next
issue.
Yeah
and.
A
K
A
Look
a
lot
of
these
things
also
can
be
minimized
by
using
data.
Loaders
I
mean
it's
also
Implement
implementation
standpoint
from
a
user
here
like
if,
for
instance,
okay
user
list-
maybe
not,
but
if,
if
you
have
certain
things
like
cached
with
data
loaders,
they
wouldn't
have
the
additional
cost,
like
you,
wouldn't
fetch
this
twice
from
the
database
and
things
like.
K
That
yeah
yeah,
no,
that
that's
100
true,
but
the
only
thing
that
I
wanted
in
this
issue
is
to
discuss
whether
we
want
to
allow
defer
to
clients
in
operation
to
use
these
nested
format
to
specify
an
order
onto
fur
versus
something
that
might
come
later
with.
You
know
something
that
we
might
Implement
later
like
this
argument
of
order,
which
doesn't
seem,
as
it
seems,
much
more
brittle
we're
going
to
discuss,
rethinking
everything,
I
suppose
in
a
second
but
I'm
just
can
anyone?
Can
anyone
better
explicate
why
this
would
be
bad?
We're
currently
not.
K
D
Do
want
to
want
to
describe
like
what
the
behavior
that
we're
talking
about
it
was
like
that
was
basically
when
we
first
started
looking
into
this.
D
It
was
feedback
from
Facebook
that
they
had
tried
to
do
field
merging
with
defer
and
ultimately
decided
that
it
was
better
to
do
this
kind
of
forking
of
execution
where
the
Deferred
Fields
don't
merge
back
into
the
non-deferred
fields
and
I
believe,
like
the
reason,
was
that
like
trying
to
do
that
merging
across
like
many
deferred
fragments,
especially
with
fields
that
have
like
fragments
inside
of
fragments
very
nested
objects,
going
all
the
way
down
was
very
complex.
D
Basically
from
that
feedback,
we
didn't
like
look
into
it
anymore
if
it
turns
out
that
it
actually
is
easy
and
there's
I'm
not
against
it.
But
that's
I
just
want
to
like
explain
why,
like
this
is
the
Avenue
we
went
down
from
the
like.
Basically
like
the
start
of
this
project,.
K
C
Yeah,
you
might
also
have
to
give
us
a
high
level
and
then
access
to
chime
in
a
discussion
thread
too.
Just
knowing.
K
So
so,
basically,
the
suggestion
here
is
to
First
note,
as
was
pointed
out
previously,
that
we
made
this
specific
choice
to
require
branching
of
execution.
K
We've
made
this
specific
choice
to
say
that
when
fragments
are
deferred,
what
the
client
will
get
later,
we'll
have
all
the
data
in
that
payload
and
we
and
the
client
is
sort
of
allowed
to
discard,
whatever
it's
seen
already
and
should
have
all
the
data
that
it
has
within
that
next
payload,
so
that
it
that
is
potentially
a
choice
that
we
might
want
to
revisit.
K
But
I
think
we
can
revisit
it
through
a
very
an
ordered
set
of
paths,
and
that
is
first
not
to
say
that
we
should
defer
sorry
for
the
pun,
that
we
should
defer:
releasing
incremental
delivery
until
fragment
modularity
and
a
new
response
format
and
all
the
wonderful
things
in
that
RFC
are
merged,
but
specifically
that
we
should
take
one
component.
K
This
idea
of
Alias
fragments
and
say
that
all
deferred
fragments
should
have
to
have
an
alias
and
skipping
down
from
the
worst.
From
the
worked
example,
I
think
we
could
try
reading
that.
You
can
read
that
at
your
leisure.
The
basic
idea
is
that
we
can
get
a
payload.
That
looks
something
like
this.
K
So
every
time
that
we
have
the
name,
the
Alias
for
the
fragment,
whether
it's
in
the
initial
payload
or
whether
it's
in
a
later
payload,
we
will
always
have
it
named
and
we
no
longer
need
a
label
and
clients
will
always
be
know
whether
on
the
initial
payload
or
on
a
later
payload,
exactly
which,
which
fragments
have
been
delivered
now.
K
One
of
the
basic
concerns
about
this
form
of
fragment
modularity
is
repetition
of
data,
but
the
argument
that
I
would
make-
and
it's
kind
of
an
interesting
argument,
considering
what
we've
heard
so
far
is
that
our
current
implementation
of
incremental
delivery
already
repeats
data,
and
so
the
idea
of
repeating
data,
potentially
a
little
bit
you
see
over
here.
How,
in
the
initial
query
ID
is
repeated.
Within
These
fragments
the
idea
of
repeating
it
here
this.
K
So
this
is
sort
of
like
an
intermediate
step,
and
so
this
optimization
is
made
by
the
server
to
send
name
data
initially,
but
the
idea
would
be
here
of
requiring
that
the
entire
fragment
descent
would
be
would
be
just
limiting
the
optimization
that
the
server
you
know
could
make,
with
the
advantage
that
it's
very,
very
clear
in
this
response
format,
which
fragment
is
there
now?
There
are
other
possibilities,
other
ways
this
could
be
done,
including
the
fulfilled
field.
K
But
this
is
the
in
my
mind,
the
simplest
and
best
a
way
to
do
it
that
that
is,
if
we
want
to
repeat
repeat,
data
I,
think
the
the
next
level
of
fragment
modularity
with
that
new
response
format
is,
is
something
that
we
could
use
to
to.
You
know
to
to
make
sure
that
data
is
not
decreased.
K
Data
is
not
duplicated
too
much
in
non-deferred
payloads,
but
in
deferred
pay
loads
were
basically
already
repeating
data,
so
the
idea
of
always
requiring
it
to
use
name
fragments,
basically
just
simplifies
our
uses
of
labels.
Every
time
that
you
have
a
deferred,
fragment
it'll
go
in
the
path
and
So.
Currently,
if
you
have
a
stream
nested
in
multiple
field,
nested
in
like
multiple
different
branches
of
execution,
the
label
on
that
have
the
same
path.
The
label
on
that
won't
actually
help.
K
You
distinguish
which
branch
of
execution
you're
in,
which
is
like
a
subtle,
prob,
just
a
subtle
problem
that
speaks
how
it's
it's
confusing
to
have
these
different
paths
and
labels.
What
we
really
want
is
the
branches
of
execution
to
be
encoded,
I,
think
a
better
solution
would
be
to
have
the
branches
of
execution
encoded
within
the
response
itself
and
for
time
constraints.
K
I'll
have
to
leave,
leave
us
there,
but
I
definitely
love
for
greater
feedback
in
this
discussion
and
again
I
I,
really
don't
want
to
suggest
that
we
have
to
you
know,
delay
all
of
incremental
delivery
until
we
figured
out
everything
about
fragment,
modularity
I
think
this
idea
of
taking
this
one
component
makes
a
nice
compromise
that
there
is
some
weakness
in
that,
even
when
the
server
optimizes
it
can't
it
does
duplicate
Fields,
but
through
compression
the
you
know,
it's
been
pointed
out.
K
If
that's
being
used
that
might
help.
This
format
would
also
help
an
additional
concern
that
Benji
pointed
out.
I'll
highlight
it
for
you
here
and
you
can
link
over
there
about
how
we
can
batch
deferred,
fragments
at
the
same
path
level,
similar
to
how
potentially
we
can
patch
individual
stream
items.
Now
that
we
use
an
array.
So
there's
a
bunch
of
helpful
things.
K
It's
a
consistent
response,
format
and
I
think
it
can
pave
the
way
to
further
optimizations
and
mesh
well
with
whatever
solution
we
eventually
come
to
with
rapid
modularity,
for
your
consideration.
A
Did
Matt
already
comment
on
that.
K
B
C
Yeah
there's
something
really
interesting
here.
Thank
you
for
keying
this
up.
It's
worth
talking
about,
I
know
we're
at
time,
but
I
think
the
specific
request
here
is
for
everyone
to
go.
Take
a
look
and
channel
some
of
your
thoughts
into
the
discussion
thread,
so
you
can
pick
this
back
up
and
run
with
it.
Foreign
folks,
thanks
for
healthy
discussion,
see.