►
From YouTube: Incremental Delivery Working Group - 2023-01-23
Description
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. Get Started Here: https://graphql.org/
B
C
So
it's
all
of
us
right
without
you
here.
B
All
right,
yeah,
why
don't
we
get
started?
Yvonne,
you
just
posted
a
proposal.
Do
you
want
to
walk
everyone
through
that.
D
C
It's
like,
but
that
I
cannot
like
uncoops
it.
It's
a
GitHub
like
make
it
scrollable,
but
basically
idea
is
actually
like.
I
discussed
this
proposal
previously
and
that's
when
it's
like
for
the
iteration
on
this
solution,
but
basic
idea.
What
what
if
we
we
say
like.
C
I
will
first
try
to
explain
like
idea
behind
it
and
one
to
like
the
whole
payload
of
the
whole
shape
of
the
word.
I
idea
is
that,
right
now
we
do
initial
response
and
one
response
and
one
additional
payroll
per
path,
and
you
need
to
do
in
order
to
get
like
a
full
data,
because
data
shoots
the
duplicated
between
initial
response
and
default
part.
You
need
to
do
much
anyway,
so
clients
need
to
implement
like
Merchant
anyway
so
code,
those
already
their
price
is
paid.
C
Why
why
we
should
stick
to
only
one
pay,
what
per
pop?
What
if
we
are
all
clients
to
send
multiply
by
watts
per
path
and
use
completed
field
which
we
want
to
use
for
stream
anyway,
with
the
same
semantic?
So
what
happening
here
so
in
tricky
example,
B
ABCD
is
easy
part,
so
it
shift
in
initial
response,
so
yeah.
It
should
hear
when
we
go
to
a
tricky
part,
and
we
have
like
enf
that
shared
between
two
of
them
and
potentially
small
field
and
G
and
H
are
potential
disorder
field.
C
C
Server,
smart
enough
to
to
figure
out
like
several
can
do
two
strategies:
server
can
send
like
a
Fields
as
fast
as
they
resolved
or
server
can
be
smart
and,
for
example,
I
calculate
this
intersection.
I,
don't
know
what's
more
efficient
than
what
we
strive
for,
but
it
doesn't
influence
the
proposal
here
so
proposal
here
is
like,
for
example,
all
the
stuff
is
slow,
as
name
of
field
suggests,
so
after
initial
period
EMF
resolved.
C
So
in
in
current
proposal,
we
cannot
do
anything
until
like
at
least
one
of
four
Fields
resolved,
and
only
one
will
ship
something,
but
here
what?
If
we
can
supply
multiple?
It's
mean
like
we
send
EF
next
question.
Under
which
path?
Should
we
send
EF
under
path,
a
b
or
under
path
under
root
path?
And
after
after
thinking
about
it,
root
path?
Wins
it's
essential
magic,
as
we
do
like
fulfilled
much
and
basically
right
outer
scope,
always
win,
so
we
ship
EF
under
incremental
with
like
empty
bar,
and
we
ship
the
f.
C
Nothing
is
completed
here
like
which
buffer
is
not
completed.
We
just
shipped
part
of
it.
This
part
should
be
merged
with
the
initial
response.
C
When
suppose
like
order
can
be
different,
but
for
this
example
suppose
field
a
result
first,
so
we
ship
it
under
path,
a
b
and
they're,
basically
with
the
Third,
because
it
doesn't
use
in
any
other
differs.
So
we
shift
potentially
so
field
a
Under,
A
and
B,
and
we
mark
it
as
completed
because
previous
payroll.
C
Solved
it
so
like
missing
part
and
last
thing:
we
still
have
GH
and
potentially
so
field
B,
and
we
shift
it
under
like
the
root
path
and
we
also
Mark
it
Complete,
because
everything
is
resolved.
One
thing
I
was
like
trying
to
rush
and
make
it
fast.
I
put
it
on
the
increment,
all
the
free
pivots
and
the
same
incremental.
Just
imagine
I
will
correct
my
Comma
just
to
mention
it's
like
three
different
Pilots
here
is
my
basic
proposal
and
I
can
do
screen,
sharing
a
stop
screen
sharing
yeah
so.
B
C
Here,
like
my
I'm,
like
it
doesn't
fit
out
on,
should
we
do
it?
Should
we
do
like
determinist,
or
should
we
I
will
server
to
Break
Stuff?
One
thing
clears
it's
like
common
part
either
should
be
like
it
should
not
be
like
interlock,
as
we
discussed
with
Michael
previously,
so
like
implementation
should
be
able
to
send
it
stuff
that
is
ready
and
is
common
part
of
the
stuff.
So.
C
Separate
Fields
it
can
ship
separate
Fields.
If
we
decide
that
it's
problematic,
we
can
change
it
to
like
deterministic
order.
Key
question
here
is
like
the
Only:
Rule
is
top
level
wins,
which
is
the
same.
It's
like
it's
the
same
row
as
we
have
like
with
the
initial
response
so
and
it's
all
kind
of
present
logic,
but
on
the
same
level,
which
fields
are
sound
like
you
can
do
potentially
small
field
a
first
and
one
potential
is
for
field
B
and
vice
versa.
We
don't
know
it's
like
non.
C
A
Yeah
I'm
trying
to
work
out
what
the
value
is
of
the
completed
it
doesn't
seem
to
correlate
really
with
the
fragments
themselves,
so
right
yeah,
it
tells
you
that
the
path
is
completed,
but
I
don't
understand
why.
That
is
useful.
What
is
what
is
the
use
case
for
that?
What's
the
value
that
we're
getting
from
from
informing
us
that.
C
We
can
basically
it's
related
to
to
issue
we
discussed
with
bonoa,
so
in
code
generation.
You
need
to
know
where
one
particular
fragment
is
resolved
or
not
like.
If,
if
you
have
enough
data
for
particular
fragment
technically,
you
can
check
like
presence
of
a
field.
D
C
C
A
You
can
it
doesn't
necessarily
solve
that
because
it
doesn't
relate
to
fragments
it
relates
to
paths.
So
if
you
take
your
example
and
the
the
problematic
query,
the
bottom
defer
that's
at
the
root
level.
If
you
imagine
that
as
just
a
fragment-
and
we
want
to
know
when
that's
completed,
you
could,
if
you
take
your
incremental
responses,
that
you've
put
and,
as
you
say,
split
them
up
into
separate
incrementals.
A
Described
before,
if
you
swap
the
order
of
the
second
and
third
payloads
in
that
incremental,
then
after
the
second
payload,
that
fragment
is
complete.
But
there
is
no
information
to
the
client
telling
them
that
fragment
that
you
requested
is
complete.
That
will
never
be
seen
as
complete
until
the
entire
query
is
complete,
with
what
is
currently
proposed
right,
because
the
root
level
path
is
not
complete.
C
C
C
A
I
I
think
I
see
what
you're
saying
so.
What
you're
saying
is,
after
in
my
scenario,
where
you
take
those
second
and
third
payloads,
and
you
reverse
them
on
the
second
one.
It
is
still
completed
because
that
defer
that
was
in
the
root
payload
is
completed.
Yeah.
C
Or
in
case
of
the
night,
since
we
because
we
remove
labels,
I,
have
proposal
of
how
to
reinstate
to
Able
kind
of
able
and
how
to
have
been
obvious
levels
and
but
that's
separate
one
I
I
decided
to
split
it
up
because
it's
independent,
but
currently
since
we
do
matching
of
stuff,
you
cannot.
You
cannot
complete
Fields
independently
a
complete
fragments
independently,
so
banoa
just
waits
for
until
he
gets
everything
on
the
level
and
say
like.
C
If
we
receive
everything
we
can
fulfill
all
the
fragments
to
make
to
communicate
to
quants
that
particular
fragment
is
resolved.
I
have
like
another
proposal,
I'm
working
on
so
yeah.
This
one
is
separate.
E
E
Do
you
see
those?
As
you
know,
you
know
me
I
mean
I,
guess
those
are
two
separate
things.
In
theory
we
could
be
sending
payloads
as
they're,
ready
and
I
can
still
allow
clients
to
sorry
servers
to
duplicate,
Fields
I.
Don't
know
why
we
would
do
that,
but
you
know
I,
don't
know
why
you
would
advocate
for
that.
E
But
basically
what
I'm
getting
at
is
I'm
wondering
if
this
feature
is
something
that
we
could
enable
as
like
as
like
an
argument
or
like
optional,
smarter
Behavior,
you
know
later
than
the
later
than
the
you
know,
the
initial
release
sort
of
like
how
we
said
that
we
could.
E
E
It
would
say
you
know,
you
know
something
like
send
when
ready
as
an
argument
and
if
that
was
sent
to
True
you
know
you
would
have
this
behavior
and
if
that
was
set
to
false
you
know
it
would
you
know
everything
would
you
know
you
know
would
be,
would
have
to
be
held
until
it's
ready
and
then
I
guess
there
wouldn't
be
a
use
for
a
completed
field,
and
you
would
see
like
if
that's
absence
you
would
assume
you
know
that
it
is
completed
or
maybe
you
would
change
completed
to
like
something
like
you
know.
E
You
know,
you
know
not
completed.
You
know
something
to
get
the
behave
semantics
right,
but
the
basic
idea
is,
it
sounds
like
this
is
something
that
might
be
useful,
but
it
might
not
necessarily
be
be
necessary
for
the
initial
release.
So
just
wondering
what
you
think
about
that
yeah.
C
C
Sorry
right,
my
electricity
went
down
yeah,
so
here
yeah,
but
you
cannot
see
me
and
yeah.
It's
good
investment,
optical
fiber,
every
time,
I'm
happy
and
recommend
to
everybody.
It's
work
without
electricity,
so
so
yeah
and
I
will
probably
disable
my
camera
because
it
doesn't
make
sense
so.
C
In
here,
like
use
case
is
clear:
it's
like
the
duplication
and
it's
like
for
me.
It's
basic
premise
of
graphql.
We
ship,
like
all
the
data
that
you
need
and
it's
like
motto
or
graphql,
and
when
we
suddenly
do
duplication,
it
depends
on
complexity.
If
complexity
is
small-
and
it's
like,
after
speaking
with
benowa
understood,
why
key
thing
that
made
me
I
had
this
idea
for
a
long
time.
But
what
triggered
me
is
that
talking
with
banoa,
you
need
to
do
matching
anywhere
in
the
client.
E
Quite
I'm
not
sure
I'm,
not
sure,
even
if
everyone
agrees
that
we
that
we,
that
we
have
to
do
deep
duplication
of
the
initial
response,
I'm
actually
not
sure
that
that's
the
case.
B
E
Mean
I
I
worked
on
the
pr
for
the
spec
and
I.
Would
the
feedback
that
I
got
was
that
we
should
take
all
deduplication
out
of
that
initial
spec
PR?
So
that's
what
you
know
allowing
it
Okay.
E
Let
me
correct:
let
me
correct
myself:
that's
actually
not
now
I'm,
remembering
the
feedback
I
got
was
that
deduplication
should
be
allowed
so
that,
actually
you
know
if
it's
allowed
by
the
server,
then
the
client
has
to
expect
to
potentially
deduplicated
response
so
that
you
know
so
I
guess
yeah.
No,
so
I
guess
you're,
I,
guess,
you're,
right,
I'm,
sorry,
I,
guess
you're
right,
we
would
have
to
do.
The
client
may
expect
a
deduplicate,
a
response.
C
So,
like
complexity
of
the
record,
is
there
like
benowa
how
I
it's
required
for
clients
to
do
like
patching?
It's
required
you
to
march
to
Json
at
some
form,
not
literally
Json,
but
some
representation
of
Json
to
merge
it
together,
and
it's
already
implemented
as
a
benefit.
We
will
receive
the
duplication
and
we
receive
like
potentially
server
can
like
for
few
certain
fragments
faster
and
it's
what.
C
Yeah,
it's
based
on
my
second
proposal
of
of
returning
the
label
in
different
form,
but
yeah
like
if
a
return
variable
labels,
and
in
that
case
we
we
receive
like
staff,
can
can
be
like
fulfilled
faster,
faster
than.
E
Right
but
but
the
reason
why
I
give
the
analogy
to
stream
is
that
it?
You
know,
let's
say
you
know
right
now:
we
have
to
deliver
streamed
items
in
order
and
let's
say
the
you
know,
the
last
streamed
item
in
a
very
long
list
is
slow.
Sorry,
the
first
streamed
item
in
a
very
long
list
is
is
slow,
but
everything
else
has
been
completed.
So
that
means
that
we
have
to
wait.
Potentially
I,
don't
know
an
hour
five
minutes.
E
You
know
some
really
long
time
to
even
start
streaming
the
lists
it
would
be
nice
if
we
could
stream
the
you
know
the
items
that
are
ready.
You
know
as
soon
as
they
are
because
you
know
ready,
because
then
you
know
the
whole
response
would
get
there
faster.
So
there's
an
argument
for
that
and
similarly
here
we
have
an
argument.
You
know
you
know
if
you
have
a
part
of
a
response,
that's
ready!
Why
not
just
send
it?
E
You
know
as
soon
as
it's
ready
and
then
when
and
then
we'll
signal
to
the
client
when
it
when
the
whole
thing
is
is
complete
and
it's
you
know
it's
a
similar
argument.
You
know
that
you
know
you
should
never
you
know
let
the
wire
be
empty.
We
should
always
be
sending
something,
but
you
know
it's
possible
that
you
it's
possible
that
clients
you
know
may
prefer
to
you
know
not
to
do
that
potentially
or
that
or
you
know
just
that.
E
That
might
be
a
feature
that
we
could
add
later
in
terms
of
deduplication.
I
agree
that
that
I
guess
would
be
ideal,
and
you
know
if
we
can
find
an
algorithm
to
do
it
cheaply.
You
know,
maybe
we
should
do
it,
but
I'm
just
wondering
meaning.
If
these
these
are
like
to
me.
These
are
extra
features
on
our
stream.
You
know
we
have
a
data
stream.
Could
we
make
it
deduplicated?
Could
we
allow?
You
know
you
know
to
you
know
to
be.
E
You
know
to
unlock
sending
parts
of
it
as
soon
as
they're,
ready,
I'm,
just
I'm
just
wondering
if,
if
we
could,
you
know
allow
make
these
things
opt
in,
or
at
least
not
delay
the
initial
release
of
these
features.
You
know
for
these
Advanced,
sorry
of
of
all
of
incremental
delivery,
for
these
Advanced
features.
C
Core
idea:
it's
organizational
now:
it's
not
not
technical,
but
your
question
is
organizational
methodology
called
Shape,
Up
I,
really
like
it
I
didn't
finish
the
book,
but
a
basic
idea.
You
say
how
much
time
you
okay
to
dedicate
to
a
feature.
It's
not
like
you're
doing
feature
to
to
to
the
end.
It's
like
you
say
these
features
work
like
one
week
of
my
time.
If
I
cannot
do
it
by
one
week,
let's
drop
it
so
I'm
I'm
like
have
the
same
idea
about
this
thing.
So
if
we,
if
I,
cannot
write.
C
Create
concrete
proposal
and
implementation
in
time
frame-
and
we
discussed
it
last
time
until
the
next
working
group-
it's
mean
it's
too
complex
to
do
now
and
we
can
figure
out
how
to
is
enable
Twitter
or,
like
totally
forget
about
it.
So
I'm
like
I'm,
also
for
cutting
features
but
I'm
treated
as
like
refinement
and
not
a
feature
of
stuff
that
we
try
to
do.
And
second
thing:
I
I
want
to
notebook
not
not
to
block
progress
and
progress
at
the
earliest
point
that
we
can
have
progress.
E
C
E
E
Might
not
want
this
feature
and
I
think
you
know.
I
I
can't
speak
to
everything,
but
just
but
but
I
mean
here
we
have,
you
know
basically
you're
going
to
be
doing
those
merges.
Every
time
you
receive
a
deferred
Frac.
You
know
they
start
with
the
current
implementation.
You're
gonna
be
doing
the
mergers.
Every
time
you
receive
a
completed,
fragment
you're
going
to
have
to
merge
an
additional
tree.
So
now
you
know,
if
you
send
incomplete
data,
you
will
have
to
do
more.
E
You
know
those
mergers
will
be
spread
out,
but
I
don't
think
it
should
be.
Have
really
is
spread
out
in
time,
but
because
you're
merging
subtrees
I,
don't
really
think
it
has
like
a
complexity,
you
know,
I,
don't
think
it's
really
has
an
additional
like
complexity,
cost
for
the
client.
So
I,
don't
think
that's
an
issue.
I
guess
one
issue
would
be
is
like
you
know.
If
you
want
to
use
the
wire
for
something
else
and
the
client
for
some
reason
doesn't
want.
You
know
data
until
it's
ready
for
some
reason.
E
You
know
because
they
want
to
they're
in
the
middle
of
some
other.
You
know
activity
but
I
I
mean
I,
get
I
mean
so
that's
I.
Guess
that's
I!
Guess
the
question
is
there?
Is
there
some
client
that
might
not
might
not
want
this
feature
and
honestly
I?
Don't
I
I'm
I'm
but
I
mean
I
I'm,
not
I.
Don't
have
a
clear
answer
on
that,
but
I
guess
that's
what
we
would
have
to
Define.
B
Yeah
sorry
I
mean
the
only
it's
it's
a
trade-off
of
we're
making
the
response
like
a
little
bit
more
complicated
to
understand
where
it's,
not
just.
You
got
to
play
a
payload
back
and
now
you
know
that
that
deferral
from
that
path
is
complete,
but
yeah
I
think
that's
the
main
trade-off
right
again
and
I
guess:
I
can't
think
of
another
reason
why
a
client
would
be
against
it
other
than
it's
slightly
more
work.
C
There
is
one
small
thing
and
I
will
add
comment
about
it.
Client
suppress
the
client
needed
to
do
matches
only
on
particular
path.
C
Saying
like
you
need
to
get
imagine
like
when
the
bench
a
proposal
of
pension
case,
support
method,
so
go
and
really
Advance
clients
that
want
to
really
save
resources
and
very
like
in
small
small
way,
but
still
optimization
Clan
can,
when
he
receive
panjang,
it
can
get
like
attached,
attach
parts
of
Json
initial
Json
to
IDs
and
drag
mattress
on
those
and
technically,
if
clients.
C
Decide
to
like
maintain
with
separate
copies
of
initial
response
separately,
not
not
shared
but
separately.
It
can
be
problem
because,
in
my
example,
top
level
staff
for
Fields,
like.
C
C
C
I
don't
see
it
as
like
big
benefit
and
somebody
actually
implementing
it,
but
it's
there
so
the
shorter
version.
You
need
to
track
changes
on
the
global
on
like
response
one
response
tree:
you
cannot
track
changes
per
fragment
on
separate
per
fragment,
trees.
B
Have
you
tried
implementing
implementing
this
on
the
server
or
do
you
have
like
a
an
idea
of
how
it
would
be
implemented.
C
What
What's
three
it's
like
last
last
week,
I
discussed
and
with
and
since
then
it's
like
short
iteration.
This
one
is
super
simple,
but
I
came
to
it
today.
So
I
did
not
have
the
chance
to
implement
it,
and
please
please
think
about
that.
Maybe
I
like
missing
something
and
there
is
like
a
Corner
cases
after
it,
but
I'm
like.
C
So
in
theory
it
should
work,
but
I
have
no
idea
how
to
implement
it
or
how
hard
it
would
be
to
informat
it.
So
I
will
I
plan
to
work
it,
or
maybe
we
can
work
together
with
yaakov
if
yako
wants
to
help
because
experimenting
a
lot
in
this
field,
so
not
yet,
but
I,
don't
think
it
would
be
super
super
complicated
implementation.
C
Next
small
question
I
wanted
to
ask
I
wanted
actually
to
write
it,
but
yeah
I
didn't
have
enough
time
today.
I
idea
is
that
What
If
instead
of
labels,
we
can
use
fragment
names
plus
buff.
C
What
I
realized
we
don't
need
to
like
if
you
don't
care
about
naming
your
inline
fragment,
wait
in
most
cases,
code,
gen
and
other
stuff,
don't
care
about
inline
fragments,
but
they
care
about
named
fragment,
at
least
like
from
vanua.
Implementations,
cares
about
fragment,
with
names
and
assume,
see
more
clients.
C
The
co-generation
of
stuff
care,
about
default,
fragments
with
names
and
what's
unique,
is
that
fragment
name
plus
path
is
unique
combination,
so
you
know
for
sure,
even
if
fragment
is
reused
inside
other
fragment,
we
still
know
like
if
you
have
enough
data
to
fulfill
this
fragment
or
not
so.
C
Ideas
here
is
to
to.
C
Until
we
have
like
field
for
field
fragments
and
write
like
names
of
fragments
that
was
fulfilled
by
particular
payload,
even
if
complete
is
false,
so
imagine
your
ship
like
some
fields
on
west
row
and
say
like
a
field
fragments
and
list
the
name
of
a
field
fragments
or
or
only
one
of
them.
So
what?
What
do
you
think
about
what
the
solution
for
tracking
individual
fragments
I
delivered
wanted
to
make
it
separate
from
previous
proposal?
But
previous
proposal
enables
us
tracking
for
fields,
names
of
fulfilled,
fragments
on
particular
path.
A
That's
an
interesting
idea:
we've
talked
before
about
how.
If
we
go
with
the
named
fragments
approach,
then
the
fragment
name
Will
effectively
become
part
of
the
path
anyway.
But
what
you're
proposing
here
is
forget
that
instead
take
the
path
and
the
name
of
the
fragment
and
just
say
at
this
path,
these
list
of
fragments
have
been
completed.
The
alternative
Tech
now
I
quite
like
that.
It
seems
simple
at
first,
but
I
am
concerned
that
it
would
balloon
the
response
size,
especially
for
clients
like
relay
that
use
fragments
for
every
single
individual.
A
Like
react
component
in
the
entire
tree,
the
number
of
fragments
that
you're
going
to
see
in
a
response
could
be
quite
high,
and
normally
those
fragments
would
just
evaporate,
like
they
get
got
rid
of
by
field
merging
so
actually
having
to
dictate
each
single
one
of
those
that
has
is
now
present
in
the
response.
That's
a
lot
of
extra
data
to
send
through,
especially
if,
if
you
have
like
nested
lists,
you
can
imagine
easily
times
the
number
of
fragments
you're
using
by
100,
because
there's
a
list
of
10
things
with
a
list
of
10
things.
A
Inside
of
that,
and
suddenly
that's
a
lot
of
information,
I
wonder
if
we
could
solve
it
more
specifically
by
like
opting
certain
fragments
into
it.
So
only
certain
fragments
are
actually
like
monitored
in
this
way
or
whether
there's
another
way
to
reduce
this
potential.
Large
increase
good.
B
C
You're
doing
yeah
only
one
of
the
stuff
that
have
default
yeah,
because
it's
not
in
data,
it's
like
it
fulfilled
fragments,
I'm,
always
thinking
about
that
in
the
top
level,
together
with
powerful,
like
ID
or
like
whatever
filled
with
at
Beyond
beside
data,
we
can
add,
like
a
few
fragment
names.
A
So
if
you
were
to
do
a
a
bunch
of
named
fragment,
spreads
inside
of
a
unnamed
fragment,
spread
an
inline
fragment
that
was
deferred,
then
you
wouldn't
get
any
labels
out
of
that,
but
yeah
yeah.
How
would
you
then
know
that
that
inline
fragment
was
now
complete,
I
guess?
The
path
that
you've
proposed
here
would
imply
that
it
is
now
complete.
Yeah.
C
Yeah,
it's
complete,
but
so.
C
If
you
want
to
get
separate
notifications,
saying
part
of
your
response
is
fulfilled,
and
you
want
to
highlight
separate
part
of
your
response
from
another
separate
part
of
your
response
that
you
want
to
be
deferred,
you
can
do
it
as
a
name
fragment
I
would
argue
you
should
do
it
as
a
name
for
argument,
because
it
it
will
make
a
code
generation
easier
and
everything
else
easier.
C
My
fragments
was
added
to
do
like
a
set
of
field
for
code
generation,
initially
inside
Facebook,
so
it's
like
fragment
art
type
system
on
a
client
not
on
the
server.
So
in
this
semantic,
if
you
want,
if
you
want
to
have
separate
as
a
person
programmer
who
do
web
application
and
use
like
a
railway,
a
poor
or
any
other
client,
if
you
want
to
have
special
treatment
for
this
set
of
default
Fields,
you
need
to
put
it
in
default
in
a
named
fragment
and
you
would
get
a
special
treatment.
C
B
So
before
we
before,
we
said
that
fragments
at
the
same
path
would
be
merged,
I
guess
once
we
said
that
they
would
be
merged
the
benefit.
The
trade-off
that
we
made
was
that
if
you
had
two
deferred
fragments
at
the
same
path,
then
they're
no
longer
independent
of
each
other,
depending
on
which
one
is
faster
or
slower,
maybe
they're
tied
to
unrelated
components
and
one
would
be
able
to
render
before
the
other.
B
Does
the
server
need
to
like
keep
better
track
of
all
the
fields
in
each
fragment
to
do
this,
or
is
it
still
the
situation
where
it's
just
resolving
them
all
together?
And
now
it's
just
telling
you
that
both
of
these
fragments
are
complete
at
the
same
time
and.
C
Yeah
so
I
thought
about
that
and
several
usually
in
most
of
implementation,
at
least
in
reference,
implementation
and
I
think
most
of
implementation,
don't
have
a
control.
You
cannot
say
like.
Please
resolve
this
thing
faster
and
we
think
slower.
You
just
start
everything
and
whatever
result.
First,
you
get
the
data.
So
the
question,
since
we
cannot
prioritize
things
and
in
most
systems
we
cannot
prioritize
things
so.
C
You
you
have
two
options:
you
can
ship
ship
as
you
resolve
so
stuff
is
resolved,
then
immediately
shipped
or
you
can
budget
until
it's
meaningful,
so
you
can
batch
stuff
until
you
get
at
least
like
one
named
fragment
for
field
or
all
the
stuff
for
field.
Should
you
do
this
like
a
batching
or
not
I'm,
not
sure
it's
dependent
how
complex
it
would
be.
C
So
if,
if
it
would
be
in
implementation,
wise
or
algorith
wise,
if
it
would
be
easy
to
track
that
that
to
not
not
send
stuff
and
truck
until
like
meaningful
part
of
it
is
done
so
I
named
fragment
is
is
done
at
least
one
name
fragment
is
done
and
one
ship
it
yeah.
It
can
be
nice
optimization.
If
not
server
can
ship
whatever
is
resolved
until
next
week.
So,
like
you,
you
get
all
the
data
and
wait
a
tick
and
Chip
whatever
was
resolved
on
previous
stick.
E
I've
been
just
on
just
on
the
question
of
using
the
the
fragment
name.
I
would
I
would
say
that
you
know
I
I,
don't
feel
so
strongly
about
it,
but
I
think
it's
just
a
different
feature
like
I
would
say
that
we're
okay,
you
know
just
using
a
label,
you
know,
instead
of
making
the
label
the
fragment
name
and
tying
it
to
whether
you're
doing
it
in
line
or
not.
You
know
we
can
you
know
we
can.
We
can
just
go
with
the
regular
label
as
it
was
before.
E
I
mean
again,
I,
don't
feel
so
strongly
about
it,
but
you
know
I
think
it
might
make
sense
to
even
require
yeah.
You
know
not
even
to
require,
but
yeah
yeah,
I
I'm,
not
sure
I,
understand
why
it
would
be
better
to
limit
Us
in
that
way
and
making
and
making
it.
D
C
Actually,
like
okay
with
both
I'm
I'm,
just
fought
that
the
label
is
contradiction
like
a
last
five
months
in
some
some
ways.
So
that's
why
I
thought
like
it
will
write
some
concerns
that
why
we
need
stuff,
why
we
need
to
add
new
name
to
fragment
if
in
future,
we'll
have
other
fragments.
C
My
main
idea
that
you,
if
with
previous
proposal
of
of
awarding
you
to
send
incomplete
payloads,
is
accepted,
it
will
basically
enable
us
to
have
our
two
labels
in
some
for
because
problem
with
the
variables
previously
was
that
label
is
attached
to
a
specific
form.
So
you
would
say
like,
if
you
receive
a
swayable
with
payroll,
should
include
this
data.
C
Even
even
if
this
data
is
part
of
his
data
is
already
duplicated
somewhere.
So
I'm
think
my
previous
proposal
that
we
discussed
previously
enable
us
to
not
die
labels
to
it
to
a
shape
and
allow
us
to
just
signalize,
where
you
have
enough
data
in
merged
Json
tree
to
fulfill
particular
fragment
and
wine
fragment
or
whatever
so
yeah
I.
B
C
Yeah
yeah
yeah
yeah
yeah,
it's
just
one
one
argument:
I'm,
okay
with
for
this
particular
feature:
I'm.
C
Okay,
to
do
it,
if
nothing
like
nobody,
thinks
feel
strong
about
it,
because
it's
like
which
second
proposal
about
fragment
names,
it's
like
clear
feature
and
it's
it
can
be
done
incrementally
why
I
wanted
to
voice
it
up,
because
I
think
it
give
like
more
Pros
to
previous
proposal,
because
it
shows
like
a
path
to
enable
that
and
because
this
current
state,
where
we
partly
the
duplicating
stuff,
adding
weibo
Cinemas,
it
would
be
complicated.
B
Yeah
got
it.
Could
you
leave
a
comment
like
under
your
proposal
on
this
on
this
issue,
with
that?
Okay.
C
Yeah
yeah
and
I
will
edit
the
example
to
to
show
like
separate
responses
instead
of
one
incremental
and
I
will
write.
This
comment
about
client
that
quite
need
to
track
changes
now
in
one
one.
Three.
B
And-
and
that's
just
just
under
just
so
I
understand
it's-
this
is
like
this
is
saying
this
is
something
that
we
could
do
in
the
future.
If
we
go
in
this
direction
now
yeah
and
it's
something
that
we
could
weigh
against
fragment,
aliases
or
or
maybe
they
they,
it
makes
sense
to
have
both
or
one
or
the
other,
or
something
like
that,
but
yeah
so
I
think
so.
A
A
But
it's
almost
to
me
like
what
Ivan
is
proposing
is,
if
you
do
a
defer
on
a
named
fragment,
spread
then
at
some
later
point
we
can
tell
you,
oh
that
defers
complete,
but
that
means
that
no
client
will
ever
be
able
if
we
don't
Implement
that
from
the
start,
no
client
can
ever
rely
on
that
behavior
that
that's
going
to
come
through,
because
originally
we
didn't
mandate
that
that
was
the
case.
A
So
I
think
it
would.
If
we
were
to
go
that
route
yeah,
it
sounds
interesting.
I
think
we
would
need
to
introduce
it
from
the
start.
Otherwise,
clients
can't
rely
on
the
fact
that
they
will
be
getting.
Those
confirmations
come
through
or
I
may
have
misunderstood
something.
C
C
Like
to
solve
your
point
about
not
duplicating
fragment
names,
we
need
like
some
mechanism.
We
need
is
a
Boolean
flag
on
on
deferred
itself
or
we
need
like
stuff
and
pendant
so
I.
Think
because,
like
as
you
said,
we
cannot
push
like
fragment
names
inside
the
inside
every
item
of
list
and
repeated
many
more
times.
We
need
to
exam
some
some
other
stuff.
We
either
need
to
Mark
a
fragment,
in
which
case
it's
similar
to
weibo.
C
So
if
you're,
able
to
mark
fragment,
that's
been
like,
you
can
rewire
me
or
we
need
to
do
like
is
a
pendant
style
or
like
stuff
in
The
Branding,
when
we,
when
we
list
fragments
and
use
like
numbers
so
anyway,
I
will
need
to
formulate,
but
the
proposal
to
solve
issues
that
you
rise
and
as
part
of
his
proposal,
I'm.
C
I'm
I
think
it
will
be
a
mechanism
that
I
will
client
to
rely
on
on
this
stuff.
If
it's
a
decorator
anyway,.
D
C
A
And
can
I
ask
you
some
other
questions
about
this?
One
is
with
the
original
labels
right.
The
the
idea
behind
them
was
that
you
could
then
say:
I
want
this
bit
done.
I,
don't
want
this
bit
done
and
I
don't
care
which
of
them
comes
in
first,
but
I
want
them
to
come
in
as
soon
as
they're
ready
and
then
for
a
while.
A
So
now
you
can
get
fields
from
each
of
them
as
as
of
when
they're
ready
and
then
at
some
point
it
will
say
this
one's
finished
and
at
another
point
it
will
say
this
one's
finished,
which
sounds
ideal,
but
it
would
still
I
guess
be
acceptable
for
the
server
to
treat
it
as
if
it
were
this
middle
state
where
we
just
sent
them
both
at
the
same
time,
there's
no
specification
level.
You
must
send
these
two
things
separately
anymore,
like
we
can
send
them
all
at
once.
C
So,
in
current,
on
the
same
level,
right
you're
right
if
it's
on
the
same
level,
it's
if
it's
only
different
levels,
you
need
to
to
to
do
the
duplication
example
B
that
I
showed
as
part
of
when
I
did.
Screenshotting
I
will
go
through
example,
B,
and
it's
only
it's
the
only
case
where
you
forced
to
ship
stuff
separately,
so
in
in
example,
B
from
that
issue,
you
must
you,
must
ship
and
complete
objects.
A
I
think
I'd
need
to
see
that
worked
up,
I'm
interested
to
know
if
we
could
have
like
a
single
incremental,
payload
and
I'm
I
don't
mean
a
single
entry
in
the
array.
A
Multiple
entries
in
the
array
is
fine,
but
I
mean
just
one
follow-up
payload
effectively
later
in
the
Stream
that
satisfies
this
whole
query
so
effectively.
You
have
the
initial
payload
with
the
ABCD,
and
then
you
have
another
incremental,
which
would
have
the
abdef
potentially
slow
field,
a
potentially
slow
field,
a
again
as
it'll
be
I,
forget,
b
b
and
the
G
and
H.
All
of
that,
as
the
data
of
one
thing
and
then
potentially
a
couple
of
little
follow-ups
that
say
path
root
is
now
complete
and
path.
A
b
is
now
complete.
A
Something
like
that.
That's
what
I
I'm
interested
in,
because
I
think
it
would
be
easier
on
the
client
and
often
on
the
server
if
we
can
compress
it
down
to
that,
but
also
allow
the
spec
the
spec
allows
you
to
do
it
in
the
multiple
steps.
If
you
want
to
which
can
be,
you
know,
lower
latency.
C
C
Very
semantic
of
initial
response,
so,
if
stuff
is
get
much
on
top
level,
you
don't
you
will
not
get
deferred
in
the
first
place
on
on
that
point,
so
like
in
this
case
to
you,
you'll
not
get
in
stuff
that
you
described,
you
will
not
get
entry
independent
for
inner
defer
because
after
the
force
will
took
all
that,
it
will
take
all
the
data.
So
you
have
don't
need
to
defer
any
anything.
C
C
Yeah
but
buff
is
buff
is
finishing
like
if
we
go
pending
crude
so
for
and
we
need
to
go
pendant
growth.
Otherwise
we
don't
know
if
initial,
like,
if
staff
get
annoying
inside
the
initial
pay,
what
you
don't
know
about
it
right
for
for
to
know.
A
C
Now
yeah
yeah,
because
I
didn't
want
to
make
like
because
right
now
we're
going
through
pick
and
mix
phase
and
I
wanted
to
present
it
as
a
orthogonal
thing
rope
in
top
level
issue.
He
also
wanted,
as
far
as
understand
separate
stuff.
So
there
is
no
opinion
in
Topo
ever
like
initial
command.
So
that's
why
I
didn't
use
it
in
my
in
my
solution,
so
yeah,
but
it's
assumed.
C
I'm
not
sure
about
shape,
and
it's
totally
separate
discussion,
but
yeah
some
mechanisms
to
Signal
where
stuff
is
in
one
or
not.
We
need
it
anyway
for
initial
response,
and
if
we
have
a
financial
response,
we
have
it
for,
like
everything
else
and
pendant
fits
a
bill
for
both
for
inviting
inside
the
initial
response
and
foreign.
D
B
And
I
do
have
to
have
to
run,
but
I
I
will
I'm
gonna
ask
Michael
and
Matt
if
they
have
feedback
on
this
proposal
and
I
think
that
we
should
try
to
implement
it
to
see
if
there's
anything
that
we're
missing
and
then
we'll
reconvene
next
week.