►
From YouTube: Incremental Delivery Working Group - 2023-04-17
Description
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. Get Started Here: https://graphql.org/
A
A
A
A
Is
how
is
everyone
doing.
A
Likewise,
I'm
frantically
clicking
buttons
to
fix
the
audio
I,
don't
know
why
it
is
messed
up
on
my
side,
but
oh
well,
everybody
had
a
nice
weekend.
A
D
A
B
B
Yeah,
like
church,
discuss
like
right
now
there
is
so
I.
Could
separation
from
people
tree
to
a
code
calendar
is
something
from
Russia,
so
they
wow.
So
that's
why,
like
the
whole,
but
for
me
it's
like
great,
because
calendar
is
synchronizes,
you
have
the
same.
We
can
search
everybody
else.
A
C
C
We
made
the
solution
criteria,
I,
don't
know
if
everyone
has
seen
that
yeah.
We
talked
about
that
at
the
last
working
group,
which
was
a
pretty
small
meeting.
C
Yeah
and
I
wrote
up
a
gist
with
all
examples
of
The
Proposal
that
Benji
put
forward
the
the
most
up-to-date
one
with
some
tweaks
that
we
talked
about
over
the
last
week,
so
so
I
guess
what
I
would
like
to
get
consensus
on
next
is
like
if,
if
this
Benji
proposal
is
like
the
direction
that
we
want
to
move
forward
in,
if
we
can
make
that
decision
or
if
we
need
to
explore
anything
else,.
C
B
Yes,
yeah
just
to
clarify
like
last
week.
It
was
like
a
call
last
week
or
not.
B
Okay,
okay,
we
canceled
yeah,
Monday,
okay
and
because
he
said,
like
a
small
meeting,
I
thought.
Maybe
I
like
yeah.
C
A
Yeah,
let's
do
you
have
links
to
the
the
solution
criteria?
Maybe
I
haven't
seen
that
sorry
I
was
just
taking
around
for
it.
A
A
Awesome
did
we
did
people?
Did
you
already
get
feedback
on
this
Rob?
Did
people
already
have
a
chance
to
go
through
this
yeah?
We.
C
Did
go
through
it
at
the
at
the
work,
the
main
working
group
meeting?
Oh.
A
Okay,
awesome:
do
you
feel
like
you
got
enough
feedback
on
it,
or
should
we
go
through
it?
Some
more.
B
I'm
I'm
viewing
program
and
actually
I
have
like
some
some
clarification.
Maybe
we
can
get
a
quick
round
since
everybody
have
a
link,
yeah
and.
B
If
yeah,
if
you
can
open
it,
so
I
have
like
a
idea
and
I
think
it
would
be
more.
B
A
Before
we
run
through
I
guess,
the
one
question
I
have
is
yeah
again
sorry
I
wasn't
at
the
working
group
meeting,
but
I
did
the
people
on
the
call
all
agree
with
the
scoring
that's
in
the
dock.
Right
now,.
C
They're
I
think
there
is
a
few
small
recommendations
which
I
did
incorporate.
Okay.
A
C
A
D
B
So,
like
I
didn't
do
my
homework
before
it
was
cool,
but
I'm
looking
is
Freud
now
and
I'm
like,
for
example,
A
and
B
totally
makes
sense
and
for
sure
I
I
would
make
it
stricter,
because
it's
like
right
now,
it's
say
about
one
value
per
path,
which
is
important,
but
another
important
thing
is:
you
should
be
able
to
construct
the
same
result
as
you
would
get
in
totally
synchronous
variant.
B
C
I,
don't
I
I
intentionally
didn't
include
that,
because
I
think
that
it's
it's
not
possible
for
cases
where
you
have
no
bubbling
inside
of
a
defer.
You
can't
like
novel
bubble
back
up
to
the
initial
result.
So
no.
B
Yeah
I
mean
not
by
applying
Puffs
patches,
I
mean
like
if
clients
who
wants
it's
important
for
question
can
for
like,
for
example,
if
we
speak
about
intermediate
server
and
right,
it
wants
to
store
operation
as
like
normalized
cache,
for
some
reason
for
something
else,
or
you
want
to
support
like
a
legacy.
Part
of
your
systems
that
don't
know
about
streaming
differ
a
smart
client
with
Squad,
not
white,
with
simple
patches,
but
with
squat.
It
should
be
enough
info
should
not
be
like
contradict
each
other.
That
client
can
construct.
B
C
B
Yeah
so,
for
example,
Hulk
Warrior
without
the
thing,
so
we
get
like
part
of
responses
and
when
you
get
an
error,
but
error
have
a
correct
path.
So,
even
though
I
you
technically
get
the
data
that
you
should
not
supposed
to
get,
but
but
you
should
like,
you
should
have
ability
to
read
by
words
and
understand
like
if
I
want
to
mash
it
up
at
the
top
hour
should
be
now.
E
So
if
I
understand
what
you're
saying
about
you're
basically
saying
this
requires
that
the
client
understands
the
schema,
so
it's
not
Reliant
only
on
the
payload,
but
also
on
the
schema
knowledge,
you're
saying
the
error
that
comes
through
from
stream
and
defer.
We
could
look
at
the
parts
of
that
see
that
an
error
has
been
thrown.
B
If
it's,
how
we
like
use
case,
for
example,
it's
want
to
store
it
in
the
cache
or
it's
one
to
like
I,
don't
know
like,
for
example,
there
is
two
components:
one
queration
between
two
components,
one
components
so
extremely
for
ready,
and
one
is
like
dumb
component
that
the
expect
like
stock
results
during
differ.
So.
B
Maybe
I'm
going
from
from
from
bad
side
I'm
trying
to
foremost
criterias
that.
E
A
Yeah
thanks
for
summarizing
this
sorry
I
just
read
through
your
proposal,
the
other
doc
that
you
shared
Rob.
This
is
great,
but
it
sounds
like
like
based
out
of
the
last
working
group
meeting,
and
these
meetings
like
this
is
our
winner.
A
So
mostly
so
far,
it
looks
like
it
meets
all
the
criteria,
except
for
a
couple
of
the
minor
ones.
C
Yeah
and
so
I
guess
basically
I
want
to
know
like.
Is
there
any
criteria
that
is
important,
that
we
don't
know
about
that
this,
wouldn't
that
would
prevent
us
from
moving
forward
with
with
that
proposal,.
F
I
I
have
a
hi
I.
Have
one
one
question
just
for
clarification.
F
F
So
so
then
you
so
so
if
a
client
I
just
want
to
make
sure
I'm
I'm
getting
it
right,
because
I
think
I
might
not
be
if
a
client
at
the
at
the
you
know
if
there
are
two
different
defer
fragments
at
the
same
level
that
you
know
you
know
put
forward
by,
you
know
two
different
components:
those
those
you
know
each
each
component
has
to
wait
for
the
other.
One
is
that
is
that
right,
because
you
know
car
yeah
is
that.
Is
that
correct?
No.
E
That's
not
correct,
I
think
it's
actually
laid
out
in
one
of
Rob's
examples:
sibling
defers,
I'm
just
scanning
through
as
Israel.
A
D
E
I
think,
though,
that
and
now
D
is
probably
the
closest
that
will
give
you
the
same
kind
of
behavior.
So
in
this
situation,
Jacob,
if
you
imagine
that
the
defer
the
second
defer
is
moved
inside
of
me,
then
that
is
effectively
describing
what
you
say.
E
In
this
case,
the
two
defers
would
be
able
to
be
delivered
separately,
but
effectively.
The
list
and
item
would
become
a
common
payload
for
one
of
a
better
term,
a
common
incremental
entry
that
would
be
delivered
with
whichever
of
A
or
B
completes
first,
so
yeah,
as
you
can
see,
Rob's
just
highlight
that.
E
So
that's
the
common
bit,
and
in
this
case
the
first
defer
came
first,
as
you
can
see
from
the
id123,
so
we
get
the
common
one
and
then
we
get
the
id123
and
then
later
in
a
later
payload
we
get
the
value
fubarbaz,
which
was
from
the
second
defer,
so
the
they
don't
have
to
wait
for
each
other.
Even
without
labels.
Adding
a
label
doesn't
change
that
they
don't
have
to
wait
for
each
other.
A
We
just
need
to
figure
out
if
there's
anything,
we're
missing.
That
needs
to
be
part
of
the
solution,
criteria
that
we're
just
not
catching
here
and.
E
E
E
Does
that
delivery,
with
with
some
kind
of
mental
model,
of
like
a
rough
idea
of
how
it
works
using
field
collection,
kind
of
thing,
but
actually
I
know
from
having
written
up
my
previous
proposal
that
trying
to
actually
mesh
it
into
the
the
execution
model
is,
is
quite
challenging.
Yes,.
C
I
I
have
been
been
working
on
implementing
it.
Oh.
A
C
And
I've
I
feel
like
I'm
I
mean
what
I
did
is
like
not
ready
for
any
kind
of
review
or
anything
but
I.
It
I
feel
like
I've
gotten
enough
of
it
in
there
that
I'm
pretty
confident
that
implementing
it
won't
be
like
a
gigantic
challenge.
I
think
it's
actually
a
lot
of
the
complexities
that
are
in
yakov's
implementation
aren't
necessary
with,
with
this
results,
so
I
think
it's
overall,
a
little
bit
simpler,
yeah
I
mean
very
well.
C
A
Cool
well
yeah
I'm,
sharing
it
with
people
as
we
speak,
so
I'll
definitely
try
to
get
some
more
feedback.
Yeah
should.
C
E
We
get
into
that
Rob
you
and
I
were
discussing
privately
about
this
execution.
Would
it
make
sense
to
discuss
that
first?
Whilst
we've
still
got
a
reasonable
amount
of
time,
because
I
think
it
could,
it
could
be
a
can
of
worms,
yeah
sure,
you're,
right,
okay.
So,
to
give
a
brief
a
brief
summary
of
this,
you
may
remember
that
Michael
stabe
implemented
an
early
version
of
stream
and
defer
ages
ago
and
gave
feedback
from
his
users.
E
That
basically
said:
if
we
don't
start
executing
the
Deferred
Fields
up
front,
then
the
total
time
to
deliver
the
entire
payload
can
get
significantly
larger
right.
So,
ideally,
we
want
to
start
executing
things
as
early
as
possible
and
just
deliver
them.
You
know
when
they're
ready,
I.E,
we
shouldn't
be
doing
everything,
that's
not
deferred
and
then
doing
the
things
that
are
deferred
afterwards.
E
Michael
says
robber,
grease.
E
I,
however,
do
not
agree,
or
at
least
I
don't
mind
things
starting
executing
beforehand.
If
the
server
decides
that's
the
case,
but
I
think
the
spec
algorithm
should
be
written
in
a
way
where
you
imply
that
they
are
started
afterwards,
like
you
do
all
of
the
non-deferred
stuff
first
and
then
everything
else
afterwards
and
there's
a
few
reasons
for
that.
One
is
that
it
significantly
simplifies
how
the
spec
would
be
written.
I
think
I
believe
anyway.
E
E
So
if
a
resolver
has
a
side
effect,
you
can't
undo
that
you
can.
You
can
choose
not
to
deliver
it,
but
if
there's
a
side
effect
there,
it
can
be
problematic
and
I
know
that
there
are
people
that
are
doing.
You
know
what
they
call
nested
mutations,
where
they
have
fields
that
are
on
the
child
fields
of
entries
on
the
mutation
type.
So
it's
two
levels
deep,
for
example:
now
we
we
don't
forbid
this
in
the
graphql
spec,
but
we
set.
We
don't.
Also.
We
don't
allow
it
like.
We.
E
E
So
there
are
people
that
are
doing
it
despite
the
fact
that
there
are
side
effects,
and
it
is
actually
quite
a
widely
like
it's
been
in
conference
talks
at
graphql
conferences.
So
it's
not
something
that
we
can
ignore
now,
if
we
mix
defer
and
stream
with
this,
and
we
allow
like
a
defer
within
one
of
the
mutation
Fields,
the
graphql
spec
doesn't
see
non-mutational
Fields
as
anything
special.
So
this
is
where
the
risk
of
like
null
bubbling
and
the
handling
of
it
could
actually
have
unexpected
side
effects.
E
E
So
there
is
there
is
that
risk
and
I
think
that
that
could
actually
leak
into
other
areas
and
basically
there's
some
amount
of
complexity
there.
So
anyway,
I'll
open
it
up
to
the
floor
now.
C
Yeah
so
my
I
I
feel
like
I
feel,
like
the
spec
can't
say
you
have
to
wait
until
everything's
done.
It
should
provide
like
the
ability
for
servers
to
do
early
execution
I.
Also,
don't
think
it
should
say
that
you
have
to
do
early
execution.
We
could
say
we
could
write
this
back
as
if
you
are
doing
it
and
say
you
can
delay
as
long
as
you
want.
C
But
I
think
that
it's
like
I'm
I'm
I
was
my.
My
thoughts
were
that
we
should
write
this
back
with
early
execution
and
have
all
the
the
caveats
of
what
you
have
to
do
of.
C
You
know:
don't
deliver
this
payload
if
a
sibling
knows
out
that
was
like
a
thing
that
we
discussed
a
while
back
and
we
have
the
code
to
do
that
so
that,
because
otherwise,
if
we
do
make
this
the
spec
simpler
by
assuming
that
this
execution
is
like,
doesn't
happen
that
that,
if
we
make
the
stack,
the
spectacs
will
definitely
be
simpler.
If
we
make
the
assumption
that
the
execution
gets
pushed
back
and
I
feel
like
that,
it
shouldn't
just
be
like.
C
C
A
Yeah
I
think
if
we
have
yeah,
if
we
have,
the
spec
specifically
make
it
mandatory
that
you
have
to
wait
in
execution,
we're
going
to
have
all
sorts
of
graphql
servers
that
optimize
anyways
to
fire
the
Deferred
stuff
right
away.
So
there's
going
to
be
a
lot
of
implementations
that
are
just
going
against
what
this
spec
would
say.
They.
C
A
E
I
think
that
any
server
that
implemented
an
optimization
like
that
would
still
have
to
ensure
I
mean
the
whole
thing
at
the
beginning
of
the
spec.
Is
it
says
that
the
observable
result
should
be
the
same?
So
if
you
choose
to
execute
stuff
early,
that's
your
choice,
but
you
must
make
sure
that
the
delivery
of
it
still
conforms
to
the
spec.
E
E
That
may
not
be
the
case
when
we
do
defer
and
stream,
because
we've
got
this
like
idea
of
batching
and
sending
things
a
bit.
You
know
sending
this
like
shared
thing.
We
talked
about
with
yaakov
just
now
and
various
other
stuff.
That
means
that
maybe
execution
and
delivery
will
become
a
little
bit
different,
but
I've
also
thought
there
was
this
other
concern
other
than
these
nested
mutations.
E
Imagine
that
you've
got
a
whole
bunch
of
resolvers
that
query
a
database
and
you've
optimized
your
system
to
put
all
of
your
queries
into
a
queue,
because
you
want
to
share
this
same
database
connection
for
everything
in
your
current,
maybe
even
in
a
transaction.
Whatever
for
anything
in
the
current
graphql
request,
if
you
were
to
kick
off
one
of
your
deferred
Fields
as
part
of
the
early
execution,
you
might
add
that
to
the
queue
and
then
one
of
the
non-deferred
fields
might
need
to
do
something
that
requests
the
database
as
well.
E
So
there
is
like
my
main
issue
with
this:
is
that
we
don't
control
what
people
have
in
their
resolvers
and
they
could
be
all
sorts
of
clever
optimizations
that
people
have
done
in
their
business
logic
that
will
not
be
able
to
be
leveraged
or
won't
be
able
to
leverage
stream
and
defer
if
there's
this
kind
of
situation
in
there
again.
This
is
another
concern
related
I.
C
Could
see
it
going?
The
other
way
too,
like
maybe
in
this
query,
like
the
the
queue
is
mostly
empty
most
of
the
time
while
the
synchronous
stuff
is
being
resolved,
and
now
your
queue
is
like
filled
up
with
the
defer
stuff
while
and
that
could
be
while
you
have
like
other
traffic
from
other
requests
coming
in
and
because,
like
the
time
spent
on
the
query,
is
stretched
out.
D
C
D
E
E
The
main
thing
is
I
wanted
to
raise
that
as
something
that
I
am
concerned
about
and
that
we
should
factor
in
to
when
we
do
write
up
the
the
spec
changes.
If
we
choose
to
in
the
spec
talk
about
early
execution,
then
I
think
we
should
keep
all
of
these
different
complexities
in
mind.
E
C
All
right,
yeah,
so
example
a
this
is.
This
is
basically
demonstrating
that
fields
that
are
shared
between
the
Deferred
and
non-deferred
part
are
extracted.
They're
they're
only
sense
in
this
initial
payload.
Any
intermediary
objects
are
never
sent
more
than
once
the
results
here.
The
the
only
the
only
things
in
the
first
defer
that
are
different
are
J
and
K.
C
So
that
sense
in
your
first
incremental,
you
got
your
pending
with
the
second
D2
label,
and
now
you're,
getting
l
m
just
just
general
stuff
pending
is
what's
telling
you
what
what
defers
are
being
are
queued
for
execution?
C
The
path
we
decided
is
always
going
to
point
to
the
path
where
the
defer
is
label
is
an
array.
If
there
are,
if
there
are
labels
that
match
each
one
gets
assigned
an
ID,
then
an
incremental.
The
other
path
is
kind
of
used
as
like
a
subpath
of
that
ID.
C
So
if
this
ID
was
pretty
long,
it
wouldn't
be
re
repeated
in
each
incremental
and
then
there's
a
completed
array
that
tells
you
when
a
certain
ID
is
done
and
the
the
contract
is
that
we're
not
sending
any
incremental
data
fields
until
everything
is
completed
for
that
execution.
For
for
that
for
a
corresponding
ID,
and
if
things
are
shared,
they're
not
sent
again,
but
whatever
wasn't
sent
when
that's
ready,
that's
when
you
get
the
rest
of
them.
C
This
one
is
is
similar,
but
there's
a
a
field
at
the
top
of
the
defer
in
one
all
the
way
at
the
bottom
they're
both
sent
together.
Even
if
one
is
ready
before
the
other
they're
sent
together.
Id0
is
completed.
C
This
is
the
one
with
with
overlapping
fields.
So
here's
the
example
where
slow
field
a
completes
first,
so
you
have
one
payload
with
potentially
slow
field
a
and
another
payload
with
enf
id1
is
completed.
That's
the
label
a
over
here
with
the
longer
path.
C
Then,
when
this
one
is
completed,
you're
getting
G
and
slow
field
B
and
the
way
that
we,
how
things
are
things
are
fields
are
going
to
be
grouped
into
one
incremental
when
all
of
those
fields
have
the
same
selection
of
defers.
So
if
there's
a
field,
that's
shared
between
different
defers,
then
that
would
get
broken
out
into
its
own
incremental.
C
That's
what
happened
with
enf,
because
that's
when
we
know
these
things
are
on
the
server
basically
executing
separately
and
when
it's,
you
would
get
you
this
all
right
and
in
the
example
with
slow
field
B,
it's
these
incremental
objects
are
the
same
objects.
They're
just
returned
in
different
order,
but
I
guess
that's
what
a
simple
array
of
what
I
was
trying
to
say.
E
Probe
sorry
to
interrupt
yeah
with
what
you've
got
before
and
I
mean
these
are
very
much
based
on
what
what
I've
written.
So
this
is
my
own
fault,
as
you
express
it
to
me
now,
I,
actually
wonder
that
that
shared
payload
that
has
the
id1
that's
actually
technically
shared
between
ID
0
and
1
right,
the
yes
right,
I'm.
C
C
Yeah
I
wrote
longer
ideas
preferred
or
that's
not
clear,
but
let
me
just
edit
that
right
now.
C
This
example
shows
that
there's
three
different
interferers
here
and
there's
this
one
they're
all
the
same,
except
for
this
one.
It
has
a
and
b
this
one
has
only
a
and
this
one
has
a
and
C.
C
C
I
think
I
need
to
look
at
this
example.
Again.
This
doesn't
look
right,
I,
don't
think
A
and
B
should
be
in
the
same
object,
because
no,
they
should
in
this
case
this
one.
C
Yeah,
this
is
the
one
where
everything
is
shared,
except
ID
and
value,
and
so
what's
interesting
here
is
that
list
and
item
are
all
sent
in
one
and
now
because
these
children
are
in
different
defers,
they're
separated
out
into
separate
payloads.
So
you
have
all
the
IDS
for
here
and
then
all
of
the
the
values
in
their
own
payload,
so
that
one
and
zero
can
complete
independently
of
each
other.
C
E
And
that
would
also
be
the
case
if
B
was
missing
from
one
of
those
right.
If
one
of
them
was
just
a
and
the
other
one
was
AP.
No.
E
C
Is
a
deferred
that
doesn't
have
any
fields
in
it,
so
this
one
is
just
it's
as
it's
as
if
it
was
not
there
right,
there's
no
field
to
execute.
It's
not
going
to
be
impending.
It's
not
going
to
be
incompleted,
it's
nothing!
C
It's
a
no-off,
I!
Guess!
Here's
the
one
from
your
example
where
we
show
that,
even
though
these
deferries
are
at
the
same
level,
yeah
I
guess
it's
the
one
we
were
looking
for
before.
C
And
I
think
maybe
there's
a
question
here,
because
we
were
talking
about
how
how
we
have
the
logic
for
defers
not
being
sent
pointing
to
a
path
that
doesn't
exist.
C
But
we
had
also
previously
said
that
if
you're
at
the
same
level,
even
if
you're
nested
through
other
fragments,
they
could
still
come
like
previous.
This
one
could
come
before
billing
because
they're
at
the
same
path.
But
maybe
we
should
discuss
that
again.
I'll.
Add
it
to
a
list
of
things
to
just
to
discuss
later.
C
We're
gonna
say
that
as
resolves
before,
Quacks
quacks
is
a
non-nullable
field
and
it
returns
null.
So
what
happens
is
both
of
these
are
are
pending
then,
as
resolves,
and
you
get
this
result.
Fubarbest
now
box
resolves
null.
That's
it's
a
non-nullable
field,
so
bar
should
be
nulled,
but
bar
was
sent
already.
C
So
our
rule
is
that,
if
anything,
if
because
of
no
bubbling
anything
is
going
to
overwrite
a
field
that
was
already
sensed,
then
instead
that
whole
that
whole
fragment
is
not
going
to
be
sent,
we
were
not
going
to
send
any
inconsistent
results,
so
it
has
to
be
nulled
clients
to
treat
it
almost
as
if
it
was
like
a
fragment
that
was
skipped,
but
you'll
have
the
error
in
here
and
you're
not
going
to
get
this
another
field
or
Foo.
Because
of
that
inconsistency
which
can
be
resolved.
C
Yeah,
so
that's
that's
all
the
yeah,
it's
in
the
Benji's
previous
proposal.
He
was
doing
done
on
incremental
instead
of
completed
and
when
I
talked
with
him
about
that
I
suggested
completed
for
the
fact
that
it's
possible
that
you
may
be
sending
one
field
that
resolves
multiple,
multiple
defers.
C
So
in
this
example,
each
one
overlaps
slightly
with
another
one,
and
so
we
say
that
baz
takes
the
longest
here,
so
you
get
back
Foo
you
get
back
bar
and
this
one's
completed
now
we're
just
waiting
for
baz
and
that's
going
to
resolve
both.
So
instead
of
having
a
done
on
here
that
says
only
one,
and
maybe
something
else
that
says
that
two
is
done.
We
just
say
have
this
completed
object
that
says
one
and
two
are
both
done
by
this.
One
interesting
object.
C
Then
the
the
solution
criteria-
let's
see
what
o
is.
C
C
This
one
with
these
two
potentially
slow,
Fields
I,
think
it's
predictable,
because
you
know
that
there's
going
to
be
one
payload
for
with
enf
there's
going
to
be
one
payload
with
this
and
they're
going
to
be
one
payload
with
that,
because
that's
how
they
overlap,
I
guess
it
depends
on
your
definition
of
predictable.
C
So
that's
why
I
put
a
question
mark?
What
it
doesn't
solve
is
a
full
fragment
returned
in
each
payload.
That's
basically
what
we
had
before,
where
your
response
pretty
much
mirrors
the
the
fragment
that
was
deferred,
but
that
in
that
gives
you
the
trade-offs
of
having
to
send
intermediary
objects
multiple
times
larger
payloads,
and
we
had
also
talked
about
this.
How
the
graphql
spec
says
that
you
should
preserve
field
ordering.
C
That
seems
like
almost
impossible,
where,
like
I,
should
write
the
example,
but.
D
D
E
C
C
A
No
I
think
it's
clear
yeah
other
than
the
one
you
notice
needs
to
be
updated,
but.
E
Yep
so
Q,
whilst
you're
discussing
this
internally
with
Apollo
and
anyone
else
as
well,
I
would
definitely
spend
some
time
thinking
through
example,
H
and
the
the
explosion
of
the
fragments.
I.
Think
that
is
the
right
decision,
but
it
does
definitely
has
you
know
it
may
not
be
super
intuitive
to
users
or
it
may
have
side
effects,
we've
not
thought
of,
or
you
know
it
might
not
always
be
the
right
thing.
I
think
it
definitely
needs
thought.
E
C
Yeah
this
is
this
is
another
case
of
of
you're.
Had
removing
the
deferest
is
not
going
to
give
you
the
same
reconciled.
Object,
I,
think
the
two
cases
that
this
proposal
has,
where
that's
not
true,
is
for
no
bubbling
where
something
bubbles,
above
at
the
level
of
a
defer
I
mean
without
knowledge
of
the
schema.
A
G
A
Sorry,
yeah
no
great.
What
do
you
think
so
far
about
this,
since
this
would
mean
some
changes
for
kotlin,
for
example,
the
kotlin
client.
G
Yeah
definitely
some
changes,
but
from
my
so
I
haven't
done
too
much.
I
really
have
to
to
dig
more
on
this,
but
from
what
what
I'm,
seeing
and
I
think
everything
is.
Everything
is
there
for
us
to
to
implement
it,
yeah,
okay,
so
yeah.
Basically
this
this
looks
good
so
far,
but
I
yeah
I
would
need
to
think
of
how
to
implement
it.
A
bit
in
more
details,
but
first
at
first
first.
A
D
G
E
All
right:
well,
that's
interesting.
Rob
won
me
around
on
that
one
yeah
like
it's
it.
Definitely
it's
kind
of
the
set
it's
the
mirroring
of
the
pending,
so
you
get
the
pending
and
then
you
get
the
completed
and
they're
like
two
separate
things
and
then
in
between
you've
got
the
incremental,
which
is
its
own
like
area
of
concern,
if
you
will.
A
F
A
Awesome
well
yeah,
thanks
again
for
putting
that
all
together.
Definitely
we'll
keep
you
posted
as
we
get
some
some
feedback.
Yeah.
A
A
A
A
C
Yeah
and
I
could
I
actually
probably
could
get
the
spec
PR
I
could
probably
update
the
last
one.
That
I
did
like
the
2B
proposal
to
include
this
because
I
think
it's
pretty
minor
difference
and
yeah
I
want
to
talk
to
Yakov
some
more
about
the
implementation
and
what
can
be
factored
out
of
both
of
ours
and
to
move
forward.
E
I
think
it
is
worth
if
there
is
common
things
like
yaakov's
previous
proposal
in
the
spec,
with
the
with
the
subfields.
If
that
makes
sense
with
your
proposal
or
you're
writing
up
about
how
proposal
I
suppose,
then
it
would
be
good
to
get
those
changes
in
into
maybe
not
necessarily
into
the
spec,
but
into
a
stack
so
that
we
can
review
them
layer
by
layer
and
and
merge
them
bit
by
bit,
rather
than
having
just
one
massive
stream
of
defer
change
at
the
end.
E
A
We
will
appreciate
it,
it
definitely
appreciate
it
and
yeah
it's
gonna
be
exciting,
we'll
we'll
get
there
we'll.