►
From YouTube: GraphQL Working Group (Primary) - 2023-04-06
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
I'm
only
going
to
be
able
to
be
here
for
the
first
30
but
yeah,
it's
small,
so
I'll
try
to
be
helpful
if
I
can
be
and
I
have
no
topic.
So
that's
fine.
D
Okay,
cool:
it's.
B
B
A
D
There
doesn't
seem
to
be
one
already
set
up
and
we
may
as
well
get
started
so
hello.
Everyone
welcome.
D
D
It
would
be
great
for
help
taking
the
notes.
I've
shared
the
link
to
the
doc
in
the
chat,
though
I
think
everyone
may
have
missed
that
so
I'm
going
to
paste
it
again.
D
There
we
go
cool,
so
we
only
actually
have
really
one
thing
on
the
agenda
this
week,
which
is
to
look
at
incremental
delivery
and
the
the
main
point
of
this
agenda
item
was
to
bring
it
to
the
wider
working
group's
attention.
D
Now,
all
five
of
us
I
believe
are
members
of
the
incremental
delivery
working
group,
though
some
of
us
may
be
not
as
up
to
date,
as
others
I'm,
not
sure
whether
it
would
make
sense
to
just
push
this
agenda
item
to
a
future
meeting
where
there
might
be
greater
attendance
or
whether
we
should
continue
to
discuss
it
now.
What's
your
general
feel.
B
So,
for
me,
for
me
it
would
be
brilliant.
I
would
be
updated
to
the
latest
bit
but
I,
don't
know
what
is
the?
How
up-to-date
is
the
user
group.
C
And
probably
the
least
up
to
date
and
honestly,
the
blob
that
Rob
posted
and
reading
through
that
and
like
that's
fine
I
can
I
can
keep
it.
D
Cool,
so
you
wanna,
you
wanna,
go
ahead
and
do
the
item
anyway.
Yeah
excellent,
okay,
I
I'm
not
going
to
review
any
of
our
previous
meeting
items.
Unless
anyone
is
aware
of
any
that
have
been
completed.
D
No,
in
which
case,
let's
move
straight
on
to
incremental
delivery,
I'll
pass
over
to
Rob.
E
Yeah,
so
the
biggest
the
big
thing
that
we've
been
discussing
for
a
while
now
is
deduplication
and
kind
of
like
just
background.
What
what's
merged
into
graphql
JS
now
and
what
is
expect
in
my
PR
is
a
algorithm
that
does
what
we've
been
calling
branching
and
no
sort
of
duplication
deduplication.
Basically,
every
time
it
comes
across
a
fragment
with
a
defer
starts
the
execution
right
there
with
those
fields
and
Returns.
The
results,
I
think
a
big
thing
that
came
up
in
the
last
working
group
meeting
that
we
discussed
it
is.
E
This
example
and
where
we're
saying
how
you
know
by
by
doing
this
type
of
branching
we'd,
be
calling
the
resolver
of
this
most
recent
common
field.
More
than
once,
you
could
get
different
results
and
what
we
generally
agreed
on
is
that
we
should
have
a
constraint
that
or
a
requirement
I'll
say
that
if
we're
sending
a
result
for
a
path
you
should
it
should
you
should
you
shouldn't
have
the
same.
You
shouldn't
get
different
results
for
the
same
path
that
shouldn't
really
be
possible.
E
So
since
then
Yakov
isn't
able
to
be
here,
but
he
did
a
lot
of
work
on
this
as
well
as
Benji,
and
one
thing
that
we
wanted
to
clarify
is
that
we
have
both
execution
and
duplication
and
response,
duplication
and
those
are
separate
things.
We
could
only
execute
the
field
once,
but
still
send
the
results
back
more
than
once
not
saying
we
want
to
do
that,
but
that
is
possible.
So
Yakov
did
some
work
and
he
actually
has
a
PR
on
graphql
JS.
That
doesn't
I.
E
Think
it's
not
actually
a
breaking
change
in
any
way
with
what
was
already
there
before,
but
it
changes
the
algorithm.
So
that
every
field
only
gets
executed
once
and
then
it's
it's
as
it's
going
down
through
the
fields
as
we
collect,
Fields
keeps
track,
of
which
defer
each
field
belongs
to
could
be
more
than
one
defer.
E
E
So
what
we've
been
talking
about
in
these
other
meetings
is
that
that
seems
like
a
straight
up
improvement
over.
What's
there
now
so
I
think
we're
going
to
work
on
getting
that
merged,
even
though
it
may
not
be
the
final
Direction.
But
since
it's
not
breaking
and
it's
an
improvement,
we're
gonna
work
on
that
I
do
want
to
call
attention
to
this
spec
PR
that
he
had
opened
up
a
while
back,
which
introduces
a
a
new
function
into
the
spec
text
for
collect
subfields
I.
E
Think
it's
called
this
already
exists
in
graphql.js
and
I
think
that
this
is
going
to
be
like
something
that
we're
going
to
need
just
for
any
kind
of
way
forward,
because
we
need
to
pass
some
metadata
through
collect.
Subfields
is
not
possible
with
the
merge
selection
set
function.
That's
in
here,
so
I
do
want
to
call
this
out.
If
anyone
has
time
to
review
it,
I
think
this
would
be
step
in
the
right
direction
that
we
need.
B
E
In
the
agenda,
but
I'll
put
it
in
the
chat
too
yeah,
yeah
and
so
to
decide
on
a
Way
Forward
I
worked
on
this
solution
criteria,
only
really
covering
defer
now,
but
we'll
expand
it
to
also
include
stream
and
I
have
things
labeled
as
either
critical,
major
minor
and
then,
as
we
compare
different
approaches,
we
can
use
this
as
a
criteria
over
how
we
want
to
rank
them.
E
I
can
talk
through
a
few
of
these
yeah.
The
first
one
clients
need
to
know
which
fragments
have
been
delivered.
That's
like
very
pretty
basic
we're
assuming
that
a
client
when
it
puts
a
bunch
of
fields
inside
of
a
single
defer
fragment.
That
means
it
needs
all
of
them
back
at
the
same
time,
there's
no
use
in
having
one
of
those
fields
without
the
others,
and
so
the
client
needs
to
know
when
those
fields
are
actually
there
so
that
it
could
render
the
component
that's
assigned.
E
That
is
that
corresponds
to
it
or
trigger
a
callback
or
something
the
client
needs
to
know
that
it
stuff
that's
been
deferred
is
resolved.
That's
the
main
idea
for
this
I
would
say
critical
criteria
up
next,
like
we
said
execution
deduplication,
we
don't
want
to
execute
the
same
field
more
than
once.
E
This
was
what
we
talked
about
in
the
last
meeting
with
the
final
reconcilable
object,
and
this
is
actually.
This
is
very
similar
to
the
previous
one,
but
it
means
that
there
shouldn't
be
different
data
for
the
same
path,
meaning
that
you
can't
apply
all
of
the
incremental
results
onto
the
original
object.
E
This
is
also
listed
as
a
as
a
major
criteria.
We
should
try
to
avoid
any
kind
of
ways
of
really
amplifying
the
results.
I
think
this
could
be
very
important,
especially
for
a
public
graphql
API
server.
There
shouldn't
be
like
really
obvious
ways
to
really
amplify
the
amount
of
data
the
server
will
produce.
E
Yeah,
this
was
I,
think
brought
up
by
Matt
and
it's
like
if
we
are
doing
like
the
type
of
pattern
where
fields
are
executed
separately,
we
shouldn't
really
return
them
to
the
client
before
they
could
even
be
used.
If
you
have
like
a
fragment
that
has
three
fields
in
it
and
two
of
them
are
ready,
the
client
can't
do
anything,
and
so
all
three
are
there.
So
there's
not
much
use
in
sending
them
ahead
of
time.
E
Fragment
consistency
is
we
don't
want
to
do
anything?
That's
going
to
break
this
underscore
underscore
type
name,
type
of
hack
that
you
could
use
to
identify
that
a
fragment
was
fulfilled.
There
shouldn't
be
a
state
where,
like
this
footer
Alias
on
type
name,
was
delivered
and
resolved
and
not
and
me
wasn't
resolved
yet
that
would
mean
that
the
client's
not
able
to
tell
that
the
whole
fragment
is
there.
C
So
I
have
a
comment:
if
you
go
back
one
slide,
this
is
kind
of
the
same
thing
as
both
enf
so
with
the
not
deliver
them
until
at
least
one
entire
deferred
fragment
is
completed.
So
the
major
requirement
is
that
the
server
must
provide
some.
C
The
server
must
tell
the
client
when
the
payloads
are
completed.
A
nice
to
have
requirement
I'd
argue
is
that
they
actually
happen
like
we
don't
end
up
with.
You
know:
100
tiny
payloads
in
order
to
complete
one
result,
but
he
that,
like
this
deferred
payload
is
completed,
could
happen
because
we
only
give
completed,
deferred
payloads
or
by
like
oh,
we
give
a
whole
bunch
of
results,
and
then
oh
at
this
point,
here's
all
the
things
we've
completed
and
either
of
those
seem
fine,
because
the
client
can
just
like
keep
accumulating.
C
The
client
needs
to
keep
accumulating
regardless.
It's
just
like
one
is
probably
a
nicer
experience,
because
you
don't
trigger
the
accumulation
path
as
often.
C
C
A
C
Okay,
yeah
yeah
this
that
makes
sense
to
me
yeah
I,
wonder
if
the
this
one
is
a
major
requirement,
but
it
also
probably
doesn't
matter
if
you've
already
got
it
like
implemented
as
is
but.
E
E
That
feels
there's
a
way
for
fields
to
be
deferred
independently,
like
the
type
of
solution
that
this
would
rule
out
is
that
every
single
field
and
every
defer
everywhere
in
the
whole
query
all
gets
returned
at
the
same
time,
once
everything
is
ready
versus
having
I
could
defer
these
field
Fields,
A
and
B
in
one
fragment
it
Fields,
C
and
D
in
another
fragment
and
field
C
isn't
going
to
hold
up
field
a
this.
B
Would
have
essentially,
because
we
once
discussed
merging
of
the
first
right
yeah.
This
would
be
essentially
ensuring
that
we
that
you
have
a
mechanism
to
to
ensure
that
this
is
not
happening,
or
that
means
that
we
are
not
merging
at
all.
E
Well,
I
think
I
think
just
because
it's
a
solution
criteria,
that's
considered
major,
it's
just
something
that
we're
going
to
evaluate
a
result
on
and
maybe
there's
an
idea
that,
like
scores
highly
in
all
the
other
ones,
and
doesn't
do
this.
But
there's
like
it
could
be
argued
that
that's
the
way
we
want
to
go,
but
just
to
have
this
documented
as
a
thing
that
I
think
is
it's
major.
It's
pretty
important
and
exactly
how
it's
done
will
depend
on
like
what
the
actual
solution
we
go
with
is.
C
C
Yeah
so
that
I
think
is
likely
a
minor
criteria
of
like
oh
Fields,
within
a
defer
that
could
be
reconcilable
to
the
same.
Defer
can
be
done
independently.
That's
like
a
minor
thing
that
we
might
get
with
like
fragment,
aliases
or
something
like
that
yeah,
but
yeah
so
possible.
It
basically
yeah
just
quick
feedback.
Possibly
this
is
split
to
be
like
the.
B
Top,
but
how
was
it
meant
Rob?
Were
we
talking
about
fears
in
the
same
past,
where
I
essentially
have
two
differs
around.
D
D
There's
there's
the
deferring
the
email
I
want
to
do
at
the
root
level
as
well
like
where
you're
opening
separate
branches,
so
those
are
all
sibling
Fields
anyway,
so
I
think
even
for
the
case
of
sibling
Fields,
it's
still
major.
It
might
be
that
we
go
for
a
trade-off
where
you
know
we
make
some
concessions,
but
still
have
most
of
this
but
I
think
as
a
general
thing,
it
is
still
major
personally.
B
Yeah,
the
question
is
a
bit
when
you
think
in
fragments
right
you
you
could
have
in
various
Preference
defers.
They
are
actually
on
the
same
level
and
you
don't
necessarily
intend
to
have
like
a
multiple
defers
there.
It's
just
a
new
component.
You
said:
okay,
this
can
be
deferred.
E
But
the
way
I
intended
it,
it
was
it's
to
be
like
intentionally
vague,
whereas
a
solution
that
literally
only
returns
two
payloads
one,
that's
everything
initial
and
one
that's
everything
deferred
would
fail
this,
but
a
solution
that
defers
every
single
deferred
fragment
on
its
own
would
pass
it
or
even
one
that
merged
everything
in
the
same
path
would
also
pass
it
because
you
could
do
tricks
with
aliases
too
yeah.
Okay
achieve
what
you
wanted.
C
Yeah
I
think
in
the
doc
we
actually
put
up,
or
you
actually
put
up
having
the
explicit
hey
this
is
this
would
allow
for
merging
of
same
path.
Defers
that
is
not
like.
Not
merging
them
is
not
part
of
this
criteria.
B
Yes,
it's
a
bit
difficult
to
really
get
the
intent
of
the
user
here
right,
that's
yeah!.
B
E
Is
meant
just
as
like
the
first
draft
and
definitely
welcoming
input
and
not
yeah,
and
then
so
so
this
one
I
I
think
that
it's
still
pretty
important
servers
can
inline
individual
differs
or
streams
for
various
reasons:
server,
performance,
yeah
and
there's
a
couple
different
reasons
that
we've
discussed
over
the
past
yeah
and
then
something
else
is
how
to
handle
non-null
violations.
And
this
this
one
is
definitely
like
the
least
concrete
out
of
all
the
ones
that
I
wrote.
E
I
think
this
is
this
really
just
describes
an
example,
but,
like
I
think
we
there
just
has
to
be
like
a
cohesive
way
to
handle.
Not
null
violations
and
I
from
here.
I
think
I
can
hand
it
over
to
Benji
to
talk
about
the
proposal
that
he's
worked
on.
D
Yeah
sure
thank
you
Rebel,
so
we've
we've
covered
the
sort
of
many
of
the
aims
that
we
care
about
so
I'm
just
going
to
quickly
go
over
some
of
the
solutions
that
we've
discussed.
A
D
A
D
D
Some
of
the
solutions
that
we've
looked
up
before
one
was
to
track
everything
like
log
it
all
to
some
Global
kind
of
cash
object,
whether
it's
been
delivered
or
not,
which
may
well
work,
but
it
does
have
a
lot
of
trade-offs,
one
one
of
which
is
that
it's
complex
for
the
server
potentially
High
memory
requirements
as
well,
but
also
I,
think
it's
quite
unpleasant
to
factor
that
into
what
the
spec
edits
would
have
to
be,
and
it's
just
not
ideal.
D
We
could
have
the
spec
itself
enforced,
that
everything
is
cached,
but
this
seems
I've
put
distasteful,
not
ideal.
We
could
do
well.
We
thought
about
doing
forking
with
independent
execution.
In
fact
that's
what
we
have
already,
but
as
we've
already
discussed,
that
doesn't
work
if
we
execute
the
same
thing
multiple
times,
because
we
can
end
up
with
objects
that
we
can't
merge
together
or
various
other
situations.
D
One
of
the
options
that
we
considered
was
thinking
of
it
from
the
point
of
view
of
rewriting
the
query.
So
could
we
rewrite
the
query
so
that
it
had
defers
in
different
positions,
but
it
turns
out
even
this,
even
with
different
ways
of
rewriting
the
query
will
not
solve
those
underlying
problems
if
we
still
allow
branching,
it's
still
problematic,
so
that
was
not
a
solution
that
we
could
follow.
D
Another
option
is
only
one
level
of
defer,
but
we
decided
that
that
doesn't
give
us
enough
functionality,
so
we
needed
to
to
disable
that
option
as
well.
So
what
I
think
we
should
do
is
we
should
embrace
the
field
merging
algorithm
that
we
already
have
in
the
graphql
spec
and
see
how
we
can
modify
field
merging
to
work
with
this,
so
the
idea
is
build.
Merging
already
makes
it
so
that
we
only
execute
each
field
at
each
path
once
and
we
only
deliver
each
field
at
each
path.
D
So
I
had
a
look
at
implementing
this
and,
as
Rob
said,
this
could
be
based
on
yakov's
pull
request
999
that
we
had
a
glance
at
earlier
to
start
with.
I
came
up
with
this
idea
of
having
like
defer
layers
where,
when
you
see
a
defer
that
introduces
a
new
layer
and
then,
if
you've
got
a
defer
inside
of
that,
that
would
be
like
a
nested
layer
and
you'd
effectively
merge
all
of
the
defer
layers
at
each
point.
In
turn,
this
would
have
a
number
of
drawbacks.
D
One
is
that
it
wouldn't
allow
independent
execution
of
sibling
Fields,
even
if
they're
in
aliased
parents,
which
is
problematic
and
the
property
of
it
was
or
at
least
the
way
that
it
was
written,
was
that
a
two
nested
defers
at
the
same
level
so
in
the
same
selection
set,
would
just
collapse
together
and
that
actually
had
consequences
in
various
different
layouts
of
the
query.
That
might
not
initially
be
obvious,
and
there
was
a
few
oversights
in
the
spec
edits
that
I
drafted
out,
which
Rob
helpfully
pointed
out.
D
I've
not
bothered
to
fix
those.
Because
after
much
discussion,
I
came
up
with
an
alternative
which
works
on
the
concept
of
incremental
paths.
D
So,
if
you
think
of
a
path,
rather
than
being
the
string
path
that
we
normally
think
of,
think
of
it
in
terms
of
the
actual
selection
objects
like
the
field
selection,
the
fragment,
spread
or
inline
fragment
spread
any
of
those
that
have
a
defer
on
them
effectively
build
up
a
path
for
each
field
and
when
I
say
field
I
don't
mean
a
field
at
a
given
path.
D
I
mean
literally
a
field
in
the
query,
like
a
field
in
the
collect,
Fields
sense,
where
you
take
lots
and
lots
of
fields
that
represent
the
same
path
and
you
put
them
into
the
same
set
I'm
talking
about
the
individual
entries
in
that
set
in
the
graphql
spec.
Currently,
when
we
do
collect
fields,
we
build
up
that
set
and
then
generally,
we
just
take
the
first
item
in
it,
because
we've
already
validated
that
all
the
items
inside
are
basically
the
same
other
than
their
selection
sets.
D
In
this
we
wouldn't
be
doing
that
we'd
actually
be
looking
at
all
of
them,
but
we
already
have
that.
As
part
of
collect
field,
so
it's
an
interesting
thing
to
do
thus
only
executing
each
field
once
and
only
delivering
each
field
once
would
just
be
a
natural
consequence
of
the
way
of
building
this
based
on
collect
Fields.
There
wouldn't
need
to
be
any
explicit,
like
caching
and
things
like
that.
B
D
D
Yeah
I
I
hear
what
you're
saying
I'd
have
to
look
concretely
at
the
actual
spec
edits
to
answer
that,
but
I
think
because
of
the
way
that
collect
Fields
works.
It
only
looks
at
one
level
anyway,
so
the
index
isn't
actually
important
at
that
point.
Yeah
all
you
care
about
is
why
it's
deferred.
You
don't
care
about
actually
what
index
it
it
is
in
like.
D
D
Thing
really,
anyway,
so
the
the
collect
Fields
would
split
things
into
things
to
execute
now
and
things
to
execute.
Later
you
execute
all
the
narrow
stuff,
and
then
you
move
on
to
the
next
bit,
which
is
when
later
becomes
narrow,
and
you
do
the
same
thing
again
walking
through
all
the
selections.
Now
there
is
some
interesting
things
that
actually
have
to
go
on
to
make
this
work,
but
there's
some
really
interesting
side
effects
of
this,
one
of
which
is
that
the
annoyingly
I've
deleted
that
slide.
D
Each
Leaf
will
only
be
delivered
once
and
when
we
come
to
merging
in
the
results,
we
only
would
be
doing
additive
mergers.
So
if
you've
got
a
list
with
a
stream
you'd
just
be
adding
to
the
end
of
it,
appending
to
the
end.
If
you've
got
an
object
that
already
had
previous
Fields,
the
only
thing
you'd
be
doing
is
adding
new
keys,
you'd,
never
overwrite
old
keys
or
do
any
deep
merging.
You
wouldn't
need
to
do
any
of
that
you're
only
ever
adding,
which
massively
simplifies
the
work
that
the
client
needs
to
do.
D
D
The
other
I
think
the
major
issue
from
my
point
of
view
about
this,
the
main
reason
that
we
might
consider
rejecting
it,
but
honestly
I
think
it's
worth
it
not
to
is
that
the
error
bubbling
Behavior,
which
is
essentially,
if
you
have
a
deferred,
fragment
that
overlaps
with
a
non-deferred
bit
or
with
a
different
deferred
bit.
D
If
you've
already
sent
parts
of
this
fragment,
because
it
was
already
in
previous
payloads,
you
can't
override
a
field.
That's
already
been
delivered.
D
Error
would
then
blow
up
and
you
can
think
of
it
as
if
you
remember
client-controlled
null
ability
you
can
think
of
it
as
any
shared
field.
Inside
of
this
fragment
is
treated
as
if
it's
got
the
the
exclamation
point,
the
bang,
to
say
this
is
non-nullable.
So
therefore
it
would
blow
up
the
whole
thing.
D
So
that's
the
main
thing.
So
then
I
just
wanted
to
look
at
some
of
the
actual,
like
queries
and
payloads
that
we
might
get
with
this
I'm
going
to
turn
on
the
laser
pointer
for
fun.
A
D
Right
now,
first
thing
I
want
to
note,
is
I've
put
labels
in
here.
Labels
are
entirely
optional
and
the
reason
I
put
them
in
in
Gray
is
because,
if
you
were
to
remove
this
label
here,
then
this
text
here
would
go
away,
but
everything
else
would
be
exactly
the
same.
Labels
don't
influence
the
grouping
of
anything
in
this
solution
at
all.
They
are
purely
there
as
metadata
for
the
client.
So
if
the
client
wants
to
know
tell
me
when
this
defer
has
been
completed,
then
that's
the
information.
The
way
of
getting
that
information.
D
You
could
do
it
with
the
dunder
type
name
hack,
that
we
discussed
earlier
or
with
other
approaches,
but
this
is
one
way
of
doing
it.
So
here
we
look
at
this
query.
We
look
at
everything
that
is
not
deferred
and
we
deliver
that
in
the
first
payload,
and
then
we
notice
that
there
are
things
that
are
going
to
be
deferred,
so
we
say:
there's
a
pending
it's
at
the
pass
f2cf,
because
there
is
nothing
before
that
that
hasn't
already
been
delivered.
D
So
f
is
where
things
start
to
change
with
the
JK
and
the
LM
fields
that
are
coming
later,
so
we
say:
there's
this
path
here,
that's
pending
and
also
this
relates
to
our
defer
D1.
D
We
have
an
incremental
payload
that
comes
later.
That
gives
us
this
JK
field.
Here
it
is
your
J
and
your
k
at
the
path
that
is
specified
by
ID
0..
So
we
don't
need
to
repeat
this
path
down
here.
We
can
reference
it
just
using
its
ID
and,
as
you
can
see,
this
is
an
additive
change,
we're
just
adding
the
JK
so
effectively.
It
would
be
inserted
in
here,
and
then
we
say,
and
also
there
is
another
pending.
D
It
turns
out
it's
this
defer
here,
D2
at
the
same
path,
and
then
we
have
a
final
incremental
payload
that
gives
us
our
l
and
m,
and
we're
done
so
that's
a
reasonably
straightforward
example.
D
Labels
are
optional.
Here
is
a
more
complicated
example
that
shows
this
overlapping
behavior
that
I
mentioned
just
now.
So
in
this
case
we
have
a
whole
bunch
of
these
defers
and
all
of
them
have
this
bio
field.
Every
single
one
of
them
has
this
biofield,
so
we
happen
to
know
that
the
ID
field
executes
first
right.
It's
already
known
all
the
others
need
to
be
looked
at
from
the
database,
ID's
already
known,
or
something
like
that.
D
So
when
that
comes
in,
we
get
this
ID
field,
but
we
also
get
this
bio
fields
that
all
of
these
are
shared.
So
this
ID
12
gets
two
payloads.
One
is
the
shared
bit.
One
is
the
ID
itself
and
then,
when
it's
done
it
says
yeah
I'm
done
now,
and
now
we
know
that
ID
12
in
this
list
is
now
complete.
D
These
should
technically
I
realize
looking
at
it
now
being
the
opposite
order,
so
that
the
bio
field
comes
after
the
ID,
so
that
we
can
maintain
the
order
of
the
fields.
But
that's
not
super
important.
It
would
just
be
switching
these
two
and
then
in
a
later
incremental.
Maybe
all
of
these
other
fields
all
came
at
once.
The
name
age
date
of
birth,
Avatar
joined
at
last
scene
and
location.
So
here
they
are
name
age
date
of
birth,
Etc
and
each
of
those
complete
for
those
zero.
D
Three,
six
and
so
on,
but
we've
still
got
the
pending
ones
for
the
other
friends.
So
that's
how
that
would
work
with
the
merging.
D
This
shows
where
we
have
two
overlapping
defers:
they're
overlapping,
even
though
the
defers
happen
at
different
levels.
They
both
have
the
me
item
list
and
item
Fields
here,
the
pink
ones.
So
initially
we
deliver
the
me
because
it's
not
deferred
here
and
everything
else
is
deferred.
So
it's
just
an
empty
empty
object.
Here
we
say
that
we've
got
D1
and
D2
are
due
to
come,
and
then
we
do
this
shared
payload
which
doesn't
complete.
It
doesn't
have
a
done
true
on
there.
So
here's
a
shared
payload.
D
Then
we
satisfy
the
ID
field,
so
the
blue
field,
for
each
of
those
items,
you'll
note
that
we've
used
this
shared
path
from
ID
0
and
then
we've
added
we've
appended
a
subpath
to
it
to
so
it
would
be
me
list.
Zero
item
me
list,
one
item
and
then
the
ID
field,
once
we've
done
all
those
done
is
true.
That
means
that
our
D1
fragment
is
complete.
So
this
defer
is
now
complete
and
later
we'll
get
an
incremental.
That
will
give
us
all
of
the
value
fields.
D
We
know
at
that
point
that
these
have
already
been
delivered,
so
it's
just
delivering
those
and
again
we
do
done
true
at
the
end
of
that,
and
that's
it
done
for
that
style
of
list.
A
D
Which
shows
two
overlapping
things
with
key
and
value,
but
without
any
shared
properties,
that's
those
being
delivered
and
they
can
be
delivered
in
any
order,
doesn't
matter,
but
they
will
still
be
consistent
and
then
here
is
the
same
example
again,
but
this
time
adding
in
that
shared
ID
field.
So
it
shows
you
that,
because
we
now
have
overlapping,
even
though
they
weren't
previously
overlapping,
what
we're
doing
is
introducing
this
initial
shared
payload.
For
each
of
these,
this
one
happens
to
come
with
the
key.
D
This
one
happens
to
come
with
a
value
for
the
second
record.
It
doesn't
matter
so
long
as
this
one
is
here
before
the
id2
comes,
and
this
one
is
here
before
this
key
here
comes
everything's,
fine
and
finally,
because
I
know
I've
been
talking
for
a
while.
D
This
one
shows
how,
if
you
have
fragments
at
the
same
level
that
are
deferred
within
each
other,
how
that
would
work.
So
in
this
case
we
load
our
project,
synchronously
well,
I,
say
synchronously.
We
load
our
projects
initially
and
we
defer
loading
our
billing
data,
so
here's
our
ID
Avatar
and
projects.
D
Then
we
get
billing,
which
gives
us
our
tier
renewal
date
and
latest
invoice
total.
But
then
we
have
these
previous
invoices
that
we
wanted
to
load
and
that's
a
much
more
expensive
field.
So
we
want
to
do
that
afterwards.
It's
still
part
of
the
billing
widget,
but
it's
a
sub
part
that
can
be
loaded
later.
So
we
defer
that
at
this
point
and
then
that
can
come
in
through
this
final
payload.
D
So
that
is
essentially
what
I'm
proposing
based
on
the
field:
merging
algorithms,
with
a
few
accommodations.
E
Yeah
in
the
the
spec
algorithm,
it's
it's
doing
something
like
making
a
some
a
record
for
every
for
every
defer
and
then
assigning
the
fields
that
are
be
executed,
executing
for
it
into
a
list
and
but
if
there's
overlapping,
Fields
it's
the
same.
The
same
reference
to
the
same
object
for
that
field
would
go
in
both
lists
and
then
we
would
store
like
store
a
flag
on
it.
That
says
it
was
delivered.
So
you
know
to
skip
it
when
you're
doing
the
other
one
or
put.
D
E
Reference
in
like
a
in
an
array
in
a
set
somewhere
that
says
this
one
or
keep
track
of
a
set
of
like
all
the
fields
that
have
been
delivered
already.
B
Do
we
have
already,
like
you
said,
do
we
have
already
some
spec
edits
for
this.
D
We
have
spec
edits
for
an
earlier
version
of
this,
which
was
the
the
1A
that
I
found.
Okay,
I
haven't
had
time
to
write
up
this.
This
2C,
yet.
E
And
we
have
spec
edits
for
the
one
that
I
did,
that
grouped
everything
by
path,
yeah,
but
I
think
we
would
it's
very
similar
to
that.
Just
not
doing
it
by
deferred
path,
but
by
doing
it
by
the
actual
defer,
fragment,
spread.
D
Yeah
effectively
slightly
different
to
what
Rob
said
for
the
the
Gathering
of
the
data
effectively,
it
would
be
we're
currently
in
collect
fields.
We
we
build
this,
this
map
from
the
response
key
to
a
set
of
fields
that
that
match
that
response
key
instead
of
having
the
fields
for
each
of
those,
we
would
have
a
record
that
contains
the
field,
and
some
additional
information,
often
like
one
of
the
pieces
of
additional
information,
would
be
the
parent
value
yeah.
Something
like
that,
so
that
we
don't
need
to
reevaluate.
It.
E
I
think
it
would
actually
like
delete
a
bunch
of
code
out
of
his
implementation
to
get
to
what
we
have
here.
E
But
I
think
he
did
all
the
work
of
annotating
the
fields
during
the
collect,
Fields,
algorithm
and
handling
the
execution
of
them.
B
D
The
graphql.js
implementation
and
he's
also
written
up
a
spec
PR
for
it
as
well.
So
there's
a
lot
of
information
there.
B
D
Yeah
I
agree,
but
I
should
mention
that
the
ID
is
barely
interchangeable
between
Solutions,
so
we
can
decide
on
using
that
separately.
But
it
is
my
preference
because
without
it
you
you
a
have
to
do
that.
Navigation
on
the
client
a
lot
more
and
B.
It
inflates
the
the
payloads,
so
I
do
prefer
to
have
the
ID
yeah.
B
Otherwise,
you
have
to
always
look
really
at
the
past
and
yeah,
it's
very,
very
nice
to
reason
about
the
stream
how
it
belongs
together.
F
Can
you
share
like
a
euro
to
presentation.
D
It's
already
in
the
chat
presentation
in
the
euro.
F
So
it's
like
one
presentation:
it's
not
two
separate
presentation.
You
and
The
Rock
basically
showed
once
swipe
deck
right.
Okay,
now
I
get
it.
F
Actually,
like
in
the
middle
I,
had
the
call
in
the
middle
I
needed
to
respond
to
some
some
stuff,
so
I
will
watch
a
recording
one
thing
I'm
like
I'm
thinking
about
is
that
currently
we
assume
by
default
fragmented
dependent
and
we
go
into
a
lot
of
trouble
to
make
some
concurrent.
B
A
B
E
A
E
Do
any
merging
based
on
labels
or
anything
it
just
if
they're
there
they're
used
to.
F
Yeah,
what
I
kind
of
like
is
your
previous
proposal,
where
we
treat
the
first
layers.
One
was
quite
squash,
everything
together
and
I.
Think
it's
like
in
a
sense.
F
Heaven,
like
basically
like
everything,
squashed
together
on
the
same
level
and
ship
there's
the
same
book,
except
if
you
put
like
a
label
and
stuff
with
the
same
level,
merge
together.
So
it's
like
basically
very
very
similar
to
what
you
do
right
now.
The
big
difference
is
that
stuff
is
like
merged
and
squashed
by
default
and
to
to
signify
that
you
actually
need
stuff
to
be
independent.
F
You
adorable
and
if
you
add
the
same
variable
to
a
couple
different
fragments
the
shipped
like
on
the
same
deferral
label
so
like
like
you
to
a
right
or
like
where,
by
where
thing
onion
proposal,
I
would
call
that
onion
proposal
so
like
in
onion
proposal
I,
like
combination
with
weibose
I,
think
like
one
way
or
and
I
would
think
if
it
can.
So
like
all
the
issues
or
not
because
like
in
a
in
a
current
proposal,
it's
like
too
much
things
happening
and
we
don't
like.
F
Basically,
we
give
fragment
influence
on
response
like
what
I
like
in
your
question
proposal.
Everything
is
squashed,
number
of
like
items
and
overheads
of
DeForest
pretty
wall
by
default,
and
it's
also
very
deterministic
by
default.
So
I
know,
as
you
had
like
labels,
you
will
always
get
the
same
pivots
in
the
same
order.
You
will
never
get
like
anything
in
different
order,
so
it's
good
for,
like
quotation
for,
like
everything,
is
predictable,
it's
not
predictable
how
much
time
it's
take
to
get
like
a
second
layer,
but
it's
predictable.
F
The
second
layer
will
come
and
obviously
you
can
make
way.
It
was
predictable
by
the
labels
and
in
West
case
like
Starships,
like
whatever
red
label
is
ready
first,
but
by
default
it's
like
deterministic
and
by
default.
That's
why
cover
head
as
well
so
I'm,
like
still
thinking
onion
proposal,
is
like
really
good
and
for
me
it's
like
fit
Spirit
of
wait,
not
Spirit,
but
wait.
Mental
model
graphql
today
fragments
are.
F
And
also
like
stuff
gets
matched.
Is
this
so
it's
like
onion
proposal,
it's
so
logically,
it's
like
you
put
before
on
a
fragment,
but
you
really
put
the
four
on
the
field.
In
a
sense,
it's
like
yes,
I
will
try
to
think
I
will
walk
from
from
slides
and
try
to
think
it's
possible
to
push
like
onion
proposal
to
to
meet
the
more
criterias
solution
criteria
that
it
does
today.
E
I
feel
like
it
is
easier
to
test
easier
to
conceptualize
what
the
response
is
going
to
be,
but
I
feel
I.
My
gut
feeling
is
that
that's
not
what
people
who
are
writing
defer
are
going
to
want,
like
the
the
it's
just
basically
going
to
be.
Everyone
is
going
to
write
a
unique
label
just
for
the
reason
of
having
them
not
be
tied
to
unrelated
parts
of
the
the
query.
E
F
Yeah
I,
actually
I
I.
Think
if
you,
if
you
boys,
in
a
way
that
if,
if
stuff,
is
automatically
composed,
as
we
discussed
like
even
initial
proposal,
I,
don't
remember
if
it
was
much
much
said
or
somebody
else
like
they
will
do
unique
labels
anyway
in,
like
oh,
so,
I
think
like
complex
Frameworks
people
who
use
complex
Frameworks.
Is
there
a
way
for
them?
It
will
be
invisible
thing,
people
who
use
waikapoa
and
how,
like
20
fragments
they
need
to
manage
it
by
hand
in
a
sense
not
by
hand
up
or
provide
something.
F
But
basically
you
don't
you
you
don't
have
like
a
component
title
fragment
you
get
like
you
get
like
some
I
think
I
need
to
to
look
like
how
Apple
implemented.
F
D
So
I
completely
disagree
with
that.
Being
someone
who
writes
queries
by
hand,
one
of
the
things
is:
if
I'm
writing
it
by
hand
anyway,
then
I'll
put
the
defers
where
I
want
them
to
be
right:
I'm
not
going
to
need
the
system
to
merge
my
defers
together
for
me,
because
I
will
specifically
put
them
around
the
things
that
I
want
deferred
independently
and
separate
separately.
D
One
of
the
use
cases
that
I
have
for
for
defers
is
for,
like
a
like
a
reporting,
dashboard
style
thing
where
you
have
a
lot
of
widgets
and
those
widgets,
you
know,
have
top
level
data
and
then
often
they
have
like
further
deeper
data
that
they
need
to
get
so
they
might
have
like
a
headline
figure
and
then
they
have
like
a
full-on
graph
or
like
a
plot
and
I
want
these
to
come
in
as
they
are
ready
and
it
might
be
like
the
sixth
one
loads
in
first
and
then
this
one
and
then
the
graph
appears
and
then
so
on
and
so
forth.
D
D
Now,
if
I
didn't
want
them
all
deferred
like
if
I
wanted
them
deferred
together,
then
I
just
put
them
in
one
defer,
fragment
right,
I
wouldn't
put
them
deliver,
there's
more
typing
to
put
them
in
separate
defers,
so
I
feel
like
if
the
programmer
is
saying
I
want
these
in
separate
to
first.
We
should
probably
respect
that.
F
Is
kind
of
in
the
middle
people
usually
put
fragments
near
the
components,
so
they
don't.
So
there
is
like
three
paradigms
right
away.
It's
like
it's.
You
tied
the
fragment
to
a
component
and
everything
assembled
after
magically
the
rest,
like
your
Paradigm
when
you
handcraft
the
thing
and
the
rest
like
thing
in
the
Middle,
where.
F
D
E
F
Yeah,
you
probably
don't
want,
basically
in
where
proposal
you
how
I
couple
of
renders,
but
you
have
like.
Initially,
you
have
like
initial
data
and
bunch
of
like
spinners
and
when
you
have
like
one
way
of
components
rendered
in
one
go
and
one
way
yeah,
and
it
will
look
weird
and
yeah
in
that
first
scenario.
I
agree,
it's
kind
of
like,
especially
if
it's
like
really
heavy
data
like
statistics
or
something
basically
like
something
simple
Woodstock
on
something.
D
The
other
comment
that
I
have
on
this
is
originally
I
was
quite
a
big
proponent
of
merging
the
defers
together,
but
that
was
when
we
had
forking
when
we
had
branching,
because
merging
them
together
was
solving
a
lot
of
that
repetitive
delivery
of
the
data
on
the
duplicate
execution
and
all
that
other
stuff
it
was
It,
was
kind
of
squashing
it
together
as
a
you
know,
as
a
side
effect
like
that's
why
I
was
a
proponent
of
it,
but
now
that
we've
decided
that
we
a
shouldn't,
be
executing
Fields
more
than
once
and
I
think
that
is
a
concrete
requirement
at
this
point
like
we
are
actually
backporting
that
into
the
existing
implementation
of
stream
and
defer,
so
not
executing
things
twice,
I
think
is
concrete.
D
Not
delivering
things
twice.
I
think
is
a
fairly
reasonably
obvious
extension
that
we
should
aim
for
I.
Think
it's
very
important
I,
don't
see
any
value
in
delivering
things
twice,
but
it
is
a
separate
concern,
as
Rob
mentioned
earlier,
but
again
with.
If
we
can
avoid
both
of
those
things,
then
the
reason
for
merging
these
defers
together
kind
of
goes
away
really
like
there's,
not
a
huge
amount
of
additional
cost
to
delivering
these
things
separately
versus
delivering
them
all
together.
D
The
the
amount
of
data
being
sent
over
the
wire
is
not
much
bigger.
The
amount
of
work
that
the
client
needs
to
do
is
really
not
much
bigger,
and
it
gives
us
more.
It
lets
the
user,
be
more
expressive
about
what
order
of
operations
they
need
to
happen
even
potentially
doing
a
defer
inside
of
a
defer
at
the
same
level
of
the
selection
set
can
be
enabled,
and
that
is
exactly
what
I
would
want
to
do.
In
my
widgets
example,.
F
Yeah
good
words
that
we
have
solution
criterias.
Now
it's
a
it's
when
I
will
think
I
will
have
like
a
list
to
compare
and
so
definitely
wait
forward.
D
F
D
D
Think
this
lists
the
Rob
has
prepared
is
worth
additional
discussion
and
a
lot
of
what
we've
done
today
is
like
surfacing
those
topics
but
I
think
some
actual
debate
around
each
individual,
one
like
whether
it
is
high
or
low,
like
we
had
today
the
discussion
of
whether
the
certain
criteria
like
what
does
it
mean?
Should
this
be
two
one
where
one
where
one's
major
and
one's
minor,
that
kind
of
stuff
I
think
would
be
valuable
but
other
than
that,
like
I,
haven't
made
any
further
progress
on
my
proposal
currently.
B
D
B
Like
Monday
is
like
in
Germany
and
Switzerland's
Eastern.
A
D
Let's
skip
Monday
Rob.
Can
you
reach
out
to
the
relevant
authorities.
F
Yeah,
what
what
one
thing
to
prepare
to
make
like
with
process
of
discussion
effective,
so
what
you
have
in
mind!
It's
like
we
will
get
one
criteria
and
have
around
or
around
of
a
table
and
discuss
it
and
brainstorm
like
on
the
spot
or
preparing
PR's
more
effective.
What
what's
your.
B
We
feel
what
would
be
great
is
if
we
get
the
graphql
Js
for
requests
that
we
have
there
reduced
to
the
part
that
we
think
it
should
be.
B
F
D
I
think
one
of
the
most
important
things
is:
if
you
have
more
solution
criteria,
even
if
they're
not
ones
that
you
necessarily
think
that
we
definitely
need
right,
they're,
just
things
that
you
think
would
be
nice
to
have,
and
let's
get
them
in
that
list
like
it
would
be
great
to
add
them,
so
those
should
be
done
through
pull
requests.
If
you
build
any
of
the
content
that
Rob
has
written,
is
unclear
or
has
a
mistake
in
it
or
anything
like
that.
D
That
should
be
a
pull
request,
a
separate
one
that
fixes
one
small
issue
and
Rob
can
look
at
that
and
decide
whether
or
not
he
agrees
if
he
doesn't
agree.
It's
a
discussion
point
if
he
does
agree,
it's
a
merge,
yeah
but
I
think
when
it
comes
to
the
actual
waiting
of
them,
then
that
is
more
a
discussion
and
it
won't
I,
don't
think
we'll
just
go
through
them,
one
by
one,
because
I
think
a
lot
of
them.
We've
we've
been
discussing
this
for
many
weeks
now
between
the
whole
group
right.
D
So
many
of
them
are
fairly
consensus
anyway.
So
what
I
think
it
would
be?
Is
we
open
it
to
the
room
for
someone
to
say
I,
don't
feel
that
this
one
should
be
a
major
I,
think
it's
minor
I
think
this
one
is
critical
or
whatever,
and
then
we
discussed
that
that
one
that
is
controversial
rather
than
going
through
each
one.
In
turn,.
A
B
B
But
regarding
Solutions,
so
so
the
the
solution
you
guys
are
working
on
or
the
The
Proposal
that
you
you
guys
made.
That
is
something
like
that
is
something
where
you
feel
that
we
we
should
go
or
is
it?
Are
we
still
like
just
throwing
things
on
the
wall
and.
D
One
of
them
is
yaakov's
solution,
of
which
we
will
probably
be
adopting
part
of
it
into
graphql.js,
currently
to
fix
the
existing
double
execution
issue
that
needs
to
be
solved
because
it's
a
major
issue
as
raised
by
kwaku,
but
then,
based
on
that
there
is
the
further
extension
of
yaakov's
solution
that
may
be
a
better
fit
for
streaming
defer
overall,
there's
my
proposal
that
is
based
on
field
merging,
which
borrows
a
bit
from
Rob's
proposal
and
there's
Rob's
proposal,
which
I
think
is
also
quite
similar,
that
borrows
a
bit
from
mine,
but
they
are,
they
are
different
but
like
a
bit
overlapping
and
I
think
we
are
sort
of
trying
to
Ferry
them
all
like
to
find
what
this
this
ultimate
final
location
is
so
I
think
we're
still
iterating
on
all
of
them.
D
That
was
my
proposal,
the
field
merging
proposal,
which
is
an
evolution
of
the
one
that
I
proposed
just
just
under
a
month
ago,.
B
Okay,
but
like
we
crossed
a
couple
of
Solutions
in
the
beginning
of
the
presentation.
So
what
are
the
competing
solutions
that
we
have
now
at
the
moment.
D
You
present
yeah,
which
I
think
has
spec
PR
and
jspr
I.
Think
they're
both
up
to
date,
is
that
right,
Rob
yep
we've
got
my
one,
which
is
literally
these
slides.
I
did
have
spec
edits
for
a
previous
version
of
this,
but
they
are
not
right
for
this,
and
I
need
to
spend
some
time
rewriting
them.
Yeah
and
we've
got
Rob's
one
which
has
actual
more
up-to-date
spec
edits
that
handles
things
like
the.
E
I'm
withdrawing
mine
because
because
I
I
mean
I
think
there
was
a
lot
of
there
was
like
a
good
amount
of
pushback
against
the
deferring
and
I
think
that
I
agree
as
well,
like
my
mine
was
the
version
that
is
the
same
as
yours,
but
does
all
the
batching
at
the
defer
path
level
instead
of
of
the
each
individual
deferred,
fragment
and
I.
Think
that,
with
your
arguments
of
it's
not
necessary,
you
like
to
do
that
when
we
have
the
results
being
delivered,
the
way
they
are
I
I
think
it
makes
sense
to
withdraw
it.
D
Okay,
excellent
well
I'll
be
merging
somewhat
of
your
PR
into
mine.
Anyway,
I
mean
they
are
they're
very
similar.
We've
bounced
ideas
off
of
each
other.
Quite
a
lot
like
it's
definitely
a
collaborative
effort,
yeah
cool,
so
those
are
the
two
main
ones.
Then
I
guess
is
mine
and
robs
and
yakovs.
E
Yeah
and
and
the
real
difference
between
them
is
I
think
it's.
The
delivering
of
these
fields
is
as
their
own
incremental
objects
or
reassembling
it
back
into
an
incremental
object
that
resembles
the
the
Deferred
fragment
and,
in
your
example,
literally,
is
like
my
Benji
proposal
that
one
is
no
field
is
ever
sent
twice
where
yakov's
its
leaves
aren't
sent
twice,
but
by
necessity,
intermediary
objects
have
to
be
sent
twice
because
we
need
a
place
to
put
those
leaves
that
are
in
different
defers
everything
else.
E
Ids
labels
stuff,
like
that,
how
the
path,
what
the
paths
look
like
I
think
those
could
apply
to
either
one
but
they're,
not
necessarily
like
I,
don't
think
it's
take
it
or
leave
it
for
either
either
one
so
like.
That's
really
what
I
want
to
like
decide
on
before
we
start
like
workshopping
like
other,
more
Minor
Details.
B
D
Definitely
I
annoyingly,
whilst
you
were
talking,
then,
was
thinking
about
the
differences
between
them
and
I.
D
Think
I've
come
up
with
a
problem
that
neither
of
themselves-
and
that
is
at
the
moment
the
spec
for
non-stream
defer
the
spec
guarantees
the
order
of
the
fields
that
will
be
delivered
matches
the
order
that
they
are
in
the
document
like
according
to
the
field,
collection,
algorithm
and
I,
think
both
a
Yakov
solution
and
probably
my
solution,
yeah
my
solution
to
don't
respect
that
they
will
generally
do
it
but
like
if
one
of,
if
this
defer
that
was
later
gets
solved
first,
then
it
will
be
merged
in
and
the
others
will
be
added
afterwards.
D
D
But
what
I
think
we
should
do
is
find
out
the
people
that
think
that
that
ordering
is
important,
which
may
be
a
case
of
going
back
to
like
2015
and
seeing
who
who
said
that
this
text
in
the
in
the
spec
should
say
that
it's
an
audit
map,
for
example,
and
then
talking
to
them
and
finding
out
what
the
reasons
are
for
that
and
then
investigating.
Whether
it
is
actually
an
important
issue
or
not.
B
Yeah,
didn't
we
take
it
out
because,
like
the
gradco.net
guys,
they
had
a
problem
with
hash
Maps
I
I
mean
they
implemented
these
maps
with
hash
Maps,
and
that
was
the
issue
was
because
why
we
changed
that
and
said
it's
not
important.
Yeah.
B
F
Yeah
and
I
remember
people
from
go
actually
the
reporting,
maybe
a
separate
issue,
so
yeah
I,
think
Google
was
one
and
second
was.net
and
Lee
decided
if
it's
already
too
so
it's
because
debugability,
so
ability
to
debug
at
c0
and
also
as
far
as
I
understand
Facebook
had
some
had
some
experiments
with
binary
formats
for
mobile
phones
so
and
in
those
experiments
very
wide
on
the
order
of
fields.
F
A
B
Yeah
I
think
so
it's
in
the
response
section.
It
says
it
doesn't
have
to
be
ordered
in
the
response
yeah
just
because
I
think.
Yes,.
B
What
yeah,
exactly
what
Benji
posted
the
execution
selections
are
dead?
Is
it
should
be
ordered?
It
says
it's
ordered,
but
later
in
the
response
section,
it
says
there
is
an
note
that
it
doesn't
have
to
be
on,
but
I
I
think
from
from
like
in
general.
I
also
prefer
to
be
ordered,
because
when
you
see
like
query
to
response
in
in
graphical
when
you
debug
things,
it's
very
nice
for
the
user,
like
it's
a
very
good
effect,
especially
when
you
start
this
class,
but
I
understand.
B
D
So,
currently,
the
data
and
errors
object
is
explicitly
an
unordered
map,
and
yes,
it
may
be
that
we
recommend
putting
errors
first,
but
yeah
strictly.
It
is
an
unordered
map,
whereas
the
execution
of
selection
sets
is
an
ordered
map
but
yeah,
as
you
say,
when
it
comes
to
delivering
it,
it
is
a
should,
rather
than
a
must.
A
F
Yeah
I
I
wrote
at
that
error
part
because
for
Star
Wars
API
for
one
time
we
had
errors
and
nobody
saw
them
because
they
was
like
under
big
dump
of
data.
Nobody
like
actually
list
graphical
yeah.
B
D
A
D
Has
been
a
fruitful
discussion,
so
thank
you
all.
We
will
reconvene
to
discuss
incremental
delivery
a
week
on
Monday
and
I
think
we
have
another
working
group
next
week,
General
working
group.
B
Yeah
but
we
are
not
recommending
on
Monday
we're
skipping.