►
From YouTube: Incremental Delivery Working Group - 2023-04-03
Description
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. Get Started Here: https://graphql.org/
A
C
B
Hey
so
yeah,
let's
get
started
so
since
the.
B
Where
now
we
have
a
version
where
the
response
looks
a
lot
like
it
did
in
our
like
previous
iterations,
where
the
response
shape
matches
what
the
defer
fragment
looks
like,
but
with
without
any
branching
and
with
deduplication
Jacob.
Are
you
able
do
you
want
to
go
through
Your
solution
a
little
bit
and
show
some
examples?
Maybe
or
I
can
do
it
if
you're
not
able
to.
B
All
right,
maybe
I'll
I'll,
just
share
my
screen,
then
yeah.
C
Sorry
I'm
a
little
I'm
a
little,
only
able
to
listen
today,
unfortunately,
but
yeah
if
you're
able
to
that
would
be
fantastic.
Thank
you.
B
Yeah,
so
here
are
here's
some
examples.
This
is
the
the
one
that
we've
looked
at
for
a
while
and.
B
And
because
enf
is
sent
in
the
in
the
first
payload,
it's
not
sent
in
the
second
one.
There's
some
example:
there's
an
example
with
null
bubbling
and
I.
B
Think
that's
no
bubbling
is
definitely
a
tough
issue
for
us
to
figure
out,
but
in
in
this
example,
so
we
have
ABC
in
this
field
that
nulls
and
is
not
null
so
first,
this
the
defer
for
here
is
sent
down
to
D
and
then
in
a
later
incremental
payload
a
since
this
field
has
nulled
out,
see
you
sent
again
with
with
null
and
the
and
the
errors.
B
Yeah
and
I
think
this
is
a
another
similar
example
that
we
were
showing
so
for
this
meeting.
I
kind
of
I
I
think
maybe
we
have
on
the
agenda
for
the
main
working
group.
That's
coming
up
on
Thursday
to
talk
about
this,
and
so
I
would
like
to
get
a
sense
from
everyone
else.
If
we
want
to
move
forward
with
Benji's
proposal
that
we
talked
about
last
week
or
something
more
like
this
yeah,
so
anyone
have
any
initial
thoughts.
C
Sorry,
the
just
that,
just
to
just
add
one
line
to
that,
the
basic
idea
is
that,
with
my
proposal,
we
we
are
sending
like
individual
fields
to
each
payload
and
then
building
the
payloads
when
they're
complete,
and
so
we
have
control
over
whether
well
for
whether
you
know
what
to
do
about
nulls
or
not.
So
basically,
it
only
solves
the
one
problem
that
we
had
of
executing
each
field
once,
but
it
doesn't
give
us
consistency
in
terms
necessarily
in
terms
of
null
bubbling.
It
could
or
could
not.
C
B
Yeah,
the
the
main
difference
is
that
we're
we're
keeping
the
consistent
shape
of
the
the
payload
I
guess
consistent's,
not
the
right
word:
we're
matching
the
shape
from
the
fragment
that
was
deferred
versus
and.
B
D
D
And
so
in
payroll,
all
the
leaves
mentioned
once
what
about
intermediate
objects?
Yeah,
so
intermediate
objects
duplicated
but
leaves
are
deduplicated
right.
B
D
Duplicated,
okay,
so
yeah,
but
they
cast
so
they
execute
once,
but
they
like,
okay
I'm
when
I'm
totally
for
it
like
because
I'm
I'm
see
it's
I,
don't
treat
it
as
an
end
goal:
I
treated
it's
like
incremental
step
in
the
right
direction
because,
like
both
Rob
yours
proposal
and
bachelor's
proposal
right,
you
can
format
it
on
top,
so
yeah
just
to
clarify
like
we
discuss
your
proposal
way
and
basically
it's
the
same
right.
So
it's
like
Foundation
of
it's
like
current
state
of
things,
but
according
to
like
in
a
better
way.
E
C
Only
solves
the
the
idea
that
we
only
execute
once
and
the
original
way
we
had
solved.
That
was
with
weak
maps
and
you
know
Etc
and
now
we
you
know
it's
formally
built
in
that
we
only
execute
each
once
and
the
downside
of
that
is
that
we
have
to
send
each
in
each
field
to
the
you
know,
to
the
payload:
that's
keeping
toward
the
object,
that's
keeping
track
of
when
it's
ready
and
then
when
it's
already
it
has
to
be
rebuilt.
C
You
know,
there's
a
faster
implementation
that
I
have
in
mind
rather
than
the
one
that
exists
now,
but
it's
meaning,
but
it's
going
to
be-
it's
probably
slower.
I
think
you
know
from
the
get-go
than
than
just
delivering,
then
not
rebuilding
anything
and
just
deliver.
You
know
executing
as
we
go,
but
basically
it's
the
current.
C
It's
the
current
state
of
things
with
without
branching,
but
and
but
implementing
that
without
weak
maps
and
I
showed
here
how
you
can
get
deduplication
you
can
you
can
move
forward
in
different
directions,
maybe
based
on
how
we
want
to
go
to
side
here,
but
it's
really
more
of
an
implementation
than
than
a
concrete
proposal.
Like
we
mentioned
earlier.
C
Yes,
we
can
show
here
that,
and
basically
the
other
change
besides
not
branching
is
that
different
defers
at
the
same
level
and
with
the
same
label
or
With
No
Label
are
merged
and
that's,
okay
and
that's
sort
of
to
make
sure
that
you
know
the
the
path
plus
label
is
now
100,
unique.
D
Can
you
explain,
can
you
explain
Benjamin,
what's
what's
the
distinction?
Yes,.
A
So
jakov
was
just
saying
the
effectively
the
the
defers
at
a
given
path.
Merge
in
his
proposal
in
my
latest
proposal
to
see
they
don't
so
two
separate
defers
would
not
merge.
B
I
I
do
is
that.
Is
it
true
that,
in
for
either
proposal
like
we
could
we
could
decide
to
do
it
either
way?
I,
don't
think
that
it's
really
I
I,
don't
think
that
should
be
like
a
differentiating
factor.
I,
don't
think
it
matters
too
much
in
either
for
either
proposal.
B
It's
not
I,
don't
think
it's
core
to
like
the
implementation
but
I,
but
I
think
what
is
different
is
that
the
the
shape
of
the
how
we're
sending
the
data
I
like
I,
feel
like
yakov's
proposal,
could
easily
be
modified
to
not
merge
to
labels
that
are
the
same
or
Benji's
proposal
could
be
modified
to
merge
labels
that
are
the
same,
but
I
think
that
what's
core
to
figure
out
is
like.
B
C
Yeah,
the
more
I
think
about
it.
The
more
I
realize
that
I,
you
know,
I
haven't
really
brought
anything
to
the
table.
That's
new
I
mean
I,
showed
an
implementation
and
I
think
about
it
more
in
terms
of
what
features
do
we
want?
Do
we
want
no
branching,
and
so
that
checks
like
I,
think
everyone
agrees
that
with
that
and
then,
like
you
know,
there
are
certain
things
that
might
be
easier
with
my
implementation,
slash
spec
algorithm,
you
know,
but
but
again
the
implementation
that
I
have
doesn't
have
to
match
the
spec
algorithm.
C
You
know
it
could
be
different,
so
I
the
way
I
think
about
it
is
more
like
we
have
to
figure
out.
What
features
do
we
want
to
get
rid
of
branching
I,
think
everyone
would
agree.
Then
we
have
we
have
to
decide.
You
know
what
the
shape
of
the
payloads
is
as
you
as
you're
saying.
Do
we
want
pending
and
completed?
You
know,
maybe
probably
you
know
like
how
do
we
want
null
bubbling
to
to
work?
C
Are
we
gonna
never
allow
in,
you
know,
inconsistencies
or
are
we
going
to
allow
them
and
then
like?
How
are
we
going
to
deal
with
that
like
that
filtering
or
whatnot,
so,
like
I,
totally
agree
that
there's
sort
of
nothing
new
in
my
proposal
and
I
may
some
things
will
be
easier
in
my
implementation
and
something
maybe
at
some
point
we
might
have
to
scrap
it.
So
I
I,
you
know,
I,
don't
think
we
should
evaluate
basically
anything
that
I've
done
on
its
own
merits.
C
Just
a
question
of
what
features
do
we
want,
and
you
know
maybe
my
implementation
will
be
bad
if
we
want
a
certain
combination,
but
I,
don't
think
that's
a
reason
to
adopt
my
implementation.
You
know
it's
it's.
It
is
what
it
is.
D
So
question
here
just
to
clarify,
because
we
we
discussed
and
like
over
idea
like
future
or
future
like
development
work.
Are
we
like,
okay
with
imagine
what
Jaco
proposed
as
a
base?
Why
not
not
as
a
finish
state,
but
it's
a
baseline
to
to
measure
every
like
every
other
proposal
is
like
to
make
gifts
more
basically
for
every
other
proposal
and
to
have
like
to
to
our
people
to
use
stuff
with
that
we're
discussing
wait,
execution
ones.
For
example,
it's
like
I
think
it's.
It's
really
important.
Yeah.
A
Great
that
we
have
one
and
having
a
working
solution
is,
is
brilliant
to
experiment
with,
but
the
intent
for
my
one
is
that
it
in
it
effectively
builds
out
from
the
current
status
of
the
spec,
which
presumably
is
also
the
current
status
of
graphql.js.
So
I
would
expect
that
the
the
final
diff
against,
like
the
current
graphql.js
or
a
graphql.js
that
doesn't
even
support
stream
interfer,
would
be
less
in
total
than
implementing
yakov's
changes
and
then
implementing
the
ones
required
for
my
difference.
A
The
equivalent
with
my
proposal
would
just
be
a
a
natural
extension
of
how
the
the
spec
is
written.
It's
just
a
part
of
the
of
the
field
merging
it
just
properties
that
emerge
from
the
field,
merging
approach
in
a
in
a
quite
straightforward
manner
and
I'm,
not
sure
whether
that
is
necessarily
true
for
the
way
that
yakov's
done
it.
But
to
be
honest,
I
haven't
read
yako's
implementation,
so
I'm
not
no.
C
I
think
so
I
think
that's
right,
I
think
that's
right!
I'm,
not
sure
you
know
it's
a
funny
situation
now,
because
right
now
we
have
a
version
of
incremental
delivery
in
graphql
Gs.
So
so
I,
don't
think
you
meaning
Benji's
eventual
version.
I,
don't
think
the
diff
will
be
smaller
if
we
merge
mine
in
if
we
adapt.
If
we
then
change
it
all
together
for
expungies,
you
know
so
I
don't
I
mean
it
helps
us,
maybe,
with
only
with
the
examples
like
the
test
examples.
C
But
again
the
payload
format
is
going
to
be
so
different.
We're
going
to
have
to
change
so
many
lines
of
code
anyway,
I
think
I
think
we
might
be
more
productive,
just
just
trying
to
decide
which
which
features
we
want,
or
you
know,
can
we
as
like
a
subgroup,
come
to
a
consensus
about
which
features
we
want
to
present
to
like
the
working
group
at
the
next
meeting,
like
especially
what
Benji
mentioned
last
time,
it
would
be
nice
to
decide
about
about.
D
Okay,
in
this
case,
let's
focus
on
like
I
think
what
would
help,
because,
like
right
now,
I
I'm,
like
I,
was
on
over
this
meeting
and
I'm
confused
I
didn't
do
like
homework.
I
didn't
read
the
current
status
of
all
the
discussion,
but
at
the
same
time,
I'm
confused.
What
what's
Benja
proposal
like
to
see
or
to
be
or
like,
like
what
property
it
has
and
in
reality
it's
like
it's
every
proposal.
How
like
different
answer
or
no,
except
of
like
eight
questions,
probably
like
do
you
have
a
duplication
of
leaves?
D
Do
you
have
duplication
of
their
immediate
objects?
Do
you
keep
a
shape
of
fragments
together
and
like
set
of
other
questions?
So
what
would
be
helpful
is
to
have
like
a
set
of
questions
and
like
table
I
think
it
will
help
like
other
people,
wait
bigger
working
group
to
understand
what
what
we're
discussing.
A
So
the
original
point
of
this
presentation
that
that
Rob
has
opened
was
to
try
and
explain
some
of
the
various
Concepts
that
we're
talking
about.
So
if
you
go
right
to
the
very
beginning,
Rob
and
step
through
from
there,
it's
talking
about
things
like
the
the
fragment
consistency
like
that's
explaining
to
the
working
group.
What
one
of
the
problems
is
that
we
aim
to
solve,
and
so
on
and
so
forth.
As
we
go
through
different
of
them,
then
it
was
to
look
at
some
of
the
solutions
and
then
to
look
at
my
one
now.
A
What
we
actually
have
on
the
agenda
for
the
April
working
group
at
the
moment
is
field
merging
approach
to
incremental
delivery,
so
it
was
effectively
or
originally.
My
plan
was
just
to
present
an
alternative
solution.
Since
then,
we've
evolved
quite
significantly.
A
Rob
came
up
with
a
counter
proposal.
Yakov's
got
his
own
build
that
tries
to
achieve
some
of
the
similar
goals,
and
so
there
was
no
2
A,
B
and
C.
A
When
I
first
wrote
this,
there
was
just
a
option:
two,
which
is
the
build
merging
approach,
so
I'm
cool
with
like
moving
this
stuff
around
choosing
what
we
present
but
I,
definitely
think
that,
as
you
were
saying
like
having
a
way
of
figuring
out,
what
these
questions
are
is
really
really
critical
and
then
figuring
out
what
the
different
Solutions
mean
when
we
did.
A
As
you
know,
Ivan
when
we
did
the
interface
input,
unions
working
group,
we
effectively
came
up
with
a
whole
bunch
of
different
criteria,
and
they
were
all
things
that
different
people
wanted,
and
none
of
the
solutions
that
we
came
up
with
had
a
yes
100
agreement
in
every
single
section.
I
mean
that's
one
of
the
reasons
why
maybe
that
particular
thing
hasn't
been
completed
yet,
but
I
think
there's
a
lot
of
like
there's.
A
There
are
definitely
contradictory
aims
here,
for
example,
one
aim
perfectly
reasonable
aim
could
be
to
have
the
fragments
delivered
as
whole,
like
Atomic
finished
objects,
and
another
aim
could
be
to
never
deliver
leaves
twice
those
two
conflict
with
each
other.
You
can't
have
both
of
those
you
have
to
have
one
or
the
other,
and
but
that
doesn't
mean
that
they
can't
both
be
goals.
D
D
D
A
parallel
delivery,
minion
quake
through
some
mechanisms,
webos
or
fragment
Alias,
so
something
that
you
have
one
one
fragment
delivered
faster
than
another.
One
is
important,
but
either
one
gets
gets
fragmented.
One
Bob
always
gets
it
through
couple
increments,
it's
less
important
and
also
when
we
had
like
working
group
discussion.
You
remember:
I
had
like
a
proposal
to
also
split
away,
split
response
between
response
to
fragmented
couple
chunks
and
maina
position.
D
Wasn't
that
its
break
fragment
shapes
the
biggest
deposition
was
from
a
mat
saying
like
we
should
not
send
useless
payloads
so
like
we
should
not
set,
send
payloads
that
don't
awoke
client
to
render
something.
So
we
should
not
sound
like
each
field
separately,
basically
other
than
that,
like
I,
think
everybody
was
okay
with,
or
at
least
like
I
didn't
heard.
Any
strong
opposition
and
people
saying
like
fragments
should
be
delivered
just
as
as
one
pop
in
response.
A
Yeah
I
completely
agree
with
that,
and
it
doesn't
mean
that
we
couldn't
still
write
it
up
as
a
goal
and
then,
as
a
working
group,
say
right.
This
is
no
longer
a
goal,
and
here
are
the
reasons
for
that
which
you've
laid
out
quite
well.
A
Having
some
having
a
resource
like
that,
like
we
did
for
the
input,
Unions
would
be
very
valuable
saying
why
something
that
might
seem
to
someone
who's
not
gone
through
all
of
the
huge
amount
of
work
that
we
all
have
especially
Rob,
giving
them
that
kind
of
context
and
saying
you
might
expect
it
to
come
through
as
a
big
payload.
But
it
turns
out.
A
That's
not
important
because
of
this
this
and
this,
and
actually
these
are
more
important
criteria-
is
a
valuable
resource,
because,
if
I'm
not
mistaken,
the
current
version
of
of
stream
and
defer,
like
the
version
that
Apollo
are
using
right,
is
using
the
branching
approach.
D
A
D
Well,
one
also
important
thing
like
Jacob
work
proves
that
there
is
two
two
different
things
there
is
like
execution,
deduplication
and
responses
duplication
and
when
we
start
with
think
in
my
brain,
it
was
like
batched
together.
So
a
price
was
like
huge
like
what
what
currently
in
graphql
jazz
did
you
like
it,
create
a
huge
problem
because
of
two
things
like
execution,
duplication
and
pivot,
duplication
and
I,
see
execution.
D
Duplication
is
also
a
problem,
but
not
as
huge
yeah
just
want
to
query
and
yaakov
shows
Jacobs.
It's
it's
like
two
separate
things.
Basically,
so
even
if
yeah,
so
you
I
think
like
the
whole
like
Circle,
makes
sense,
even
if
we
like
abandon
everything,
but
that
we've
done
since,
but
just
much
like
execution
deduplication.
That
will
be
already
like
huge
win
and
justify
always
like
the
process
of
discussion,
because,
like
execution,
duplication
is,
is
semantically.
It's
like
bad
thing.
A
A
D
Yeah,
it's
it's
a
great
idea
idea
like
I
the
actually
like
Jacob.
Is
it
possible
to
split
like
execution
deduplication
from
from
a
huge
Merchant,
because.
C
Yeah
I
said
I
set
it
up
in
two
different
commits
I.
Think
it's
not
there's
a
whole
section
in
the
code
that
I
mean
there's
some.
You
know
to
Do's
left.
Basically,
so
I
wouldn't
I
wouldn't
want
anyone
to
really
use
it
for
production.
I.
Think
I
think
it
would
be
great
if
we
got
people
to
use
it
and
to
give
us
more
test
cases
Etc,
but
I,
don't
know
if
you're
certainly
not
ready
for
a
production.
Past
production
use
but
I
think
it's
ready
for
more
testing.
C
D
Yeah,
so
it's
like
OS
ready
for
production
use
than
current
status
of
Main,
or
it's
so
we're
making
it
less
reliable
for
production
compared
to
like
current
mine
or
or
not.
D
So
if,
if
you
can
separate,
if
it's
not
like
huge
amount
of
work,
since
you
said
that
separate,
maybe
you
create
a
separate
PR
and
we
like
crop,
for
example,
can
review
it
and
because
he's
bigger
expert
on
this
I
guess
of
course,
me
and
myself
and
I
will
try
to
find
the
time
to
also
open
it.
And
maybe
we'll
show
production
issue
and
merge
it.
And
it
will
be
clear
when,
like.
D
C
Cool
okay
I
mean
I'm,
glad
I'm
glad
to
give
a
pass
to
try
to
fix
the
the
holes.
I
know
about.
D
A
Just
to
Circle
back
a
little
bit
to
the
previous
discussion
that
you
were
discussing
Ivan,
you
were
saying
how
the
the
execution
and
the
payload
delivery
are
effectively
separate,
as
proven
by
yakov's
proposal
and
effectively.
What
I'm
saying
is
that
that
is
true.
A
We
have
found
that
to
be
true
and
we
could
definitely
do
the
execution
separately
and
then
deliver
with
duplicates
or
without
duplicates,
but
what
is
I
think
the
the
main
difference,
with
the
way
that
I'm
trying
to
do
my
proposal
is
that
the
the
the
delivery
of
the
payloads,
the
deduplication
of
the
leaves,
is
a
artifact
of
the
execution
deduplication,
so
it
it
flows
out
of
that.
It's
not
a
separate
thing.
It
is
part
of
the
same
algorithm.
It
doesn't
happen
as
a
second
phase.
A
E
B
B
Both
both
what
you're,
proposing
and
what
Yakov
implemented
it's
like
during
execution,
it's
breaking
down
the
individual
fields
of
executing
them
once
and
keeping
track
of
which
payloads
of
which
defers
they
belong
to
and
Benji's
has
been
sending
that
data,
just
as
it
was
executed,
whereas
yakovs
is
reassembling
it
back
into
the
the
payload
shape
to
match.
What
the
Deferred
fragment
looks
like
is
that
accurate.
B
And
and
I
think
that
the
difference
between
them
what's
most
interesting
is
how
is
what
happens
when
there's
non-nullable
fields
and
null
bubbling
happens
where?
Because
of
the
way
that
it
gets
reassembled
back
in
in
yakov's
implementation,
you
could
end
up
with
the
same
field
being
sent
twice
first
with
the
null
and
then
again
with
the
data,
because
it
bubbled
here,
but
it
didn't
bubble
there
and,
if
you're,
trying
to
write
it
back
up
into
a
a
single
object
that
looks
the
same.
It's
into
like
one
reconcilable
object.
B
Now
you
have
a
conflict
and
you
have
to
choose
how
to
handle
it,
whereas
with
Benji's
approach,
I
think
that
we
would
have
like
you
couldn't
make
that
choice,
because
once
that
field
is
already
sent
it,
it
has
been
sent,
and
you
can't
send
another
value
for
the
same
thing
and
I
think
that
that
could
be
good
or
it
could
be
bad.
Maybe
because
you
have
a
client
that
is
merging
is
rendering
fragments
more
directly
and
it
it
could.
B
Maybe
you
could
render
that
c
being
null
in
one
place
of
the
client
and
the
C
having
data
in
another
place
or
but,
but
maybe
that
adds
more
complexity
for
clients
that
don't
want
to
do
that,
and
maybe
that's
not
really
that
much
of
a
valid
use
case
anyway.
A
What
I
think
would
happen
is
that
the
effectively
if
there
was
a
null
bubble
that
happened
later,
then
it
would
effectively
invalidate
that
entire
fragment
that
was
that
had
been
deferred
so
that
entire
pragma
would
now
error
out
and
wouldn't
deliver
any
of
its
data
if
it
bubbles
past
any
sort
of
shared
or
previously
sent
field.
So
there
would
never
be
a
case
where
there
was
a
null
scent
and
then
there
wanted
to
be
an
object
later
that
wouldn't
happen.
A
C
I've,
actually,
you
know
from
within
my
existing
solution.
I
I
demonstrated
how
I
guess
how
you
could
have
not
branching
but
sort
of
Independence,
but
I,
don't
in
terms
of
goals
that
conflict
I
think
that
goal
if
it
is
a
goal,
even
conflicts.
What
really
with
the
idea
of
deduplication,
because
then
it's
like
really
difficult
for
clients
to
figure
out.
You
know
what
has
been
sent.
C
What
hasn't
you
know
what
they
can
rely
on,
how
everything
fits
together
and
I
think
the
safest
option
you
know
for
this
kind
of
error
case
is
just
is
basically
to
adopt
exactly
what
Benji
proposed,
so
meaning
I
think
that
if,
if
we
should
always
take
the
initial,
we
should
just
have
consistency
and
all
nulls
should
should
travel
forward
and
any
new
nulls
that
you
know
can't
travel
backwards
should
result
in
the
payload
erroring
I
mean
I
I.
So
basically,
I've
come
to
the
same
conclusion,
but.
E
A
And
an
interesting
thing
is,
you
can
think
of
it
a
little
bit
like
the
client-controlled
null
ability,
so
you
can
say
like
if
you
have
a
deferred
fragment
that
overlaps,
multiple
layers,
where
it
overlaps
things
that
have
already
sent
you
can
think
of
each
element
of
that
chain.
Having
the
the
bang,
the
exclamation
point
modifier
to
say
this
is
now
non-nullable,
and
that
would
be
effectively
what
causes
the
fragment
to
to
blow
up.
That's
just
an
analogy:
it's
not
like
concretely
how
it
would
be
implemented.
A
B
Sorry,
no
I'm,
just
asking
basically
like,
is
there
any
benefit
for
having
you
know
this
type
of
payload
structure
that
matches
the
the
Deferred
fragment.
B
Right,
yeah,
I,
guess:
I
guess
what
I'm
thinking
now
is
that
the
two
paths
to
go
down
are
so
we
don't
want
execution
duplication
there.
We
I
think
that's
just
objectively
bad.
Now,
there's
no
like
good
reason
to
have
it,
since
we
proved
that
it
doesn't
affect
response
duplication.
B
Now.
The
the
next
question
is:
do
we
want
response,
duplication
or
or
not,
and
I
think
that
if
we
decide
that
we
don't,
then
I,
don't
I'm,
not
I,
don't
think,
there's
a
benefit
to
trying
to
maintain
this.
The
the
layout
of
the
payloads
matching.
What
the
Deferred
fragment
looks
like
I
think,
because
if
stuff
is
being
deduplicated,
you
have
to
keep
track
of
everything
and
merge
it
back
together
to
get
something
useful.
B
If
you
are,
if
we're
not
doing
duplication,
if
we're
not
doing
deduplication
and
then
clients
could
just
like
look
at
this
payload
and
render
it
directly,
but
if
you
have
to
like
keep
track
of
all
the
previous
payloads
and
build
it
up
again,
then
I.
We
might
as
well
rule
this
out
and
go
with
the
fields
being
sent
individually.
C
Well,
the
fields
being
sent
individually
does
give
us
a
lot
of
potential
like
extra
metadata
about
each
film
the
path
to
each
field.
So
so
in
my
I,
the
way
I
thought
about
it
is
that
we
have
a
deduplicated
response
that
other
than
the
deduplication
of
leaves
or
objects
that
are
sent,
we're
basically
batching
and
we're
batching
in
ways
that
are
predictable,
and
so
so
I
think
that's
highly
desirable
to
batch
responses.
And
then
the
question
is:
do
we
want
to
do
some
of
to
provide?
C
You
know,
objects
that
will
have
to
do
a
deep
merge
or
do
we
only
want
to
provide
objects
where
the
client
has
to
do
like
individual
mergers
on
multiple
payloads
like
I,
see
that
as
a
difference
like?
Maybe
we
don't
want
to
batch
too
much
if
you
know
for
some
reason,
we
think
it's
bad
to
have
a
deep,
merge.
I
think
that
was
one
of
the
points
that
Benji
raised,
that
that
you
or
one
of
the
pros
of
one
of
his
Solutions
I'm,
not
sure
why
that
is
a
pro.
D
Can
I
like
create
a
criteria
for
that?
Can
we
call
it
like
greedy
delivery?
It's
what
might
always
works
talks
about
an
emphasize
in
previous
discussion
that
we
send
as
many
as
many
like
stuff
in
1.1
is,
is
already
or
make
sense
for
like
from
fragment
view.
So,
like
yeah
said,
like
we
send
stuff
separately,
either
for
the
duplication
or
because
it's
like
fit
and
fragment
or
like
specific,
fragment
or
specific
fragment
with
the
label.
D
D
B
So
so
I
think
what
I
should
do
for
before
the
next
meeting
I
hope
that'll
have
time
to
do.
It
is
I
mean
we
we
had
discussed
last
time
like
these
are
like
these
are
guarantees
that
we
can't
break
there.
B
There
was
a
list
of
them
and
we
had
added
one
more
into
the
list
last
time
and
that's
what
completely
rules
out
execution
duplication
so
I
want
to
try
and
do
that
and
try
and
come
up
with
like
these
are
the
other
requirements
that
we've
had
not
not
necessarily
requirements,
things
that
we
want
to
try
to
achieve,
see
how
different
options
line
up
and.
B
D
Yeah
and
what's
interesting
is
part
of
our
goal.
We
can
like
do
execution
deduplication
on
current
stage
of
state
of
graphql
Js
and
because
yeah
it
will
benefit
entire
community
yeah.
Now.
D
A
So
I've
just
shared
a
link
in
the
chat
to
the
solution
criteria
for
the
input
Union
RFC,
and
in
this
effectively
we
came
up
with
a
list
of
individual
goals.
Basically,
we
didn't
really
throw
any
goals
out,
or
at
least
not.
Initially,
we
just
wrote
down
what
each
individual
person
felt
wanted
to
be
the
goals
we
grouped
them
together.
We
gave
them
good
names,
and
then
we
evaluated
each
of
those
goals
against
each
of
the
solutions,
but,
more
importantly,
you'll
notice
that
each
of
them
has
a
criteria
score.
A
There
were,
however,
other
ones
that
were
less
important,
like
a
member
type,
maybe
a
leaf
type,
which
was
e
that
had
a
lower
criteria
waiting,
so
the
things
that
we
as
a
group
feel
are
actually
less
important.
We
can
still
write
them
down
as
criteria.
We
can
still
evaluate
things
against
them,
but
we
can
give
them
like
a
lower
weighting.
So
if
it
fails
for
that,
but
it
passes
for
a
more
important
one,
then
it
might
still
be.
A
A
This
was
a
really
valuable
exercise
that
we
did
as
part
of
the
input
Union's
group
and
I
would
like
I
would
love
to
see
a
a
simple
resource
like
this,
where
each
of
these
is
described
in
very
you
know
like
one
sentence,
two
sentences,
maybe
with
a
couple
of
objections,
saying
why
we
shouldn't
aim
for
that
or
why
it's
not
important.
D
We
like
have
more
or
less
consensus,
but
about
what's
criteria
is
so
for
people
outside
with
group
to
propose
Solutions
it's
currently,
it's
it's
like
really
really
hard
for
somebody
outside
with
group
to
purpose
solution.
Making
this
document
or
iterate
on
some
solution
would
be
helpful
and
also
robto.
To
make
your
wife
easier
you
you
can
write
like
stops,
that
minimal,
stuff
or
stuff
that
you
feel
strong
about,
and
if
somebody
have
a
strong
opinion
about
some
other
criteria.
So
this
person
can
submit
PR
food
web
criteria.
B
Yeah
yeah
I'll
I
I
want
to
try
and
come
up
with
something
like
this.
The
the
only
thing
is
I
feel
like
we
have
a
like,
like
we're
talking
about
it
as
Benji's
proposal.
B
Yakov's
implementation,
but
I
feel
like
it's
really
like
a
a
matrix
of
possible
features
that
could
be
combined
in
different
ways,
but
I
think
that
I
I
just
need
to
spend
some
time
thinking
through
it
and
seeing
if
I
could
organize
it
into
something
like
this
I'm
I'm,
not
sure
that
I'll
be
able
to
do
it
before
the
meeting
on
Thursday.
B
So
maybe
we
should
post
on
that.
But
I'll
try
to
do
some
work
today
and
tomorrow
and
see
how
far
I
get.
A
A
Yeah,
okay
and
Ivan
is
right,
like
if
people
have
complaints
that
you
don't
necessarily
agree
with
this,
their
responsibility
to
add
them
to
the
document
and
also,
if
they
have
other
goals
that
you
don't
necessarily
agree
with,
then
it's
their
responsibility
to
add
up
to
the
document,
I'd
be
happy
to
sit
with
you,
for
you
know,
half
an
hour
hour
and
maybe
scratch
out
some
of
this
in
a
Google
doc.
If
that
would
be
helpful,
yeah.
A
Okay,
well,
we've
got
about
10
minutes
left
with
regard
to
what
we're
talking
about
at
the
at
the
working
group.
Do
you
think
a
a
much
shorter
version
of
the
presentation
that
we've
been
currently
using
to
propose
my
different
solutions
would
work
as
a
good
onboarding
there?
Do
you
think
it
covers
some
of
the
main
topics?
Is
there
anything
obviously
missing
from
that.
B
I
think
this
is
really
good
to
show
why
we
we
should
go
from
what
is
currently
merged
to
Maine
right
now,
which
is
duplication
and
branching
to
not
doing
execution
duplication
then
I
think
like
as
a
result
of
this,
like
there's
still
options
that
we
have
to
consider.
E
D
You
know
one
thing
I
suggest
like
to
have
also
a
positive
positive
note
and
say
we
figure
out
execution.
This
duplication,
I
think
it's
like
positive
and
it's
it's
like
because
from
outside.
Maybe
it
look
like
we're
stuck,
but
it's
actually
measurable
thing
that
is
actually
like
in
whole
with
discussion
and
it's
totally
of
work.
D
For
me,
it's
like
totally
made
it
more
and
to
say,
like
you,
have
a
guarantee
that
you
receive
the
same
even
like
yeah
and
don't
have
like
a
problem
with
semantics
or
walks
or
like
work
in
the
entire
operation
for
incremental
I.
Think
like
it's,
a
huge
progress,
so
I
would
I
would
share
that
as
a
way.
Yes,
maybe
before
or
after
discussion,
yeah.
B
All
right
cool
I'll
reach
out
to
Benji.
We
can
schedule
some
time
to
go
through,
go
through
the
criteria
and
yeah
see
you
guys
on
Thursday.
Then.