►
From YouTube: GraphQL Working Group - 2023-01-05
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
Happy
2023!
Yes,
indeed,
it's
already
been
a
very
hectic
year
already
so,
what's
going
on,
how
is
how
is
the
break?
Well,
assuming
you
all
took
a
break.
How
was
the
break.
A
I
was
good.
Kids
are
still
here,
though,
because
they're
still
on
their
break,
so
working
this
week
is
proving
challenging,
but
just
extra
soundtrack
outside
of
my
office
for
sure
percussion.
B
A
It's
a
good
thing:
I
have
noise
cancellation,
lots
of
yelling
at
weird
times
on
calls
so
yeah.
A
They
they
do
a
lot
of
kind
of.
A
F
F
We
had
a
crazy
storm
in
San
Francisco,
most
of
California.
Actually,
my
internet
actually
just
came
on
like
almost
five
minutes
before
the
meeting
so
did.
A
You
did
you,
were
you
in
one
of
the
areas
that
lost
power
as
well.
A
G
D
A
A
F
Wild
okay,
I
think
I.
Have
our
agenda
file
all
cut
up?
Let
me
see
if
I
have
any
other
PRS
yeah
I
got
one
left,
Vaughn's
attendance
merged,
sweet,
all
right,
sorry
for
getting
things
started
five
minutes
late,
I
mean
internet
and
power
chaos
and
getting
her
a
dental
pile
up
to
date,
we're
in
good
shape.
F
Okay,
welcome
everybody
to
the
first
working
group
meeting
of
2023:
that's
pretty
crazy!
So
I
did
a
little
bit
of
cleanup
of
our
repo
and
agenda
files
and
stuff,
and
so
you
might
notice
that
our
agendas
are
slightly
more
cleaned
up
and
I
moved
some
of
the
joining
and
meeting
stuff
into
it's
a
separate
markdown
file
just
a
little
bit
of
cleanup,
but
it
reminded
me
that
we
have
agenda
files
that
date
back
to
2017.,
which
is
when
we
started
this
working
group.
F
And
what
does
that
mean
one?
Two,
three,
four
five
six!
This
is
the
sixth
seventh,
if
you
are
include
both
2017
and
2023
as
years,
but
six
years
or
continuously,
and
and
that
we've
been
doing
this
I
think
that's
pretty
wild
and
we
we
did
track
attendees
I'm
trying
to
think
do
we
have
any
do
we
have
any
overlaps,
I
think
I
might
be
the
only
person
who's
been
in
both
the
very
first
one.
No
that's
not
true.
Yvonne
is
the
other
person
bond
is
in
the
very
first
one
in
2017.
F
and
there's
some
other
familiar
faces,
there's
Rob,
zoo
and
Andy
Marek,
and
a
couple
other
folks
who,
who
do
occasionally
show
up
so
pretty
wild.
Here
we
are
six
years
later,
still
still
doing
it
anyway.
I
thought
that
was
like
a
fun
thing
to
celebrate
so
happy
New
Year.
F
We
have
a
a
well-packed
agenda,
so
we'll
try
to
stay
on
time
here
to
make
sure
you
get
through
everything.
If
not,
hopefully
we
can
use
the
secondaries
to
over
low,
so
kicking
us
off.
By
joining,
we
of
course
agree
to
the
spec
membership
agreement,
participation,
guidelines,
contribution,
guide,
code
of
conduct
all
well
written
docs,
go
take
a
read
anytime.
F
We
have
a
good
tight
attendance
today,
so
hopefully
we
can
do
a
quick
round
of
intros
very
quickly.
We
will
go
in
the
order
that
is
listed
in
the
agenda,
doc
I'm.
On
top
so
I'll
start
hello,
everybody.
My
name
is
Lee.
H
I'm
next
hi
everyone
I'm
Matt
from
meta.
B
F
Welcome
haven't
seen
your
face
here,
happy
to
have
you
as
part
of
the
tribe.
F
F
Him
awesome.
Thank
you,
Hugh,
okay,
quick,
look
over
our
agenda,
making
sure
we
got
everything
we
want
to
talk
about.
I
put
this
on
a
standing
agenda
to
just
do
recap
now
that
we
have
the
sort
of
primary
secondary
Cadence.
The
attendance
is
not
the
same
across
all
of
those
it's
kind
of
the
point
but
figured
it
would
be
a
good
thing
to
just
do
a
super
quick
few
minute
recap
back
on
those
so
I'll
get
to
that.
In
a
minute
we
will
do
a
review
of
action
items.
F
I,
don't
know
that
we
will
have
much
to
look
at
here,
since
it
was
the
holidays,
but
still
we'll
take
a
look
at
that.
Then
we've
got
fragment
arguments.
Discussion
I
saw
some
notifications
flying
back
and
forth
late
in
the
game.
Matt
very
excited
to
see
what
you're
working
on
we
have
a
bunch
of
approved
PR's
from
Roman,
and
we
can
do
a
quick
review
on
the
ones
that
are
ready
and
take
a
look
at
actions
for
those
that
are
not
yet
ready
default
value,
validation,
status,
check.
F
F
F
Have
technically
officially
closed
but
for
whatever
reason
you
forgot,
we
haven't
kicked
the
vote
off
yet,
but
we
will
do
that
pretty
imminently,
so
you
can
always
look
at
previous
agendas
links
for
that.
We
are
going
to
kick
that
off.
That's
going
to
be
done
all
virtually
so
I
will
get
an
email
out
to
TSC
members
to
take
a
vote.
F
Okay,
let's
do
a
quick
recap
of
our
prior
meetings.
I
have
links
to
both
in
the
agenda
file,
so
the
first
of
the
two
was
the
APAC.
One
I
think
this
falsely
listed
me
as
attending
I
believe
I
did
not
attend,
but
Benji.
You
did
and
you
ran
this
meeting
correct.
C
B
I'm
trying
to
open
the
Google
Doc
hang
on
a
sec.
B
Oh
yeah
yeah
cool,
so
this
one
was
actually
quite
a
simple
meeting.
B
It
was
broadly
the
the
main
items
to
come
out
of
it
were
discussing
the
legal
sign
off
for
the
graphql
scalers
project
and
reviewing
various
of
Romans
PR's,
some
of
which
we'll
be
discussing
again
today.
I
think
we
did
get
a
couple
of
those
merged
which
was
nice
and
made
some
advancements
on
some
of
the
others,
but
I
think
we'll
be
hearing
more
about
that
later.
F
Great
and
I
think
I
have
next
action
for
the
scalers
project,
which
is
they're
actually
good
to
go
and
from
a
legal
point
of
view,
but
they
need
some
sort
of
boilerplate
text
to
put
on
scalars.
So
people
understand
how
to
interpret
those
the
next
one
was
also
pretty
short,
I
think
the
main
highlights
here
were
the
actually.
F
This
ended
up
being
a
very
good
discussion
about
validation
of
variables,
which
I
think
we
had
talked
about
in
the
past,
but
we
got
a
good
needle
in
on
exactly
what
the
right
next
actions
are.
There,
adding
style
guides
to
the
specification,
which
was
great
anyway.
We
can
automate
away
my
grammar
fantastic,
thank
you
Benji
and
then
the
last
was
another
step
forward
on
deferred
stream,
which
I
know
we
have
on
the
agenda
say
that
was
the
recap
of
that.
F
F
H
All
right
did
we
not
have
any
open
issues
took
over
cool.
Let
me.
C
H
H
I've
got
the
basically.
This
is
the
RFC
document
for
fragmentar's
check
that
in
case,
you
guys
have
also
have
floating
Keys
the
we've
gone
through
in
the
past.
Why
this
matters
and
the
basic
point
is
that
fragments,
as
they
are
right
now,
don't
provide
a
way
for
you
to
reuse
them
in
different
contexts.
H
So,
for
instance,
I
could
have
I
could
build
out
this
really
fancy
component
in
react
or
whatever.
That
lets
me
have
n
items
in
a
list
of
my
friends
and
and
of
my
friends,
but
in
graphql
I
either
have
to
push
the
logic
all
the
way
up
to
where
I'm,
making
the
query
to
figure
out
how
many
friends
is
going
to
be
in
this
list
or
I
have
to
hard
code.
A
value
and
I
can
only
show
three
friends
or
I
need
to
duplicate
the
fragment
as
many
times
as
I
want
to
use
it.
H
We
already
have
existing
solutions
for
this.
Where
relay
has
arguments
and
argument
definitions
as
non-spec
compliant
directives,
because
they
have
the
directives
here,
have
a
type
that
can't
be
described
in
graphql's
type
system,
which
is
nice
so
given
in
relay,
at
least
within
meta
I
know
we
we
see,
argument,
definitions
and
arguments
used
all
over
the
place.
H
It's
very
very
common
pattern,
so,
given
that
I
would
like
to
bring
it
into
the
spec
itself
so
that
we
don't
have
to
have
like
my
main
motivation
was
actually
getting
rid
of
this
non-spec
compliant
directive
system
and
I
was
okay.
Initially,
I
was
okay
with,
even
even
if
we
just
added
it
to
the
AST
and
didn't
solve
the
executor
or
validation
or
any
of
that,
and
just
let
the
client
have
AST
nodes
that
they
could
work
with.
H
But
back
when
I
brought
this
up
almost
two
years
ago,
the
pushback
was
well.
Why
not
just
bring
it
into
the
executor?
Why
not?
Just
have
us
like?
Have
the
server
understand
these
arguments?
Natively,
and
so
that's
what
this
iteration
of
the
RFC
is
is
basically
okay.
We
have
this
new
syntax,
where
the
syntax
is
that
you
define
your
argument
by
you'd
find
a
fragment
argument
using
a
something
that
looks
like
a
variable
definition,
but
isn't
quite
because
it's
going
to
then
be
used
as
a
named
argument.
H
I
know
this
bit
is
a
little
bit
weird
where
you
have
a
dollar
in
the
definition,
and
then
you
use
it
like
if
more
like
a
field
argument
at
the
call
site,
but
looking
I
took
a
pretty
deep
look
into
existing,
so
really
I
looked
into
PHP,
because
a
lot
of
graphql
is
based
on
phpisms
and
PHP
does
exactly
this.
They
allow
you
to
Define
Arguments
for
your
function.
H
In
this
case,
fragments
are
somewhat
similar
to
functions
and
those
arguments
are
defined
with
a
dollar
when
you're
using
that
argument
within
the
function
you're
using
the
dollar
variable
and
then,
if
you're,
using
a
named
argument
instead
of
a
positional
argument,
you
call
it
without
the
dollar
and
then
provide
the
actual
value
that
you
want
to
pass
it.
H
So,
unless
there's
a
strong
objection
that
feels
that
feels
pretty
reasonable
to
me,
I
I.
So
that's
one
thing
that
we
need
to
just
like
agree,
make
sense
or
try
to
come
up
with
something
else.
H
The
only
other
two
that
I
could
think
of
is
that
we
in
the
definition
we
use
our
name
type,
which
is
how
we
Define
field
Arguments,
for
instance,
but
then
you
have
to
use
it
with
a
dollar.
Otherwise,
things
get
really
weird
or
at
the
call
site
you
use
dollar,
to
define
or
to
describe
the
argument.
That
also
feels
weird
to
me
so
yeah
any
questions
so
far.
H
A
Curious
to
know
why
why
did
relay
originally
add
this
in
in
a
non-spec
compliant
way?
Was
there
some
benefit
performance
benefit,
some
other
reason
why
they
went
that
way.
Yeah.
H
F
F
G
G
H
Yeah
yeah,
that's
a
good!
That's
a
good
point
for
pushing
there.
The
other
thing
I'll
point
out
going
back
up
to
the
arguments
is
what
was
I.
Oh
I
forgot
what
I
was
going
to
say
there
from
before
sorry.
C
F
This
is
also
maybe
just
like
a
terminology
thing
that
has
gotten
Twisted
that
might
help
I
know
relay
calls
them
arguments,
but
based
on
sort
of
the
framing
of
the
syntax
that
you
have.
It
might
be
easier
to
think
about
it
as
fragment
variables
like
they
are
variables
because
they
they'd
be
within
the
scope
of
the
fragment.
They
behave
identically
to
variables
everywhere
else.
F
It's
just
that
like
what
provided
the
value
for
that
variable
was
passing
an
argument
to
the
fragments
spread,
but,
like
that
way,
you're
defining
like
the
the
syntax
by
which
you're
defining
this
for
the
fragment,
is
identical
to
the
syntax,
where
you
define
a
query
variable
or
an
operation
variable
yeah,.
H
H
Fence
we
are
actually
including
a
type
definition
and
not
just
like
a
you-
will
pass
this
in
eventually,
but
like
a
type
definition
that
defines
how
subsequent
call
sites
can
be
used
in
a
way
that
we
kind
of
aren't
with
like
we're
we're
defining
new
arguments
that
normally
like
for
fields
and
input,
objects
and
directives.
We
Define
input
arguments
and
now
we're
defining
a
new
kind
of
input
argument,
and
that
kind,
though,
just
happens
to
be
within
the
document.
H
It's
the
within
the
executable
document
and
in
fact,
when
I
did
some
of
the
validation
for
like
argument
or
variables
in
correct
location,
validation.
H
One
of
the
things
that
I
realized
is
that
I
needed
to
pull
out
each
of
these
fragment
definitions
as
their
own
hype
system
definition
essentially,
and
one
of
the
things
that
I
found
was
in
fact,
where
did
I
put
this
one
of
the
things
I
found
was
that
fragment
yeah
required
arguments
are
defined
yeah.
One
of
the
things
I
found
is
that
I
basically
wanted
this
argument
in
the
AST
node,
as
I
was
like
using
the
AST
nodes.
What
I
really
wanted
was
for
it
to
be
an
input
value
definition.
H
And
the
only
reason
I
can't
do
that
I,
like
I
tried
to
have
it
be
I.
Think
I
heard
it
here:
dollar
input
input,
so
no
okay,
I
didn't
I,
didn't
put
it
here.
I,
have
it
documented
somewhere
else?
Basically,
the
only
reason
so
input
value
is
defined
almost
identically
to
variable
definition.
H
Our
input
value
definition
is
almost
the
same
as
variable
definition,
except
for
without
the
dollar
in
front
of
name.
H
And
like
in
terms
of
what
we're
actually
doing
we're
defining
a
new
argument,
which
is
why,
like
I'd,
be
open
to
calling
these
variables
and
kind
of
shifting
like
I'd,
be
open
to
switching
back
to
using
variable
definition,
I
tried
that
it
felt
a
little
clunky
to
me.
It
felt
more
clunky
than
defining
a
new
syntax
node,
but.
E
But
oh,
go
ahead:
Lee.
F
An
argument
is
a
is
a
property
of
how
the
thing
gets
called,
not
right.
So
it's
like
you
I,
would
describe
this
as
these
are
fragment
variables.
They
behave
identically
to
operation
variables
and
the
way
that
you
provide
them.
You
provide
a
operation
variable
by
way
of
like
submitting
it
as
part
of
the
call
to
graphql.
You
provide
a
fragment
variable
by
way
of
supplying
it
as
an
argument
to
the
fragment
spread
like
a
fragment
spread,
has
an
argument,
but
a
fragment
does
not
have
argument.
F
H
Yeah,
the
other
thing
that
causes
a
little
bit
of
confusion
with
is
like,
because
is
with
scoping
so
because
you're,
like
the
scope
of
the
value
as
an
argument,
is
much
wider
than
the
scope
of
the
value
as
a
variable.
H
If
that
makes
sense
so
like,
in
this
case,
I've
decided
to
limit
the
scope
to
only
the
fragment
that
it's
defined
on,
not
any
recursive
fragments,
not
Global,
scope
like
and
I
was
able
to
implement
it
allowing
shadowing
of
variables.
So
you
can
have
a
parent.
You
can
have
a
global
variable
and
a
fragment
that
defines
that
same
variable,
value
and
it'll
work.
Just
fine,
because
within
the
scope
of
that
fragment
the
global
variable,
the
operation
level
variable
is
not
considered.
It's
basically
impossible
to
access.
F
H
F
It
does
mean,
though,
that
if
you
have
a
fragment
art
or
a
fragment
Bearer,
that
is
you
like.
If
you've
then
decomposed,
that
fragment
into
other
fragments
right,
you
have
something
complicated.
You
need
to
explicitly
thread
it
all
the
way
through.
So
if
you
have
like
at
the
very
Leaf
node,
you
want
to
Define
a
variable
for
the
size
of
a
picture
that
you're
going
to
render
it's
like
going
to
a
field
and
you're
like
I'm
gonna
parametrize
this
fragment,
and
then
that
thing
is
encased
like
eight
levels,
deep,
each
one.
H
H
C
A
E
That
makes
it
makes
it
all
so
simple
to
use
and
I
think
otherwise,
if
people
had
to
figure
out
like
what
is
on
the
stack
where
and
when
is
it
applied
would
be
very
complicated.
But
this
way
it's
straightforward,
but
you
can
read
it
and
then
understand
it.
G
Right,
oh
yeah,
I
would
leave
about
calling
these
variables
because
again,
first
of
all
we're
talking
about
not
more
like
about
meaning
but
the
exact
name,
the
cement,
the
not
semantics
but
naming,
and
which
will
be
easier
for
the
first
time
reader,
let's
say
or
regular
reader.
They
look
like
variables.
H
H
So
I'm
I'm
happy
to
take
as
an
action
item
for
me,
basically
putting
a
PR
on
top
of
this
one.
A
differently
named
that
is
stacked
on
top
that
switches
from
argument,
definitions
to
variable
definitions
and
still
using
arguments
at
the
spread
level
like
right,
because.
H
Yeah
at
the
call
site
and
seeing
because
I
that
was
what
I
originally
did
was
use.
Variable
definitions,
but
I
also,
like
things
were
messy,
possibly
because
I
was
also
doing
it
for
the
first
time,
whereas
now
I'm
vibrated
on
this,
like
four
or
five
times
so
it
might
just
feel
cleaner,
because
I've
actually
cleaned
up
all
the
stuff
around
it.
B
F
Yeah
I
think
either
way
you're
going
to
end
up
overloading
a
term
and
it
like.
Maybe
a
principle
to
apply
here-
is
to
minimally
override
existing
terms,
and
if
the
semantics
are
in
fact
nearly
identical
to
variables,
then
that
is
a
good
sign
that
all
you're
doing
is
introducing
like
you're
introducing
the
concept
of
scope,
and
so
that
is
new
complication
but
like
if
you
see
a
particular
place
where
available
gets
used
and
if
the
actual
executor
is
not
doing
anything
particularly
complicated.
F
Aside
from
now
having
to
consider
the
scope
piece,
then
that's
a
good
sign
that
these
are
in
fact
variables.
F
G
G
Yeah
but
you
have
so
basically
we
have
it
already
kind
of,
and
you
are
looking
for
matching
variable
either
on
the
fragment
level
or
at
the
operational
level
and
they
kind
of.
But
it's
weird
to
call
them
argument
here.
But
then
you
you
are
going
to
variable.
That's.
It
feels
more
natural.
F
Yeah
but
Matt
I
think
you're,
probably
right
that
they're
both
names
are
correct
and,
like
you
need
to
have
some
clarity
in
when
you
use
each
one
like
I,
think
within
the
context
of
a
fragment,
they're
variables
and
on
the
call
side
of
a
spread,
their
their
arguments.
H
G
D
Yeah
I
have
a
question
so
like
basically,
it's
like
just
two
Scopes
so
like
Global
and
like
operation
level
and
fragment
level.
So
what
I
expect
like
I
think
Facebook
will
introduce
validation
rows
on
top
of
it.
If
you
like,
merge
this
thing
into
spec
I
expect,
like
people
create
validation,
rule
saying
like
you
cannot
use
stuff
from
Global
scope
in
fragments,
if
they
like
so
I'm
like
do
they
like
agent
with
complication
and
weather
people
like
create,
will
create
a
validation
rule
to
explicitly
forbido.
D
It's
like
with,
like
two
scope
situation,
one
one
interesting
thing
to
to
explore.
Maybe
if
we
discussion
about
our
watching
tournament,
maybe
we
should
not
overload.
Maybe
we
should
create
nodes,
determine
and
use
like
different
symbol
like
we
can
easily
use
double
door
signs
or
like
some
another
symbol,
and
basically
it's
like
you
pass
in
global
Global
variable
operational
variable
into
like
foreign.
D
It
will
also
show
your
issue
with
like
PHP
like
syntax,
which
is
maybe
controversial.
Oh,
maybe
not
so
I,
I'm
I'm
personally,
think
think.
Now
we
will
write
complication
and
people.
Wait
to
just
forbid
like
shadowing,
quite
enjoy
JavaScript
double
shadowing,
but
everybody
enable
linter
to
forbid
shadowing,
and
so
it's
like
it's
a
weird
situation
when
language
I.
H
Don't
think
we
would
forbid
shadowing
because
it's
not
shadowing
within
a
function
like
if
you
consider
an
operation
a
function,
but
in
my
mind
an
operation
is
like
the
collection
of
functions
within
a
module
and
you
can
have
the
same
variable
like
I.
Don't
think
any
linter
prevents
having
the
same
variable
in
three
different
functions.
D
H
D
Also,
I
cannot,
if
you
can
like
consult
with
other
people,
and
if
you
will
how
I
expect
somebody
other
validations
to
come
I'm
like.
Can
you
write
it
in
document
because,
especially
since
you
used
to
like
previous
iteration
of
this
idea
in
form
of
gear
review,
yeah.
H
I'm
I'm,
basically
trying
I
have
I,
have
a
lot
of
within
meta.
I
have
kind
of
a
mind
share
that
we
should
be
unwinding
our
previous
iteration,
so
this
is
I
I've.
This
concept
has
been
pretty
widely
shared.
I
will
share
again
within
but,
like
I,
don't
think
we're
going
to
have
any
validation
above,
what's
in
graphql.js
PR
right
now,
okay,.
D
In
this
case,
so
I
need
to
think
more
because,
like
you
know,
a
shadowing
when
you
hear
shadowing
you're,
like
I,
have
almost
instinct
direction.
Are
you
think
more
about
that?
The.
H
F
G
E
Yeah
my
instant
reaction
was
is
something
wrong
with
my
system.
Okay,.
H
If
you're
like
it
does
mean
that
if
you
remove
say
this
number
field
and
it's
the
last
usage
of
the
fragment
variable
that
then
you
need
to
go
update
all
your
call
sites
to
remove
it
as
well.
We
could
solve
that
eventually
with
like
at
deprecated,
but
I
wouldn't
want
that
in
the
first
version
of
configuration.
G
You
know
I
I
in
general,
have
this
a
bit
bad
taste
about
this
requirement.
It
should
be
used
because
it
makes
experimentation
really
difficult.
You
know
you
try
something
calling
with
value
without
value.
You
know
you're
working
on
it
and
each
time
when
you
decide
not
to
use
some
variable
here,
you
have
to
remove
it
formally
from
the
operation.
Currently
yeah.
C
G
H
F
Don't
have
a
concept
of
a
warning:
we
have
you
either
pass
our
nation
or
you
fail
it.
Yeah
generally,
like
we've,
tried
to
take
the
category
of
things
that
a
compiler
would
call
a
warning
and
like
they
don't
all
go
in
One,
Direction
or
the
other,
but
some
of
them
we
try
to
be
slightly
more
strict
than
many
compilers
would
be
there's
some
validation
rules
that
are
sort
of
nitpicky
that
are
in
the
category
of
like
these
are
the
kinds
of
errors
that
well-run
software
shops
tend
to
up
level
into
full
compiler
errors
anyway,.
F
It's
a
good
point:
it's
worth
being
thoughtful
about
this,
but
I
think
it
makes
sense.
It
certainly
mirrors
our
existing
rule
that
if
you
have
a
variable
to
find
an
operation,
you
don't
use
it.
We
consider
that
an
invalid
query,
the.
H
Yeah,
so
that's
kind
of
I
did
consider
making
also
the
change
for
like
requiredness
versus
non-nullableness
splitting
that
out,
I
decided
against
it,
because
that
would
change
how
arguments
how
fragment
arguments
are
used
versus
field
arguments.
H
So
basically
treating
this,
where
you
have
a
nullable
argument
that
it
has
no
default,
meaning
that
you
actually
must
provide
that
argument
like
I
like
languages
where
that
is
the
where
that
is
the
case.
I
prefer
languages
like
that,
but
that's
not
how
the
language
exists
today
and
I'd
rather
meet
graphql,
where
it
exists
rather
than
introducing
A
New
Concept.
H
Yeah
yeah,
so
I
might
be
able
to
have
like
optional
extra
validation,
but
I
definitely
could
do
the
validation
like
encourage
the
validation
that
we
are
recommending
from
last
meeting
of.
If,
if
the
argument
or
if
the
values
required,
then
you
can't
pass
a
non.
C
H
Can't
pass
a
nullable
value,
even
if
it
has
a
default
value,
but
that's
yeah.
So
that's
kind
of
I
think
that's
all
I
decided
against
document
Arc
uniqueness,
because
we've
discussed
shadowing
anything
else.
I
have
both
the
spec,
PR
and
graphql
jspr
on
this
and
I.
Think
like
I,
think
this
is
ready
to
get
to
rfc2
so
long
as
like
the
shape
of
the
solution.
H
If
we
all
agree
that
this
is
the
right
syntax
and
that
for
the
most
part
the
behavior
makes
sense,
but
we
want
to
like
try
out
a
couple
different
possible
behaviors
and
just
verify
I'd
argue
it's
probably
close
to
RFC
too,
but
I
can
stop
sharing.
At
this
point.
F
Sweets,
I
think
you
probably
are
at
stage
two
one
thing
that
I
think
would
be
helpful
is
to
take
your
PR
and
separate
out
the
RFC
dock
that
you
have
that's
sort
of
like
working
copy
from
the
spec
edits.
That
way
you
can
have
a
clean
PR,
that's
just
purely
the
spec
text
and
you
can
actually
the
the
actual
RFC
I
think
that
did
we
move
to
rfc's
now.
H
F
Cool
feel
free
to
take
that
RFC
Doc
and
stick
it
in
the
right
spot.
You
can
just
optimistically
merge
that
one
and
that'll
make
sure
your
spec
at
it.
One
is,
is
sort
of
a
clean
one
that
we
could
eventually
merge
cool
yeah.
This
is
looking
great
there's
I
think
the
choices
you
made
so
far
sound
reasonable.
F
What
might
be
helpful
is
sort
of
just
like
listing
out
a
to-do
lists
in
that
either
in
the
pr
or
whichever
is
your
sort
of
Master
thread
tracking
this.
That's
the
open
questions
that
you're
still
trying
to
resolve.
H
Yep
yeah,
I
I,
think
the
action
item
for
me
is
try
switching
back
to
variable
definitions
and
see
what
that,
how
complex
that
actually
gets
and
yeah.
That's
that's
I.
Think
the
next
step.
A
F
This
is
I,
think
it's
not
quite
stage
two
yet
because
one
of
the
entrance
criteria
for
stage
two
is
we've
resolved
all
of
our
identified
concerns
and
challenges.
I
think
that
isn't
quite
right,
but
it's
it's
fair
to
say
this
is,
like
you
know,
stage
1.9
or
like
really
really
close,
yeah,
really
close.
It's
it's
well
beyond
the
entrance
criteria
for
stage
one,
it's
made
significant
progress,
It's,
it's
very
closely
approaching
stage
two.
A
I
don't
know
if
you're
planning
on
working
with
the
relay
team
to
get
this
in
just
to
test
things
out,
but
if
you're
looking
for
another
project
to
work
with
on
this,
to
try
it
out.
We'd
love
to
an
Apollo
client
work.
I
Awesome,
quick,
a
cool
question
if
you
had
the
same
fragment,
spread
multiple
times
in
the
same
place,
but
with
different
arguments.
That
would
be
an
error
for
because
you
wouldn't
be
able
to
merge
the
fields
inside
yeah.
H
So
in
the
in
the
spec
PR
I
actually
am
splitting
out
like
an
additional.
You
need
to
check
the
spread
for
differing
arguments
and
there's
some
element
of
like
how
do
you
decide
what
the
variable
value
is?
That's
a
little
bit
but
yeah.
A
B
The
con
about
differentiating
those
is
actually
a
really
interesting
one,
seeing
whether
the
arguments
are
the
same
or
not.
For
example,
if
you
pass
a
variable
into
one
and
the
static
value
10
into
another,
then
so
long
as
the
variable
has
the
value
10,
it
could
technically
be
merged.
H
Like
they
don't
resolve
to
an
operation
level
variable
or
they
resolve
to
the
same
operational
variable
and
we
could
fall
on
either
end
of
like
oh,
the
actual
fragment
spread
needs
to
just
like
the
string
of
the
fragment
spread
needs
to
be
identical
or
like
every
the
resolved
string
of
the
fragment
spread
needs
to
be
identical.
H
B
D
D
D
Yeah
yeah,
so
it's
a
better
name
and
you
just
Trace
current
name
and
is
a
a
new
Trace
like
operation
name
because
like
to
bend.
This
point
like
like
I,
think
we
have
two
cases.
If,
if
you
have
like
two
variables
that
how
I
identical
default
values
even
now
with
fields
and
you
use
in
the
same
field
like
variable
a
with
default
value,
one
another
variable
B
with
default
value
or
one
you
don't
know.
D
But
it's
like
breadcrumbs
like
from
from
arguments
to
like
aliases
separate
things,
intermediate
States
should
make
sense,
or
we
should
do
it
as
a
package
deal
like
is
a
way
around.
H
Yep
I
I
agree
yeah
the
specifically
the
allowing
the
top
level
variable
to
be
thread
through
when
the
top
level
variables
thread
through,
where
two
different
parents
name
their
very
name
their
argument
differently,
but
then
pass
that
same
argument
to
the
child.
H
Yeah
I
think
that
is
actually
an
important
thing
to
not
like
explode.
In
that
case,.
G
Can
I
make
one
comment
here
so
regarding
this
I
think
the
general
idea
would
be
helpful
that
if
user
does
this
two
fragments
with
kind
of
questionable
use,
but
two
three
fragments
with
it
different
values?
Maybe
it's
intentionally.
He
needs
this,
and
in
this
case,
rather
than
be
prohibitive
and
analyzing,
what
matches
or
not
we
kind
of
should
adopt
the
strategy
of
forgiving
and
let's
try
to
fight
and
make
something
reasonable
of
what
what
he
wants
to
do
of
the
user.
G
The
client
wants
to
do
rather
be
all
these
invent
static,
validation
in
front.
Do
they
match
or
not?
Let's
just
try
to
make
sense
and
try
to
merge
them
because
it
looks
like
for
me
it's
a
conscious
decision
by
the
programmer
and
he
wants
to
do
something
useful
yeah.
H
We've
found
we
found
in
practice
it's
having
it's
it's
the
identity,
it's
almost
identical
to
the
problem
of
fields
that
have
different
arguments
and
we
found
in
practice
that
that
is
never
intentional.
It's
always.
It
almost
always
happens,
because
two
teams
are
building
two
different
components
and
not
talking
to
each
other.
F
And
hopefully
these
can
be
pretty
smooth
going
Roman.
Do
you
want
me
to
go
to
the
call
for
Action
ones
first,
since
those
may
require
some
discussion
and
then
yeah
through
the
PRS
ready
to
go.
G
It's
it's
essentially
I
didn't
plan
it
as
reviewing
particular
PRS.
So
basically,
what
turned
out
in
the
last
meeting
when
we
actually
discussed
them
in
details,
I
raised
the
problems
that
some
PR's
been
approved.
G
At
least
once
are
sitting
there
sometimes
for
months,
and
it's
a
bit
frustrating
and
kind
of
nobody
goes
there
and
I
think
Benji
suggested
to
raise
the
discussion
and
suggestion
of
making
it
a
regular
part
of
our
meeting
to
review
the
PRS
that
are
ready
to
go
if
there
are
any
and
kind
of
make
an
action
on
them
and
record
an
action
that
this
VR
is
okay
and
ready
to
go,
and
so
on,
and
the
first
four
so
basically
I.
G
This
is
my
suggestion
to
include
like,
like
we
review,
open,
Action
items,
review
the
aprs,
which
are
ready
to
go
hprs,
which
have
at
least
one
approval
and
basically
close
discussion,
so
that
they
don't
hang
out
there
for
too
long.
And
basically,
let's
discuss
this.
What
do
you
think
guys.
F
That
sounds
good
I,
like
the
idea
of
bringing
spec
PRS
to
the
working
group,
because
we've
got
a
fantastically
high
quality
bar,
or
at
least
we
try
to
and
so
being
able
to
talk
through.
These
things
is
almost
always
useful.
F
One
thing
that
I
will
say,
though,
is
anything
that
is
sort
of
a
a
stylistic
Improvement
or
a
very
obvious
Clarity
fix
does
not
need
to
be
blocked
on
me.
So
if,
if
a
TSC
member
comes
across
one
of
these
and
wants
to
approve
it,
we
can
always
merge
those
into
the
draft
and
if,
for
whatever
reason,
we
decide
later
that
that
was
the
wrong
thing
to
do.
We
can
always
take
it
back
out
of
the
draft,
so
you
know
especially
I've
seen
Benji
and
Matt
go
through
a
handful
of
these.
F
G
Yeah,
but
this
is
exactly
so
discussion,
I
understand
we
discuss,
but
when
it's
clear
that
it's
sitting
there-
and
so
this
is
kind
of
the
last
stop
here.
If
it's
still
sitting,
then
we
clearly
look
at
them
which
are
sitting
and
essentially
approved,
but
for
some
reason,
not
merged.
It's
a
reminder,
let's
review
and
merge
them
immediately
or
right
after
the
meeting,
and
so
basically
it's
just
for
historical
purposes.
There
is
four
of
these
nine
seven,
four,
nine,
seven,
five,
nine,
seven,
nine
nine,
eight
one
which
I
think
absolutely
ready
to
go.
G
We
discussed
them
in
the
last
meeting
and
probably
right
after
the
meeting.
One
of
you
guys
can
merge
them
the
other
three:
it's
called
for
attention.
They
are
sitting
there.
You
know
kind
of
waiting
for
some
discussion
and
I'm
just
asking
you
guys,
let's
discuss
them
and
in
general
I
would
a
kind
of
call
for
attitude.
If
somebody
comes,
let's
say
in
the
with
the
bigger
things
and
proposes
the
discussion
proposed.
The
problem
brings
up
the
problem.
Not
everybody
has
this
extra
time.
G
You
know
to
stay
for
years
to
push
the
issue
through.
If
we
identify
some
issue
clearly
that
this
is
important,
we
should
kind
of
more
automatically
move
over.
Even
without
you
know
original
originator
around
here
there
are
things
out
there
that
still
need
you
know
resolution
so,
but
small
things
like
this
PR
they're
sitting
there
and
without
any
attention
and
I
actually
don't
know
how
to
drag
anybody's
attention
other
than
putting
them
here.
G
So
without
discussion,
it's
just
my
personal
ask
to
to
have
a
look
at
these
three
and,
of
course,
if
you're,
okay,
to
match
the
first
four
and
for
the
next
meeting,
probably
make
it
a
regular
item
on
the
agenda.
D
How
I
come
as
as
for
editorial
I
agree
with
me:
it's
like
can
be
merged
more
or
less
easily,
as
non-editorial
change.
I
think
our
current
policy
of
having
Champion
is
is
a
good
thing,
especially
since
like
stuff
that,
like
previously,
we
discussed
like
somebody
from
a
guild
proposed
to
use
variable.
D
Argument
with
the
same
name
and
it's
awkward,
super
simple
proposal
and
everybody
agree,
and
it's
ended
up
in
a
big
discussion.
So
if
changes
is
not
in
tutorial
like
I,
don't
think
we
need
a
new
procedure.
I
think,
like
current
procedure
like
if
it's
a
tutorial,
it's
get
much
of
non-editorial.
D
G
I
didn't
mean
it
to
go
that
far,
of
course,
but
yes
and
regarding
editorial,
so
if
it's
simple,
then
it
should
be
merged.
So
basically,
this
is
just
a
check
for
much
things
and
even
if,
let's
say
I'm,
not
here,
it's
automatic
that
you
guys
review
and
approve
them
go
or
you
you
make
an
action
item
immediately
after
the
meeting
within
you
know
a
few
days
somebody
says
some
of
the
Buddhists
enough
rights.
He
either
had
another
comment
that
oh
no,
no,
that's
not
good
enough,
but
some
some
action
on
this
on
merge
it.
D
If
I
remember
correctly,
we
have
like
a
GitHub
group
for
GC
right
can
can
like
people
ask
for
review
from
GC
and,
like
everybody
from
GC
get
notified.
Okay,
maybe
we
can
add
it
into
some
document
because,
like
we
make
this
call
shorter
to
to
have
like
a
lot
of
topic
and
if
we
switch
like
doing
it
on
call,
will
force
us
easy
to
do
it
fast
and
over
in
quality
or
like
spend
a
bunch
of
time
on
it.
D
D
Members
of
TC,
like
somebody
from
10
people,
should
have
time
to
manage
it,
so
we
can
distribute
it
and
go
offline
instead
of
like
taking
10
15
20
minutes
from
this
meeting,
and
if
it's
not
much
by
TC
without
any
comment
and
everybody
ignored,
yeah
I
can
I
like
agree.
We
need
to
escalate,
but
let's,
let's
use
GC
first
yeah.
B
G
Like
today,
I'm
not
suggesting
to
discuss
all
of
them
just
for
historical
purposes,
I'm
writing
down.
These
are
ready
to
go
after
the
meeting.
Let's
do
it
and
do
it
I
suggest
doing
this
as
a
part
of
the
Cross
and
every
meeting
so
list
of
items.
That
should
be
it's
kind
of
a
reminder
that.
D
This
experiment:
can
you,
can
you
try
and
I
will
try
to
find
like
a
name
of
or
group?
Can
you
attack,
like
GC
members,
reviewers
on
on
this
issue,
and
we
will
see
if
it's
like
this
back
work
Disappear
by
itself,
because
not
every
TC
member
on
visco
and
I
think
it's
yeah
four
of
us
even
between
four
of
us.
We
can.
We
can
do
it.
Okay,.
D
D
F
F
I
think
we
can
evolve
is
if
something
if
a
TSC
member
is
approving
something
that
feels
highly
likely
to
be
done
like
if
you're
saying
I'm
approving
this,
and
it
needs
more
discussion.
But
I
have
my
support,
then
leave
it.
But
if
it's
I
approve,
because
this
is
editorial
and
plainly
makes
it
more,
cleaner
then
merge
it.
F
G
D
By
somebody
like
from
the
school
right,
not
by
randomly
yes,
okay,
oh
okay,
now
I
get
it
because
sorry
I'm
misunderstood
the
problem.
I
thought
like
nobody
reviewing
her
but
you're
saying
it's
reviewed:
it's
not
not
much.
D
Maybe
we
can
our
people
to
get
safer
because
previously
I'm
much
like
a
bunch
of
stuff
in
this
pack
and
now
Benji
is
doing
that
but
I
think
like
some
members
of
TC
or
some
like
new
members
who
have
like
mental
barrier
of
pressing,
merge
button
if
you
don't
have
like
with
documented
somewhere
so
anyway,
if
you
think
it's
a
tutorial,
if
it's
not
changes,
but
please
feel
free
to
merge
it.
If
something
wrong
has
happened,
we
will
always
can
remove
it
rewarded
later.
E
E
G
E
Roman
I
know
I
just
I'm
just
discussing
that
to
to
get
an
agreement
between
the
TSC
members
how
we
want
to
handle
that.
F
My
bid
is
that
it
is,
is
up
to
the
TSC
member
so
or
or
more
specifically,
when
you
approve
add
a
line
of
text
clarifying
what
the
next
action
is.
So
if
you
just
simply
approve
but
don't
say
anything
that
leads
to
ambiguity,
we're
not
sure
is
it
waiting
for
me
to
come
merge
it.
Are
you
looking
for
more
opinion,
because
you
weren't
sure?
Is
there
a
reason
you
didn't
merge,
it
just
say:
hey
I
want
one
more
opinion
at
TSC,
then
it'll
be
a
good
call
to
action.
F
If
it's
like,
hey
I,
want
to
leave
a
look
at
this,
then
I
know
that
it's
blocked
on
me,
but
like
I,
think
what
we
can
do
is
remove
the
ambiguity
I'm,
not
promising
that
that
will
make
us
move
dramatically
faster.
At
least
it'll
be
clear
whose
fault
this
is
for
not
taking
the
next
action,
which
will
probably
most
of
the
time
be
me,
but
at
least
it'll
be
clear,
and
the
particular
pattern
of
like
I
want
two
sets
of
eyes
on
this
thing
super
reasonable.
F
As
long
as
we
make
it
clear
that
that's
the
case.
F
F
You're
done
all
right:
I
will,
after
the
meeting
I
I,
already
I
merged
one,
while
you're
discussing
and
merged
the
first
one.
A
couple
of
these
others
have
either
lint
failures
or
test
failure.
I
will
go
through
and
clean
some
of
those
up
so
that
I
can
merge
these
and
any
that
have
more
discussion
on
them.
I'll
tap
books
to
figure
out
next
actions,
so
we'll
get
some
of
those
move
forward.
Okay,
thank
you.
F
Absolutely
speaking
of
things
that
are
aged
and
out
of
date
default
value,
validation,
yeah.
If
you
put
this
on
the
list,
I
have
a
feeling
that
I'm
going
to
end
up
speaking
to
it.
But
let
me
know
what
you
were
thinking.
C
That's
basically
the
case
I
mean
I'm
excited
to
to
I've
been
able
to
help
out.
Hopefully
it
helped
out
a
little
bit
by
rebasing
all
of
your
hard
work,
so
I
put
a
link
in
the
agenda
to
where
I
last
saw.
This
discussed.
I
was
back
in
September
2021
and
it's
basically
just
a
synopsis,
I
guess
from
the
working
group
meeting
there
where
I
guess
there
was
support
voiced
by
some
of
the
implementers.
C
You
know
that
this
was
working
out
well
and
it
looked
like
it
looked
like
we
were
thinking
something
like
you're
gonna
do
one
last
check
and
it
was
almost
ready
to
go
and-
and
hopefully
it's
still
that's
the
case-.
F
Tweets
does
that
mean
that
this
next
action
is
purely
on
me?
That's
amazing,
because
I
remember
that
last
discussion
about
the
rebase
was
the
real
pain,
because
I
had
done
all
that
work.
I
think
right
around
the
same
time
that
Yvonne
and
crew
were
porting,
the
code
base
to
typescript,
and
so
there
was
a
bit
of
a
race
condition
of
which
of
these
major
bodies
of
work
would
get
ready
first.
C
B
Yes,
so
there
is
an
open
action
item
in
the
working
group
for
Lee
to
re-review
the
spec
changes,
because
I
believe
Lee
was
reasonably
happy
with
the
spec
changes.
Then
he
went
about
actually
making
the
changes
to
graphql.js
and
I
believe.
At
that
point,
you
may
have
changed
Direction
a
bit
and
I
struggled
to
figure
out
how
to
turn
that
back
into
spec,
Tech.
So
I
think
that
is
also
on
you
as
well:
Lee,
I'm,
afraid,
fun.
F
Times,
okay,
foreign!
Well
then
we
have
maybe
an
underwhelming
I
think
you
offer
hard
work,
but
maybe
an
underwhelming
status,
which
is
that
this
is
stuck
on
me
for
next
action.
But
I
will
make
a
priority
to
make
this
move
forward.
F
D
Maybe
we
can
separate
something
because
it's
a
huge
pair,
the
more
stuff
we
can
separate
the
easier
it's
like
for
people
review
and
understands
these
spec
changes
as
much
and
quite
implementation,
because
previously
we
had
like
issues
when
both
things
make
sense,
but
they
didn't
match
so
yeah
I
will
try
to
work
with
Jaco
and
see
why
it
can
be
as
first
to
accept
to
see
if
we
can
separate
some
non-spark
changes
and
maybe
there's
more
if
yeah
and
review
it
actually.
Like
last
time,
I
tried
to
understood
it.
D
It
was
pretty
complex
one.
One
thing
that
made
me
like,
like
easier
during
review
and
stuff,
is
to
check
what
what
NG
implemented
in
graphql
Java
GTM
format
like
a
spec
or
graphql.js,
and
if
you
implement
graphqjs,
and
they
had
like
it's
already
like
one
year
or
two
years
passed
since
he
implemented
it
didn't
count
like
any
issues,
because
if,
if
it's
the
same
thing
with
that,
graphql.js
is,
and
let's
understand
from
badges
commented
last
iteration
it's
what
graphql
is
and
spec
is
working
behind.
D
So,
if
that's
what
graphql
Java
format
and
and
they
didn't
find
any
issues,
it
will
pressure
or
maybe
they
will,
they
found
something
and
they
fix
it.
That
are
like.
One
of
the
thing
is
because,
like
in
this
particular
case,
they
like
much
stuff
and
our
community
to
test
it
so
I'm
for
for
learning
you
you
want
to
Champion
with
and
push
forward.
Can
you
contact,
Angie
and
or
somebody
from
graphql
team
and
ask
like
what's
the
status
on
their
side
and
feedback
from
the
users.
C
Yeah
yeah
I'm
good
glad
to
reach
out
one
additional
thought
is,
is
that
is
that
there's
actually
I
was
noticing.
There's
actually
seems
to
be
like
two
spec
changes
in
in
the
stack
I
mean
one
one
is
the
schema
coordinates
is
that
is
that
maybe
that
then
that
came
first
is
that
maybe
simpler
and
ready
to
and
more
ready
to
go.
F
D
One
thing
about
schema
Cardinal
before
we
forget,
like
we
had
like
discussion,
point
about
the
introspection,
Fields
and
the
use
of
a
special
Syntax
for
introspection
Fields,
like
type
name
which
should
have
coordinates-
and
this
was
the
only
like
kind
of
controversial
thing
from
the
whole
thing.
So
everybody
else
yeah
it's
old
right,
but.
E
E
E
E
The
schema
with
with
the
coordinate,
that's
okay,.
F
I
don't
mean
to
open
up
the
can
of
worms
around
that
if
there's
more
to
discuss
before
nailing
it
down
we'll
do
that,
but
I
can
like
make
sure
I
say
review
through
the
work
so
far.
Let
me
see
if
there's
something
that
needs
extra
action.
F
I
know
we're
at
15
minutes
the
hour,
which
is
the
amount
of
time
that
you
asked
for
Rob,
so
I'm
gonna
close
the
book
on
this.
Thank
you
Jaco
for
the
hard
work
getting
that
PR
stack,
rebased
I
will
take
a
look
Rob
in
it
to
you.
I
Yeah,
so
we
had
another
breakout
meeting
shortly
before
the
holidays,
so
just
want
to
like
give
a
little
bit
of
a
recap
of
that
and
show
a
new
proposal
that
we've
iterated
on
since
the
last
time.
I
just
want
to
get
just
some
initial
gut
feedback
from
everyone,
because
we
have
another
breakout
meeting
scheduled
Monday
but
yeah.
So
let
me
share
my
screen.
I
Yeah
we're
still
on
this
issue
that
stemmed
from
clients
being
not
unable
to
tell
if
a
fragment
has
been
deferred
or
not,
but
in
there
and
we've
been
discussing
it
going
back
to
labels
and
this
execution
branching
Behavior
generally
I.
Don't
think
anyone
is
really
happy
with
labels,
so
we're
looking
for
ways
to
drop
it
if
needed.
I
If
we
can
and
so
kind
of
going
back
to
the
basics
in
graphql,
we
have
a
mechanism
to
Branch
execution
on
fields
which
is
aliases
and
we
do
not
have
the
same
thing
on
fragments.
Of
course,
maybe
we
will
in
the
future
so
and
if
we
did
have
fragment
aliases,
you
definitely
wouldn't
need
labels,
because
you
could
use
a
fragment
Alias
and
get
in
part
of
the
path
of
exactly
which
fragment
your
defer
refer
to.
I
So
we
were
talking
about
what
would
defer
look
like
if
we
did
have
fragment
aliases,
and
if
that
was
the
case,
would
we
allow
to
use?
Would
we
allow
you
to
use
defer
on
a
fragment
that
was
an
aliased
I?
Think
everyone
wanted
said
that
should
generally
be
true,
and
the
answer
to
that
would
be
that
all
of
your
non-aliased
fragments
that
are
deferred
should
get
merged
together.
I
I
So,
mapping
that
out
a
little
bit,
here's
like
an
a
new
proposal
of
saying
what,
if
we
don't
have
label
onto
first
stream-
and
we
do
say
that
all
of
your
deferred
fragments
that
are
under
the
same
object,
get
merged
together
and
you
only
get
one
payload
back
for
that
and
that
has
the
selection
of
all
those
fragments
and
let's
also
say
for
Simplicity,
that
we
don't
allow
any
stream
on
the
same
field
to
merge
with
another
one.
I
So
if
you
have,
if
you
have
a
field,
that's
being
streamed,
and
you
want
two
separate
independent
streams,
you
have
to
Alias
that
field
and
Benji
talked
last
time
about
having
a
pending
object
to.
Let
clients
know
when
something
is
in
the
works
like
a
like
an
analog
of
a
promise
being
that's
being
executed.
I
So
here's
like
a
simplified
version
of
that,
where
we
just
only
put
the
path
in
there
and.
I
Yeah,
so
an
example
is,
let's
say
we
have
this
list
field
that
has
a
whole
bunch
of
fragments
under
it
they're
the
same
one
here,
but
they
don't
have
to
be,
but
basically
it's
just
all
a
whole
bunch
of
fragments
spread
under
the
same
object,
and
so
the
result
should
be
that
you
get
one
payload
for
each
object.
That's
in
the
list
all
day,
all
the
fields
in
these
fragments
got
merged
together,
and
that's
just
one
defer
that
happen.
Basically,.
I
I
Another
example
there's
a
stream
with
a
deferrent
side
of
it
and.
I
So
it's
kind
of
the
same
thing
we
were
expecting
where
you
get
back
the
the
streamed
items
and
the
Deferred
items
on
there.
I
have
examples
with
the
pending
payloads.
So
now
clients
can
know
that
something
wasn't
in
line
because
they
see
that
the
pending
was
there
and
I
also
headed
a
completed
true
object
here.
So
a
client
can
know
that
the
stream
has
closed
when
it's
over.
I
We
left
this
off
with
a
with
an
open
question
of
what
happens,
to
fields
that
are
both
inside
a
deferred,
fragment
and
not
inside
of
a
deferred
fragment.
So
that's
this
example
here
it's
a
kind
of
nasty
example
with
a
bunch
of
nesting
it
we
thought
that,
ideally
it
could.
These
fields
that
are
both
in
both
places
could
get
removed
out
of
the
defer.
I
But
it's
kind
of
hard
to
implement
that,
with
the
way
that
collect
Fields
works
now
collect.
Fields
is
basically
going
down
each
level
of
the
object
once
at
a
time,
and
you
would
have
to
when
you're
looking
at
C,
you
would
have
to
know
and
go
down
to
the
depth
of
both
of
them
to
know
whether
it
could
be
removed
or
not.
I
That
does
lead
to
like
this
example,
which
is
kind
of
nasty
where,
if
you
are
doing
that,
removal
which
we
haven't
figured
out,
how
to
do
it,
it
would
like
merge
down
nicely
into
this.
One
deferred,
fragment.
E
The
the
issue,
the
issue
here
is
so
Rob
me
and
Benji
discussed
it
a
bit
between
the
the
days
over
the
holidays
and
that
the
issue
here
is
so
if
you
have
a
two-phase
execution
where
you
compile
the
query
essentially,
then
it's
not
a
problem,
so
you
can
do
a
pre-traversal
and
then
it's
an
easy
thing
to
do.
But
the
graphical
collect,
Fields
algorithm
goes
field
by
field,
so
you
cannot
figure
that
out
very
easily.
E
So
at
the
moment
there
are
two
thinkings
about
that.
Two
describe
essentially
collect
fields
to
figure
out
most
of
the
cases,
but
then
tell
in
in
a
in
a
note,
maybe
that
this
could
be
optimized
in
that
way
and
then
leave
it
up
to
implementers
to
have
a
more
optimized
version.
E
There
are
a
couple
of
graphical
implementations
and
anyway,
do
like
to
face
executions,
and
let
them
fix
it
that
way
or
it
would
be
a
greater
change
to
the
spec,
because
then
you
need
something
like
a
pre-charted
version,
but
the
contents
there
is
that
this
would
be
a
too
big
of
a
change
for
the
spec.
G
D
E
We
we
can
go
through
it,
but
the
the
essence
is,
if
you
have
over
multiple
levels,
fields
that
you
need
to
merge,
that
is
not
possible,
because
the
the
way
collect,
Fields
works
is
only
on
one
selection
set
level.
But
in
this
case,
if
we
ideally
merge
it,
we
could
figure
out
that
also
the
deeper
levels
could
be
inlined,
and
that
is
essentially
what
collect
Fields
doesn't
do
it.
It
goes
level
by
level,
and
here
an
ideal.
D
E
D
D
E
D
D
C
I
I'll
write
a
detailed
comment
and
we
can
come
back
to
it.
What
what
I
I
do
mostly
want
to
hear
if
anyone
has
opinions
on
is,
is
the
idea
of
merging
the
deferrers
together
into
a
single
response.
I
It
would
things
would
work
very
ideally
if
we
do
figure
out
that
merging.
If,
if
we're
not
there
is
this
this
case,
where
you
could
have
multiple
responses
coming
back
to
the
same
path.
F
F
At
I'm,
a
little
surprised
at
the
proposed
removal
of
the
you
had
like
an
ID
field
or
like
some
nonce
identifier,
that
described
like
a
unique
promise
equivalent
in
here
and
I.
Think.
Maybe
it's
not
safe
to
assume
that
a
path
uniquely
identifies
that
you
want
to
get
that
back.
But
to
your
question
on
merging
defers.
I
do
think
that
that
will
be
the
expected
behavior
that
most
people
will
have
like
I.
F
Think,
most
of
the
most
of
the
examples
that
you've
shown
in
this
comment
make
a
lot
of
sense
to
me
whether
we
can
get
the
behavior
actually
work.
That
way
is
a
separate
story,
but
it
I.
You
know,
I,
do
think
that
if
you
encounter
two
separate
branches
of
fragments
that
both
encounter
to
defer
that
you
would,
at
the
same
level
that
you
would
kind
of
expect
a
single
batch
to
come
back
with
those
in
place.
That
makes
a
lot
of
sense.
F
Does
this
is
the
idea
to
completely
remove
label
or
just
to
make
label
optional
such
that
this
is
the
default
Behavior
because
it
did
seem
useful,
but
maybe
not
necessary
to
have
the
the
ability
to
say
like
yes,
these
two
differs
are
at
the
same
level,
but
I
explicitly
do
not
want
them
to
be
merged.
I
want
them
to
come
back
as
two
payloads,
because
the
second
one
is,
you
know
not
urgent,
but
I
need
it,
and
this
third
one
is
very
expensive
and
slow,
but
I
also,
you
know
what
I
mean
I'm.
I
I
There
is
another
workaround
that
could
be
done
where
you
Alias
the
parent
field,
that
has
the
Deferred
fragment
and
that'll.
Give
you
two
separate
paths,
then.
E
We
essentially
sorted
that
out
so
with
that
it's
possible
to
to
explicitly
address
that
with
the
aliasing
of
fragments,
but
in
order
not
to
block
it
now
with
another
proposal
that
we
need,
we
just
essentially
skipped
it
out,
and
the
the
problem
is
that
label
was
never
enough
for
for
what
we
wanted
to
do
and
the
original
intent
was
not
to
prevent
the
merging.
So
it
feels
not
right
to
have
the
label
there.
Yeah.
F
One
thing
that
I'll
say
is:
it
is
much
better
to
have
like
we
can.
We
can
always
add
functionality
that
results
in
multiple
payloads,
rather
than
one
like
it's
I
think
it
is
more
painful
to
go
from
a
default
behavior
of
multiple
payloads
to
one
that
later
causes
them
to
be
merged,
as
opposed
to
the
other
way
around
like
this.
Is
this
a
simpler
possible
payload
and
label
was
always
a
little
confusing
to
me
and
I
I.
F
Think,
like
many
many
years
ago,
we
discussed
the
idea
of
having
like
priority
as
like
an
integer,
be
a
thing
here
that
would
cause
them
to
be
split
and
then
like
ordered
in
their
delivery
in
some
way,
so
it
seems
like
there's
like
a
future
follower
that
we
could
consider
that
re
unmerges
them
so
I
I
think
I'm
in
favor
of
this
of
this
direction,
where
merging
is
the
way
that
these
work
and.
E
I
Yeah
and
to
be
clear,
the
merge
like
this
case
is
definitely
doable
easily
implementable.
It's
just
like
collect
Fields
can
easily
be
updated
to
return,
not
just
one
selection
set,
but
two
selection
sets
here's
all
the
Deferred
fields
and
all
the
non-deferred
fields,
it's
just
the
specifically.
How
do
we
take
stuff
out
of
the
Deferred
Fields
if
they're
already
in
the
non-deferred
fields?
That's
where
the
open
question
is
right.
F
F
F
I
Yeah
and
awesome
work
just
just
a
quick
note:
you
mentioned
the
ID
I
did
it
include
it
here,
just
to
have
one
last
concept,
but
that's
like
an
optimization
that
we
could
add
or
not
add,
not
totally
sold
in
either
direction
right
now.
Okay,
on
that
I,
just
haven't
really
been
focusing
on
that
makes.
F
Sense
all
right,
that's
time.
Thank
you
all
for
the
ample
conversation.
Good
topics
see
y'all
in
the
next
meeting.