►
From YouTube: GraphQL Working Group (Secondary, EU) - 2022-12-15
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
Happy
Thursday
Thursday
evening
for
you,
but
Thursday
still
it
is
indeed
how's.
Life
been
recently
other
than
hectic.
A
Today,
yeah
it's
nice
to
be
able
to
talk
to
somebody
on
the
call
that
that
deals
in
Celsius,
like
I,
do
talking
to
people
and
they're
telling
me
Fahrenheit
I'm,
like
what.
B
A
Exactly
the
way,
that's
what
I
do
every
time
too
so
yeah
we,
it's
actually
been
fairly
warm
here.
It's
it's
usually
much
colder,
but
yeah
we're
only
at
about
actually
went
above
freezing
today,
which
is
bizarre,
but
yeah
usually
we're
around
-10
ish
around
this
time
of
year,
but
it's
been
surprisingly
warm.
At
least
we
do
have
a
bunch
of
snow
on
the
ground
now,
which
is
good,
but
yeah
that
also
took
a
long
time
to
show
up
to
so
hey.
A
Cold
and
rain
yeah:
do
you
get
big
snowfalls
where
you
are
at
all
or
not
so.
B
We
normally
don't
get
snow
or
hardly
any,
and
normally,
if
we
do
get
it,
it's
like
in
February
or
maybe
even
March
yeah
so
having
snow
in
December
is
incredibly
rare.
A
And
and
soon
you're
gonna
have
the
power
of
light
to
serve.
A
C
It's
interesting
how
how
things,
how
you
change
criteria
of
children,
things
fiber
optics
work,
even
if
you
don't
have
like
electricity
in
a
Groupon,
because
it's
white
everything
is
special
between
you
and
provider,
so
yeah
and
big
benefit.
It's.
A
E
A
Not
joined
hello,
how's
it
going
Rob
hey.
How
are
you
good
doing?
Okay,
talking
about
the
power
of
light
to
serve
the
internet
and
fiber
optics.
C
B
B
C
A
Cool,
so
it's
the
last
meeting
of
December
wow.
B
A
B
Not
here,
I
was
looking
at
least
yeah.
A
D
A
Thought
that
I
updated
it
yeah
I
thought
I
did
too
yeah,
it's
just
the
one
that
says
when
I
look
at
the
calendar
event,
let
me
just
see
where
it's
coming
from
the
one
I
added
when
I
click
on
the
calendar
event.
A
It
looks
like
it
is
the
graphql
foundation,
one
just
says:
WG
number,
two:
okay,
yeah
and
I-
think
that's
where
it
came
from
originally
and.
A
It
yeah
I'm
gonna
double
check
here,
just
to
make
sure
it
hasn't
been
updated.
Since
last
for
the
meeting
at
the
the
first
working
group,
one
meeting
I
clicked
on
the
link
in
the
calendar
invite
and
it
was
wrong.
But
today
I
just
went
straight
to
the
agenda.
C
A
D
E
Folks,
hello,
are
we
talking
about
calendar
pain?
Yes,
yes,.
A
E
I
also
just
got
locked
out
of
Zoom.
That's
why
I
was
five
minutes
late.
It
was
just
like
frantically
trying
to
figure
out
how
to
log
back
into
zoom
in
it.
Otp'd
me
like
three
times
in
a
row:
we've
just
been
not
been
a
great
day
for
the
calendar,
slash
the
zoom
combo.
A
E
Oh
yeah,
this
is
the
other
thing.
Yeah
I
got
locked
out
of
the
I
got
locked
out
of
the
graphql
foundation.
Zoom,
that's
the
host,
yeah
and
I
need
I.
Need
that
in
order
to
start
the
recording.
B
But
if
you
click
it,
it
will
just
say
you
need
host
permission
and
it
doesn't
recognize
Lee
or
me
as
the
host.
So.
C
E
All
right
well,
then,
we'll
have
a
fantastic
first
couple
of
minutes
of
us
all,
looking
very
confused
about
how
to
use
software,
which
is
I,
think
Super
relevant
for.
E
Is
oh
boy,
let
me
reload
our
agenda
file,
okay,
cool
I,
think
I.
Think
we've
got
a
full
crew.
I
think
this
is
just
our
audience
for
today.
Right,
there's
I
see
six
names
in
our
attendee
list.
We've
got
six
here,
so
yeah
we
got
Quorum.
Let's
go
all
right.
We
all
agree
to
the
four
top
links
listed
in
the
agenda
and
let's
do
just
a
quick
names
to
faces
for
the
for
the
value
of
the
recording
I'm.
First
in
the
list,
so
hello,
everybody,
my
name
is
Lee.
E
Thanks
all
for
joining
and
I
believe
to
have
I,
don't
have
the
link
set
up
in
the
doc
for
live
notes,
but
we've
been
using.
E
E
B
I
think
it's
fine
I,
don't
always
synchronize
it
like
I
will
often
after
the
first
primary
meeting
and
then
after
all
of
them
are
done.
I
don't
seem
to
do
it
after
the
secondary
one,
because
it's
just
too
many
times
but
yeah.
E
E
I
think
everybody
here
has
been
in
the
primary
meeting,
so
not
necessary
for
us
to
do
a
review
of
that
do.
Actually,
maybe
it
would
be
helpful
for
us
to
do
a
review
of
the
APAC
time
zone
secondary
one
that
happened
last
week.
Benji
I
know
that
you
were
in
attendance
there.
B
Well,
we
skipped
over
quite
a
lot
of
the
stuff
like
reviewing
the
previous
meeting
action
items.
There
wasn't
really
anything
to
advance
there,
I'm
afraid
I'm
a
bit
behind
in
filing
those
Donna
wanted
to
find
out
about
getting
the
legal
sign
off,
which
I
believe
is
on
Julie
and
okay.
I
believe
that
they
have
filed
an
issue
about
it
which
is
assigned
to
you,
so
you
should
have
the
relevant
thing
there
and
then
the
rest
of
the
meeting
was
other
than
mentioning.
B
The
TSC
elections,
of
course,
was
discussing
Roman's
various
pull
requests
to
the
spec,
many
of
which
were
just
a
you
know,
a
few
lines,
some
of
which
were
more
looking
into
the
reasons
why
they
may
not
have
been
immediately
merged.
B
Expanding
on
some
of
those,
so
I
think
a
couple
of
those
got
merged.
Some
of
them
got
some
good
feedback,
and
some
of
them
are
still
waiting
on
waiting
on
the
advancement
by
the
author,
okay,.
F
I
think
the
the
one
takeaway
was
like
Roman
was
pretty
frustrated
that
he
had
gotten
sign
off
on
some
of
these
approval
and
still
could
not
figure
out
how
to
make
progress
so,
like
figuring
out.
Okay,
if
you
manage
to
get
one
person
to
approve,
especially
a
person
on
the
TSC
or
who
has
merge
rights,
how
like
what's
the
pro
process
to
make
sure
it
doesn't
get
mired
and
in
his
case
bringing
it
to
the
working
group
was
probably
a
good
progress
right.
E
I
can
take
some
of
the
blame
there
I
think.
Historically,
our
process
has
been
someone
from
the
TSC
or
working
group.
Does
the
review
gives
a
thumbs
up
and
then
I
as
editor
does
do
a
final
pass
and
get
it
merged,
though?
We've
had
a
handful
of
cases
where
that's
not
been
the
case,
and
it's
been
okay
for
things
that
are
like
very
obvious
editorial
improvements
where
you
all
can
pretty
reasonably
read
my
mind
and
be
like
well,
this
is
certainly
better
than
what
we
had.
So
let's
do
it.
E
Those
seem
good,
but
I
can
go.
Take
a
look
through
some
of
the
remaining
ones.
If
there's
anything,
that's
still
left
on
me
for
editorial
review.
B
It
would
be
good
to
have.
We
were
talking
about
like
an
improved
process
there
as
well,
and
also
you
know
it's
get
at
the
end
of
the
day
right.
So,
if
you
need
to
revert
it,
you
can
so
I
think
having
the
the
TSC
and
other
working
group
members
have
more
confidence
to
to
push
these
things
through
would
be
good.
B
E
Me
that
seems
pretty
reasonable.
Also
we're
we're
intentionally
kind
of
plottingly
slow
with
the
spec
changes
like
that's
that's
by
Design,
so
yeah
I
understand
the
frustration,
but
you
know
I
think
we
shouldn't
over
optimize
towards
like
rapid
PR
merging.
B
Definitely-
and
that
was
that
was
it
really-
it
was
quite
a
long
discussion,
but
yeah.
E
Like
it
was
pretty
cool,
we've
got
actually
a
decent
amount
of
interesting
things
to
get
through
today,
despite
the
small
audience,
which
is
great
Benji,
do
you
want
to
talk
about
field
errors
from
insufficient
to
validation,
variables.
B
Yeah
absolutely
does
someone
want
to
volunteer
to
take
notes,
I've
just
put
in
some
headings
but
yeah.
It
would
be
nice
to
have
someone
go
through
and
take
some
notes.
A
D
D
B
Okay,
yes,
so
this
is
reopening
the
old
wound
of
null
ability
versus
optionality
I,
as
you
may
all
know,
now,
I'm
working
in
on
another
implementation
of
the
graphql
spec,
particularly
an
alternative
execution
engine
and
as
such,
I
am
going
through
with
an
even
more
fine-tooth
comb
than
I
was
previously,
and
there
are
some
things
that
are
quite
interesting,
one
of
which
is
this
one.
B
Where
effectively
a
value
has
two
defaults.
It
has
the
default
that
is
provided
to
the
variable
and
it
has
the
default
that
the
field
itself
has,
and
at
the
moment
we
allow
the
variable
to
be
nullable,
which
is
so
that
you
can
not
provide
the
variable,
in
which
case
I
think
the
yeah
anyway,
there's
there's
a
couple
of
places
where
that
gets
interesting.
B
But
you
can
because
it's
nullable
pass
explicitly
null
and
if
you
pass
explicitly
null,
then
the
variable
default
doesn't
kick
in,
because
you've
said
it
is
not,
rather
than
omitting
it,
in
which
case
the
defaults
say
three
would
kick
in.
If
you
explicitly
state
that
it
is
null,
then
the
default
doesn't
kick
in
and
it
is
null.
But
then
we
try
and
pass
it
to
a
field
that
is
non-nullable,
and
that
gives
you
a
runtime
error
rather
than
a
validation
error.
B
B
That's
what
it
seemed
like
to
me
and
the
queries
that
we
had
that
supported
that,
like
this
one
I've
got
at,
the
top
of
this
issue
could
well
have
taken
a
variable
that
was
an
INT
bang
equals
three,
whereas
where
you
either
provide
a
number
as
in
a
non-nullable
int
or
you
don't
provide
number
at
all
and
the
default
applies.
B
But
yes,
that
is
not
the
case.
That
is
not
the
status
quo,
and
so
we
have
this
runtime
error
that
feels
like
it
should
be.
A
validation
error.
F
F
Yeah
we
we
decided
that
if
you
have
a
default
value,
then
you
are
allowed
to
be
used
in
a
non-nullable
position.
So
long
as
the
default
value
is
not
null,
and
we
did
that
because
I
think
the
reason
we
put
it
in
the
spec
this
way
is
because
the
Facebook
server,
the
way
it
behaves,
is
actually
when
you
we
all,
we
previously
always
stripped
nulls.
So
if
you
explicitly
set
a
variable
to
null,
it
was
just
stripped
from
the
request,
in
which
case
it's
actually
impossible
to
override
the
default
variable.
F
And
we
like,
we
baked
that
behavior
in
and
then
made
like
bang
means
you
are
required
to
set
it
and
we
actually
on
our
Facebook
servers.
We
made
it
actually
a
validation
error
to
have
banged
with
a
default
value
because
we
wanted
Bing
to
mean
you
must
set
this
variable
and
yeah
I
think
that
that
is
I.
I
think
that
that
was
incorrect,
like
that
was
that
was
up.
D
E
E
The
Hairball
of
this
Edge
case
and
I
remember
like
the
motivation
to
get
this
right
was
explicitly
to
disallow
nulls,
making
their
way
through
a
well-typed
boundary
like
if,
if
your
schema
declares
that
this
isn't
can't
be
null,
then
allowing
a
null
through
is
a
security
risk,
because
someone
could
find
out
that
you
can
throw
a
null
pointer
exception
and
then
just
Spam
your
server,
with
null
pointer
exceptions,
trying
to
take
out
your
service.
E
So
this
is
alarmingly
surprising
and
High
urgency
to
fix
if
we
have
not
I'm
curious,
if
we
were
to
assemble
this
use
case,
like
Benji
as
you
assembled
this
this
example.
Are
you
evaluating
it
as
your
own
read
through
the
spec
rules
or
you
evaluating
this
with
existing
code.
B
Both
I
did
it
with
my
read
through
the
spec
rules,
because
I
was
implementing
a
graphql
engine
and
then
I
have
in
I've,
then
written
a
test
case
that
you
can
run
against
graphql.js.
That
shows
the
behavior.
That
I
was
explaining
it's
at
the
bottom
of
the
of
the
top
comment
there.
Oh.
A
E
E
Either
we
can
say
a
value
null
means
has
value
is
false.
My
sense
is
it's
probably
the
wrong
way,
but
that
would
solve
this
problem
right.
It
would
mean
that
default
values
would
override
the
null
or
we
must
move
the
assertion.
B
Yeah,
so
I
think
one
option
would
be
to
make
a
validation
rule
so
that,
if
you're
using
a
variable
in
a
non-nullable
position,
then
it
needs
to
be
a
non-nullable
variable.
Then
you
can
give
it
a
default
if
you
want
to
make
it
optional,
but
ultimately
the
default
bore
that
argument
won't
if
you're,
if
you've
fed
a
variable
in
for
it,
it
will
only
apply
if
you
don't
feed
anything
into
it.
B
If
we
were
to
do
that,
though,
that
would
be
a
breaking
change,
but
it
would
only
break
queries.
I
was
going
to
say
it
would
only
break
queries
that
were
already
erroring,
but
that's
not
true.
B
It
would
be
a
breaking
change
because
queries
that
were
previously
valid,
such
as
this
query,
queue
that
I
have
at
the
top
of
my
issue
would
no
longer
be
valid,
because
the
the
validation
rule
would
say
you
can't
Define
a
variable
here
that
is
nullable,
so
I
fear.
We
may
not
be
able
to
do
that,
in
which
case
I
think
the
only
option
would
be
what
previously
was
erroring,
which
is
when
you
feed
a
null
into
this,
which
is
causing
the
problem.
Instead.
B
F
There's
also
a
breaking
change,
though,
because
this
means
that
if
we
coerce
it
to
the
default
value,
it
means
it
becomes
impossible
to
pass
null
into
a
variable
like
situations
where
clients
are
currently
passing
null
in
explicitly
to
a
variable
that
has
a
default
value
in
a
place
where
it's
allowed
to
be
null
would
not
coerce
to
the
default
value
and
that
or
are
not
now,
but
would
after
this
change
so
either.
One
of
these
choices
is,
in
fact
a
breaking
change.
F
E
C
C
Yeah,
because
I,
when
we
mentioned
it,
I
also
start
to
remembering
we
how
I
really
want
discussion
with
like
free
options
and
respond
like
half
a
year
deciding
what
to
do
so.
The
thing
is
is,
but
that
crap
here
just
doesn't
Implement
with
the
right
Bunch,
since
you
tried
it
on
Craft
Kitchen,
because
we
have
code
sample.
So
it's
it's
not
causing
error
right.
E
Had
to
throw
a
field
error,
but
it
should
not
throw
a
like
a
null
pointer.
Exception,
run
tone
error
right,
like
what
is
important
is
that
you
can't,
if
you
have
a
resolver
function
that
is
well
typed
like
in
so
graphql.js,
assuming
a
typescript
code
base,
where
you
say
that
the
arguments
to
this
function
is,
you
know
you're.
What
was
the
one
from
your
example?
E
Number
okay
number
is
the
is
the
argument
to
your
function,
and
it
is
a
none.
It
is,
is
a
number
it
is
not
number
or
null
it
is
number
and
then
at
runtime
it
all
gets
passed
in,
and
so
you
want
to
do
like
all
right.
I
want
to
return
double
the
number
and
you
multiply
it
by
two
and
it
returns
Nan
and
then
like
breaks.
E
E
It
is
not
possible,
detect
it
any
earlier,
because
it
is
a
runtime
value
path
in
so
there
is
no
way
for
validation
to
catch
this,
because
it's
about
a
runtime
provided
value.
Then
it's
just
a
matter
of
like
what's
the
best
case,
we
can
do
for
this
particular
Edge
case,
while
still
preserving
the
constraint
that
user
code
is
well
typed
and
we
respect
the
types
of
the
user
code.
B
F
It's
not
an
all-pointer
exception
on
the
server.
It
is,
however,
like
if
you
have,
for
instance,
a
Java
client
or
a
kotlin
client
or
whatever,
where
you're,
like
your
query,
Builder.
That
you're
building
up
like
the
unfortunate
thing
here
is
that
when
we
like
have
the,
when
we
generate
that
code
for
the
query
Builder,
we
cannot
like
you
can't
pass
null,
but
there's
no
way
for
us
to
say
that
to
the
client,
like
I
I
treat
this
situation
as
a
bug
in
the
spec.
F
E
So
the
note
that
we
have
here
or
actually
right
above
the
note,
there's
a
section
that
says
in
the
example
below
an
optional
variable-
is
allowed
to
be
used
in
a
non-null
argument,
because
that
variable
provides
a
default
value
in
the
operation.
We
explicitly
allow
this
for
compatibility
with
earlier
editions
of
the
spec
authoring
tools.
E
Aka
graphical
Winters,
whatever
may
want
to
report
this
as
a
warning
with
suggestion
to
replace
the
type
Boolean
here
with
the
type
Boolean
exclamation
point
non-no
Boolean.
In
order
to
avoid
this
ambiguity,
because
if
you
took
that
example
example
189
in
the
in
the
draft
and
added
just
an
exclamation
point-
everything
there
would
continue
to
be
true
right,
like
the
default
value.
Is
there
you
could
pass
Boolean
false
to
that
ARG.
If
you
wanted
to,
you
could
not
pass
it,
it
would
get
the
default
value.
E
True,
if
you
passed
null,
it
would
catch
it
with
a
improved
error
message
which
is
like,
rather
than
waiting
for
it
to
arrive
at
that
particular
location.
It
would
say.
Actually
this
is
a
non-nobley
invalid
variable
and
therefore
you
cannot
pass
null
to
it.
E
E
Maybe
what
we
should
have
done
then-
and
we
could
consider
doing
now-
is
introducing
a
validation,
Rule
and
sort
of
like
reframe.
This
back
compatibility
thing
to
say
this
is
this
validation.
Rule
is
not
a
month.
This
validation
rule
as
it
should
and
and
the
validation
rule
in
this
case
is
like
there's
a
I
think
we
have
like
an
implicit
allowance
of
this
via
the
validation
where
we
we
have
like
the
explanation
for
it.
E
Oh
actually,
no,
this
is
the.
This
is
the
right
validation
rule.
All
variable
usages
are
allowed
and
so
like
that
could
be
the
other
way
around
this,
which
is
there's
like
a
either
like
an
addition
to
this,
or
something
that
you
could
like
flip
a
flag
like
I,
can
imagine
a
config
flag
in
graphql.js,
where
you
intentionally
turn
this
off,
because
you've
been
reliant
on
this
Behavior
and
then
once
you've
like
fixed
all
your
clients,
whatever
you
can
turn
it
on
or
if
you're
gonna
go
build
a
new
system
on
day.
E
F
Yeah
there
is,
there
is
something
like
looking
towards
the
future,
where
I
think
now
that
we
we
have
default
values,
we
have,
we
have
bang
or
non-nullable
variables
and
nullable
variables,
I
think
looking
towards
the
future.
It
would
be
really
lean.
Sorry
about
that.
It
would
be
really
clean
if
the
type
was
always
had
to
be
compatible
with
the
usage
and
then
the
default
variable
tells
you
whether
or
not
you
are
required.
F
If
there
is
no
default
variable,
then
you
are
required
to
pass
that
very
like
to
pass
a
value
and
like
to
be
backwards
compatible.
We
could
allow
that
to
coerce
to
oh,
if
you
don't
pass
a
value,
it's
null
but
like
when
I'm
thinking
through
specifically
fragment
arguments.
If
we
don't
require
passing
values
for
arguments
that
are
defined
with
no
default
value,
then
it's
possible
to
break
scope.
F
Locality
and
it'll
be
it'll,
be
a
weird
thing
with
fragment
arguments
that
they
like
what
a
default
value
means
is
whether
or
not
you
are
required
to
include
it,
whereas
on
the
query,
level
or
operation
level,
it
means
like
it
doesn't
mean.
E
I'm
I'm
more
nervous
about
changing
the
semantics
of
what
it
means
to
have
a
default
value.
I
think
I,
remember
a
couple
years
ago,
working
through
that
and
trying
to
explore
every
corner
case
of
exactly
how
to
get
the
behavior
right.
F
I
I
think
if
we
were
like,
if
we
were
starting
from
scratch,
I
think
that's
the
behavior,
but
like
it's
definitely
the
backwards
compatibility
like
if
we
ever
cut
a
like,
you
must
version
to
be
backwards,
compatible,
release,
I,
think
that
that's
what
we
would
want
to
do
so
there's
there's
like.
Maybe
we
need
just
like
a
list
of
things
that
we
would
do
if
we
were
cutting
like
a
new
if
we
said
this
spec.
If
your
server
follows
this
spec,
it
is
not
compatible
with
the
old.
E
Yeah
I
don't
know,
we've
had
a
principle
for
a
while
that
we
we
want
to
make
sure
long,
lived
servers
continue
to
be
viable,
I
think
our
primary
tool
around
that
has
been
to
introduce
things
as
students,
where
we
have
like
very
clear
language
that
the
the
only
reason
why
you
would
not
do
the
should
is
backwards
compatibility
for
an
existing
service,
and
then
that
way,
it
becomes
clear
that
an
implementation
would
want
some
kind
of
tool
there
to
to
like.
E
If
you
did
nothing,
the
is
is
followed,
but
you
like
a
must.
You
would
not
expect
the
user
of
a
library
to
to
disable
a
must,
but
I
should
you
might
expect,
depending
on
the
sophistication
of
your
library,
a
user
to
be
able
to
disable
the
should,
especially
if
there's
like
a
provided
reason
in
the
spec
itself,
as
opposed
to
just
saying
like
any
spec
prior
to
this
date
is
like
unlikely
to
continue
to
work
because
of
this
change.
I,
don't
think
we
can
do
that.
C
Can
we,
like
reverse
language,
I
mean
we
describe
the
future
like
behaviors,
that
we
want
and
how
like
appendix
said,
but
if
you
need
for
like
a
series
and
so
I
think
like
reversing
order,
because,
like
currently,
everybody
was
confused
because,
like
eventually
write,
this
problem
is
exist,
but
it's
it
took
us
some
time
to
find
like
a
piece
that
said,
it's
intentional,
maybe
it's
worth
to
as
a
policy.
Actually
it's
a
good
suggestion
for
second
topic
about
guide
editorial
guide
is
to
have
like
Behavior.
C
We
want
to
be
implemented
first
and
the
Historical
Notes
or
like
Legacy
as
as
appendixes,
and
but
basically
we're
so
issue
because,
like
people
information
from
scratch,
because
what
happened
right
now,
a
bunch
of
writing
it
from
scratch.
So
he
originally
coined
by
wine
for
in
the
spark-
and
he
implemented,
like
old,
Behavior,
problematic
Behavior,
instead
of
like
behavior,
that
we
want
implementation
Implement
unless
they
need
Backward
Compatible
to
be
Backward
Compatible.
So.
F
Though,
is
this
like
an
action
item
here,
for
this
specific
case
put
the
should
like
make
the
default
make
the
default
algorithm
use
should
and
then
have
an
append
it
have
like
outside
of
that,
if
you
need
back
like
four
backwards
compatibility,
this
is.
C
So,
like
you
can
disable
it,
but
you
need
to
do
something
to
disable
it
and
what's
what's
like
matching
changes
which
actually
will
prove
if
it's
a
big
issue
or
not
similar
to
how
how
JavaScript,
how
is
principle
not
to
break
the
web?
And
it's
like
tested
with
assumption,
with
principles
tested
by
having
Chrome
and
machine
release,
features
and
vaccine
if
they
break
anything
or
not
so
doing
like
this
spectacles
and
reverse
in
like
implementing
the
graphic
address
and
having
it
on
by
default,
will
show
issue.
E
Yeah
I
wish
it
was
easy
as
reversing
the
language
around
like
the
the
tricky
part
here.
Is
that
there's
like
an
explicit
step
in
the
algorithm
which
produces
this
behavior
on
purpose
and
I?
Don't
know
that
we
have
any
other
examples
of
cases
where
we
say.
E
Please
disregard
the
next
step
by
default,
unless
you're
doing
some
sort
of
compatibility
mode,
like
that's
just
like
inherently
weird,
not
saying
that
I
I,
don't
think
this,
that
we
should
do
it
categorically,
but
I'm
curious
to
see
like
if
we
were
gonna
if
we're
gonna
actually
employ
this
idea.
Let's,
like
let's
do
the
reversal.
E
The
default
behavior
is
the
right
one.
There's
language
that
describes
the
back
compatibility
mode.
If
we
were
to
look
at
the
actual
spec
text.
Change
of
that
would
we
go
oh.
This
is
a
lot
worse
than
what
we
had
before
I'd
be
curious
to
exactly.
C
Actually,
we
have
a
couple
examples,
but
in
general,
like
about
extensions
in
errors,
we
had
that,
like
we
had
that,
like
iterator
after,
like
1.0
release-
and
it
says
the
same
so
like
you
can
put
whatever
properties
inside
there
says
you
want,
but
it's
recommended
to
you
to
use
extension,
but
for
legacy
Services
normal
to
maybe
maybe
like,
and
we
also
I,
don't.
Remember.
Probably
we
have
it
in
the
spec
that
the
error
should
precede
the
data.
C
I
think
I
did
what
they
are,
and
it
was
also
later
so
maybe
like
have
like
special,
like
Banner
saying,
like
Legacy
compatibility
because,
like
we
have
like
from
from
top
of
my
mind,
we
already
have
three
examples
of
like
maybe
appendix
maybe
it's
just
separate
appendix
saying
like
if
you
need
the
Legacy
refer
to
his
appendix
and
it's
how
like
clear
text.
Please
keep
with
step
and
example
like
a
problem.
E
Yeah
I'm
not
opposed
to
adding
an
appendix
around
this
I
think
I'm,
like
usually
biased,
to
keeping
the
language
as
close
together
as
possible
and
as
pithy
as
it
needs
to
be
to
get
the
point
across,
but
something
worth
exploring
as
we
write
it
out.
B
B
Okay
did
I
not
put
that
in
okay.
E
Yeah
part
of
that
is
I'm
thinking
like,
as
we
were
evaluating
this
one,
we
should
think
about
the
like
net
Improvement
in
developer.
Experience
versus
the
like
potential
for
chaos
of
the
change
I
think
it's
probably
right
to
make
the
change
I
think
we
probably
like
over
pivoted
to
allowing
the
back
compat
case
last
time
as
the
default
mode.
B
C
Can
you
post
it
in
in
nature
could
be
easier
to
read
it
yeah
sure
we'll
do
that.
B
It
does
does
come
with
a
stack,
Trace,
I'm,
afraid,
foreign.
E
Yeah
this
this
line
in
that
algorithm
I
think
is
the
like
one
end
question
but
I'd
be
curious.
We
need
to
gut
check
that,
thanks
for
getting
that
in
the
comments
and
Gene
graph
calculator.
E
That
certainly
doesn't
help
you
is
it
what
we
should
really
like.
Ideally,
if
we're
gonna
handle
that
edge
case,
we
were
putting
the
work
in
to
say
basically
like
make.
It
appear
the
same
as
a
variable
error.
It's
just
like
you
catch
it
late,
instead
of
catching
it
early,
but
anyway,
I
think
this.
This
line
three
in
is
variable
usage.
Allowed,
is
probably
the
the
one
that
needs
the
change.
I'm
curious
like
what
is
the
backwards
incompatible,
but
like
idealized
version
that
just
the
step
three
destroyup
doesn't
exist.
E
Yeah
algorithms
are
kind
of
weird
to
add,
should
or
may
language
in
them,
because
they're
kind
of
like
either
are
the
algorithm
or
they
aren't,
which
is
I.
Think
the
quirkiness
that's
like
running
me
through
a
loop
a
little
bit
here.
E
E
F
Or
have
is
variable
usage
strictly
allowed
as
like
a
separate
Rule
and
then
have
like
should
and
must
like
is
variable
usage
he's
variable
usage
strictly
allowed?
If
you
do
that,
that
encompasses
is
variable
usage
allowed,
but
you
are
allowed
to
just
do.
Is
variable
usage
allowed
I,
don't
know.
C
I
I
would
suggest
like,
instead
of
making
it
trickier
for
people
who
don't
care
about
work,
I
say:
can
we
just
have
this
variable
about
Legacy
inside
the
appendix
and
beneath
beneath
is
variable
allowed?
We
have
I,
guess
Banner,
saying
if
you
care
about
Legacy
things
you
need
to
implement
is
variable
usage
about
Legacy,
which
is
described
in
the
appendix,
which
is
copy
paste
with
small
change.
C
I
I
I'm
I'm,
like
yeah,
already
tricky
as
it
is
without
like
putting
stuff
historical.
C
E
I
think
that's
probably
right
like
there's
this
Top
Line
one
has
is
variable
usage
lab
and
then
somewhere
in
this
exact
sort
of
you
know,
specific
section
is
sort
of
a
highlight
that
there's
an
element
of
this
that
maybe
incompatible
with
previous
versions
of
graphql
and
if
that's
the
case
refer
to
this
appendix
and
that
appendix
has
and-
and
it's
like
explicitly
says
in
that
case
is
variable,
usage
allowed
is
replaced
by
is
variable
usage
allowed
Legacy,
and
it's
just
a
duplicate
of
that
particular
step.
F
E
They
don't
want
to
break
backwards,
compatibility
with
existing
queries
or
existing
yeah
existing
requests,
yeah,
okay,
I
think
that's
directionally
right
the
good
the
nice
thing
about
that
is
on
to
your
point.
This
section
ends
up
actually
getting
simpler
because,
in
addition
to
the
algorithms
here
being
overly
complicated
because
of
this
Edge
case,
there's
also
this,
like
exception,
element
to
the
explanatory
text,
which
is
less
than
ideal.
So
we've
got
to
have
some
element
there,
because
we
need
something
that
points
to
the
appendix
that
kind
of
frames
up.
E
The
fact
that
this
is
an
exception
that
you
should
be
aware
of
and
go
here
to
read
the
details,
and
then
we
need
that
that
thing,
I
I,
don't
have
a
strong
opinion
about
whether
it
is
an
appendix
versus
whether
it
is
just
like
at
the
bottom
of
this
particular
thing
is
like
an
addendum.
That's
like
within
section
I,
think
there's
something
nice
about
it,
just
like
being
kind
of
immediately
there
and
we
don't.
Actually
we
only
have
two
appendices
and
adding
a
third
one.
E
B
Plus
we're
on
this
topic,
partly
this
issue
comes
down
to
that
line
in
the
execute
algorithm.
Sorry
in
the
coerce,
no,
not
variable
values,
the
other
one
coerce
argument,
values,
yeah
yeah
course,
argument
values
that
says
if
value
cannot
be
coerced
according
to
the
input
coercion,
rules
of
argument
type
raise
a
field
error
now
for
variables.
Variables
have
already
been
coerced
once
so
we're
now
doing
a
secondary
coercion
of
them,
possibly
I'm,
not
sure
exactly,
whereas
the
other
values
that
might
be
fed
into
an
argument
would
be
like.
B
You
know
the
static
values
that
are
in
the
document
right.
The
variable
has
been
coerced
already.
So
it's
not
like
you
know
a
string
or
abstract
representation.
It
is
what
that
input
type
should
already
be,
and
we
are
then
coercing
it
again.
Is
there
any
reason
why
a
variable
would
need
to
have
this
additional
re-coversion
other
than
this
null
ability?
Yes,.
F
Specifically,
you
have
an
old
client,
you
shipped
a
breaking
change
on
your
schema
and
having
that
extra
coercion
means
that
we
don't
just
like.
If
I
pass
a
number
an
INT
into
something
that
now
expects
a
string,
we
can
still
do
the
coercion,
even
even
though
the
like
be
yeah.
Basically,
even
though
that
the
query
level,
we
have
it
as
like,
if
we,
if
we
have
old
queries
that
have
passed
previous
versions
of
our
validation
and
we're
not
running
validation
against
them,
we
can
still
do
something.
Semi-Intelligent.
B
Okay,
that
makes
sense.
Let
me
let
me
rephrase
the
question
if
the
query
is
valid
against
the
current
version
of
the
implemented
spec.
Is
there
any
other
situation
other
than
this
nullability,
because
your
your
example
was
of
not
validating
it,
because
you've
previously
done
that
on
an
older
version
right.
F
B
E
E
So
there's
like
okay
I'm
looking
at
five
f,
which
is
5,
is
looping
through
all
your
arguments
and
then
looking
at
each
one
f
is
the
particular
case
where
you've
provided
a
value
or
sorry
a
variable,
and
in
that
case
we
we
set
value
to
be
the
thing
that
was
actually
for
provided
as
that
that
variable
and
then
the
rest
of
the
algorithm
kind
of
continues,
which
means
you
get
then
to
5
J.
It's.
E
Yeah
and
then
5j
I,
it's
like
okay
value,
which
could
have
come
from
a
bunch
of
cases
like
it
could
have
come
from
the
default.
It
could
have
come
from
the
value
being
provided
at
runtime.
It
could
have
come
from
what
variable,
but
like
either
way,
if
it's
null
or
actually
a
5i
is
the
case.
That's
like
in
particular
for
the
k
for
like
if
you
have
a
value
and
the
value
is
null
and
it's
a
non-nullable
type
like
here's
the
moment
to
raise
a
field
error.
E
Otherwise
you
continue,
and
you
add
stuff
in
and
then
that
like
five
J
dot
triple
I
is,
is
the
case
where
it
is
neither
null
nor
a
variable.
Like
that's
the
scenario
where
you've
got
just
a
typical
value,
that's
been
provided
and
you
need
to
do
the
coercion,
so
I,
don't
I
I,
don't
think
we're
doing
double
coercion
of
variables
as
a
result,
damn
it
did
that
follow-up.
That
makes
sense
if.
B
B
E
Like
a
little
bit,
happenstance
that
we've
lifted
null
out
I
think
like
a
way
that
we
could
simplify
this
a
little
bit
is
is
to
say
that,
like
there's
one
scenario
that
it's
a
variable,
in
which
case
you
don't
have
to
worry
about
it
at
all,
because
it's
already
been
checked.
Otherwise,
it's
a
value,
in
which
case
you
have
to
like
apply
the
origin
rules,
including
you
have
to
do
the
null
check
first
and
then
you
need
to
apply
the
coercion
rules,
so
we
could.
E
We
could
potentially
rewrite
this
algorithm
to
be
simpler,
and
so
this
is
sort
of
like
a
we
need
to
handle
the
null
case
for
variables,
because
the
edge
case
we
need
to
handle
the
null
case
for
values
just
because
you
have
to
do
that
and
it's
the
same
step.
So
instead
of
repeating
ourselves,
we've
just
added
the
very
first
step
is
look
to
see
if
it's
null
and
then
continue
so
I
think
you're,
there's
a
flavor
of
what
you're
saying
that's
on
the
nose,
which
is
like
hey.
E
If
we
didn't
have
to
worry
about
this
Edge
case
with
this
algorithm,
it
gets
simpler.
I
think
the
answer
is
yes,
but
I
don't
know
that
it
would
get
so
much
simpler.
That
it'd
be
worth
having
the
same
sort
of
discussion
that
we
had
before
about
here's,
the
primary
algorithm
and
here's
the
Legacy
algorithm
that
handles
the
edge
case
like
I,
think
that
ended
up
being
actually
more
complicated.
B
B
Maybe
we
add
another
note
below
the
note
here
in
section
four,
six,
four
one
that
Harkens
back
to
the
the
note
that
already
exists
in
the
validation
section,
because,
for
example,
when
I've
been
writing
my
execution
engine
I've
been
using
graphql.js's
validation
system
because
all
I
care
about
is
xq,
so
I
haven't
been
reading
validation
closely.
E
Think
that's
right,
yeah
I
think
that's
probably
right
cool
there
is
that
there's
at
least
the
one
note
there
that
points
to
the
coercion
of
variable
values.
Maybe
it's
worth
mentioning
also
that
there's,
like
a
validation
rule
there
and
then
that's
the
right
pointer
but
I
think
you're
right.
It
needs
to
be
a
note.
E
A
E
E
Okay,
my
blood
pressure
is
lower
now
after
talking
that
through
I
was
like,
oh,
not
not
a
security
hole.
Okay,
thank
God,
okay,
style
guide:
this
is
a
fun
question.
Benji
go
nuts.
B
Yay
me
again
guys
so
Roman
pointed
out
that
we
had
some
inconsistencies
in
capitalization
of
I.
Don't
know
what
to
call
them,
but
the
the
headers
that
are
just
bold,
where
they
aren't
numbered
the
unnumbered
headers.
If
you
will-
and
he
raised
a
pull
request,
which
we
discussed
last
week
to
fix
the
case
there,
which
I
had
approved
previously
back
in
August
because
I
was
like
yeah
make
them
consistent,
seems
reasonable.
B
Anyway,
following
yesterday's
discussion,
I
actually
did
a
last
week's
discussion.
Sorry
I
actually
did
a
bit
more
of
a
dig
and
we
have
an
interesting
mix
of
capitalization
in
the
spec
and
it
seems
like
something
that
it
would
be
nice
to
just
guide
people
that
are
so
that
there
is
one
correct
answer
so
I
went
through
and
there
is
a
comment
that
I
left
on
that
linked
issue.
B
That
lists
it's
ridiculous,
but
I
went
through
I'd
used,
grep
and
then
I
organized
things
manually,
but
it
lists
through
all
the
places
where
we
use
title
case
where
we
use
what
could
be
title
case.
But
it
uses
keywords
and
maybe
we've
just
capitalized
keywords,
and
it
looks
like
title
case
sentence
case
and
Center's
case,
but
where
we
have
capitalized
keywords
and
also
just
where
there's
one
word
titles
and
there's
a
big
mixture
of
all
of
them.
B
B
So
I
have
written
us
a
very
basic
style
guide,
just
as
a
starting
point
effectively
and
then
I've
gone
through
and
I've
fixed
every
heading
in
the
spec,
not
just
the
unnumbered
headings,
but
the
numbered
headings
as
well.
To
then
follow
the
star
guide
and
then
hopefully
that
can
put
this
issue
to
bed
and
from
now
on,
we'll
just
have
somewhere
to
point
that
says:
here's
what
you
do.
E
Seems
legit
the
the
style
guide
that
I
most
often
refer
to
as
the
Chicago
Style
guy
I,
don't
know
the
AP
style
guide
but
they're
all
they
all
copy
each
other.
So
the
reason
that.
B
I
didn't
go
with
the
Chicago
style
guide
which
I
do
like
is
because
it
talks
about
I,
think
it
always
uses
the
I
forget
the
keywords
like
prepositions
and
conjunctions,
no
matter
how
long
they
are
and
I
think
that
that
might
be
problematic
for
non-native
speakers
to
know
specifically,
is
this
word
a
preposition
or
a
conjunction?
B
E
E
All
the
time
as
you
were
describing
this
was
like
Benji
get
out
of
my
head
you're,
like
my
my
English
teacher
from
grade
school
but
yeah,
but
yeah
I
think
this
is
right,
though
I
noticed
I,
don't
know,
maybe
I'm
overlooking
at
your
before
and
after
I'm,
seeing
r
a
r
e,
not
getting
lowercased
within
the
title,
casings
and
some
other
ones
is,
it
seems
like
the
before
and
after
still
not.
E
Yeah
I,
don't
know
that
just
seems
weird
to
me,
like
RN
I
would
expect,
but,
like
directives
are
in
valid
locations,
I
would
expect
RN
to
be
lowercase
since
they're.
Both
four
letter.
A
E
Right,
maybe
I
just
don't
know
how
to
apply
the
style
guide.
Cool
I'm
happy
to
delegate
to
someone
who
is
better
at
English
than
myself.
B
It's
one
of
the
reasons
that
I
chose
the
AP
is
because
there
is
just
this
list
it's
for
and
nor
but
or
yet
so
as
if
in
at
two
on
off
of
four
versus
and
per
those
words,
get
lower
case,
everything
else
is
uppercase,
that's
basically
the
rule
yeah.
There
are
some
other
exceptions
where
one
of
those
words
gets
used,
not
as
a
conjunctional
preposition.
But
let's
not
if
you
go
into,
let's.
E
Is
is
this
something
like
what's
the
what's
the
Pres
preservation
of
this
going
forward
like?
Can
we
do
we
add
Veil?
Do
we
add
a
tool.
B
I
think
it
would
be
very
cool
to
add
a
a
lint
tool
that
can
lint
spec
MD
to
apply
these
Styles.
But
as
far
as
I
know,
there
isn't
one
currently.
C
B
Sounds
good
well,
I
can
take
that
as
an
action
item
to
look
into.
If
you
want.
E
Yeah
because
it'd
be
nice
to
not
just
because
I
think
we
did
the
same
thing
for
spelling
right
where
we
applied
a
spell
checker
as
a
link.
Oh
it's
step
with
some
like
graphical
specific
words
in
our
white
list.
All.
A
One
suggestion
Benji
is
in
your
styled
guide.
Markdown
file
maybe
mentioned
that
this
is
based
on
the
AP
style
guide,
so
that
we
can
defer
a
lot
of
questions
around.
Why
did
you
pick
this
way
or
not
pick
this
way?
We
can
just
say:
hey
we're
following
the
AP
style
guide
as
much
as
possible.
B
Yeah
I
deliberately
didn't
do
that,
but
yeah
I
am
happy
to
do
that.
If
everyone
is
in
consensus
that
we
should
oh
sort
of
like
it's
based
on
that,
but
like
yeah
I,
don't
know
what
the
what
the
rules
are
of
actually
like
explicit.
I,
honestly,
don't
know
what
the
rules
are
around.
It
got.
E
It
okay,
I
had
the
same
thought:
it's
like
the
more
we
can
make
our
style
guide
short
by
saying
we
defer
to
these
other
style
guides.
It's
like
Auto,
formatting,
We're,
not
gonna,
write
anything.
We
run
the
prettier
tool
like
run
the
prettier
tool.
Whatever
it
says,
is
what
goes
and
it's
like
grammar
and
spelling.
It's
like.
E
We
run
this
spell
checker
and
this
grammar
checker,
which
this
one
is
based
on
AP,
and
this
is
like
done
and
then
the
other
thing
I
think
to
be
just
some
of
this
stuff
is
maybe
repetitive
of
what
spec
MD
does
for
us,
so
whether
it's
worth
kind
of
capturing
the
style
guide
or
otherwise,
it's
kind
of
up
to
you
like
the
numbered
headings
bit.
E
Is
you
quickly
learn
if
you
do
it
the
wrong
way,
because
the
spect
text
comes
out
wonky,
but
otherwise
it
looks
great
yeah.
It's
awesome.
D
B
So
Rob,
if
you
wanna
yeah,
give
us
a
summary
of
the
last
meeting.
We
had.
D
Yeah
we
met
earlier
this
week,
A
bunch
of
us
talking
specifically
about
the
issue.
That's
linked
here.
Clients
can
reliably
distinguish
if
defer
was
or
stream
was
in
line
or
not.
D
D
Kind
of
feel
that
we
need
some
kind
of
additional
data.
That's
returned
on
the
response,
because
that
that
is
fulfilled
field
isn't
going
to
help
you
for
stream.
D
B
Awesome
hi
again
folks,
so
yeah.
This
is
very
much
based
on
you
know,
standing
on
the
shoulders
of
giants
as
it
were.
This
is
just
another
iteration
on
top
of
all
the
ideas
that
everyone
else
has
come
up
with,
I
think,
most
recently,
possibly
Advanced
proposal
of
having
a
way
of
tracking
I
forget
what
keywords
you
used
to
van.
B
Yeah
so
like
detailing
which
things
are
still
to
come
effectively
what
my
proposal
does
the
easiest
way
to
think
of
it
like
and
I'm
I'm
afraid
this
is
going
to
be
JavaScript
Centric,
but
if
you
think
of
it,
as
every
defer
is
effectively
a
promise
and
every
stream
is
effectively
an
async
iterable,
it
is
detailing
to
the
client
that
those
things
exist,
giving
them
an
ID
and
saying
there
is
a
defer.
There
is
a
promise
that
we've
created
for
this
deferred
thing.
B
It's
going
to
be
at
this
path,
and
it's
going
to
come
later
that
way,
if
you
don't
get
that
in
the
payload
and
you've
already
got
like
a
placeholder
for
it
like
a
null
or
whatever,
then
you
know
that
thing's
not
coming
that's
fine
same
for
streams,
so
a
stream,
you
might
say,
give
me
initially
two
items:
you've
got
a
list
there
with
two
items:
you
don't
know
whether
or
not
that's
finished
or
not.
If
there
is
no
new,
like
I've
just
created
a
stream
for
this.
B
In
that
self-same
payload
saying
at
this
path,
we
have
created
a
stream
that
it
will
be,
you
know,
satisfied
later.
Then
we
know
that's
not
streaming.
What
this
then
allows
us
to
do
is
it
means
that
we
can,
on
a
whim,
decide
to
defer
or
not
defer
to
stream
or
to
not
stream
at
any
position,
not
just
on
a
particular
individual
directive,
but
on
an
like
an
incantation
of
that
directive.
B
So
this
is
quite
valuable
for
that
which
allows
the
server
then
to
rather
than
having
to
validation,
time,
decide
whether
to
allow
or
not
allow
the
query
or
whether
to
just
ignore
all
streams
into
Furs.
We
can
sort
of
build
up
this
list
until
we
say
there's
enough,
there's
enough
pending
things
now
we're
just
gonna
inline
everything
else,
which
is
one
of
the
issues
that
we've
been
discussing
quite
a
lot,
actually,
the
the
risk
of
like
this
explosion
on
the
server
side
and
also
transport
level.
B
Also
as
part
of
this-
and
this
is
a
bit
of
a
change-
a
significant
change.
I
think
is
we
detail
that
these,
like
promises,
async
itribles,
exist
and
we
give
them
an
ID
which
I'm
proposing
is
just
like
one,
two,
three,
four,
five,
whatever
doesn't
really
matter,
and
then,
when
those
things
come
through,
we
just
give
you
the
ID.
We
just
say
here
is
the
thing
for
id7
rather
than
giving
you
the
path
to
it.
B
That
does
mean
that
you
need
to
keep
track
on
the
client
side
of
what
they
all
are,
but
by
doing
so,
especially
for
streams,
we
don't
need
to
give
you
every
the
path,
every
single
time
which
reduces
the
amount
of
trans
of
transfer
on
the
network.
It
also
reduces
the
amount
you
have
to
serialize
in
server
memory,
but
also
on
the
client.
It
means
we
don't
have
to
do
this
comparison
of
the
path.
We
don't
need
to
Traverse
each
time
and
say:
oh
we've
got
a
path.
B
B
The
other
thing
is
removing
label
from
streams,
because
we
don't
need
them,
I,
don't
think
we
need
them.
We
can
sort
of
merge
all
of
the
streams
on
the
same
field
together
and
then
we
can
identify
any
individual
defer
or
stream
incantation
like
promise
or
asynceterable
by
the
combination
of
its
path
and
its
list
of
defer
labels
that
it's
seen.
If
a
defer
doesn't
have
a
label,
then
we
just
give
it
the
null
label.
E
This
is
an
interesting
proposal.
The
okay,
the
element
of
this
I
think
is
really
interesting.
Is
the
mental
model
of
these
as
promises
or
tasks
or
async
iterable.
Basically,
there
is
a
we're
giving
you
the
information
that
there
exists
such
a
thing
at
a
particular
path,
with
a
particular
identifier
and
then
later,
as
we
tell
you
more
we're,
essentially
updating
you
on
that
state.
For
that
thing,
that's
that's
pretty
nice.
E
And
it
makes
sense
to
me
as
to
why,
like
moving
path
up
then
is
as
actually
kind
of
nice.
It's
like
you're,
saying
there
exists
a
promise
at
this
path.
It'll
get
resolved
later.
E
Are
labels
and
reasons
still
useful
here,
like
I'm
looking
at
labels
with
an
empty
list
and
labels
with
an
array
of
null
I'm
like
I,
don't
even
in
this
example,
I
like
I,
don't
understand
how
a
client
is
going
to
take
advantage
of
these
things
or,
like
the
reason,
is
this
how's,
the
client
Behavior
gonna.
Look
at
that
reason
and
do
something
meaningfully
different.
B
No
I'm
not
sure
offhand
I
just
put
it
in
there,
because
it
was
a
nice
bit
of
extra
information
and
gives
us
space
to
expand
this
in
future.
If
we
had
another
thing
that
wanted
to
make
use
of
incremental
delivery,
but
wasn't
a
defer
or
a
stream
because
it
may
have
its
own
semantics,
the
labels
and
the
path
are
necessary
in
order
to
uniquely
identify
which
thing
it
is
that
that
triggered
this
or.
B
B
So
the
stream
needs
a
label
entry
so
that
you
can
uniquely
identify
the
stream
if
the
stream
is
inside,
of
a
defer,
for
example,
or
inside
of
a
I
guess.
Another
string
with
a
defer
actually
yaakov
has
an
example
of
this.
That
makes
it
more
obvious
his
yeah.
His
comments
should
be
visible,
but
I'll
send
you
the.
B
You've
got
essentially
two
paths
right:
you've
got
the
path
in
the
response
body
which
is
like
you
know
me
and
then
friends
and
then
zero
right,
I'm,
the
first
friend,
but
then
you
have
also
the
path
through
the
defers,
because
the
difference
can
have
labels,
because
you
could
have
like
two
forked
versions
of
me
that
are
in
separate
defers
because
they
have
separate
labels.
B
I
mean
I.
I
would
prefer
that
nothing
has
labels,
but
we
still
want
labels
for
various
things
we.
Actually.
This
is
one
of
the
things
I
think
Rob
didn't
mention.
B
We
did
consider
getting
rid
of
label
entirely,
but
there
is
a
desire
to
keep
it
because
there
may
be
a
situation
where
you
have
one
thing:
you
you
want.
Your
initial
render
to
be
like
you
know:
25
milliseconds,
you've
got
another
thing
that
takes
two
seconds
and
another
thing
that
takes
10
seconds
and
you
might
want
to
defer
those
two
separately
and
not
have
them
effectively
merge
together.
B
As
such,
you
know
both
of
those
might
be
inside
of
the
friends
stream,
so
you
might
have
two
incantations
of
the
friend
stream,
which
are
at
the
exact
same
path
in
the
response
document.
You
know
the
the
final
document
that
we're
building
but
they've
come
through
two
different
defer
paths,
so
we
need
to
know
which
one
of
those
we're
talking
about.
E
So
my
original
understanding
of
this
in
terms
of
a
problem
to
be
solved,
was
that,
as
we
were
then
provide
basically
this
original
problem
that
you're
describing
of
like
modeling
these
as
promises
or
facing
iterables
conceptually.
You
need
to
then
know
which
of
those
things
are
in
what
state
and
label
would
give
us
a
tool
to
do
that.
E
But
you
need
ID
to
respect
the
fact
that
at
any
given
path,
there
might
be
multiple
of
these
things
that
are
active
and
that
you're
like
tracking
collectively,
but
if
I
was
gonna
like
spin
this
around.
From
the
point
of
view
of
a
client,
it's
less
clear
to
me
how
like,
if
I
and
Matt,
maybe
this
is
more
of
a
question
for
you.
It's
like
if
I'm
gonna
build
a
smart
client
like
relay
or
something
like
it
for
labels
and
reason
like
what
is
what
is
it
that
I'm
actually
doing?
F
E
E
E
The
identifier,
because
that's
just
like
the
particular
instance
of
that,
in
the
same
way
that
if
you
had
defer
with
no
label
at
all
like
you,
can
just
trace
it
through
as
you
execute
and
like
each
one
that
you
hit
is
id1
id2,
ID3,
id4,
yeah,.
F
F
Basically,
you
either
need
to
have
some
field
included.
That
says.
Yes,
this
thing
was
fulfilled,
which
is
kind
of
how
we
sort
of
sometimes
do
it
now,
but
not
always
or
you
need
I
I,
actually
don't
like
the
splitting
out
the
labels
from
the
field
path,
because
in
my
mind
the
label
actually
is
part
of
the
path,
because,
as
soon
as
you
hit
a
defer
a
one
of
these
promises,
you're
saying
that
it
is
actually
a
separated
out
sub
tree
and
anytime,
we
have
a
unique
subtree
that
sub
tree
should
have
a
unique
path.
E
B
B
E
The
I
mean-
maybe
this
is
I-
hope
this
isn't
like
too
much
of
an
insane
thing
to
ask
for,
but
like
an
imagined,
client
API
like
I'm
I'm,
wondering
like
what
is
the
next
generation
of
relay
user
C
like
what's
the
motivation
for
a
client
developer
to
include
or
not
include
a
label,
because,
right
now,
we've
said
labels
are
optional,
so
one
one
is
the
scenario
in
which
I
add
a
label,
and
what
does
it?
Allow
me
to
do
that?
F
F
A
E
Would
it
be
valid
to
say,
I
have
two
separate
defers
that
have
the
same
label
on
them
and
a
response
like
that's,
not
an
invalid
query,
and
what
that
means
is
that
there's
a
single
conceptual
promise
getting
created
with
like
two
branches
of
the
query
that
are
getting
added
into
that?
That's
the
right.
Okay,.
B
Yeah-
and
there
is
an
example
of
that
in
it's
the
second
code
block
I've
got
a
whole
bunch
of
defers
with
different
labels,
some
without
labels,
some
with
labels
and
then
a
detail
that
actually
that
boils
down
to
effectively
four
different
defers
and
what
they're
like
identifiers
are.
There's
then
a
more
full
one
in
the
pending
section.
That
shows
you
how
it
interacts
with
streams
which
may
help
answer
the
the
previous
question
you
had
as
well.
F
E
F
Go
ahead
yeah.
This
is
why,
in
the
cree,
the
identifier
like
the
path
for
the
identifier,
in
my
opinion
like
when
we
have
is,
should
be
field
path,
interleaved
with
labels,
and
maybe
we
have
like
a
special
like
hashtag
or
something
for
labels
in
there
to
indicate
that
they're
not
Fields.
But
that
gives
you
basically
the
unique
sub
tree,
a
path
to
the
unique
sub
tree.
E
E
That
makes
sense
to
me
I
think
the
Innovation
that
I
really
like
about
Benji's
proposal
here
is.
Does
this
give
us
the
ability
to
just
ignore
all
of
that
like
all,
rather
than
having
to
come
up
with
some
like
hash
of
multiple
pieces
of
data?
We're
just
like
this
is
the
first
one.
This
is
the
second
one
and
you
like
just
don't
need
to
think
that
hard
about
field
paths
interleaves
with
labels
and
like
where
these
things
live.
You're
just
like
there
exists
a
promise.
E
It's
called
id1
and
when
the
data
comes
back,
here's
where
it's
going
to
go
and
and
that's
why
I'm
asking
about
so
okay,
the
use
case
of
a
label
to
distinguish
separate
logical
defers,
makes
a
ton
of
sense
to
me,
like
here's,
two
chunks
and
I
actually
need
to
separately
defer
them.
It's
not
okay,
to
like
scoop
them
all
up
and
defer
them
in
one
batch.
E
F
E
That's
what
I'm
asking
yeah
like?
What's
the
like,
if
I'm
a
relay
end
user
developer,
what
kind
of
rough
API
am
I
working
with
like?
Is
there
an
API
that
gives
me
access
to
the
fact
that
there
are
labeled
deferred,
fragments
within
the
context
of
my
container,
and
that
like
I,
can
ask
questions
about
which
of
those
are
pending?
Which
of
those
are
fulfilled,
in
which
case
I
need
to
know
the
label
so
that
I
can
provide
that
relay
API
or
is
this?
Is.
F
Not
a
thing
that
exists
you
either
need
to
do
it
in
to
have
in
the
response
inline,
some
key
that
indicates
this
or
you
need
the
pending
indicators,
which
we
can
a
relay
client,
is
able
to
basically
Stitch
these
pending
indicators
into
the
local
context.
E
Yeah
part
of
the
reason
why,
because
I'm
asking
for
it
That
explicit
use
case,
is
I
think
that
it
will
inform
the
relevant
data
necessary
to
empower
it
and
I
worry
that
right
now,
it's
a
little
bit
of
we
don't
know
so
we're
going
to
throw
all
the
data,
and
that
might
mean
that
the
intended
use
case
is
actually
unnecessarily
Complicated
by
the
fact
of
having
to
dig
through
a
thing
to
find
the
right
piece
of
information,
and
it
may
be
benefit,
and
also
it's
like
extra
stuff
in
the
payload.
E
You
know
like
I
I,
also
worry
about
the
scenario
where
the
defer
ends
up
the
juice
isn't
worth
the
squeeze
right
like
you,
do
all
the
defers,
and
you
find
out
that
all
this
overhead
of,
like
tracking
promises,
actually
just
negated
the
performance
gain
that
you
got
from.
Having
done
the
defer
in
the
first
place,
and
certainly
like
tracking
a
bunch
of
metadata,
is
one
of
the
reasons
why
that
could
be
true.
C
E
Particular
I
I
know
I'm
over
rotating
on
this,
but
like
in
particular
I'm.
Looking
at
the
example
I'm,
seeing
like
labels
array
with
null
and
I'm,
just
like
I
just
I
can't
imagine
any
client.
That's
like
gonna.
Look
at
that
and
be
like
thank
God
I
got
that
information
like
now,
I
know
exactly
what
to
do.
It's
like
I,
just
it
seems
there's
something
that
feels
off
about
that
as
like
the
preferred
payload
shape.
E
D
Go
ahead,
Rob,
yeah
I
just
want
to
describe
what
relay
does
now.
According
to
my
understanding,
which
I
think
is
like,
let's
say
you
have
your
component
that
has
fragments
nothing's
deferred
so
far
in
line
to
that,
you
have
to
that
component
is
rendering
two
other
components
both
of
those
have
fragments.
They
both
have
they're
both
deferred
and
with
react.
D
You
wrap
each
one
in
a
suspense
boundary
relay
is
behind
the
scenes,
automatically
generates
the
labels
and
when
each
payload
comes
back,
it
knows
which
of
the
components
to
not
be
suspended
anymore,
and
what
what
are
most
not
sure
about
with
this
proposal
is
the
merging
of
the
labels,
because
before
it
was
kind
of
like
an
implementation
detail,
the
client
like
code
could
just
handle
all
of
it
for
you,
but
now,
there's
like
is
some
specific
meaning
of
do
you
want
them
to
merge
together
or
not
so
I
think
it
requires
a
developer
to
specify
them
and
I
think
the
problem
that
we're
solving
that,
which
must
be
an
issue
with
relay,
is
that
if
you
have
these,
two
fragments
that
are
deferred
and
one
of
them
is
in
line
relay,
doesn't
understand
that
it
was
in
line.
D
F
Like
our
our,
or
rather
our
server
solves
this
by
always
expanding
every
single
deferred,
fragment,
which
is
fine
internally
but
like
as
soon
as
you're
opening
it
up
to
broader
usages
like
it's,
not
a
good
I
agree
with
all
the
reasons
why
we're
like.
We
should
be
able
to
inline
part
of
the
response,
like
it's
not
a
good
state,
which
is
to
say
we
don't,
we
don't
actually
have
a
solution.
E
What
Rob's
saying
resonates
like
it
is
surprising
to
me
that
relay
if,
if
the
behavior
is
that
by
default,
all
differs
at
a
particular
level
or
a
particular
path
in
the
query,
get
merged
which
makes
sense
to
me
I
think
that's
the
right.
That
would
be
the
right
expected.
Behavior
is
like
these
are
the
set
of
things
that
I
would
like
to
defer
and
then
there's
like
a
later
single
defer.
That
includes
them
all,
unless
that
you
explicitly
State
otherwise
and
then
label
is
the
tool
for
doing
that,
like
that's,
that
provides
semantic
value.
E
But
if
that's
the
case,
then
it
would
be
surprising
to
me
that
relay
would
generate
them
because
by
generating
them
it
could
influence
that
intent.
So.
F
F
B
B
So,
for
me,
I
think
all
the
defers
should
be
able
to
merge
together
if
they've
all
got
the
same
label
I.E
No
Label,
all
the
streams
should
be
able
to
merge
together,
and
you
end
up
with
something
really
simple:
all
you
care
about
is
where,
in
the
response
body,
the
various
bits
of
data
go,
which
is
why
the
path
is
straightforwardly
here
is
where,
in
the
final
document,
this
data
goes,
which
is
why
the
path
is
not
built
out
of
the
two
parts.
Instead,
we've
pulled
the
labels
out.
B
So
if
your
client
does
care-
and
if
it
does
have
this
forking
Behavior,
where
it's
got
a
list
and
it's
deferred
two
things
and
it
wants
to
render
one
only
when
it's
got
all
of
the
data
for
that
one
and
the
other
one
only
when
it's
got
all
the
data
for
that
one,
then
the
labels
allow
you
to
determine
which
of
those
two
you're
talking
about
and
know
whether
there's
still
anything
else
pending
at
that
position.
B
If
there
isn't
fantastic,
we
can
render
it,
whereas
this
one's
still
pending-
and
you
don't
have
this
information
without,
if
you're,
merging,
all
the
defers
and
the
streams
together
if
they've
got
the
same
labels,
you
don't
have
this
information
unless
you
combine
both
the
path
and
something
else
so
labels
or
like
Matt,
said,
like
some
kind
of
inline
field,
that
we
say,
hey,
there's
a
promise
here.
You
know
promise
in
the
response
body
or
something
using
a
character
that
cannot
be
provided
any
other
way,
which
you
know
I'm
actually
totally
open
to.
A
Oh
no
I
was
just
gonna
say
we're
at
time.
Did
we
want
to
wrap
it
there
and
and
just
know
that
we
have
another
breakout
meeting?
That's
scheduled
for
this
upcoming
Monday
to
talk
further
about
this.
So.
E
Totally
I
think
so
yeah,
let's,
let's
wrap
since
we're
at
time.
My
closing
thought
on
this.
One
is
Benji
I
think
this
proposal
is
super
interesting,
but
we've
got
to
figure
out
the
label
semantics
of
this
stuff.
That's
the
squirreliest
bit
and
my
bid
would
be
any
information
included
here.
That's
like
a
nice
to
have.
We
should
slice
that
way.
We
can
like
firmly
describe
why
each
piece
of
information
is
here.
A
Lee
I
think
all
of
us
are
on
the
the
breakout
call
for
this
that's
coming
up
on
on
Monday.
Is
that
something
you
would
like
to
be
invited
to,
or
would
you
prefer
to
just
have
us
kind
of
report
back
to
you.
E
A
E
If
I
can
I
will
and
if
I
can't
then
I'll
hear
about
it,
awesome
all
right.
Folks,
thanks
for
the
sprightly
conversation
across
a
bunch
of
good
topics
and
good
to
see
everybody
if
I
see
y'all
next
week,
then
fantastic,
otherwise,
I
hope
everybody
has
a
great
holiday
season.