►
From YouTube: Incremental Delivery Working Group - 2023-05-08
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
A
B
A
C
Let's
get
started
so
in
the
working
group
on
Thursday
we
presented
The
Proposal
Matt
had
some
feedback
and
you
left
a
comment
on
the
gist
with
some
ideas
so
yeah.
Maybe
we
should
start
by
talking
through
that.
I
can
share
my
screen.
C
Yeah
Matt:
do
you
want
to
maybe
just
just
walk
through
this
a
little
bit
for
everyone.
B
Like
what
I'm
trying
to
avoid
us
losing
in
this
proposal
is
essentially
the
like
as
much
as
possible
the
wussy
wig
sort
of
nature
of
graphql
or
the
response
format.
So,
like
the
the
fact
that
when
you
see
a
defer,
you
should
be
able
to
know
like
okay
yeah.
This
is
in
some
sense.
This
is
a
thing
that
that
we're
going
to
have
to
refer
to
later
and
the
so
in
this
iteration.
B
We
end
up
still
with
trees,
the
incremental
response.
He
basically
becomes
a
map,
so
you
can
quickly
look
up.
Oh
I
defer
I,
have
a
defer.
Zero
I
have
a
defer
one,
and
only
the
defer,
like
the
defer.
Zero
has
not
come
back
because
it's
not
in
the
incremental
payload.
Yet
it's
in
none
of
the
incremental
payloads
that
we've
received
until
later,
but
the
first
incremental
payload
has
some
like
it
could
have
some
shared
payload
as
the
server
like
the
current
server
executable
design.
B
Has
it
so
that
each
time
that
there
is
a
potentially
shared
deferred
payload
that
you
basically
split
it
into
its
own
pointer
and
like
even
in
the
current
design,
the
not
this
design
but
like
the
one
that
yaakov
has
built
and
Jacob
and
Rob
built
like
the
we
have
these
pointers
they're
just
sitting
there
as
flattened
lists,
essentially
rather
than
as
like,
like
they're,
flattened
lists
that
contain
a
tree,
but
looking
up,
my
real
problem
is
like
looking
up
finding
the
exact
item
that
corresponds
to
the
place
where
I've
deferred
is
difficult
and
I.
B
Think
something
along
these
lines
where
we
could
have
some
pointer
know
where
that
pointer
is
and
then
like,
have
the
incremental
payload
be
a
map
of
which
pointers
we
have
and
what
the
subtree
is
and
potentially
pointers
inside
of
that
map.
B
That
would
allow
like
a
very
that,
would
allow
a
pretty
naive,
client
algorithm
of
just
like
walk
when
you
see
the
defer
payload
see
if
it's
in
any
of
the
incremental
Maps,
if
it
is
not,
then
like
you're
still
waiting
for
it.
Otherwise
it's
there
and
like
you,
can
keep
walking
from
that
point.
B
C
Yeah
yeah,
it
makes
sense
just
like
to
start
with
the
low
hanging
fruit.
This
this
version
injects
some
data
into
into
Data.
B
Yeah
we
could.
We
could
avoid
that
I
think,
but
that
even
Ivan
last
during
the
working
group
was
like
if
we
could
somehow
get
the
injected
value
in
that
just
it
simplifies
so
much
Downstream
in
terms
of
the
response
format.
But
if
we
can't
we
can't
okay
Yakov.
D
D
Unless
they,
you
know,
you
know,
obviously
they
have
knowledge
of
the
individual
operation
and
the
schema
so
they
could
have
pronounced,
but
just
looking
at
the
so
just
looking
at
the
the
response,
you
know
very
very
naively,
you
would
have
to
walk
the
the
payload
to
look
for
those,
so
I
posted
an
idea.
D
Maybe
that
might
address
some
of
your
concerns
in
the
Discord
chat
that
I
that
I
just
dumped
into
this
chat,
also
where
basically
I
don't
know
if,
if
people
basically,
there
was
the
comment
that
I
that
I
made
for
the
completed
array
that
we
could
also
use
for
pending,
meaning
we
could,
we
could
basically
create
like
a
separate
tree
of
just
the
pending
defers.
D
We
would
still
have
to
embed
some
special
characters
for
the
completed
we
were
talking
about
a
plus
sign
and
and
for
def
for
the
pending
I
was
talking
I
used
in
the
in
the
chat
that
I
just
dumped
in
I
used
a
minus
sign,
because
you
could
have
a
defer
at
some
level,
and
then
you
could
have
some
nested
defers
as
well,
but
I
I,
I,
I
I,
don't
know
if
I
get.
If
you
have
time
to
take
a
look
now
or
I
could
walk
everyone
through
it.
D
Basically
in
terms
of
what
that
example
would
be,
but
it
it
basically
is
a
way
to
build
up
the
you
know
each
payload
from
from
its
components-
and
it
has
the
downside
of
of
well,
it
never
repeats
leaves.
It
certainly
does
repeat
subpaths
as
well,
and
it
has
another
little
bit
of
A
Wrinkle
in
that
the
original
data
will
get
broken
up
into
fragments
as
as
well.
C
Did
your
I
think
your
example
got
cut
off
in
the
chat.
E
E
In
your
examples,
in
your
example,
I'm
just
trying
to
read
through
it
makes
sense
a
bit
now.
You've
got
the
pending
zero
one
and
then
you've
got
incremental
with
the
keys
one
and
two.
Oh,
that
I
see
the
two
now
I'm
looking
at
Rob
screen
I
can
see
it.
It's
the
defer.
A
that's
embedded
has
a
value
of
t.
A
C
A
C
I
haven't
had
a
ton
of
time
to
to
think
through
it,
but
but
just
like
overall,
like
getting
around
the
problem
of
injecting
data
I
feel
like
it
would
either
be.
You
somehow
put
that
data
in
a
parallel
tree
somewhere
or
you
have
a
new
double
under
field
that
you
could
query,
but
but
I
think
the
problem
would
be
that
when
you
have
these
overlapping
Fields,
you
would
basically
need
to
put
that
double
under
like
everywhere
right,
because
it's
not
necessarily
going
to
line
up
with
where
the
originally
I
was
thinking.
C
A
B
Right,
it's
right,
I
I
agree
here,
the
like
so
I've
tried
to
keep
the
labels
and
whatever,
but
right
the
double
under
defer.
A
showing
up
twice
is
weird
I,
don't
know
how
to
get
around
that
if
we
preserve
the
server
only
sends
like
the
server
deduplicates
portions
of
the
response.
A
A
C
E
E
Is
I
wonder
if
we're
optimizing
for
the
wrong
thing,
because,
with
the
with
the
flow
of
where
you
effectively
just
apply
the
append
only
patches,
sure,
there's
there's
mutation
involved,
but
you're
doing
it
once
a
re
reading
from
the
network
time
and
then
it
is
done,
whereas
in
this
style,
if
you're
I
mean
you
could
still
do
the
same
thing.
E
But
if
you're
encouraging
clients
to
to
read
from
it
this
tree
and
build
it
up
each
time
a
component
renders
or
something
you're
doing
that
work
over
and
over
and
over
again
and
I.
Think
that
that's
not
necessarily
something
we
should
encourage.
B
So
redoing
the
work
over
and
over
and
over
again
that,
like
that,
is
the
react
model
right
flow
from
the
top
I
mean
it's
like
react
is
smarter
in
that
it
does.
Calculations
of
oh,
this
subtree
is
doesn't
actually
need
to
be
re-rendered.
The
subtree
actually
is
the
exact
same
but
like
at
its
core
that
it's
just
like
start
from
the
top
pass.
B
All
the
new
props
through
and
re-render
inflow
flow
flow
to
the
leaves,
basically,
every
time
like
every
time
data
it
updates
go
to
the
top
and
re-render
all
the
way
through
and
like
that
is
actually
our
native
clients
that
is
so
relay
doesn't
really
do
that,
but
our
native
clients
have
that
exact
model
where
we
only
have
a
single
subscription
at
the
top
and
even
for
defer
and
stream
every
time.
There's
a
new
deferrer
stream
payload.
B
E
B
B
Although
we
are
our
native
clients
have
a
bug
where
figuring
out,
the
local
part
is
hard
which
I
want
to
fix,
and
but,
like
part
of
part
of
the
reason
why
like,
if
you
have
to
continually
mutate
a
store
you
that
actually
forces
that
from
the
top
re-render
every
time,
because
the
it's
the
top
level
item
that
has
the
that
has
the
store
and,
like
you
don't
know
where
in.
B
If
you
don't
know
whether
your
component
is
affected
by
that,
like
you,
can
only
know
whether
your
component
is
affected
by
a
change
to
the
overall
response
store
by
essentially
walking
the
the
full
response.
E
Okay
separate
question:
it
looks
to
me,
like
you,
could
build
this.
These
objects
from
the
objects
that
were
previously
proposed
by
looking
at
the
the
pending
objects
and
applying
you
know,
building
the
the
little
in
lines.
E
B
B
If
we
assume
that
you're
going
to
get
a
lot
of
incremental
payloads,
which
maybe
will
maybe
won't
like
it's
fine,
especially
for
the
spec
to
have
yeah,
essentially
the
like,
pending
with
the
paths
like
I,
don't
in
the
completed
I,
don't
think
you
necessarily
need
the
double
underscore
that
was
just
like.
B
This
provides
a
very
concrete
pointer
into
it,
but
I
do
think
you
probably
and
I
think
I
failed
to
add
the
pending
payloads
in
the
incremental
responses
that
we
would
need
if
we
didn't
have
the
double
underscores,
but
even
depending
like
okay.
Here
are
the
two
IDs
that
are
pending
here's
their
paths
and
then,
in
the
second
incremental
response
we
would
still
have
a
pending.
Oh,
we
wouldn't
have
a
pending
two
I
guess
we
would
actually
have
a
potentially
if
we
didn't
have
the
double
underscores.
B
C
It's
Shifting
the
IDS
from
being
like
this
is
the
ID
for
that
defer
label
path.
Combo,
like
this
specific
defer
to
referring
to
the
ACT
to
the
incremental
data.
B
Yeah
and
the
real,
the
real
tricky
bit
I
think
is
figuring
out
because
I
think
the
final
response,
if
we,
if
we
don't
have
the
double
underscores,
the
final
incremental
payload
also
needs
in
it
doesn't
necessarily
need
a
maybe
pending
is
the
wrong
word,
but
like
deferred
pointers
where
right,
it
also
needs
a
deferred
pointer
back
to
two,
even
though
two
has
already
come
like
the
final
payload
means
to
say:
hey
there
like
there
is
an
ad
defer
at
this
path
and
that
at
defer
actually
points
back
to
or
like
there
is
a
deferred
payload
at
this
path
and
when
you're
looking
up
that
deferred
payload,
you
got
to
go
back
to
the
tube,
because
otherwise
the
fields
aren't
going
to
be
there,
like.
D
So,
if
Rob,
if
you
refresh
on
that
gist,
I
think
I
hope,
there's
a
comment
there.
Now
that
has
the
full
example
and
I
think
it's
basically
along
the
lines
of
what
you
want.
D
So
basically
we
have.
The
initial
result
is
a
little
bit
different
because
it's,
but
it's
also
separated
into
fragment,
fragments
that
can
then
be
reused.
Fragments
of
data-
and
this
is
this-
just
demonstrates
defer
and
not
stream
I
haven't
thought
too
much
about
how
stream
would
fit
into
it.
D
But
basically
the
idea
is
sort
of
I
think
what
Rob
alluded
to.
We
have
ideas
both
both
for
fragments
and
for
the
incremental
results,
and
we
give
like
all
the
information
that
we
have
meaning
as
each
Frac.
We
only
give
fragments,
as
you
know,
when
they're
when
it
when
an
incremental
result
is
completely
completed.
D
We
only
emit
the
fragments
at
that
point,
but
once
we
do,
we
tell
the
CL
the
client
all
the
result,
IDs
that
it's
eventually
we
give
a
preview
of
like
all
the
result,
ideas
that
this
is
assigned
to
and
that
way
they
can
keep
track.
You
know
to
only
hold
on
to
them
for
as
long
as
as
necessary
and
so
and
then
so
for
the
first
result.
D
In
this
example,
we
have
two.
We
have.
The
common
fields
between
the
initial
results
is
going
to
be
fragment,
ID,
F0
and
then
F1
is
that
leaf
I?
That
only
shows
up
in
the
initial
results,
and
then
we
say
that
there's
a
pending.
Now
we
have
a
map
here,
there's
just
one
example,
but
in
a
more
complicated
example
you
could
have
fields
and
then-
and-
and
you
know
listed
under
that-
and
that
minus
says
that
a
minus
says
that
you
could.
D
You
know
we'll
expect
something
if
something
subtracted
I
guess
from
the
end
result
it's
kind
of
the
the
mental
model,
but
that's
the
defer,
that's
going
to
be
showing
up
and
it's
going
to
be
called
R1
and
so
and
so
then
the
next
result
that
comes
through
R1
says
to
reuse.
Some
of
the
fragments
you
know
at
the
root
we're
going
to
reuse
F0,
and
then
we
have
a
new
fragment
F2
that
is
sent
now
and
then
and
then
we
have
a
new
bra.
D
You
know
a
new
Leaf
F3
at
that
at
that
that
new
Leaf
J,
so
I
think
I
mean
basically
we're
repeating
some
of
the
insertions
like
F0,
is
repeated
twice.
So
if
someone
doesn't
have
meaning,
if
you're
just
trying
to
update
a
store,
then
you
could
keep
track.
If
you
already
inserted
F0,
you
don't
need
to
also
it's
non-destructive.
So
if
you
wanted
to,
you
could
just
well
actually,
no,
it
would
be
destructive
at
that
point.
So
you
know
if
you're
updating
a
store
you
don't
want
to.
D
If
you
inserted
F0
it
would
rewrite
what
was
already
inserted
under
F1.
So
that
would
be
dangerous,
so
you
would
only
be
able
to
insert
the
first
time,
and
that
would
be
like
a
different
algorithm,
but
it
has
all
the
information.
You
know
additional
information
that
allows
you
to
have
different
client,
algorithms.
D
I'm
sorry
I
didn't
see
Matt
what
you
wrote
over
there.
So
I
commented
in
the
Discord
I
I
could
have
commented
earlier,
but
I
guess
I
was
still
working
it
out.
To
be
honest,.
D
D
That's
kind
of
annoying.
We
didn't
need
to
do
that
with
the
pure
insert
only
model,
but
now
we,
but
now
we
do
so.
B
That
feels
that
feels
like
it
will
almost
immediately
cause,
and
maybe
it's
I'm
getting
hung
up
on
fragment
ID
because
they're
not
actually
it's
like
compiled
out.
It's
like
compiler
Frick,.
D
So,
on
the
on
the
execution
side,
they're
called
like
group
field
sets,
or
you
know
so:
okay
they're,
not
they're,
not
really
they're,
not
really
fragments,
and
we
should
probably
rename
that
here
also,
but
I
was
just
whipping
this
up.
Yeah.
D
And
the
idea
would
be
that
also
when
the
Deferred
payloads
come
in,
you
know
you
can
read
from
that
map
exactly
what's
in
it,
you
don't
get
any
excess
Fields,
there's
nothing
in
that
map.
That
was
like
already
delivered
belonging
to
a
different
fragment,
and
so
you
have
sort
of
you
know
local,
correct,
no
local,
completeness
and
so
local
exactness.
D
C
Just
to
like
take
a
step
back
do
do
we
do.
We
all
agree
that,
like
we
shouldn't
inject
additional
like
metadata
Fields
into
any
kind
of
like
data
response,
I
could
I
think
you.
You
definitely
can't
do
a
double
underscore,
because
that
could
be
a
valid
field.
You
are
allowed
to
Alias
any.
You
can't
have
a
double
underscore
as
part
of
like
a
regular
field,
but
you
can
Alias
something
to
it
and
then
but
then
even
anything
else
gets
tricky.
C
E
Just
to
respond
to
that
Rob
I
think
that
there
should
be
an
extremely
high
barrier
for
entry
for
adding
keys
in
line,
but
I,
don't
think
that
we
should
entirely
rule
it
out.
Secondly,
we
can
use
external
data,
so
we
already
have
this
pending
field.
E
If
the
pending
field
references
where
these
special
inline
keys
are,
then
they
won't
or
they
can
be
disambiguated
against
confusion
with
custom
scalers
and
further
than
that,
like
I
just
said
in
the
the
chat,
I
think
it's
essential
that
if
we
were
to
put
these
little
placeholder
keys
in
line,
we
should
also
reference
them
in
an
external
array
to
save
clients
from
having
to
scan
through
every
single
key,
deeply
nested
in
a
in
an
incoming
field
in
order
to
process
it
so
I
think
that
by
having
this
necessary
pending,
we
can
not
worry
about
the
custom
scalers
issue,
so
I
don't
see
there
being
a
very
significant.
E
E
D
Yeah,
so
when
you
know
an
example
that
I'm
showing
over
here,
there
are
never
any
like
double
underscores
or
pluses
or
minuses
inside
the
data.
That's
inside
fragments
there
is
a
field
called
Data
inside
completed,
but
those
are
just
kind
of
sub.
That's
like
a
subpath
map,
Ford's
actual
data,
it
Network
it
should
never
have
any
leaves
in
it.
If
I.
If
I
have
that
correct,
is
this
and
so.
D
Correct
those
special
characters
inside
that
data
there
should
never
be
any
leaves
I
mean
you
can
meaning
you'll.
Never
we're
talking
about
where
to
insert
you
know,
fragment,
fragments
or
for
group
field
sets,
but
we're
always
inserting
into
an
object
field.
So
there
are
never
any
you
know
leaves
or
leaves
over
there,
and
so
you
should
never
get
any
confusion
with
custom.
Scalers.
E
D
Essentially,
yeah
I
mean
I
I
think
it
makes
naturally
I
would
call
it
data,
because
it's
it's
a
it's.
You
know
it's
going
to
be
the
data
after
you
follow
all
the
insertions,
but
it
it's
not
not.
It's
not
quite
data,
maybe
a
better
name
for
that.
Also,
probably
once
we're
through
with
this
we'll
have
a
better
name
for
all
of
these
fields,
but
I
think
the
structure.
E
So,
just
to
make
sure
that
I
understand
what
you're
saying
yaakov.
Are
you
saying
that
you
would
always
have
that
field
C
F
in
like
the
original
fragments
entry?
So
that's
how
the
client
knows
it's
an
object
because
it
was
given
it
without
any
of
the
the
pluses
in
line
and
then
the
pluses
come
later.
D
Yeah
well,
a
deferred
was
that
once
we
have
a
deferred
result,
all
of
the
leaves
will
show
up,
meaning
that
oh
these,
these
paths,
essentially
that
are
in
data,
is
really
a
a
tree
of
IDs
and
subpaths
from
the
other
proposal,
meaning
that
make
up
this
completed
and
it's
a
it's
a.
D
So
it's
a
they're
all
basically
like
pointers
back
to
the
individual
incremental
items
from
our
old
proposal,
and
so
just
like
in
you
know
the
the
paths
to
to
an
incremental
payload
when
the
sub
paths
never
had
any
leaves
in
it.
You
know
that
it
just
so
too,
or
this
you
know
the
the
the
the
entries
in
this
in
this
map
will
never
have
any
leads
in
it.
E
Right,
so
this
this
data
that
Rob's
got
highlight
is
more
template.
It's
more
a
template!
Yes,
yes,
got
it!
Okay!
Thank
you.
D
Which
is
which
is
not
to
say,
there's
not
a
better.
You
know
a
different,
better
solution,
but
it's
only
to
say
that
I
agree
with
what
you
said
Benji
and
what
you
said:
Rob
that
that
we
can
insert
it
into
actual
data.
You
know,
that's
all
you
know
it
could
be
a
better
solution.
Still.
E
One
of
them
is
that
the
order
of
the
incremental
payloads
is
significant,
which
is
why
it's
a
list
currently,
but
if
we
do
it
as
an
object,
that's
still
fine
with
the
pointers
in
place,
because
hopefully
we
would
ensure
that
the
pointers
resolved
in
the
right
order.
But
if
not,
the
client
could
detect
that
and
another
Advantage
I
think
that
would
apply
to
Matt's
proposal
is
that
we
would
be
able
to
restore
the
ordered
Fields.
E
So
I
was
saying
in
the
working
group
on
Thursday
that
one
issue
with
all
the
the
stream
interferred
proposals
at
the
moment
is
that
if
you
have
a
selection
set
ABC
where
the
B
is
deferred,
then
at
the
moment
it
would
always
come
out
as
AC
and
then
the
B,
because
that
comes
later
and
things
get
more
complicated.
E
When
you
add
more
deferred
things,
because
they,
depending
on
the
order
in
which
they
complete
the
field
order,
would
not
be
maintained,
which
is
quite
a
breach
from
what
we
currently
have
in
the
in
the
spec
itself,
where
we
guarantee
the
order
of
the
fields
so
having
these
in-line
placeholders
be
able
to
ensure
that
once
you've
stitched
everything
back
together
again,
the
fields
are
still
in
the
same
order.
That's
actually
quite
a
neat
thing
and
it's
something.
Definitely
in
its
favor.
B
I
I
think
I
have
an
example
where
we
could
get
away
without
using
the
double
underscores.
Let
me
just
post
that
in
the
just
in
a
sec.
A
B
Think
that
that's
mostly
right
so
I
just
posted
in
the
gist,
where
basically
oh,
shoot,
I
messed
that
up.
Let
me
edit
I
kept
it
in
a
double
underscore
that
doesn't
need
to
be
there
yeah,
but
yeah.
Basically,
the
idea
here
is
like.
Yes,
we
keep
the
paths
for
the
defer
which
Maybe
a
tricky
bit
is.
Maybe
the
like
I'm,
not
sure
whether
the
defer's
payload
like
saying
what
is
deferred
should
be
a
map
on
ID
or
inverted.
It
probably
needs
to
be
inverted
actually,
where
the
path
is
the
lookup
value.
B
Now
that
I
think
about
it,
because
that's
what
you're
going
to
want
to
right,
you're
going
to
want
to
walk
to
where
the
actual
path
is
from
this
point
in
the
data
yeah,
so
the
defers
might
have
to
become
a
tree
but
and
I
think
that
that
gets
pretty
similar
to
yakov's
proposal
without
changing
the
structure
of
like
adding
selection
set,
fragments,
specifically
I,
don't
think
we
need
those
but
yeah.
Basically,
each
incremental
payload
that
has
its
own
pointer
could
itself
have
inner
defers
that
it
needs
to
like.
B
Oh,
this
is
the
tree
that
we
are
looking
for
for
deferred
payloads,
and
that
does
like
that
does
introduce
a
second
tree
to
walk,
but
it
at
least
is
a
very
clear
like
tree
path
and
yeah.
Now
that
I'm
actually
looking
at
it
I
do
think.
B
C
From
the
path
is
relative
to
where
right.
B
Yeah
yeah
I
would
edit
the
just
and
I
can
or
I
can
repost
or
whatever,
but
yeah
and
edit
the
gist
to.
C
B
Yeah,
or
or
or
you
do
have
to
preserve
a
path
as
you're
walking
and
if
you
as
the
client
know
ho
okay
I
need
to
see,
is
this
like
I
know
that
there's
a
defer
here
do
I
have
the
data
for
it.
Okay,
you
walk
through
and
you
can
say.
Okay,
these
are
the.
This
is
the
defer
at
this
point.
Given
this
path,
this
is
and
like
you,
it's
still
a
linear
walk,
but
it's
only
a
linear
walk.
E
B
As
you
know,
the
path
that
you're
walking,
you
only
have
to
look
up
in
deep
levels,
whereas
with
the
list
path,
you
basically
need
to
for
each
item
in
the
list.
You
need
to
walk
through
the
entire
structure.
C
Yeah,
should
we
edit
this
now
just
to
I
I,
can
do
it
it
just
it.
Yeah
I
got
it.
We
can
see
if
I'm
understanding
what
you're
saying.
C
B
D
What's
the
property
name
for
that.
E
B
B
B
B
Because
that's
like
array
yeah,
because.
B
Sorry,
this
probably
needs
some,
it's
nothing
that
it
could
be
a
list.
It
could
be.
We
just
use
underscore
underscore
or
like
minus
or
Plus
or
whatever
for
items
that
are
at
the
top
level,
probably
plus,
probably
that
makes
sense
or
something
or
just
like
empty,
an
empty
key
or
something.
C
Yeah-
and
it
would
be
good
to
think
about
if
this
was
not
just
for
defers
and
also
could
tell
you
that
for
you're
waiting
for
stream
items,
yeah
yeah,
let
me
just
cancel
this
bye,
but
yeah
I.
Think.
B
Yeah
exactly
yeah,
but
is
there
any
like.
C
I
I
do
like
this
one
I
think
that,
because
it's
it's
basically
the
same
as
what
we
have
it's
just
really
just
changing
pending
in
a
small
way
putting
it
inside
of
the
incrementals.
So
you
it's
so
it's
more
of
a
pointer
having
it
as
a
tree,
so
you
can
Traverse
it
better.
C
I
mean
I
mean
I.
Do
think
that
just
like
there's
more
human
overhead
so
like
looking
at
for
for
all
these
examples
like
looking
at
it
and
understanding
what's
going
on,
but
that's
probably
fine
if
we
have
performance,
wins
in
the
client
yeah.
That's
that's
my
thoughts
right
now.
E
I'd
I'd
like
to
see
the
the
final
payloads
before
passing
up
judgment,
because
at
the
moment
I'm
a
little
bit
lost.
D
E
D
For
my
example,
I
I,
if
you
reload
it
I
refreshed
it
I
renamed,
fragments
to
segments
which
sounds
weird,
but
but
it's
always
different
and
then
I
also
I
changed
data
to
just
the
word
use,
and
the
idea
is
that
you're
in
a
it's,
a
map
to
how
you
use
those
segments
so
and
I
think
it
gets
it.
Basically,
it
has
more
changes,
obviously,
but
I
think
it
gets
at
what
your
you
know.
D
I
mean
I,
guess
it
shows
that
you
know
we
can
do
this
and
that
what
some
of
the
downsides
are
some
of
the
downsides
are
that
we
we,
we
won't
repeat,
sending
a
segment
or
you
know
or
a
leaf,
but
we
will
repeat,
we
will
repeat
that.
D
You
know
that
we're
that
we're
using
it
I
also
added.
You
know,
sort
of
exactness.
You
know
so
that
they're,
never
you
can
all
you
can.
Never.
You
can
tell
that.
You
know
you'll,
never
by
accident
reference
field
that
was
previously
sent
just
because
it
was
previously
sent
it.
D
You
can
tell
you
know
which
fragment
it
belongs
to,
but
that
you
know
Matt,
as
you
pointed
out,
results
in
you
know
more
of
these
segments,
which
is
possibly
not
desirable,
so
those
are
two
of
the
downsides
overall,
like
I,
think
I
get
why
you
know
I've
just
been
trying
to
think
about
more
I.
Get
why
you
know
you
want
a
you
know.
Immutable
version
of
this
I
think
that's
the
you
know,
I
sort
of
have
been
coming
around
to
that
I'm,
just
sort
of
wondering.
D
If
you
know
we
can't
you
know,
shim
something
yeah
on
top
of
what
we
or
what
we
already
have,
but
I'm,
okay,
you
know,
I
think
it's
like
sort
of
how
to
package
the
data,
but
basically
you
know
I'm,
okay,
with
whichever
the
group
decides
makes
sense
or
what
that's
worth.
B
Yeah
and
I
do
think
there's
value
in
just
like
readability.
So
if,
if
all
of
these,
like
okay,
we
can
have
direct
pointers.
If
all
of
these
end
up
resulting
in
you
know
huge
payload,
bloat,
huge
readability
issues
compared
to
just
like
having
the
list
and
having
the
pending
and
having
like
I
because
like
because
the
spec
response
format
is
kind,
is
really
designed
to
be
readable
and
like
grockable,
like,
even
even
like
our
intro
graphql
course
at
meta
has
like.
B
B
If,
like
you,
have
a
client
that
needs
a
lot
of
performance,
yeah
you'd
shim,
something
underneath
like
if
it
means
that
we
are
getting
a
substantially
like
more
possible,
more
readable
format,
but
I
wasn't
confident
that
we
that
the
immutable
format
was
necessarily
less
readable
than
the
mutable
one.
Basically,.
B
Guess
basically,
we
should
always
feel
free
to
pop
the
stack
like
every
time
we
adding
some
complexity
here,
we're
like
trying
to
resolve
some
complexity,
some
ambiguity,
some
and
it's
okay
to
say
we
went
down
that
path
and
it
doesn't
feel
right
so
we're
popping
and
like
we're
just
not
going
to
try
to
solve
it.
That
way
and
I
would
even
encourage
like
if,
like
from
my
perspective,
if
we
can
get
the
readability
even
with
like
response
format,
duplication
like
I've
always
been
more
or
less
like
it's
okay
to
have
large
responses.
B
If
that
means
that
they're
very
readable,
where
the
client
and
server
could
opt
into
a
more
compact
format,
if
they
really
need
those
like
strong
performance
wins,
but
the
spec
is
about
explaining
like
what
needs
to
be
possible.
A
C
C
Seems
like
we're
good
yeah,
I
I'm,
actually
not
going
to
be
able
to
make
next
Monday.
So
maybe
we
should
cancel
it
or.
B
C
And
and
I
know
that
Yakov
has
been
working
on
his
implementation
of
what's
described
at
the
top
of
that
gist
and
I
will
spend
some
more
time
reviewing
it
and
I.
Think
that
see
like
how
much
of
that
we
can
get
merged
into
made
of
graphql.js,
because
it's
it's
only
an
improvement
over.
What's
there
now
and
is
closer
to
the
direction
we're
heading,
so
I'm
gonna
try
to
spend
some
time
reviewing
it.
E
All
right,
well
great
chatting
with
you
all
Benji,
enjoy
the
rest
of
your
your
party
day
off
thanks.