►
From YouTube: GraphQL Working Group - May 13, 2021
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
C
A
Because,
usually
it's
two
hours
earlier,
I
think
shifted
it
to
accommodate
for,
for.
A
Like
entire
situation
is
a
little
bit
strange
like
it
should
originally,
it
was
planned
one
week
ago
also
so
last
minute.
Maybe
something
happened
also
right
now,
three
of
us.
E
B
F
G
D
A
G
I
would
say
it's
the
new
stable
time,
but
it's
kind
of
tentative.
So
we
had
a
discussion
about
this.
A
couple
months
ago
decided
to
try
it
out,
and
then
we
would
have
a
discussion
about
whether
it's
better
worse.
If
we
want
to
go
back,
if
we
want
to
try
a
new
schedule.
G
G
I
don't
know
how
successful
it
is
of
doing
that.
It's
hard
to
get
a
worldwide
crew
all
showing
up
at
the
same.
G
I
Hello,
everyone
lee
the
the
live
notes,
doc
doesn't
seem
to
be
up
yet.
G
Thank
you,
benji,
give
me
one
minute,
and
hopefully,
by
the
time
I've
done
that
we'll
have
full
attendance.
We
can
get
started.
G
G
And
with
that,
we
are
five
minutes
in
so
let's
get
started
all
right.
Welcome
everybody
to
the
may
edition
of
the
working
group
meeting
by
joining.
We
all
agree
to
the
spec
membership
agreement,
participation,
guidelines
and
code
of
conduct.
There
are
links
to
all
three
of
those
in
the
agenda.
Should
you
want
a
refresher,
as
we
always
do?
Let's
do
a
quick
rundown
introducing
everybody.
G
We
will
use
the
order
as
it
appears
in
the
agenda
doc.
So
look
for
your
name
coming.
Just
a
quick
name
to
the
face
is
all
we
need,
and
maybe
a
mentioned
about
where
you
work,
what
you
work
on,
if
that's
more
relevant,
so
I'll
kick
things
off
hello,
everybody.
My
name
is
lee
and
I
help
lead
these
meetings.
I
Hello:
everyone,
I'm
benji
maintainer
of
the
graphile
suite
of
open
source
tools
and
involved
in
a
number
of
graphql
spec
pull
requests
at
the
moment.
E
H
Hi,
all
I'm
hugh,
I
work
on
one
of
the
open
source
teams
at
apollo,
mostly
focused
on
client
and
server
stuff,
and
brian,
unfortunately,
cannot
make
it
so
we'll
skip
over
his
name.
D
Cool
I'm
jordan,
eldridge
working
on
relay
at
facebook,
specifically
looking
at
the
required
directive,
worked
on
that
last
half.
So
I'm
here
for
the
non-null
stuff.
K
And
hey
I'm
joe
savona,
I
also
work
on
relay
at
facebook.
All
the
things
relay
related.
B
Okay,
yeah,
I
don't
know
brian's
working
out
with
the
lawyers
I'm
here
from
ibm.
We've
got
a
graphql
proxy.
We've
got
the
various
graphical
endpoints
and
we're
interested
in
the
graphical
http
and
many
other
parts.
O
Yes
hi,
my
name
is
young
and
I
work
in
netflix
on
graphical
stuff,
on
the
studio
side
and
also
here.
G
And
don't
know,
welcome,
did
we
miss
anyone
who's
not
in
the
agenda
file.
J
O
H
Sorry,
I
said
brian
couldn't
join
from
apollo
as
well,
but
he
can
he's
here
now
as
well.
Brian,
do
you
want
to
say,
hi
and
introduce
yourself.
B
Hi,
my
name
is
brian
glad
to
be
here
sorry
about
these
cla.
C
Hey
everybody,
I'm
andy
working
on
craftsman,
java
and
other
craft
good
things
for.
G
I
think
so
solid
crew
today
welcome
everybody,
especially
new
faces
and
old.
With
that,
let's
make
sure
we
have
good
note
takers.
I
see
our
our
consistent
note.
Taker
benji
is
already
hard
at
work.
G
G
If
anybody
else
feels
the
the
desire
to
help
take
notes
feel
free
to
pop
that
live
note,
stock,
open
and
help
out
all
right.
Let's
take
a
quick
read
down
of
the
agenda
and
make
sure
that
this
covers
everything
that
we
want
to
do
we're
going
to
go
over
action
items
and
close
things
out
from
the
last
meeting
I'll
give
a
quick
update
about
the
release
plan
for
the
next
spec
cut.
G
Rfc
I'll
give
an
update
on
full
unicorn
unicode
support
something
andy
originally
introduced,
but
I've
been
working
on
the
spec
pr4,
the
glossary
rfc
from
benji
query
level,
nullability
from
alex
and
steven
fragment
arguments
from
matt
and
the
relay
crew
and
dunder
type
name
not
valid
at
the
subscription
route.
That
is
a
lot
of
stuff.
G
Hopefully
that's
everything
we
want
to
talk
about
today,
we'll
do
our
best
to
stay
on
time
to
make
sure
that
we
get
through
it
all.
I
haven't
actually
added
up
all
of
the
minutes
to
see
that
it
adds
up
to
two
hours,
so
we'll
just
have
to
keep
a
reasonable
look
at
the
clock
to
make
sure
that
we're
not
going
wildly
over
with
that.
Let's
do
a
hopefully
quick
overview
of
action
items
and
see
if
there's
any,
we
can't
quickly
clear
out.
G
G
I
I
only
see
eight,
you
only
see
eight,
oh
man,
you
know
what
I'm
looking
at
ones.
That
are
also
closed.
I
don't.
G
There
we
go
whew,
okay
for
a
minute
there.
I
thought
we
were
going
to
take
our
entire
meeting
closing
out
issues
that
would
have
been
boring.
Okay,
eight
is
still
good
delete
laser
calendar
to
avoid
counter
confusion,
done
closed
review
and
giving
feedback
for
the
one
of
input.
Object.
G
G
J
Well,
I
I've
been
hoping
to
try
and
implement
it
as
a
draft
in
ruby
this
past
month,.
A
G
I
We
yeah
we're
going
to
talk
about
that
a
bit
more.
I
think
next
session,
the
the
one-off
stuff
great.
G
Exciting
replace
query
errors
with
request
errors
is
done,
closed,
deprecated
directives
on
input
field,
rfc,
advancements.
G
I
added
that,
as
done,
so
I
think
we
are
good,
although
it
is
advanced
to
draft
there's
still
some
work.
That
needs
to
be
done.
I
don't
think
we're.
Gonna
include
it
before
the
spec
cut
is
the
major
one
all
right,
let
me
reload
make
sure
you
didn't
lose
my
place.
Assert
subscription
field
is
not
introspection
and
I
believe
we're
going
to
talk
about
this
a
little
bit
later.
This
meeting
and
we've
got
some
additional
progress
there.
So
I'm
going
to
close
this
one
out
putting
a
glossary
into
the
spec.
G
G
I'm
gonna
leave
this
one
open
just
so
that
we
don't
lose
track
of
it
because
it
seems
like
the
next
step,
for
this
is
actually
to
write
an
actual
spec
rfc
change
which,
and
this
one's
been
just
kind
of
sitting
for
a
while.
Since.
I
Yeah,
so
I
was
just
reading
back
through
my
logic
on
this.
Basically,
I
think
that
this
might
be
something
that
we
want
to
put
into
this
spec
release.
That's
going
out,
so
I
thought
we
might
want
to
actually
discuss
whether
that
needs
spec
changes,
and,
if
so,
should
they
go
into
this.
This
cut
or
not,.
G
You
know,
I
think
we
should
take
the
same
sort
of
logic
for
the
spec
cut
that
it's
it's
sort
of
a
train
that
goes
out
and
we
don't
worry
too
much
about
holding
things
for
it,
even
though
this
seems
like
very
much
a
thing
that
should
be
solved,
so
I'm
gonna
leave
this
open
just
so
we
don't
lose
track
of
it.
We
can
leave
the
ready
for
review,
so
we
confuse
ourselves
again
next
meeting
all
right.
G
That
was
this
healthy
amount
of
action
items
that
looks
great
okay
release
plan
for
next
version
of
the
graphql
spec.
I
should
have
included
a
link
for
this,
but
let
me
dig
one
up
really
quick,
because
there's
a
lot
of
work,
that's
gone
into
this
over
the
last
month.
G
Issues,
maybe
I'm
looking
for
the.
What
is
it
even
called
the
the
projects
in
github?
There's?
No,
not
projects
milestones,
okay,
milestone
so
I'll.
Send
this
in
the
chat
I'll
make
sure
I
include
it
in
the
agenda,
so
we
don't
lose
track
of
it.
So
we
have
a
milestone.
G
There
are
one
of
these
I'm
going
to
take.
The
schema
coordinates
out
because,
although
it
is
very
close,
it's
still
sort
of
an
rfc
phase
and
I
believe
it
will
land,
I
put
it
there
kind
of
tentatively.
The
rest.
That's
here
is
purely
process
or
low
editorial,
which
means
we're
incredibly
close.
My
hope
was,
for
our
meeting
last
week
to
have
a
official
spec
release
candidate
cut
that
we
could
then
begin
to
review.
G
I'm
sorry
to
say
that
I
am
not
quite
there.
You
can
see
that
it
says
past
two
by
seven
days,
but
that's
because
of
the
the
delayed
meeting,
but
I
do
intend
on
getting
this
set
up
within
the
next
couple
of
days,
at
which
point
we'll
have
a
release
candidate,
that
we
can
review
and
then
hold
a
vote
on
and
then
release
so
the
last
major
pieces
here
that
are
actually
meaningful.
There
are
a
couple
minor
editorial
things
we
want
to
fix
and
there's
a
legal
block
at
the
top
of
the
spec.
G
That
is
still
a
little
bit
ambiguous
and
probably
not
exactly
correct,
based
on
all
the
things
that
have
changed
in
the
around
the
foundation
in
the
last
couple
of
years,
and
so
those
are
the
primary
things
I'm
focused
on.
If
you
flip
to
the
close
tab,
you'll
see
that
over
the
last
month
or
so
month
and
a
half,
maybe
there's
been
quite
a
lot
of
activity
in
here,
so
actually
yeah
I'll,
say
I'll,
say
a
month
and
a
half.
G
There
was
not
a
lot
of
energy
in
here
up
until
march
early
april
and
then
starting
in
april
I
started
going
ham.
Then
she
saw
the
energy
and
jumped
in
with
me,
and
we
got
a
ton
of
editorial
changes
in,
so
that
was
this
like
long
coming.
Editorial
fix
that
we
needed
to
do,
including
making
sure
that
a
handful
of
rfcs
that
had
been
mark
accepted
had
their
final
editorial
review
and
were
merged.
G
So
a
lot
of
stuff
went
in
the
last
thing
that
I
need
to
do
that's
process
based
here
is
to
write
a
change
log.
That's
something
that
I'm
definitely
going
to
do.
It
will
make
reviewing
this
work
much
easier
mark
to
clarify.
Yes,
it
is
likely
that
they
won't
make
the
cut,
which
shouldn't
be
that
big
of
a
deal
like
I
was
saying
before
you
know.
G
We
usually
look
at
the
draft
as
the
source
of
truth,
and
these
cuts
are
ways
to
reference
fixed
points
in
time
at
which
you
know
we
can
refer
back
to
so
they'll
make
the
next
one,
but
shouldn't
have
any
meaningful
effect
on
implementations.
G
A
Questions
so
to
clarify,
like
I
added
this
agenda
item
for
you
mainly
to
clarify
what
the
blockers
from
like
from
other
projects
of
from
other
people,
because
I
like
based
on
new
activity,
I
assumed
he
also
wanted
to
merge
default
values
stuff,
and
I
thought
it
was
a
broker.
A
A
A
G
Think
so,
although
the
full
unicode
support
is
some
stuff
has
been
merged
into
the
the
reference
implementation
in
the
past,
but
not
a
complete
implementation
of
that
rfc.
We'll
talk
to
that
when
we
get
to
that
agenda
item,
I'm
pretty
confident
that
everything
in
this
this
milestone
is
a
superset
of
the
things
that
are
are
dependencies.
So
I
would
say
really
the
only
real
blocker
here
is
updating
the
legal
text
in
the
spec.
G
G
Everything
else
in
here
is
opportunistic,
so,
like
I
put
schema,
coordinates
on
this
list
a
month
and
a
half
ago,
thinking
that
maybe
we'd
get
the
work
done
in
time,
I'm
totally
comfortable,
not
including
it
I'm
totally
uncomfortable,
including
the
rest
of
these
editorial
changes
as
well,
though,
I
think
that
we
can
probably
get
some
of
the.
I
think
there's
these
two
editorial
pr's
at
the
top
that
we're
likely
can
fix
before
we
land
the
spec
cut,
but
the
legal
contribution
one
is
the
primary
one
that
I
want
to
make
sure
we
resolve.
G
G
All
right
we'll
keep
an
eye
out
for
that
again.
My
goal
is
to
have
that
legal
text
resolved
within
a
few
days
so
that
we
can
start
the
review
process
relatively
soon
and
then
get
a
cut
of
the
spec
out
pretty
shortly
after
should
we
have
a
smooth
vote,
all
right,
moving
on
a
step
before.
I
G
A
He
is
like
everything
ready
like
we
discussed
last
time.
I
just
have
like
personal
issues
with
my
parents
and
call
it
like.
A
So
I
was
a
fine
for
three
weeks
and
when
I
returned,
I
actually
saw
a
bunch
of
commits
and
prs
from
lee
so
yeah
and
I
a
couple
of
more
conversion
related
pairs
and
right
now
it's
even
even
better
shape.
A
A
One
thing
I
would
actually
like
merge
with
stuff.
I
just
wanted
didn't
want
to
interrupt
like
full
of
prs
and
matches
before
this
working
group
call
because
I
assumed
like
it,
was
a
goal
to
to
advanced
a
couple
of
proposals
and
merge
them
into
spec.
Now
I
see
it's
not
a
goal,
a
question
so
like
about
status.
It's
like
everything
is
ready.
It's
not
a
idea.
It
will
be
like
some
minor
things
like
during
conversion
and
like
we
cannot
do
it
in
one
big
merch
and
everything
will
work.
A
We
need
more
style,
breaks
are
fixed
stuff
and
but
we
pretty
proper
so
like
the
hit.
Pr
is
fully
passed
past
like
pre-tier.
Yes,
lee
and
typescript
check,
like
some
things,
disable
like
strict
knowability
check
disabled
and
we
need
to
enable
it.
We
have
a
couple
of
dozens
typescript
ignore
commands
not
on
files
and
lines.
A
So
I
cover
a
file
with
subscript
type
so
and
additional
thing
we
remove
bunch
of
flow
artifacts
in
the
process,
because
idea
was
not
just
migrate
to
typescript
and
add
typescript
artifacts,
but
remove
four
ones
in
the
process
not
to
have
like
artifacts
from
both
languages.
A
So
one
issue
I
see
is
that
if,
if,
if
I
review
and
much
like
prs,
it's
not
possible
to
do
that
because,
as
I
said,
it's
like
a
process
for
a
couple
of
days,
at
least
like
so
is
it
okay?
If
starting
from
like
will
freeze
with
freeze
main
branch
for
one
week
starting
from
today?
A
A
I
think,
like
we
target
weekends,
but
just
in
case
like
for
one
week
like
we're,
not
mentioning
anything
and
we
do
typescript
conversion,
and
when
I
like,
I
will
ping
everybody
npr's
and
as
a
person
update
pr
or
I
can
help,
update
and
update
it
myself,
like
sorry
for
like
inconvenience
but
like
with
with
rate
of
prs
and
changes
like
like
from
last
week
or
last
two
weeks,
it's
not
possible
to
do
like
why
immigration
is
that?
Okay,
so
like
question,
is
it
okay
to
freeze
for
one
week
or
non
conversion,
changes.
G
A
G
Sounds
good,
I
won't
merge
anything
in
that
time
and
I'll
keep
an
eye
out
so
I'll
keep
working
on
my
pr's
but
I'll
rebase.
The
stack
once
once.
Everything
is
in
a
good
state.
Keep
us
posted.
G
N
No,
I
I
really
like
this
pencil
just
to
clarify,
so
your
planning
one
is
that
next
thursday,
we'll
have
basically
typescript
on
main,
and
do
you
want
at
that
point,
to
release
16.0.0
alpha
one
or
or
not,
or
just
to.
A
It
will
be
like
small,
like
comments
disabling
like
so
I
I
think
like
we
will
have
some
cleanup
work
but
like
99.9
ideas
to
switch
it
in
one
week
about
release.
I
actually
think
it's
good
timing,
because
I
expect
we
need
some
additional
breaking
changes
due
to
default
values
and
other
proposals.
A
I
think,
like
we
definitely
minimize
like
breaking
changes,
but
graphql
dresses
reference
implementation.
So
I
think,
like
one
of
the
top
priority
is
to
be
like,
readable
and
stuff.
A
So,
if,
if
like
so
ideas
after
typescript
migration,
let's
let's
merge
default
value
like
stuff
that
liveworks
worked
on
andy
for
unicode,
be
sure
that
there
is
no
like
anything
planned
that
can
potentially
break
and
when
it
would
be
safe
to
release,
because
otherwise
we
will
release
and
it
will
affect
like
changes
that
we
can
do
so
like
yeah,
yeah
and
another
small
thing.
It's
like
yeah,
some
support.
It's
it's
like
big
headache:
how
to
support
native
models
yeah.
So
like
these
two
issues,
stuff
in
pipeline
and
native.
A
G
Okay
yeah,
I
think
that
makes
sense,
and
you
know
major
versions
are
free
to
create.
So
if
we
have
to
add
additional
breaking
changes
in
the
future
because
of
spec
changes
so
be
it
we'll
do
our
best
to
keep
them
minimal
but
plan
those
afterwards,
let's
focus
on
getting
the
typescript
migration
done.
First,
okay,
evan
default
value.
J
It's
I
haven't
given
up
yet.
Actually
at
this
point,
I've
gone.
I've
tried
a
couple
of
different
things.
I
need
to
go
back
and
reread
the
spec
edits
a
little
more
carefully
to
make
sure
that
you
know
in
iterating
on
the
solution
of
the
code.
I
haven't
drifted
too
far
from
the
wording
in
the
spec
again,
but
I
do
have
something
that
I
think
will
probably
mostly
work.
J
It's
definitely
it's.
It's
spawned
a
bunch
of
interesting
architecture,
discussions
and
separate
bug
reports
into
the
graphical
review,
so
not
a
not
a
small
change
for
the
the
implementation.
But
probably
at
this
point
I
don't
want
to
necessarily
like
just
give
a
thumbs
up
and
say:
yeah,
it's
implementable,
so
the
spec
change
is
fine,
but
it's
it's
looking
like
it's
probably
okay,.
G
Andy-
and
I
have
been
working
on
this
for
in
parallel
for
a
long
time,
we'll
include
you
in
your
mary
gang
he's
been
doing
it
in
graphical
java,
while
I've
been
doing
it
graphical
js
and
I
shared
a
link
in
the
chat
at
some
point.
It
was
necessary
to
write
everything
as
a
flowchart
to
understand
what
the
hell
is
going
on,
and
this
is
actually,
I
feel
like.
G
I
learned
something
about
how
graphql
works,
which
should
tell
you
something
about
how
complicated
this
issue
is
and
tried
to
represent
every
kind
of
value
and
every
procedure
for
converting
one
kind
of
value
into
another
kind
of
value
into
a
flow
chart,
and
the
root
of
the
reason
why
this
ended
up
being
much
much
harder
than
the
spec
edit
would
make.
You
think,
is
if
you're
programmatically
describing
a
schema
and
you're
providing
the
default
values.
G
What
kind
of
value
is
that
default
value?
I
don't
think
we
thought
very
hard
about
this
in
the
past
and
what
I
found
graphql
js
did-
and
I
suspect,
probably
most
of
the
others
that
have
used
that,
as
a
reference
have
also
done,
is
they
represented
as
what
I've
been
calling
a
internal
input
value
or
otherwise
they
already
assumed
already
coerced
value
and
there's
already
been
some
sort
of
slightly
sketchy
hijinks
that
go
on
in
order
to
take
that
already
coarse
value
and
translate
it
into
a
literal
string
through
introspection
or
schema
printing.
G
This
gets
way
more
difficult
when
you
add
in
like
recursive
default
values
that
need
to
be
filled
in
and,
like
you
end
up
in
this
in
this,
you
know
weird
world
where
it
doesn't
work
yeah.
So
I
you
can.
This
is
just
a
in
a
comment
on
a
larger
pr
and
that
pr
is
stacked.
On
top
of,
I
think,
like
five
other
prs,
and
this
isn't
done
so-
I'm
evan,
I'm
happy
to
ping.
You
once
I've.
G
Finally,
gotten
this
entire
state
stack
of
prs
into
a
state
that
I
think
it's
mergiable,
but
it's
required
actually
like
filling
in
two
or
three
of
these
boxes.
That
hadn't
existed
before
in
order
to
get
to
a
state
where
we
could
do
this
yeah,
that's
interesting.
It's
actually
like
I.
J
Did
run
into
that,
but
graphical
ruby
provided
a
pretty
straightforward
way
of
solving
that
particular
issue.
I
ran
into
something
totally
different
as
being
over,
so
the
ruby
implementation
provides
coercion
in
and
coercion
out
and
they're
supposed
to
be
symmetric
so
to
validate
it.
We
can
just
like
take
the
internal
representation
coerce
it
for
output
and
then
validate
that
as
input
and
that
validation
flow
works.
J
The
thing
that
I've
been
running
into
is
when
building
a
schema,
the
type
references
don't
all
get
resolved
until
the
schema
has
been
fully
loaded,
at
which
point
it
is
too
late
to
do
the
validation
pass,
but
you
can't
actually
validate
it
until
the
type
references
are
resolved
because
otherwise
you're
going
to
like
this
type,
isn't
really
a
type
yet,
and
it
doesn't
know
how
to
validate
it's.
This
big
circular
mess
of.
G
That
that
is
a
different
problem.
This
problem
was
solved
in
graphical
js
a
while
ago.
It
does
it
in
two
phases,
so
you
construct
a
schema
that
can
schema
is
not
assumed
to
be
valid
and
then
there's
a
separate,
validate
schema
function
that
takes
in
a
schema
and
returns
back
a
set
of
errors,
yeah,
and
I
think
it
just
sets
a
flag
that
that
schema
is
validated
and
then
execution
checks
to
see
that
that
flag
is
set.
J
That
definitely
makes
sense.
It
has
a
way
bigger
refactor
than
I
want
to
do
for
this
particular
rfc.
G
J
It
was,
but
there
are,
I
have
been
able
to
generate
at
least
one
infinite
loop
in
schema
building.
If
you
build
exactly
the
right
schema
with
lately
bound
types,
so
it's
yeah
it's
not
great,
but
it
seems
to
work
for
actual
practical
purposes.
So
far,.
G
Well,
yikes,
good
luck,
but
I
will
I'll
actually
I'll
update
the
agenda
with
the
link
to
this
pr
for
folks
that
come
across
this
later,
because
at
the
very
least,
I
think
this
flowchart
was
actually
super
helpful.
For
me.
C
Yeah,
I
want
to
add,
I
actually
finished,
not
really
finished,
but
I
finished
my
graphical
java
pr
and
without
the
coercion
when
you
put
like
without
the
validation
rule,
benji
talked
about
around
the
default
values.
If
it's
not
a
recursive
thing,
I'm
trying
to
tackle
this
next,
but
I
yeah
well.
C
I
basically
ended
up
implementing
the
what
we
talked
about
and
it
works
well
overall,
it's
it's
a
massive
change
for
graphical
java,
also,
I'm
touching
72
files
just
to
give
you
an
indication
of
what
you're
talking
about-
and
I
worked
on
this
now
also
for
two
to
three
weeks
like
in
parallel
with
lee,
basically
and
and
the
core
issue,
and
to
give
a
little
bit
inside
is
like
really
also
about
these.
C
Can
I
share
a
picture
here
in
the
chat,
or
is
this
not
possible?
You
can
share
a
link.
G
C
Picture,
it's
not
uploaded
anyway,
okay,
so
the
core
issue
was
basically
that
we
had
two
different
methods
which
coerced
into
an
internal
input
value,
but
we
needed
to
have
another
one
which
is
translated
between
external
input,
value
and
literal
and
and
just
to
get
to
the
state
to
understand
which
was
missing
and
what
we
want
to
attack
took
quite
a
while
and
yeah
like.
I
would.
I
would
be
interested
in
one
point:
if
you
we
had
really
the
same
challenge
or
if
this
was
completely.
J
Yeah,
the
the
second
pr
that
I
I
linked
in
the
chat
for
the
movie
site
is
actually
only
like
20
lines
and
does
technically
mostly
work
it.
It
only
does
it
at
execution
time
when
you
use
that
argument
in
a
query
which
is
pretty
gross,
but
it
does
do
the
actual
validation,
more
or
less
correctly.
G
Sounds
like
proper
schema,
validation,
implementation
and
graphical
ruby
is
coming.
G
Okay,
that's
what's
going
on
there!
I'm
glad
you
added
this
because
there's
an
excuse
to
talk
about
the
work,
andy
and
I
have
been
up
to
over
the
last
couple
weeks.
Okay,
next
up
is
unicode
support.
G
Another
one
andy
and
I
have
been
working
on
this-
is
actually
an
rfc
andy
introduced
quite
a
while
ago
over
a
year
ago
that
I
think
we've
been
struggling
with
like
proper
understanding
of
how
to
manage
unicode
full
unicode
for
a
while
now,
and
I
think,
we've,
cracked
it
and
andy's
proposal
is
the
simplest
I
actually,
what
I've
implemented
is
slightly
more
complex
than
his
original
proposal
and
and
I
have
a
spec
pr
that
has
the
slightly
more
complex
version,
the
one
piece
of
complexity
that
I've
added
is
allowing
a
new
kind
of
complex
unicode
escape
sequence.
G
G
U
and
then
in
curly
braces,
you
can
put
an
arbitrarily
long,
hex
code
that
will
then
resolve
to
a
unicode
point,
so
that
was
not
included
in
in
andy's
original
pr,
but
I've
included
that
one
as
well
and
I
have
a
implementation
pr,
I'm
happy
to
rebase
on
top
of
the
typescript
conversion
and
I
think
it's
just
down
to
making
sure
that
the
test
cases
are
correct.
But
otherwise,
if
anybody
has
any
thoughts
on
full
unicode
support,
I
I
would
love
a
review
on
some
of
these.
A
Yeah,
I
will
add
that
it
would
be
really
great
if
somebody
reviewed,
because
I
actually
tried
it,
and
I
can
review
like
test
cases
and
like
other
stuff,
but
to
really
understand
what
happens
there
like
it's
require
unicode
knowledge,
it's
good
opportunity
for
me
to
learn
something
about
unicode,
but
it
would
be
great
if
somebody
who
like
understand
or
have
a
time
to
carefully
review
it,
because,
like
my
review
up
until
now,
was
like
yes
look,
I
don't
understand
what
it's
doing,
but
code
looks
fine.
A
G
I'll
say
that
I
basically
had
to
deep
dive
and
teach
myself
a
much
better
understanding
of
unicode
in
order
to
get
through
this,
and
for
anyone
who
wants
to
do
a
review.
There's
two
subtle
things
going
on
that
interoperate
with
one
another
that
deal
with
utf-16,
so
javascript
encodes
all
strings
as
utf-16.
G
That's
just
part
of
the
spec
of
how
javascript
works
kind
of
regardless
of
what
the
source
of
your
files
actually
are.
Most
source
files.
These
days
are
utf-8,
but
javascript
will
convert
them
to
utf-16,
which
means
to
encode
complex
values
that
uses
these
surrogate
pairs.
G
So
graphql
js
has
some
additional
logic
that
will
like
convert
things
back
into
surrogate
pairs
and
that's
because
graphical
js
or
javascript
in
general
just
expects
that.
But
if
you
take
a
look
at
the
actual
spec
rfc,
it
actually
is
cautious
to
disallow
false
pairs
of
of
surrogates.
So
if
you
have
a
some
a
surrogate,
that's
not
found
in
a
pair,
it
will
throw
javascript
does
not
throw
it
just
lets.
You
provide
any
string,
but
I
think
it
moves
us
to
make
this
more
strict
because
those
are
never
safe
to
decode.
G
So
that's
the
one
thing
to
just
sort
of
be
cautious
of,
and
probably
most
thoroughly
review.
Everything
else
here
is,
I
would
say,
very
straightforward.
There's
three
changes
in
the
rc.
One
says
that
you
can
use
unicode
characters
above
the
basic
plane
in
the
spec.
That's
like
literally
a
single
line
change.
It
just
changes
the
fff
to
10
fff,
that's
it!
G
The
second
change
is
this
new
form
of
escaped
unicode
that
lets
you
escape
characters
beyond
just
four
digit
hexes
and
then
the
third
is
this
surrogate
pair,
and
so
obviously
the
implementation
of
actually
being
able
to
interpret
those
is
a
little
bit
complicated
in
a
language
like
javascript
that
is
not
based
on
utf-8,
and
I
know
a
handful
of
other
languages
have
similar
quirks
so
something
to
look
out
for,
but
again
I
would
love
a
review
on
this.
If
anybody
wants
to
take
a
closer
look,
any
questions
or
thoughts.
C
I'm
happy
that
we
take
this.
I
think
it's
kind
of
straightforward.
It's
it's
nothing!
I
don't
think
we're
doing
anything
special
here.
I
think
that's
a
good
thing,
so
craftberry
doesn't
try
to
make
something
fancier.
So
it's
it's
aligned
with
a
lot
of
other
languages
and
and
encodings
from
what
I
understand.
So
that
looks
good.
G
I'll
say
that's
part
of
why
it's
taken
us.
This
long
is
this.
Is
you
know
you
can
judge
me
that
my
understanding
of
unicode
was
done
via
javascript,
which
is
probably
the
worst
possible
way
to
teach
yourself
how
unicode
works,
because
javascript
javascript's
got
a
really
terrible
way
of
dealing
with
unicode,
but
as
I've
messed
around
with
other
languages,
I've
gotten
a
much
better
understanding
of
how
it
works.
G
So
exactly
right,
andy
what
you
said,
I'm
trying
to
do
the
thing
that
has
basically
already
been
done
in
other
languages:
we're
not
we're
not
reinventing
the
wheel
and
how
this
works.
I
Hey
okay,
so
months
and
months
and
months
ago
we
talked
about
the
ambiguities
that
exist
in
the
graphql
spec,
particularly
around
the
word
query,
which
was
used
to
represent
like
five
different
things
that
might
count.
I
But
as
part
of
that
there,
there
is
a
few
things
in
the
spec
where
terms
are
used
without
necessarily
being
well
defined,
or
at
least
making
it
quite
challenging.
To
find
the
definition
of
those
things
and
in
general,
I
wanted
to
kind
of
add
clarity
and
also
specify
like
exactly
what
words
we'll
use
so
that
we
don't.
We
don't
use
like
one
term
here
and
a
different
term
there
to
relate
to
the
same
concepts,
and
so
when
we
use
different
terms,
it
is
relating
to
different
concepts.
I
So
out
of
the
work
that
I
did
on
the
query
ambiguity,
I
tried
to
extract
a
glossary
of
the
terms
that
I'd
sort
of
figured
out
for
that.
And
then
I
was
going
to
talk
to
lee
about
how
we
might
integrate
this
into
the
spec.
But
he's
gone
ahead
and
added
to
graphql,
sorry
to
spec
md
the
project
that
we
used
to
compile
the
spec.
I
I
So
we
have,
I
think,
possibly
before
that
was
done
before
that
was
done
in
spec
md
we've
merged
this
rfc
document,
which
is
basically
a
few
collected
terms.
I
You
are
welcome
to
submit
changes
that
you
think
those
need
like
if
I've
chosen
the
wrong
terms
or
if
they're
not
defined
well
enough
or
whatever,
then
pull
requests.
There
would
be
welcome
if
you
want
to
add
more
things
there,
you
can
do
so
via
the
rfc,
but
also,
I
think
you
could
just
do
it
directly
to
the
spec
itself
using
the
new
syntax.
I
If
it
makes
sense
to
do
so.
Sometimes
you
can
do
it
with
very
minimal
edits
to
the
graphql
spec.
Sometimes
it
might
need
a
bit
more
of
like
an
extra
section
added.
So
if
you're
not
up
for
adding
an
entire
new
section,
when
you
want
to
define
something
doing
a
spec
to
the
the
glossary
rfc,
I
think
would
make
sense
as
well
but
yeah.
I
Originally,
this
was
going
to
be
a
request
for
adding
a
glossary
to
the
graphql
spec,
but
we
kind
of
have
that
now
I
think
spec
md
might
leave,
might
add
more
functionality
around
this.
In
future,
like
like
the
index,
for
example,
that
you
already
have.
G
Yeah,
so
I'm
trying
to
find
an
example
of
a
pull
request
to
the
spec
that
included
these.
Oh,
I
found
here's
there's
one
that
defines
built-in
directives
I'll
link
that
in
the
chat.
So
this
is
this
is
not
all
my
original
design
here.
I
I'm
basically
just
copying
how
definition
lists
are
done
in
markdown
and
a
couple
other
slightly
esoteric,
markdown
renderers.
G
So
what
spec
md
will
do
is
it
will
automatically
include
that
in
the
index,
so
the
index
just
includes
anything
that
is
a
well-defined
term,
whether
that's
an
algorithm
or
a
grammar
production
or
now
a
term.
It
doesn't
separate
them
out.
So
it's
just
like
a
big
long,
alphabetized
list
of
everything
that's
defined
in
the
spec.
So
that's
not
quite
the
same
thing
as
a
glossary,
it's,
but
it
will
at
least
help
backlink.
G
G
It
retains
this
property
that
the
spec
has
that
allows
you
just
sort
of
kind
of
to
read
it
top
to
bottom
and
understand,
what's
going
on
without
having
to
bounce
between
sections
to
understand
how
things
work,
and
that
was
my
main
worry
in
having
a
dedicated
glossary.
Is
that
you'd
see
a
term
and
not
know
what
it
meant
and
then
have
to
like
jump
to
glossary,
to
define
it
and
then
go
back
to
where
you
were
and
now
like?
G
The
definition
of
the
term
is
done
in
context,
and
so,
if
you
see
in
the
pull
requests
that
I
linked
there,
we
defined
built-in
directives
and
then
this
sentence
that
was
sort
of
already
there.
I
did
a
little
bit
of
refactoring
there,
but
I
I
just
sort
of
like
made
that
paragraph
a
definition
paragraph.
G
G
I
imagine
to
the
appendix
that
we
already
have
that's
the
full
grammar,
and
that
also
is
not
automatically
generated
because
there's
some
notes
and
some
sort
of
subtle
things
that
make
it
not
possible
right
now
to
automatically
generate,
although
that's
also
something
we
could
consider,
but
that's
that's
something
that
I
think
is
up
for
discussion
as
to
whether
we
want
something.
That's
like
truly
a
glossary
that
just
pulls
all
the
definitions
out
and
puts
them
together
in
one
place.
I
don't
know
if
it'll
be
helpful
or
noisy,
but
it's
worth
exploring.
I
Yeah,
thank
you
for
that
description.
That
was
great,
so
yeah.
I
think
I
think
what
we've
got
already.
What
you've
built
is
excellent,
I'm
I
would
still
like
to
see
a
glossary,
but
obviously
we
need
to
define
all
the
terms
before
that's
a
concern,
so
we're
not
going
to
have
to
worry
about
that
for
probably
a
year
or
so
I
should
think
but
yeah.
I
I
think
this
is
a
brilliant
move
forward
and
the
the
ability
now
to
just
hover
over
a
term
when
it's
used
in
the
spec
and
see
like
where
that
links
to
the
definition,
I
think,
is
really
really
valuable.
Part
of
this
as
well
is
I
want
to
try
and
narrow
down
a
few
other
terms.
So
obviously
I
talked
about
query
before,
but
we've
also
been
having
a
lot
of
discussions
around
like
inner
types
versus
rapper
types
versus
rapping
types
versus,
etc,
etc.
I
So
coming
up
with
good
strong
definitions
for
those
that
we
can
put
into
the
document
in
this
fashion,
I
think,
is
a
really
good
way
to
do
it
and,
if
other
people
know
have
noticed
other
things
in
the
graphql
spec
that
are
ambiguous,
then
it
would
be
great
if
you
could
just
raise
those
as
well
and
we
can
try
and
nail
it
all
down,
and
I
hate
ambiguity.
So
let's
try
and
get
rid
of
it.
G
G
Great,
the
other
reason
why
I
kind
of
like
this
is:
it
avoids
a
sort
of
in
incomplete
glossary
that
feels
anemic
where,
like
a
handful
of
things,
are
defined,
but
not
everything
and
we're
like.
G
Why
do
we
have
this
thing
that
doesn't
actually
define
everything,
so
we
can
kind
of
incrementally
start
using
the
syntax
to
have
better
definitions
of
things
and
refer
back
to
them,
and
we
should
keep
using
this
rfc
doc
because
you
put
in
a
decent
amount
of
work
to
make
sure
that
we
have
a
list
of
things
that
should
have
definitions
and
writing
them
out.
So
I
can
imagine
a
bunch
of
editorial
changes
that
just
fold
a
bunch
of
these
back
into
the
spec.
G
F
Yeah
steven
isn't
here
today,
but
a
bunch
of
other
colleagues
are
I'm
going
to
share
my
screen.
We
put
together
a
little
presentation.
F
Oh
okay,
we'll
just
do
it
from
here
then
cool
hi,
I'm
alex
I'm
from
yelp,
where
I
work
on
our
ios
networking
infrastructure
I'll
be
championing
this
proposal
along
with
liz
marks,
and
I
stephan
wei
and
young
and
yeah.
When
times
did
you
give
questions?
I
I
welcome
our
my
colleagues
here
to
also
try
to
field
some.
F
This
is
something
we're
presenting
for
the
first
time
we're
presenting
it
as
a
as
a
straw
man,
so
you
know,
feel
free
to
knock
it
down
to
get
this
out
of
the
way
quickly.
Some
folks
from
relay
left
us
some
feedback
on
a
proposal.
You
won't
be
seeing
your
feedback
integrated
into
the
proposal
that's
being
presented
today,
but
it
was
very
helpful
in
letting
us
know
where
communication
of
the
behavior
this
feature
could
be
improved.
F
Proposal
isn't
flat
out
rejected
today,
we'll
make
sure
your
feedback
is
further
taken
into
account.
Some
questions
we'd
like
to
answer
today.
Is
the
proposal
feasible
in
any
form.
Have
there
been
prior
attempts
at
something
similar
and
what
work
will
we
need
to
do
to
move
this
rfc
to
the
next
stage
from
a
from
a
straw
man
to
a
I
forget
what
the
next
stage
is,
but
the
next
one
number
one
cool
and
with
that
we
can
move
over
to
the
thing
itself.
F
Let
me
stop
sharing
and.
F
I
think
this
is
the
right
one,
so
we
have
a
straw
man
and
a
longer
form
rfc
that
we're
drafting
right
now.
I
recommend
that
people
focus
on
the
straw
man
for
now
the
stuff
in
the
rfc
is
a
lot
of
it
is
up
for
for
debate
and
is
very
fluid
so
to
get
going
problem
statement.
So,
in
our
experience,
client
developers
have
been
frustrated
that
the
vast
majority
of
fields
are
nullable.
F
We've
done
this
in
accordance
with
the
official
best
practice,
and
we
largely
agree
that
this
is
good
practice,
so
we
need
another
way
to
make
working
with
graphql
more
ergonomic
for
client
developers.
F
So
what
we're
proposing
is
that
graphql
spec
include
a
non-null
designator
that
can
be
used
from
the
client
side.
We're
representing
the
designator
here
with
a
a
bang
or
an
exclamation
point.
The
semantics
of
this
non-null
designator
would
be
basically
identical
to
its
counterpart
in
sdl.
F
If
a
null
is
found
on
the
server
for
a
non-null
field,
either
marked
in
sdl
or
in
the
on
the
client
side.
With
with
our
proposal,
it
would
bubble
up
to
its
nearest
nullable
parent
and
an
error
would
be
returned
to
the
client
describing
what
exactly
happened
here.
You
can
see
an
example
of
what
we're
describing
with
this
query.
So,
in
this
case,
name
is
a
nullable
field
in
the
schema,
but
we're
saying
for
the
sake
of
this
query,
it
is
not
nullable,
it
is
a
non-null
field
right,
so
why?
F
This
proposal
would
allow
graphql
code,
generators,
tooling
and
potentially
other
tooling,
might
find
use
for
it
too,
but
we're
looking
at
codegen
tooling
to
generate
types
that
are
more
in
line
with
the
needs
of
the
feature
executing
the
query
so,
for
example,
in
status
quo
name
here
would
be
nullable,
but
with
our
non-null
designator
on
name
the
name
that
is
generated
by
code
gen
in
this
case
we're
using
apollo,
but
it
could
be
something
else
too
would
be
non-null,
and
in
this
case,
in
this,
with
this
client
developers
no
longer
need
to
deal
with
nullable
types
in
cases
where
they
don't
expect
them
go
back
to
the
presentation
really
quick.
F
We
have
a
lot
of
open
questions.
A
lot
of
the
stuff
in
this
proposal
is
is
up
for
discussion,
so
one
where
are
these
nulls
caught
we're
presenting
it
as
if
it's
happening
on
the
server
side,
which
has
some
benefits,
people
on
relay
have
a
similar
solution
with
a
custom
directive
where
it's
all
handled
on
the
client
side,
though
that
might
yield
a
simpler
implementation
and
relay
already
has
a
pretty
good
idea
of
how
that
might
work
with
regards
to
client
side.
F
Caching,
how
does
this
work
if
it
finds
a
null?
Does
it
bubble
up?
Does
it
treat
as
a
cache
miss
cache
miss?
Do
we
let
the
user
choose
via
caching
policy
and
then
the
syntax
specifics
we're
using
a
bang
to
mirror
what's
happening
on
sdl?
It
has
a
nice
symmetry
to
it,
but
people
at
netflix
are
doing
something
similar
again
with
a
custom
directive
where
they're
using
a
directive
and
then
in
relay
they're
using
a
directive
that
takes
parameters
which
might
yield
some
additional
flexibility
and
then
there's
also
some
open
questions
around.
F
You
know
how
do
thin
clients
deal
with
this
directive.
A
lot
of
this
is
what
we've
been
talking
about,
is
more
for
full-fledged
clients
that
are
doing
cogen
and
caching
and
all
kinds
of
stuff,
and
then
how
does
this
play
with
mutations?
Some
people
had
concerns
around
like
we
could
get
an
error
back,
despite
the
mutation
going
through
that
sort
of
thing
right,
so
with
that
I'd
like
to
you
know,
turn
it
to
the
folks
here:
is
this
both
feasible
have
their
empire
attempts?
G
I
love
this
proposal.
There
definitely
have
been
prior
discussions.
I
don't
think
we've
ever
gotten
all
the
way
to
nrc
before
and
then
you
know,
I
think.
Obviously
this
has
been
a
feature
in
relay
for
quite
some
time,
and
so
that
goes
back
many
years.
This
particular
discussion
I'll
give
you
my
personal
opinions
for
your
questions.
You
know,
I
think,
I'm
in
strong
support
of
having
something
syntactical
rather
than
a
directive
to
to
manage
this.
I
think
this
has
always
been
my
biggest
concern
with
having
this
supported
as
a
directive.
G
Is
it
ends
up
sort
of
polluting
a
query
if
you
need,
if
you
have
lots
of
fields
that
are
all
nullable
and
you
need
to
require
many
of
them,
then
you
end
up
writing
more
non-null
directives
or
required
directives
than
you
write,
query
text
and
also
the
bang
syntax.
Is
it's
not
really
a
new
invention
for
for
javascript
swift
uses
an
extremely
similar
syntax,
and
especially
since
a
lot
of
active
graphql
users?
These
days
are
front-end
developers
who
use
languages
like
kotlin
and
swift.
G
I
think
they
would
find
that
syntax,
particularly
natural,
in
terms
of
where
this
coercion
should
or
where
the
the
error,
handling
and
nullability
handling
should
happen
on
the
client
or
the
server.
I
think
it
has
to
happen
on
the
server.
That's
that
the
spec
dictates
what
the
server
does
like.
There
are
two
choices:
either
we
put
it
in
the
spec
and
it's
managed
on
the
server
or
we
don't
put
it
in
the
spec,
and
we
do
it
with
directives,
and
we
do
it
on
the
client
and
we
already
have
the
first
one.
G
That's
I
would
say
the
netflix
and
relay
implementations
are
essentially
long-running
experiments,
showing
that
this
is
a
very
useful
thing
and
to
introduce
it
into
the
spec
would
require
the
servers
to
to
support
to
support
the
syntax
and
do
something
reasonable
with
it.
G
And
the
other
thing
I'll
say
is
I
I
think
this
is
half
a
proposal.
My
suggestion
would
be
to
also
support
the
opposite.
I
think
this
is.
This
is
a
missing
piece
in
in
query:
flexibility
in
graphql
in
general,
one
it
just
like
how
to
handle
nulls
and
and
errors
and
manage
have
some
control
over
the
air
flow
process.
G
You've
proposed
what
I
think
is
half
of
the
problem,
which
is,
if
you're
given
a
non-null
field,
and
you
need
to
require
it.
You
need
some
way
to
describe
that.
I
think
the
opposite
is
slightly
less
of
a
problem,
but
deserves
to
be
part
of
the
rfc
to
have
both
sides,
which
is
you
have
a
non-null
field,
but
on
the
client
you
don't
particularly
care
about
it,
and
if
it
has
an
error,
you
don't
want
it
to
blow
out
the
entire
object.
G
So
you
need
something
that's
an
equivalent
of
like
an
air
boundary
wrapped
around
it.
If
you're
going
to
use
the
exclamation
point
there,
I
think
it's
probably
natural
that
you'd
consider
a
question
mark
character
to
follow
those
that
would
give
you
sort
of
both
halves
of
the
of
the
equation
and
that
would
give
clients
full
control
over
the
null
ability,
both
to
wrap
something
as
a
nominal
and
also
to
unwrap
something
as
nullable
from
the
the
syntax
of
the
query
itself,
but
yeah
I'm
in
strong
support
of
this.
G
I
think
the
tough
part
is
making
sure
that
the
query
text
is
sound
and
makes
sense.
I
think
our
error
handling
text
in
the
in
the
spec
right
now
is
not
particularly
great,
and
so
that
probably
will
need
some
some
love
and
then
also
just
getting
this
implemented
as
an
rfc
pull
request
in
garfield
js.
I
suspect
that
actually
probably
won't
be
that
difficult,
but
those
are
the
pieces
to
get
it
to
draft
phase,
at
least
that's
my
opinion,
but
I'll.
Let
other
people.
F
D
We
definitely
wanted
it
to
live
on
the
server
so
that
we
could
get
some
efficiency
wins,
but
I
think
the
more
we
thought
about
it,
the
more
we
realized
that
this
was
not
really
viable
because
of
the
way
that
the
response
that
you
get
back
from
the
server
collapses
down
all
the
different
fragments,
and
so
if
you
in
one
fragment,
say
that
a
field
should
be
required,
then
that
is
going
to
leak
out
into
all
the
other
consumers
of
that
field,
which,
like
breaks
some
of
the
data
locality
expectations
that
at
least
relay
users
have.
D
I
would
imagine
that
that
exists
in
other
clients
as
well.
So
I
think
the
the
challenge
we
saw
there
was
that
unless
you
make
it
a
client-side
concern,
you
basically
are
re-implementing
the
fact
that
this
is
required
on
the
in
the
schema
and
and
like
the
you're,
not
really
making
it
local
to
like
a
single
fragment.
D
A
single
field
may
be
required
in
lots
of
different
places
in
a
single
view,
and
it
may
not
have
the
same
like
view
requirement
across
all
of
those
different
consumers,
but
yeah.
I
think
joe
also
has
some
some
good
insight
into
this.
K
Yeah
and
and
actually
the
kind
of
so
I
I
do
want
to
step
back
and
like
we
love
the
idea
of
having
syntax
for
this,
we
totally
agree.
K
This
is
a
huge
problem
and,
like
it's
a
use
case
that
should
be
solved
so
we're
100
on
board
with
like
yes,
we
should
do
something
here,
so
I
just
want
to
make
that
very
clear,
like
we're
kind
of
like,
I
think
we
were
kind
of
jumping
at
like
some
specifics
of
how
this
works
and
kind
of
like
the
effects
that
we'll
have
but
totally
agree,
huge
problem
that
needs
to
be
solved.
This
is
one
of
the
biggest
pain
points
we
see
just
using
graphql
and
absolutely
agree
like.
K
If
we
solve
it,
it
should
have
syntax
kind
of,
as
jordan
was
kind
of
pointing
out.
Basically,
we
kind
of
view
fragments,
as
you
know,
like
modular,
you
know,
components
within
an
application
and
the
idea
being
that
you,
you
might
have
one
part
of
your
ui
or
your
application.
That
needs
some
specific
data.
Another
part
that
is
is
more
resilient
to
that
data
being
missing,
and
so
this
isn't
even
about
those
two
pieces
of
the
ui.
K
Having
you
know
saying
that,
like
let's
say,
name
can
be,
it
must
be
non-null
here
and
is
optional
here,
it's
actually
it
could
be
entirely
different
fields,
but
just
on
the
same
parent
and
the
fact
that
this
fragment
treats
field
a
as
non-null
and
another
fragment
needs,
some
data
be
on
the
same
parent
object.
This
this
fragment
can
cause
this
other
fragments
data
to
go
missing
and
so
so
kind
of
thing
about
it.
K
So
what
I
think
what
I
think
that,
like
the
likely
the
likely
outcome,
if
like
let's
say
this
is
approved,
is
that
relay
compiler
would
have
to
have
special
treatment
for
this,
that
basically
strips
every
single
non-null
annotation
from
every
single
query
right,
unless
we
can
prove
that
the
fact
that
a
given
fragment
has
used.
K
This
cannot
cause
data
to
go
missing
for
any
other
fragment
in
the
application
right,
which
means
that,
like
in
general,
like
there's
gonna,
be
so
many
queries,
there's
gonna
be
so
many
other
fields
like
there's
almost
always
another
sibling
fragment
that
would
be
affected
by
it.
So,
therefore,
you
have
to
strip
out
every
single
number.
K
So
I
think
this
kind
of
gets
at
the
fact
that,
like
graphql,
doesn't
really
have
this
notion
of
modularity
and
component
isolation,
and
so
I
can
see
potentially
accepting
this
proposal
with
the
like
sort
of
accepting
that
this
will
inevitably
surface
the
fact
that
we
now
have
to
solve
fragment
like
modularity
and
composition
and
make
it
possible
to
express
a
query
in
graphql
such
that
nulls
across
fragments
don't
blow
each
other
up.
K
M
Go
also
like
I
know
lee
you
mentioned
like,
oh,
if
we
add
this
to
the
syntax,
we
need
it
to
be
server-side,
because
that's
what
the
spec
is.
I
actually
the
next
thing
we'll
discuss
is
also
a
potential
client-side,
syntax
change.
M
So
I'm
wondering
if
there
is
room
in
the
spec
for
us
to
have
syntax
that
never
makes
it
to
the
server
or
that
is
optional
for
the
server
to
implement,
but
it
can
be
implemented
purely
client-side
because
there's
like
we're,
especially
within
facebook,
we're
finding
that
we
can't
necessarily
iterate
on
our
ideas
of
like
major
things.
We
want
to
support
unless
we
have
essentially
a
compiler
that
compiles
backwards
on
top
of
the
spec
like
syntax.
G
I
so
the
spec
doesn't
necessarily
make
a
distinction
between
client
and
server.
The
spec
is
written
in
terms
of
given
a
a
operation
text
and
a
schema
that
implements
internal
resolver
functions,
produce
a
result
and
the
concepts
of
client
and
server
are
sort
of
like
one
abstraction
above
that
right.
So
if
you
want
to
do
client-side
processing
first,
followed
by
server-side
processing,
like
all
of
that,
is
below
the
seam
of
what
the
spec
cares
about.
G
So
I
I
would
say
there
would
be
a
very
high
bar
to
introduce
such
a
concept
of
a
client
and
a
server
into
the
spec
and
say
a
server
should
not
use
this
syntax
and
a
client
should
use
the
syntax,
because
we
don't
have
anything
that
looks
like
that
right
now.
G
So
when
I
say
like,
if
it's
in
the
spec,
a
server
has
to
do
it,
that's
not
100
accurate.
It
just
means
that
a
thing
that
claims
to
be
a
graphql
service-
and
I
would
argue
relay-
is
a
graphql
service
because
it
actually
like
does
stuff
under
the
hood,
and
it
talks
to
a
graphql
server
itself
under
the
hood.
But
like
really.
What
relay
is,
is
you
write
your
queries
and
your
fragments
and
then
really
like?
G
But
I
don't
think
that
it
would
be
okay
to
say,
like
hey,
we're
going
to
introduce
this
change,
but
we're
going
to
write
into
the
spec
that
a
server-side
service
should
fail,
but
a
client-side
service
should
use
this
like
complicated
way
to
translate
this
into
a
different
query.
That,
then,
is
like
able
to
be
operated
on
the
server,
because
if
you
can
do
a
cert
query
to
query
translation
like
why
can't
you
just
use
the
rules
that
describe
how
the
original
query
should
work
onto
the
latter.
But
I
do
think
that
there
should
be.
G
This
doesn't
necessarily
have
to
be
written
in
the
spectex.
But
this
should
be
a
explicit
goal
of
the
rfc
is
that
it
should
be
translatable
on
a
client.
So
if
we
write
this
in
a
way
that
makes
it
impossible
for
relay
to
keep
doing
the
thing
that
it's
been
doing
for
years,
that
seems
like
it
didn't
right,
like
ideally,
we'd
write
this
in
a
way
where
relay
and
any
other
client
that
uses
this
technique
just
go
through
and
take
all
the
at
requireds
and
just
swap
them
with
an
exclamation
point
and
be
like
whoa.
G
G
Should
it
choose
not
to
if
everything
goes
through
relay
anyway,
but
if
they
did,
then
the
relay
client
could
decide
which
of
these
would
we
like
to
manage
locally
via
translation
and
which
of
these
would
be
like
the
server
to
manage
for
us,
because
I
think
the
other
thing
that
I
mentioned
before
about
the
other
side
of
this
coin
is
taking
something
that's
already
represented
as
non-null
on
the
server
and
then
unwrapping.
G
It
is
something
that
client-side
transformation
can't
manage
at
all,
like
that's
purely
an
air
boundary
concept
that
has
to
exist
on
the
server
side
of
the
client,
server
boundary,
and
so
those
you
know,
you
probably
couldn't
translate.
G
G
K
K
I
think
the
larger
the
main
concern
I
have
is
really
more
about
like
what
is
the
actual
like
effective,
this
going
to
be
on
the
graphql
ecosystem
like
if
it
is
it
that
like
people
will
be
like,
is
it
that,
like
most
client,
compilers,
will
kind
of
figure
out
what
we
figured
out
and
realize,
like,
oh
actually,
but
keeping
these
keeping
this
that
we
are
kind
of
like
destroying,
like
gonna,
be
like
hurting
resiliency
of
our
applications
and
actually
have
to
like
remove
this
when
it
sends
the
server
and
that
and
that,
what's
what
that's
kind
of
getting
at?
K
Is
that
there's
a
missing
feature
like
in
the
sense
of
like
we're
trying
to
express
like
if
this
component's
data
is
missing,
like
don't
bother
returning
any
of
that
data
right
and
like
bail
out
of
processing
of,
like
you
know,
if
you,
if,
like
at
top
level
field
for
some
front
from
like
some
you've
like
this
huge
expensive
fragment
and
a
top
level
metal
like
required
field,
is
missing,
you
can
like
you.
K
What
you
want
to
do
is
bail
out
of
that
processing
and
get
the
efficiency
win,
but
like
with,
if
we
have
to
distribute
all
non-null
annotations
to
actually
retain
the
correct
semantics,
then
we
can't
take
advantage
of
that
optimization
and
so
I'm
just
kind
of
like
trying
to
figure
out
I,
on
the
one
hand,
I
don't
see
any
particular
problem
with
it
with
this
proposal,
I'm
just
wondering:
are
we
actually
going
to
get
the
wins
we
want
to
or
or
is
there
like
a
missing
thing
that
we're?
We
should
be
striving
for.
J
So
if
I
understand
correctly
like
the
main
issue
with
all
of
that,
is
that
the
server
is
expected
to
merge
identical
fields
and
identical
fragments,
and
if
the
server
didn't
do
that,
then
the
client
wouldn't
have
to
deal
with
all
of
this
conflict
right
right.
So
it's
more
on
top,
but
yeah
yeah.
I
would
I
mean.
K
Yeah,
it
was
we,
it
almost
made
it
into
the
original
spec.
Actually
you
I
remember
lee,
you
actually
implemented
it
and
we
talked
about
it
and
realized
that
it
was
some
confusion,
but
yeah
we've
actually
long
talked
about
named,
fragment,
spreads
for
relay
and
actually
our
native
clients
actually
effectively
do
named
fragment,
spreads
and
that
like,
when
you
do
dot,
you
know,
foo.
You
actually
get
like
an
accessor
method
like
as
foo,
so
that
the
data
is
not
just
directly
spread
in.
You
have
to
explicitly
say
like.
K
M
G
For
what
it's
worth,
I
think
it's
I
mean
we're
getting
slightly
off
topic,
but
it's
worth
redressing
that
particular
one.
If
I
remember
correctly,
the
reason
why
we
decided
not
to
do
it
was
a
just.
A
transfer
size
concern
right
like
if
everything
is
separated
out
into
alternately
named
fields.
G
Then,
if
you
fetch
the
same
field
in
every
fragment,
and
you
use
that
everywhere,
you
get
this
sort
of
combinatoric
explosion
where
you
get
the
same
value
repeated
multiple
times,
which
means
that
the
resolver
needs
to
run
every
time
for
each
of
those,
whereas
in
merged
fragments,
it
runs
a
single
time
for
that
merged
field.
So
there's
a
tricky
trade-off
at
play
and
we'd
want
to
make
sure
that
it
was
obvious
that
people
were
making
the
off
between
modularization
and
efficiency
and
that
they
could
have
something
that
they
could
measure.
G
So
I
think
it's
entirely
possible,
so
it's
very
much
worth
revisiting,
but
I
think
how
that
relates
back
to
this
proposal
is,
I
suspect
that
the
execution
change
for
this
proposal
will
be
easier
than
you
think,
and
the
validation
change
to
make
sure
that
you
can't
construct
a
query
that
performs
in
some
way
that
is
very
confusing,
will
be
quite
a
lot
more
complicated
and
probably
require,
rather
than
starting
with
spectex,
to
start
with
unit
test
cases
and
reference
implementation
to
just
like
really
tease
out
every
corner
case
you
can
think
of
because
that's
how
we've
written
most
of
our
validation
rules
so
far
and
then
work
backwards
to
the
spec
text
from
there,
because
there's
kind
of
this
tricky
question
of
like
if
you
have
two
fragments
that
overlap,
one
of
which
has
a
required
field
with
whatever
treatment
we
decide
to
use
or
vice
versa.
G
One
of
them
has
a
error
boundary
and
wants
to
unwrap
it,
and
the
other
one
does
not.
Is
it
safe
to
merge?
Can
you
end
up
in
a
case
where
you
get
a
value
that
is
confusing
for
what
those
fragments
say
they
will
get,
but
the
way
that
this
rc
is
being
written
in
the
use
case
of
client-side
code
generation
gives
me
confidence
that
we'll
probably
land
on
something
good,
because
client-side
co-generation
is
like
the
primary
case
for
getting
this
validation
rule
right.
F
F
I
So
what
lee
was
saying
earlier
with
regard
to
potentially
supporting
the
question
mark
syntax
as
well,
I
think
in
in
the
same
way
that
we
have
issues
with
nullability
in
general,
like
how
the
output
schema,
nullability
rules
are
kind
of
the
opposite
of
the
input
schema
nullability
rules.
We
have
similar
issues
if
we
were
to
go
this
route.
So
I
think,
if
you
have
fields
in
your
graphql
query
that
you
put
bangs
on
and
say
this
is
going
to
be
non-nullable.
I
We
either
need
to
have
a
rule
that
says
that
same
field
everywhere
that
it's
referenced
in
all
of
the
fragments
needs
to
have
the
same
bang
or
we
could
make
the
choice
that
that's
not
the
case.
But
if
it's
not
the
case,
what
do
we
then
do
when
we
execute
on
the
server
and
the
bank
can
still
elevate
it
to
the
next
tier
and
have
the
error
thrown,
and
that
would
still
be
a
valid
response
across
the
whole
query?
I
That
would
then
put
a
limit
on
clients
such
as
relay
that
want
to,
for
example,
allow
it
to
have
a
non-nullable
in
one
fragment
and
not
have
it
in
another,
because
the
validation
rules
for
the
operation
would
say,
that's
not
that's
not
viable,
and
the
fact
that
relay
is
then
gonna
like
extract
part.
That
out,
I
think,
may
be
problematic,
because
you
kind
of
have
to
do
that
before
you
do
the
validation,
which
I
think's
kind
of
kind
of
weird
so
yeah.
I
think
I
think,
there's
some
complexities
there.
K
Yeah,
so
what
I
was
going
to
say
there
is,
I
I
feel
like
I
can
imagine
that
the
validation
rule
could
basically
be
as
like
as
strict
as
possible.
K
Right
like
just
require
a
consistent
and
maybe
there's
some
ways
to
some
forms
where
it
could
be
relaxed,
but
I'm
actually
not
worried
about
relay
or
relay
like
clients
here,
because
I
think
what
we
basically
do
is
just
completely
strip
these
out
of
always
under
the
server
and
do
our
own,
like
validation
around
these
rules,
so
that
you
sort
of
in
terms
of
the
data
you
get
out
of
the
client.
They
it
honors,
like
it.
K
Honors
the
spec,
but
in
terms
of
like
the
actual
queer
that's
getting
sent
to
the
server
is
not
identical
to
what
you
write
so
that
that
seems
fine
to
me
to
just
have
like
strict
validation
rules
and
then
what
clients
gonna
choose
to
loosen
them.
G
Another
way
to
phrase
that
is
relay
graphql
is
is
like
not
exactly
graphql
like
it
adds
a
little
bit,
and
it
removes
a
little
bit
and
validation
is
one
of
the
ways
that
it
does
that,
and
I
I
definitely
remember
looking
at
the
implementation
of
this,
that
it
does
use
graphql,
js
validation,
but
it
just
removes
a
bunch
of
validation
rules
that
are
not
relevant,
given
the
loosening
of
constraints
that
relay
is
allowed
to
do
based
on
how
it
manages
those
fragments,
and
so
the
like
feel
overlapping
fields
must
match.
G
There's
like
a
bunch
of
nuance
to
how
that
validation
works.
That
I
think
relay
just
completely
casts
out
and
and
writes
its
own
version
of
that
applies
the
relay
specific
variants.
So
we
should
do
the
one
that
like
given
the
execution
rules,
the
validation
should
require
that
that
execution
can
work,
and
I
think
what
you're
all
saying
is
the
right
thing
like
the
most
strict
possible
is
like
yo.
If
you've
got
two
fields
and
they
overlap,
they
gotta
both
have
exclamation
points
or
rather
question.
G
They
just
got
a
match
that
that
would
be
the
simplest
possible
implementation,
and
then
you
should
kind
of
work
backwards
from
there
to
see
if
you
can
loosen
it,
because
that
might
be
overly
annoying,
but
but
that's
definitely
the
reasonable
place
to
start
yeah.
But
that's
kind
of
what
I
was
trying
to
get
that
benji
of
the.
I
think
the
validation
rule
is
the
place
where
you're
probably
going
to
spend
most
of
the
time
trying
to
get
this
proposal
in
the
right
state.
G
But
all
the
more
reason
why
y'all
should
work
with
relay
apollo
and
other
clients
to
make
sure
that
this
is
not
just
a
well-defined
thing
for
the
server
to
do,
but
that
the
clients
can
make
sure
they
can
do
any
client-side
transforms
or
compute
or
cogeneration
in
the
ways
that
they
expect
with
it.
H
Yeah
yeah
brian
and
I
are
on
the
the
teams
that
would
be
looking
at
this
and
we
control
the
road
maps
for
apollo
client,
apollo,
ios
and
apollo
android,
so
we'd
be
happy
to
work
with
you
on
this
absolutely.
L
Just
to
add,
like
a
15
seconds,
if,
if
that's
okay,
I
was
wondering
if
flake
just
people
thought,
if
it's
possible
to
do
this
in,
like
a
non-destructive
way
to
kind
of
get
the
best
of
both
worlds
and
kind
of
like.
In
the
same
way,
do
you
have
like
an
errors
away
that
you
append
stuff
to
or
something
anytime,
that
there
is
like
a
you
know,
null
ability
and
if
something's
gone
wrong
on
the
server
you
know
you
could
you
could
message
it
there
to
extensions
or
something
similar?
And
then
the
client
could?
L
Okay,
I
guess
yeah.
I
guess
it
still
becomes
like
a
client
thing
that
to
meet
the
spec,
you
should
like
enforce
things
in
this
new
bit
of
the
response,
but
you
can
do
that
selectively.
L
You
know
if,
if
you
have
like
conflicting,
you
know
like
nullability
requirements
and
different
fragments
of
something
I
don't
know
exactly
what
the
semantics
of
that
would
look
like,
but
something
non-destructive
might.
G
G
I
don't
think
we
can
do
something
where
we
require
post-processing
on
the
result
by
spec,
because
the
simplest
possible
version
that
should
be
spec
compliant
is
you
should
be
able
to
use
like
curl
or
wget
and
send
a
string
to
a
service
and
get
back
a
payload
and
be
able
to
assert
that
everything
works
correctly.
And
so,
if
the
spec
says
like
hey,
once
you
get
this
response,
then
you
have
to
do
this
post-processing
on
it.
G
I
don't
think
we
can
do
that,
and-
and
that
gets
this
idea
of
like
the
spec
abstract,
it's
subtracted
away
from
the
idea
of
there
being
like
both
a
client,
processing
step
and
a
server
processing
step.
It's
just
you
write
query
text,
and
then
you
get
results
and
like
how
that
actually
works
is
defined
well,
but
the
actual
like
implemented
mechanics
is
is,
however,
it
needs
to
be,
and
so
smart
clients
end
up
doing
additional
work
to
make
the
spec
work
or
to
be
a
subtle
variation
of
graphql
like
really
even
a
political
degree.
F
K
Yeah,
I
have
like
one
last
point
and
I
feel
like
it's
probably
enough,
like
enough
of
a
kind
of
worms
that
we
should
just
leave.
It
maybe
come
back
to
it
next
time,
but
so
I
did
want
to
point
out
something
that
jordan
had
mentioned
on
the
the
pr
was
we
actually
have
like
our
behavior
is
actually
slightly
different.
K
The
default
behavior
that
we
found
most
product
developers
want
to
use
is
actually
not
the
same
as
the
the
non-null
behavior
of
just
like
basically
bubbling
up
to
the
nearest
null,
so
the
behavior
that
we've
found
that
to
be
the
most
common
is
that
basically
developers
want
to
actually
just
throw
if
a
like
required
field
was
null,
and
so
specifically,
if
you
have
a
you,
know,
ui
component,
that
calls
or
use
like
use
fragment
hook.
If
any
of
the
required
data
was
missing.
K
That
component
will
actually
just
throw,
and
so
rather
than
have
to
like,
do
a
null
check
and
then
directly
through
that.
That,
basically
was
the
common
behavior
was
everyone
was
basically
putting
you
know
non
making
everything
down
to
like
the
not
the
the
required
field,
non-nullable
and
then
doing
a
null
check
and
then,
if
it
was
null
throwing.
K
Kind
of
bubbling
up
to
an
air
boundary
where
they
would
like
do
some
so
actually
like
some
some
handling,
and
so
that
was
the
most
common
behavior.
So
the
one
concern
there
is
like
the
behavior
that
we'd
most
likely
end
up
with.
Is
that
like
relay's,
you
know,
treatment
of
bang
would
actually
be
different
than
spec.
So
I'm
just
not
sure
if,
like
that's
been
like,
if
you
thought
about
kind
of
that
that
behavior
at
all
like
is
it?
K
Do
you
really
want
to
have
to
like
go
down
to
like
check
the
parents,
or
is
it
more
like
if
this
whole
thing
is,
if
anything
is
known
I'll,
just
like
blow
up
this
entire,
you
know
fragment,
for
example.
Again
this
is
like
we
really
embrace
fragments
heavily
and
not
most
clients,
don't
probably
kind
of
worms.
We
can
maybe
revisit.
A
F
Sweet
thanks
for
that
yeah.
Absolutely
we
can.
We
can
look
at
that
further.
Okay,
so
just
to
wrap
this
up.
What
do
we
need
to
do
to
get
the
next
rfc
stage,
we'll
open
up
a
pr
to
like
the
actual
spec
thing?
We
have
it
in
a
fork
right
now,
but
we'll
try
to
move
stuff
over,
and
then
we
have
a
partial
implementation
on
graphql.js
right
now,
it's
probably
very
outdated,
so
the
person
who's
away
who's
working
on
it
is
probably
going
to
fix
it
up.
G
Looks
like
you're
in
a
great
place,
so
the
the
between
rc,
0
and
rc1
is
basically
like
you've
gotten
wind
from
this
group
that
you've
thought
about
most
of
the
things
that
are
important
to
think
about,
and
the
group
agrees
that
this
is
a
problem
we're
solving,
so
I
think
you're
there
that
essentially
puts
you
at
past
the
straw,
man
phase,
but
yeah.
I
would.
G
I
would
love
to
see
this
appear
as
a
as
a
pull
request
against
the
spec
and
employ
requests
against
graptojs
just
so
that
we
have
like
a
source
of
truth
that
we
can
track
going
forward.
I
assume
that
they
will
change
dramatically
over
time
as
you
work
your
way
through
all
these
issues,
my
personal
advice
is
to
focus
more
on
code
than
spec.
G
I
Thank
you,
okay,
cool
thanks.
So
much
from
from
the
note
taker
who
can
I
put
as
a
target
on
this
action
like
or
could
you
add
yourselves
to
the
rsc
doc,
because
I
need
to
file
these
later
and
I
don't
know
who
to
who
to
assign
there's
a
lot
of
you
that
were
mentioned
on
that
first
slide.
I
Yeah,
if
you
could
do
like
your
github
username,
that
would
be
particularly
helpful
sure.
G
G
F
M
Another
proposal
that
we've
been
thinking
about
for
years
so
yeah,
let
me
okay,
I
cannot.
I
can't
share
screen
because
I
didn't
enable
zoom
to
do
that.
I
need
to
quit
and
re-come
back
yeah
I'll.
Let
me
do
that.
Sorry
I'll,
be
one
minute.
G
In
fact,
let's
just
do
things
upside
down,
we'll
as
matt's
getting
stuff
ready,
we'll
talk
about
the
type
name
and
subscription
root.
Actually,
that's
back
so
got.
M
So
I
can
share
the
pr,
maybe
yeah,
so
in
short,
relay,
has
had
a
concept
of
passing
arguments,
two
fragments
for
a
very
long
time
like
years,
and
they
do
this
with
a
completely
out
of
spec
directive,
because,
while
the
like
semantics
or
the
syntax
technically
is
like
partial,
it
fails
because
every
at
arguments
has
a
different
like
count.
Count,
for
instance,
is
not
defined
in
the
schema
anymore.
M
Initially
in
graphql
js,
where
to
start
we
will
just
disable
but
long
term.
If
we
want
to
allow
passing
arguments
to
fragments
this
is
the
straw
man
proposal
for
what
we
would
pack
how
we
would
define
those
argument,
values
for
the
fragment
so
basically
use
dollar
x
and
then
the
type
definition
just
like
normal
variable
definitions
and
then
for
passing
it
into
a
fragment,
spread,
use
the
name
of
that
defined,
variable
colon.
M
M
Yeah,
that's
the
very
high
level
overview.
I
basically
wanted
to
put
this
on
people's
radar
by
next
working
group
meeting.
I
plan
to
have
this
at
least
implemented
in
a
pr
on
graphql
js
for,
at
the
very
least,
the
syntax,
with
a
flag
that,
by
default,
when
you
try
to
parse
this,
it
would
fail,
but
like
an
optional
flag
on
the
parser
plus
a
validation
rule
that
says,
oh,
you
tried
to
use
these.
M
G
M
Yeah,
so
we
could
definitely
allow
a
graphql
service
to
use
it,
but
at
present
like
so
I
do
have
in
the
actual
proposal
itself,
which,
let's
see,
I
think
I
can
view
it
as
yeah.
M
So
in
the
proposal
itself,
I
would,
I
have
added
a
whole
bunch
of
potential
validation
rules
where,
if
we
had
these
validation
rules,
a
cert,
a
graphql
server
would
be
capable
of
implementing
this
syntax
change
and
it
would
base
it
would
essentially
be
a
no-op
in
terms
of
like,
or
rather
it
would
be
guaranteed
that
any
reasonable
future
implementations
would
support.
At
least
this
minimal.
M
Current
situation,
so,
for
instance,
we
could
one
validation.
Rule
I
put
up
is
that
we
would
only
allow
variables
to
be
defined
on
fragments
that,
where
they're
actually
used
currently
with
this
like
doesn't
match.
This
is
asymmetrical
with
operation
level,
variable
definitions,
but
it's
more
restrictive.
So
in
the
future
we
could
open
it.
G
The
operation
level
ones
do
that
a
very
similar
validation
rule
right
like
if
you
define
a
variable
and
it's
not
used
transitively
through
any
of
the
fragments.
Then
it
fails.
G
M
G
I
think
I
understand
what
you're
saying
it's
generally
a
good
design
principle.
Yeah
only
allow
the
behavior
that
you
think
is
reasonable
and
restrict
stuff
that
might
be
reasonable,
but
you're
not
sure
about.
I
Me
that,
with
what
you're
proposing
at
the
moment,
especially
with
this,
this
limitation
on
it,
so
that
it
has
the
tight
scope,
this
can
effectively
be
implemented.
As,
like
a
pre
passer
right,
you
can
just
take
the
input.
Query,
rewrite
all
the
variable
and
value
references
throughout
all
the
fragments
that
are
used
in
that
operation
and
then
just
evaluate
it
with
the
current
graphql
js.
M
Yes,
yes,
we
we
absolutely
can
do
that.
The
limitation
we
run
into
is
actually
tooling,
like
you
can't
use
this
in
graphical.
One
of
the
things
that
facebook's
actually
become
relatively
reliant
on
is
prettier,
like
you
can't
have.
Prettier
can't
understand
this.
If
prettier
is
relying
on
a
version
of
graphql
js
that
doesn't
have
this
syntax
available.
M
Additionally,
yvonne
made
the
point
that
even
graphql
js
could
pretty
reasonably
have
an
execution
mode
that
just
like.
Oh
you
get
this
query
text
that
includes
fragment
variables
or
fragment
arguments
just
rewrite
the
text
in
place
to
then
pass
to
the
execute
like
it.
I
from
when
I
made
this
proposal
last
week
to
now.
I,
like
I'm
less
opposed
to
actually
like
allowing
it
to
be
part
of
actual
implementations,
but
yeah.
G
G
If
it
does
exist,
it
should
provide
some
utility.
I
understand
that
the
motivation
here
is
basically
to
make
sure
that
clients
can
provide
this
syntax
directly,
but
we
should
make
sure
that
we
can
actually
define
reasonable
behavior
for
what
this
should
do,
that
is
spec
defined
and
implemented
well,
so
that
we
don't
like
require
a
transform
in
order
to
get
it
to
work
from
what
you're
describing
these
like.
G
They
work
kind
of
like
variables,
but
they
are
locally.
Scoped
is
like
not
totally
crazy.
I
expect
that
the
implementation
of
that
might
be
slightly
more
subtle
than
you
might
think,
and
there's
also
there's
just
like
the
ecosystem
effect
of
this
introduces
a
new
schema,
coordinate
yay,
a
new
thing
on
there
so
like
we
just
have
to
make
sure
that
the
whole
ecosystem
throughout
the
spec
that
this
touches
is
like
accounted
for.
O
K
One
thought
there-
and
this
I
think
kind
of
touches
on
the
previous
proposal
too,
is
like
I
think,
during
the
kind
of
experimentation
phase.
I
could
imagine
it
being
helpful
to
like
have
support
like
again
like
behind
a
flag
in
the
parser
in
graphql
js,
just
to
allow
experimentation
to
actually
iterate
on,
like
the
like
the
rfc,
the
spec
rfc
itself.
Right
like
so.
K
I
agree
with
you
like
having
syntax
in
the
spec
that
has
no
use
feels
like
not
a
state
we
want
to
be
in,
but
having
like
in
the
implementation
in
the
reference
implementation
behind
a
flag,
syntax
that
parses,
that
is
not
spec
yet
as
a
way
to
like
iterate
to
get
to
what
the
spec
for
the
syntax
should
be.
That
feels
like
maybe
a
different
like
level
of
tolerability.
K
So
I'm
just
curious.
If
there's
like
what
do
we
think
about
that?.
G
We've
done
that
before,
and
it
mostly
works,
though
I
don't,
it
doesn't
totally
solve
the
problem
you're
describing
of
like
there's
an
entire
ecosystem
right,
like
you
get
this
as
experimental,
syntax
and
graphql
js
that
doesn't
necessarily
add
it
to
prettier
or
any
of
the
other
tools.
G
My
sense
is
that
you
probably
don't
need
that
much
more
experimentation
on
how
this
should
behave
and
work
beyond
just
like
getting
this
in
a
pull
request.
If
you
do,
then
the
experimental
flag
is,
is
the
right
way
to
do
that.
But
I
know
this
is
something
that
you
all
thought
about
in
the
context
of
relay
for
a
very
long
time,
but
I'm
not
opposed
to
putting
stuff
behind
a
flag
and
making
it
clear
that
it's
an
experimental
addition
that
you
have
to
explicitly
turn
on
in
order
to
operate
with.
G
A
Your
androids
yeah
yeah,
so
like
a
little
bit
of
context,
I
think
like
matt,
it
was
you
who
had
that
like
two
years
ago,
support
in
parcel
behind
the
there
is
it's
worth
state
so
right
now
we
support
variable
definition.
Fragments
will
not
support,
passing
them
through
spreads,
so
it's
like
half
implemented
in
parser
and
to
this
point
about
like
adoption
and
ecosystem,
we
had
it
like
four
years
behind
a
flag
and
like
preachers
not
using
it.
No
like
nobody
using
it.
A
So
what
what
we
discussed
about
and
actually
like
a
month
ago,
like
two
months
ago,
I
asked
you:
can
I
like
rename
the
like
flag
from
experimental
to
to
legacy
so
yeah?
So
I
idea
like
I'm
for
going
full
in
and
like
because
syntax
is
is
like
what
to
change
there
like
just
added
to
parser,
but
for
now
prevent
execution.
So
if
servers
server
get
it
gets
it,
it
doesn't
pass
validation
unless
you
disable
validation
rules,
so
just
to
have
x,
separate,
like
experimental
validation
rules
and
prevent
execution
of
greece.
A
Another
like
point
about
like
execution
like
benj
and
matt,
is
correct.
That,
like
it,
can
be
transformed
either
on
client
or
server
side
problem
with
server
side.
We
kind
of
like
ex
leak
hd
into
resolvers
and
people
actually
use
it
and
we
lick
it
inside,
like
execution
algorithm,
so
like
changing
documents.
A
Currently
is
not
a
good
solution,
but
like
on
the
positive
side
like
we
need
to
to
change
refactor
execution
a
lot
anyway,
since
so
extreme
defer
is
a
big
change
to
execution
how
execution
works
and
like
previous
proposal
about
now
ability
is
also
a
change
in
like
execution.
A
A
If
syntax
is
super
simple
and
non-controversial,
I
would
just
add
it
to
parser
without
and
remove
it
in
breaking
release.
If
we
decide
to
to
change
something
same
thing
about
like
a
bank
and
question
mark
inquiries,
I
don't
think
like.
We
need
like
separate
facts
and
parcel
for
every
feature.
One
thing
I
think,
like
it's
up
to
server
owner
to
decide
if
he
want
to
go
with
queries
to
be
executable,
so
I
like
for
having
for
every
experimental
feature
of
having
validation,
rules
saying
like
yeah.
A
I
don't
want
to
have
stream
and
differ
like
and
enable
by
default,
so
you
need
to
remove
like
experimental
stream
and
default
rule.
You
need
to
do
remove
experimental,
fragment
variables
rule
to
to
enable
it
and
like
one
one
question
about
design,
I
want
to
ask
like
one
thing:
I
I
don't
I
like
everything
about
this
proposal,
except
one
thing
I
actually
didn't
read
the
rsu.
Maybe
you'd
already
address
it.
Potentially,
I
don't
like
if
people
mix
up
like
different
syntaxes.
A
So
if,
if
they
use
like
scoping
in
is
the
same
query,
I
think
like
it
should
be
kind
of
like
binary.
You
either
use
like
explicit,
syntax
or
implicit
syntax,
and
not
both
in
the
same
same
query,
so
it's
the
only
like
issue.
I
see.
M
Yeah,
the
basically
you're
saying
we
should
only
allow
operation
level
or
fragment
level
like
these
explicitly
scoped
variables
or
operation
scope
variables.
I
would
actually
like
I'm
personally,
a
big
fan
to
moving
towards
more
explicitly
scoped,
but
that
would
like
just
from
a
practical
standpoint.
That
would
mean
that
this
feature
is
unavailable
in
every
legacy
like
any
product
that
is
built
with
graphql
today.
G
Yeah,
I
don't
think
we
can
do
that
yeah
or
rather
that's
that's,
probably
the
way
to
make
this
the
least
useful.
It's
probably
not
what
you
want,
and
you
know
this
is
also
not
a
new
idea
right,
like
matt
joe,
and
I
we
talked
about
this
a
long
long
time
ago
and
decided
not
to
include
it
because
of
how
verbose
it
would
get
to
require
that
explicit
scope.
But
I
think
what
you've
proposed
here
is
a
reasonable
balance,
but
yeah.
G
So
I
you
know
to
wrap
this
up,
because
I
know
we've
got
one
more
agenda
item.
I
want
to
make
sure
we
have
time
for
that.
I
think
if
we
need
to
get
an
incremental
version
of
this
implemented
in
order
to
test
some
final
things.
That's
okay,
although
my
suggestion
and
preference
would
be
to
keep
this
in
a
pull
request,
since
we
kind
of
know
what
we're
after
and
then
that'll
give
us
a
place
to
iterate
on
the
execution,
behavior
and
validation
rules
and
all
the
like
ecosystem
effect
of
this.
G
M
I
Yes,
okay,
so
we
raised
a
little
while
ago,
an
issue
with
the
subscription
route
with
double
underscore
type
name,
and
it
turns
out
the
different
graphql
implementations
handle
this
slightly
differently
in
graphql
js.
I
You
can,
or
you
could
validate
a
query
that
had
just
double
underscore
type
name
as
the
only
field
in
a
subscription
root
selection
set,
but
doing
so
would
then
always
result
in
an
error,
because
that
thing
did
not
return
an
async
iterable,
I.e,
a
stream,
so
it
just
doesn't
seem
valid
or
useful
to
do
that,
especially
given
you
can
get
that
answer
from
just
regular
query
introspection
by
saying
what
is
the
schema
subscription
type
name,
so
we
thought
makes
sense
to
just
say
this
isn't
allowed
and
then
in
in
future
we
might
change
what
this
means,
because
subscriptions
are
kind
of
weird
they're,
the
only
part
of
the
graphql
spec.
I
That
only
allows
one
field
in
a
selection
set,
and
that's
kind
of
strange
right,
I
think
ivan.
Was
it
evan?
Sorry?
Was
it
you
that
you'd
said
that
graphql
ruby
implements
this
in
a
different
way
and
you
can
include
type
name
as
well
yeah.
I.
J
Was
just
looking
up
that
comment
that
was
a
couple
months
ago
now,
yeah
yeah,
if
you
put
under
type
name
in
a
subscription
root
in
graphql
ruby,
you
just
get
the
type
name
back
in
all
of
your
subscription
responses,
kind
of
the
way
you
would
sort
of
naively
to
expect
it
to
work.
I
I
We
could
go
the
route
of
allowing
the
dunder
type
name
there,
but
so
far
we've
decided
not
to
whilst
working
on
actually
like
looking
at
integrating
this
into
something.
I
think
I
don't
even
remember
how
I
came
across
it.
I
I
then
realized
that,
of
course,
this
isn't
solved
yet
because
there
are
directives,
we've
got
skip
and
include.
I
So,
even
if
you
only
have
your
one
field,
you
could
still
potentially
skip
or
include
it,
and
we
can't
validate
whether
that
is
done
or
not
at
validation
time,
because
we
don't
yet
know
what
the
variables
are,
because
you
validate
your
your
query
like
once
right,
whereas
you
execute
it
many
times
with
lots
of
different
variables.
I
So
all
of
a
sudden
this
becomes
more
challenging
again.
It
turns
out
graphql.js
just
I
can't
even
remember
what
it
does
at
the
moment,
but
whatever
it
does
is
probably
wrong.
I
It
doesn't
really
make
sense
and
I
think
it
does
allow
invalid
states
to
come
through
the
graphql
spec.
I
think
also
does
this
at
the
moment.
It
just
allows
the
invalid
states
through
and
then
at
runtime,
when
you
try
and
run
the
subscription
operation.
It
then
has
an
assert
in
there
that
checks
that
there
is
only
one
field
and,
if
that's
not
true,
it
will
run
a
it
will
throw
a
runtime
error
which
again
doesn't
feel
quite
right.
I
I
I
am
currently
proposing
that
we
also
forbid
skip
and
include
on
that
route
set
single
field
that
we
allow
yeah
I've
laid
out
in
the
issue
there
like
a
query
that
currently
validates
according
to
the
graphql
spec,
but
then,
depending
on
what
the
variables
are,
is
very
clearly
demonstrably
wrong,
and
you
can
see
that
it
will
be
wrong
as
a
human,
but
the
graphql
spec
and
the
implementations
obviously
can't
see
that
because
they
have
no
way
of
really
evaluating
all
of
those
possibilities
so
yeah.
This
is
my
proposal.
I
Let's
remove
it
also
separate
question
which
is
basically
has
anyone
implemented
anything
along
these
lines
in
the
other
graphql
implementations.
Yet
I
open
the
floor.
A
I
have
a
comment
about
what,
because
actually
like
discover
it
during
the
review
of
your
pr,
so
we
suggested
that
we
as
package
said
you
should
use
correct
fields
algorithm
from
execution
and
you
change
your
pr
to
use
it.
So
during
review
actually
go
inside
and
look
at
it
and
for
me
to
also
look
weird
why
something
from
validation
should
pass
empty
query
variables
or
like
the
code
operation
variables
now
right
after
you
change
so,
and
I
actually
wanted
to
ask
it
on
this
working
group
in
your
agenda.
A
So
it's
kind
of
cool
I
think,
like
I'm,
come
up
with
different
solution
to
a
problem.
So,
like
overlapping
fragments,
validation,
rule
it
just
ignores,
skip
and
include-
and
I
think
it's
like
correct
behavior,
so
validation
is
not
considered-
skip-
include
in
any
way
shape
or
form.
So,
basically,.
A
If
we
already
have
validation,
rule
and
semantics
is
just
to
ignore
skip
include
so
it
can
be
there.
We
just
like
during
validation,
phase
we're
not
looking
at
them,
so
I
think
we
should
do
the
same.
So
if
you
have
two
variables,
two
fields
with
different
names
in
subscription,
even
if
they
have
like
skip
include
in
like
any
combination,
we
just
produce
a
row
because
we
already
do
the
same
for
for
overwatch
and
fragments.
So
I
think
like
we
need
to
do
it
consistently.
I
A
Yes,
so
think,
like
we
have
the
same
thing
with
execution,
we
can
get
empty
object
in
execution
if
we
using
skip
include
like
it's
forbidden
to
have
like
empty
logic
in
response,
but
with
skip
include,
you
can
do
empty
objects.
So
I
don't
like
it's
like
equal,
both
and
exec
in
query
mutation
subscription.
I
So
I
think
one
of
the
interesting
like
lee
raised
the
comment
on
the
the
pull
request
that
effectively
by
locking
this
down,
we
limit
what
we're
doing
now,
which
then
allows
us
to
expand
in
future,
and
I
think
that
is
worth
keeping
in
mind
here.
I
I
don't
really
feel
that
allowing
for
a
an
empty
selection
set
on
the
subscription
route
necessarily
makes
sense.
Like
generally,
you
would
expect
to
get
back
a
a
stream
of
values.
I
I
G
I
think
that's
probably
right.
I
do
think
this
is
an
oversight.
I
think
the
the
proposed
spec
text
here
probably
needs
some
work
and
I'm
happy
to
offer
some
review
for
that
after
the
meeting.
But
the
intended
effect
here,
I
think,
is
the
right
one
it.
I
would
be
incredibly
surprised
if
there's
lots
of
live
examples
of
using
skip
and
include
considering
the
fact
that
we
already
require
a
single
field
to
be
in
use.
G
That
would
be
a
pretty
use,
useless,
skip
or
include
on
your
subscription
request,
and
so
this
is
really
less
about,
like
balancing
between
two
subscription
fields
and
more
about
like
zero
to
one
that
doesn't
seem
all
that
useful.
So
this
is
probably
an
appropriate
restriction
to
apply.
A
A
So
like
right
now,
directives
completely
ignore
through,
like
entire
validation
of
queries.
We
don't
quite
do
anything
with
directives
and
it's
mean,
like
we
create
separate
rule.
That
check
skip
include.
I
We
do
we
do
do
things
like
checking
that
the
you
know,
a
variable
pass
to
a
directive
argument
is
of
the
right
type
and
stuff
like
that,
though
right
yeah
yeah,
but
not.
A
B
J
G
It's
not
a
bad
thought,
though.
I
worry
that
that
might
get
a
little
bit
confusing
to
implement,
maybe
slightly
more
complex,
but
I
think,
like
the
implementation
aside,
the
the
thing
that's
being
proposed
here
would
make
a
lot
of
sense
like
if
you
had
a
skip
directive
there
and
you
got
sent
that
query
and
you
immediately
got
a
validation
rule
that
says
you
can't
do
that.
G
You
might
understand
why
that's
the
case-
and
this
opens
up-
I
think,
like
in
the
future-
we've
talked
about
having
multiple
fields
on
subscriptions
or
or
making
this
a
run
time,
rather
than
validation.
Time
constraint,
we
could
always
start
with
the
runtime
or
start
with
a
validation,
constraint
and
relax
it
to
a
runtime
constraint
later
option
value.
G
So
this
seems
like
the
right
thing.
Yeah
I'll
offer
some
a
bit
of
review
on
the
actual
spec
text
after
meeting-
and
I
know
we're
just
a
few
minutes
over
time,
but
we
did
just
make
it
through
the
entire
agenda
in
almost
exactly
the
right
amount
of
time.
So
amazing
good
work,
everybody
so
I
know
folks
are
starting
to
disappear.
So,
thank
you
all
and
thanks
for
sticking
around
for
five
more
minutes
to
hear
me
say,
thank
you
all
and
I'll
see
everybody
next
month.