►
From YouTube: GraphQL Working Group - November 4, 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).
B
A
Yeah
but
the
the
the
client
controversial
ability
is
really
something
I'm
looking
forward.
B
Yeah,
I
think
that's
a
particularly
interesting
one
very.
A
A
It's
the
it's
I
think
for
apollo
is
also
one
of
the
will
be
also
very
helpful
to
to
manage
these
things,
because
suddenly
the
gateway
can
batch
things
together
and
just
say:
okay,
this
root
field
is
nullable.
So
if
a
merged
query
then
has
a
fault
just
this
one
thing
is
deleted,
so
yeah.
A
B
I
just
filed
a
bunch
of
I've
created
a
bunch
of
github
projects
to
put
the
issues,
the
action
items
from
the
last
few
meetings,
and
I
was
like
I
should.
I
should
go
through
and
file
some
of
those,
and
then
I
realized
what
the
time
was
just
like.
Oh
best
join
the
call,
otherwise
I
know
what
will
happen
I'll
start
doing
that
and
in
half
an
hour's
time
I'll
be
like
oh
whoops.
I
forgot
to
join
the
call,
oh
well.
A
B
Me
and
ivan
have
been
writing
a
talk
for
the
the
apollo
summit
and
we
about
the
the
graphql
spec
and
the
various
contributors
and
stuff
and
yeah.
One
of
the
themes
is
effectively
like
look
at
how
the
number
of
contributors
has
has
changed
and
like
it
took
a
while,
like
when
we
set
up
the
graphql
foundation
for
us
to
start,
like
you
know,
really
making
to
start
really
making
progress.
B
But
you
know
initially,
it
was
like
you
know
it's
pretty
much
lee
lee
was
doing
everything,
and
then
there
was
a
few
like
typo
fixes
or
whatever
from
the
community
and
but
like
no
like
major
features
but
as
as
timers
as
come
on,
and
you
know
the
working
groups
from
meeting
and
stuff,
like
the
advances
that
we've
made
is,
is
much
better
and
it
just
seems
to
be
getting
better
and
better,
which
is
great
like
it's.
It's
snowballing
in
a
good
way.
A
C
Now
I
know
I
want
to
make
toast
hey
everyone.
Is
that
a
a
late
breakfast
alex.
E
C
C
F
C
One
other
thing
I
noticed
wasn't
on
the
agenda:
it's
just.
I
did
notice.
The
pr
has
been
sitting
there
for
a
while
it's
the
draft
pr
about
the
guidelines
for
speaking
on
behalf
of
the
project.
I
don't
know
if
that's
something
we
wanted
to
cover,
but
you
definitely.
H
C
H
G
Let's
get
started,
hey
everybody.
We
in.
G
F
C
H
G
Alrighty
is
that
done
and
without
any
pull
requests
to
merge
at
the
moment,
I
think
we're
ready
to
get
started
so
hello,
everyone
happy
whatever
time
it
is
in
your
neck
of
the
woods.
Welcome
to
yet
another
edition
of
the
graphql
working
group
meeting
happy
to
see
all
your
faces
as
per
usual.
G
We
always
kick
off
with
a
reminder
that
by
being
here,
we
all
agree
to
membership
agreement,
participation,
guidelines
and
code
of
conduct,
there's
links
in
the
agenda
as
per
usual
in
case
you
want
a
reminder
on
any
of
those,
hopefully
not
controversial,
and
let's
go
through
and
just
do
a
quick
names
to
face
introduction.
G
We
will
use
the
order
as
it's
listed
in
the
agenda
doc,
since
everyone
sees
a
slightly
different
order
in
the
zoom
participants
list
and
so
on.
The
top
of
that
list
is
myself
so
hello,
everyone,
my
name
is
lee
and
I
help
run
these
meetings.
B
Hello,
sorry,
hello,
everyone,
my
name
is
benji
and
I'm
taking
notes.
Hence
my
delay
in
notifying
noticing
myself
and
yeah.
I
work
on
the
graphile
projects.
A
Yeah
hi,
I'm
michael
stipe,
I'm
with
chili
cream
and
we
are
working
on
the
graphql.net
implementation
called
hot
chocolate.
D
C
M
I'm
stephen:
I
do
graphql
infra
at
netflix.
N
Adrian
is
a
I
recently
joined
the
amplify
team
here
at
aws
eyes,
shadowing
me
for
today
nice.
I
don't
know
if
your
mic's
working.
G
G
And
I
saw
your
poll
requests
got
to
add
your
name,
but
I
think
there's
a
little
agreement
to
the
guidelines.
G
Piece,
that's
missing,
but
hopefully
once
that's
done
I'll
merge
you
post
talk,
I'm
glad
you're
here,
okay
seems
like
we
might
not
have
to
do
much
for
volunteers
for
note-taking,
because
I
see
both
stephen
and
benji
pencil
themselves
in
the
agenda.
G
Thank
you
both
for
doing
that
always
humongously
appreciated,
and
I
see
there's
already
lots
of
action
happening
in
there,
but
just
a
reminder,
as
steven
or
benji
engages
in
discussion,
if
anybody
else
on
the
call
wants
to
jump
into
those
notes
and
help
pick
up
where
they
left
off,
that
would
be
great.
Excuse
me
greatly
appreciated
all
right.
Let's
take
a
look
at
what
we
have
on
the
plate.
G
For
today
we
will
take
a
look
over
action
items
if
we
in
fact
filed
any
there's
a
good
note
that
we
have
that
open
pr
for
a
while
now
about
guidelines
for
speech,
we
can
take
a
quick
look
at
that
and
see
what
we
want
to
do.
G
Next,
I
want
to
talk
a
little
about
a
little
bit
about
introducing
the
tsc
elections
process,
which
we
are
just
now
at
the
very
beginning,
edge
of
which
is
very
exciting,
and
then
our
one
primary
technical
topic
for
the
day
is
client
control,
nullability,
which
we
can
then
spend
as
much
time
as
we
want
to
on
that,
which
is
very
exciting.
G
Okey-Dokey,
let's
take
a
look
at
these
links
for
action
items.
I
did
not
open
new
ones
benji,
I'm
not
sure
if
you
did
in
the
last
couple
rounds.
B
I
I
filed
one
from
june
literally
like
five
minutes
ago.
I
yeah.
So
basically
I
was
just
looking
through
and
we
haven't
filed
any
since
just
before
june,
so
we're
a
little
bit
behind
on
filing
the
action
items
I'm
gonna
like
since
it
looks
like
we're.
Gonna
have
a
short
meeting
today.
I'm
probably
gonna
spend
the
rest
of
the
time
that
would
have
been
spent
at
the
working
group
just
catching
up
and
filing
all
of
those.
B
So
we
may
end
up
with
quite
a
few
to
sort
through
and
I'm
afraid
I
will
probably
file
ones
that
we've
already
dealt
with.
But
you
know
if
you,
if
you're
tagged
on
one
of
those
and
it's
already
been
dealt
with
just
reply
and
we'll
close
it
at
the
next
working
group.
G
I'm
happy
to
stick
around
too,
so
maybe
we
can
do
that
live
together.
That
way,
if
there's
anything
that's
we
can
do
a
gut
check
if
any
of
our
open
and
closed
that'll
be
fantastic
cool.
Well,
maybe
we
can
take
a
look
at
the
few
that
are
here.
G
I
think
we
have
opening
prs
for
client
level
nullability
that
very
much
happened.
Excellent
work,
there's
a
bunch
of
vrs
that
have
been
opened
on
the
spec
on
the
implementation.
We
even
have
a
document
capturing
all
the
information,
fantastic
work,
I'm
gonna
close
this.
D
Cool,
if
I
have
like
future
updates
on
the
work
I've
been
well,
I've
been
dumping,
it
updates
for
the
work,
and
that,
should
I
put
them
somewhere
else
or.
G
You
feel
free
to
open
new
ones
or
you
know,
there's
it's
better
to
have
your
like
primary
spec
pr
as
the
source
of
truth.
Okay.
So
if
you
want
to
use
that
as
kind
of
a
hub,
if
you
want
to
link
out
to
the
other
pr,
so
it's
a
good
place
to
do
that
or
you
could
also
keep
the
the
doc
that
you
we
just
merged
into
the
the
working
group
repo.
That
could
be
another
useful
source
of
truth.
G
And
that
was
one
that
was
ready
for
review
the
one
that
you
just
opened
was
from
a
while
back
and
this
one,
maybe
we'll
look
at
this
a
little
bit
later.
This
is
about
clarity
on
the
unicode
spec,
which
technically
is
seeing
in
an
approved
state.
It
has
not
been
merged,
yet
it
was
not
part
of
the
last
spec
cut,
so
we
do
still
have
time
to
revisit
details
if
there's
still
a
lack
of
clarity,
so
I
guess
that
one's
opened
on
me
I'll.
Take
a
look
at
that
sometime
soon,.
G
Next
up
is
guidelines
for
speech,
so
we
opened
this
a
number
of
months
ago
back
in
june
as
a
result
of
some
sort
of
craziness.
So
you
know
there's.
This
is
not
an
uncommon
thing
to
see
open
source
projects.
Do
they
stick
a
blm
or
palestine
or
tibet,
or
like
some
sort
of
like
political
moniker
on
the
top
of
their
readme
file
or
something
else.
G
I
think
we
we
realized
that
those
can
be
not
always
like,
broadly
supported
or
considered
good,
and
so
we
want
to
have
some
consistency
around
how
we
do
that
across
all
the
projects
within
graphql.
So
we
don't
have
some
projects
within
the
ownership
of
the
the
graphql
technical
project,
doing
this
in
a
slightly
different
way
than
others
that
was
sort
of
the
impetus
in
the
context
behind
why
this
was
written
up,
it's
written
up
as
part
of
the
tsc
document,
because
who
is
accountable
for
these
things?
G
It
is,
it
is
actually
collectively
us
as
a
working
group
but
like
in
terms
of
who
has
an
actual
like
voting
say
on
it.
It's
the
tsc,
of
course.
Generally.
We
want
to
operate
in
a
consensus
with
all
the
folks
who
join
these
calls,
but
that's
why
it's
here
you
know
the
other
place
where
it
could
have
ended
up.
Is
the
graphql
foundation
board
generally.
G
What
we
try
to
do
is
keep
keep
a
firewall
between
the
foundation
board
and
the
technical
projects,
so
the
foundation
board
doesn't
really
get
a
say
in
how
the
technical
projects
operate
themselves.
They
just
get
a
say
in
how
financial
resources
get
allocated,
and
so
that's
the
reason
why
this
is
here.
G
It's
been
a
little
bit
since
this
went
up.
It
does
have
some
approves
from
some
folks
here,
but
do
you
all
want
to
take
a
minute
just
to
read?
What's
there
there?
There
was,
I
think
the
two
things
are
worth
looking
at
are
the
change
itself
and
then
jay
had
a
thoughtful
comment
here,
which
I
think
is
the
primary
reason
why
we
did
directly
merge
it.
N
G
G
And
and
that
would
yeah
and
then
that
would
give
us
an
opportunity
to
sort
of
look
at
you
know,
what's
what's
sort
of
the
appropriate
like
either
we
decide
that
hey
guidelines
want
to
push
this
to
like
this.
G
Is
your
personal
take,
and
so
you
should
put
it
on
your
personal
space
or
we
broadly
agree
with
the
take,
and
we
want
to
put
it
on
the
project
and
then
we
can
advise
where
so,
if
it,
you
know,
came
from
one
specific
direction
like
so
like
the
the
specific
context
behind
this
one
was
some
palestine
related
political
speech
that
came
via
the
graphical
project.
G
Imagine
a
scenario
in
which
we,
as
a
group
decided
that
that
palestinian
political
pain
was
one
that
we
broadly
all
wanted
to
have
the
graphql
technical
project
advocate
for
then
we
would
look
at
is
the
graphical
project
specifically
the
right
way
to
do
that,
or
should
we
put
it
on
graphql.org
or
like
then
we
could
we
could
kind
of
strategize
exactly
how
we
wanted
to
get
a
message
out
that
we
all
agreed
with
my
intuition
is
broadly.
We
would
probably
not
do
most
of
those
things
with.
G
Maybe
an
exception
of
net
neutrality
or
something
that's
sort
of
like
kind
of
tightly
tied
to
things
that
the
graphql
technical
project
would
principally
care
about.
That's
my
kind
of
personal
take
on
it,
but
that's
the
that's
kind
of
the
mechanics
that
I
anticipate
behind
this.
N
N
But
but
I
guess
my
my
question
was
more
around
the
process,
so
it
sounds.
Let
me
just
summarize
and
make
sure
I
understand
what
you're
envisioning
for
the
process.
Somebody
with
one
of
these
concerns
would
open
an
issue.
You
would
call
an
async
vote
from
the
tf
from
the
tsc
directly
on
the
issue
if
it
can't
be
resolved.
That
way,
we'll
cover
it
in
the
next
tsc
group
meeting
is
that.
L
G
Yeah,
probably
based
on
how
straightforward
it
is
and
how
urgent
it
is.
So
if
it's
like
both
straightforward
and
urgent,
then
we
would
try
to
resolve
it
async
if
it's
straightforward,
but
not
urgent,
then
we
would
take
it
to
a
meeting
to
discuss
it.
Maybe
unless
we
just
happen
to
get
enough
energy
on
thread,
if
it's
neither
straightforward
nor
urgent,
then
clearly
we
would
bring
it
here
and
even
if
it's
urgent
but
like
not
straightforward,
then
maybe
create
some
noise
around
it
and
like
try
to
do
a
one-off
meeting.
L
G
And
generally,
this
is
like
a
little
bit
of
an
aside
we'll
get
to
this
when
I,
when
I
talk
about
tsc
in
the
next
agenda
item,
but
there
there's
like
why
this
is
a
tsc
thing
rather
than
a
working
group
thing
is
purely
just
a
matter
of
like
we
use
the
word
vote
and
therefore,
you
have
to
say
who
gets
to
vote
and
the
tsc
or
the
set
of
folks
here
who
have
a
voting
power.
G
But,
like
generally,
we
want
to
avoid
a
situation
where
the
tsc
members,
as
like
a
subset
of
the
folks
who
come
to
these
working
group
meetings,
have
a
differing
opinion
from
the
collective.
Like
generally,
we
want
to
have
a
case
where
we
roll
with
consensus,
so
I
would
usually
favor
bringing
those
these
kinds
of
things
to
meetings
that
way.
We
can
have
plenty
of
way
in.
L
C
With
this
change,
but
I
do
like
benji's
suggestion
for
the
wording,
though
I
think
that's
great.
B
Lee
after
this
call,
if
you
can
go
through
with
me,
the
notes
that
I've
taken
on
this
and
just
make
sure
that
I'm
quoting
things
correctly,
because
I
imagine
this
is
actually
notes
that
may
well
be
referenced.
Quite
you
know
precisely.
G
G
Yes,
I'm
happy
to
do
that.
I
did
just
add.
Benji's
suggested
change.
I
agree,
that's
a
good
one,
just
clear
it
clarifies
what's
there.
I
think,
probably
the
open
question.
The
reason
why
I
didn't
just
kind
of
merge
this,
as
is
even
though
there
were
some
approvals,
is
there's
a
couple
open
questions
here.
G
One
is-
and
this
is,
I
think,
more,
a
matter
of
tone
rather
than
an
actual,
like
policy
change
gets
to
jay's
comment
here,
which
is-
and
I
think,
like
my
intuition
is
probably
most
of
the
people
here-
would
support
jay's
pitch
that
if
we
want
the
graphql
technical
project
to
remain
generally
politically
neutral,
then
maybe
we
want
to
word
this
in
a
way
that,
like
kind
of
makes
that
explicit
or
we
kind
of
say,
like
you
know,
we
don't
we
don't
anticipate
doing
these-
I
kind
of
intentionally
framed
it
as
just
like
mechanics
only
without
an
opinion.
G
We
only
allow
this
with
tsc
vote
but
like
if
the
tse
happens
to
broadly
share
the
opinion
that
jay
is
framing
here
then,
like
that's
the
opinion,
that's
going
to
apply
rather
than
applying
that
opinion
in
like
the
the
tsc
rule
stock,
because
I
don't
know
there
could
be
a
future
where
the
tse
disagrees
with
that.
So,
but
I
I
I
get
the
take
that
it
might
not
come
across
as
this
being
an
opinion
that
many
folks
here
might
agree
with.
G
If
you
read
that,
as
is,
it
sounds
like
maybe
an
invitation
to
submit
recommendations
to
add
political
speech,
and
I
don't
think
that's
what
we're
intending
here,
but
anyway,
I'm
curious.
If
anyone
has
an
opinion
on
that,
if
it
sounds
good
as
it
is,
or
we
should
alter
it
in
some
way
to
add
the
like
politically
neutral
opinion
or
if
that
would
be
too
strong.
H
J
J
If
it
becomes
a
problem
where
we
start
seeing
like
many
people
like
it's
a
like,
oh,
this
is
something
we
need
to
vote
on
every
month
because
somebody's
bringing
like
a
new
political
opinion
and
asking
the
tsc
to
like
deal
with
it.
Then.
Yes,
we
probably
would
but
this
given
that
we
want
this
to
be
as
long
lived,
a
like
policy.
J
There
are
a
myriad
of
future
worlds.
Where
who
knows
like
what
situation
the
tf,
the
like
graphql
spec,
would
find
itself
in,
and
it's
like,
I
think,
starting
from
a
place
of
seeming
neutrality
offers
like
the
easiest
paths,
even
if
the
current
like
situation
is,
and
I'm
fairly
certain
that
there
is
nothing
like
immediately
obvious
that
I,
besides
maybe
net
neutrality,
but
even
that
I'm
unclear
that,
like
people,
would
be
able
to
form
a
consensus
around
right
now.
G
Yeah,
I
generally
share
that
yeah.
I
I
intentionally
left
it
mechanics
only
for
now,
because
I
know
this
is
a
little
bit
of
a
lightning
rod
thing.
I
also
kind
of
want
to
avoid
making
too
tall
of
a
lightning
rod
in
the
scenario
where
it's
like,
even
though
we're
not
really
saying
anything
other
than
that
we
we
kind
of
only
want
to
use
our
collective
voice
for
cases
that
are
kind
of
tightly
tied
to
the
graphql
community
or
project
directly.
G
That's
that's
the
primary
reason
why
we
wouldn't
like
an
alternative
to
this
change
would
be
one
where
we
just
blanket
ban
where
we
don't
even
say
tsc
vote.
We
just
say,
like
the
project
doesn't
do
this,
and
if
you
want
to
do
this,
you
do
it
in
your
own
space
like
that
would
be
an
alternative,
but
yeah
I
wouldn't
want
to
rule
out.
G
I
don't
know,
maybe
someone's
going
to
change
the
structure
of
how
open
source
works
or
there'll
be
some
like
major
legal
battle
between
some
major
tech
giants,
that
all
of
a
sudden
make
the
mit
license
mean
something
different
and
it
would
be
kind
of
terrifying,
and
we
might
want
to
have
an
opinion
in
that.
I
can.
I
can
conceptualize
some
world
where,
where
we
actually
would
be
really
incentivized
as
a
group
to
weigh
in,
but
that's
that's
kind
of
the
reason
why
the
mechanic
is
set
up.
M
J
G
G
It's
like
you,
don't
it's
like
we,
you
say
we
don't
do
it
until
we
do
it's
like
meaningfully.
That
is
exactly
the
same
thing
right
like
meaningfully.
That
just
means
should
a
scenario
occur.
We
want
to
weigh
in
on
something
political.
We
would
vote
on
it
and
it's
like
either
it's
about
changing
the
rules
about
not
doing
that
to
allow
this
one
case
or
it's
about
like
bringing
it
up
and
knowing
that
we
would
vote
on
that
to
then
support
that
case.
So
I
think,
like
the
mechanic
is
still
the
same.
G
My
sense
is
that
the
major
difference
is
like.
Do
we
want
to
formally
define
a
principle
that
we
write
down
that
says
the
graphql
technical
project
remains
politically
neutral.
Unless
such
a
political
topic
directly
affects
the
project
or
its
immediate
community's
ability
to
function
normally
and
it's
like.
Do
we
want
to
explicitly
state
that,
or
is
it
even
like
that,
might
the
trade-off?
There
is
like
one
that
gives
us
a
long-lived
thing
to
point
to
and
say
this
is
how
we
like
to
to
think
about
this.
G
The
con
is
that
that
itself
could
be
a
political
rod
or
misinterpreted,
and
so
I
wonder
if
it's
like
better
left
as
like
a
shared
opinion,
rather
than
something
simply
write
down
anyway.
That
was
my
my
last
trepidation
around
this.
M
G
Let's
see,
I
want
to
make
sure
that
we
move
past
this,
so
here's
what
I'll
do.
I
will
raise
up
like
an
amendment
to
this
that
adds
that
principle
and
we
can
just
take
like
an
offline
weigh
in
on
it
on
the
issue.
G
That'll
be
good
action.
I
don't
think
we're
in
a
huge
rush
to
like
merging
this
or
not
merging.
This
doesn't
meaningfully
change
it.
You
know,
I
think,
we're
basically
operating
in
this
model
now,
but
getting
it
right
before
we
merge,
it
seems
worth
doing
so.
Let's
do
that,
but
I'm
glad
we
took
a
look
at
this
that
very
helpful
clarifying
discussion,
and
now
we
know
where
to
go
next,
so
good
suggestion.
G
Okay,
let's
move
on
next
topic,
tsc
elections.
This
is
exciting,
so
I
wrote
up
a
whole
big
write-up
in
that
dsc
elections,
issue
that
if
you
haven't
taken
a
look
at
that,
please
feel
free
to
do
that.
I'll.
Give
you
the
tl,
dr,
so
the
high
level
is.
The
technical
steering
committee
is
a
set
of
folks
who
many
of
which
regularly
attend
these
meetings,
some
of
which
only
semi
attend
these
meetings.
G
But
everybody
on
this
list
has
some
sort
of
historical
tie
where
everybody
who's
the
current
tse
seat.
Member
has
a
historical
tie
to
the
graphql
project
in
some
important
way.
G
The
tsc
lets
us
have
anything
that
needs
formal
votes
that
basically
that's
the
primary
the
primary
value
that
having
the
tc
offers.
It
also
gives
us
a
firm
set
of
people
that
we
can
give
admin
rights
to
things
so
tsc
members
have
maintenance
control
over
all
of
github,
and
things
like
that
basically
means
that
I
don't
become
a
single
point
of
failure.
G
G
In
order
to
set
that
up,
I
made
a
digital
coin
flipper
and
decided
who
would
get
what
and
then
the
tfc
doctor
is
actually
a
link
to
that
code.
So
you
know
that
I
didn't
just
arbitrarily
decide
that
myself,
and
so
with
that
means
that
the
end
of
the
year,
five
folks,
three
of
which
are
here
today-
benji,
yvonne
and
matt,
but
in
addition
to
that,
brielle
and
james
terms
will
end.
There's
there's
no
rule
about
you
know
maximum
number
of
terms.
G
G
And
so,
if
you
are
interested,
please
fill
out
that
form
at
the
end
of
the
month
we
will
close
the
nominations
and
the
remaining
five
tsc
members
plus
myself,
we'll
do
a
vote
we'll
do
the
conquer
set
model
which
is
sort
of
the
ranked
choice,
style
vote
and
then,
at
the
end
of
the
year,
we'll
we'll
know
who
those
five
folks
will
be.
Some
seats
may
stay
the
same.
Some
seats
may
take
new
new
faces
and
that's
what's
happening
there.
G
So
that's
a
high
level
overview,
no
immediate
action
here
other
than
if
you're
interested,
please
fill
out
the
form,
but
I
wanted
to
just
kind
of
get
it
on
the
agenda
here,
one
to
make
sure
everyone
is
aware,
but
to
in
case
anybody
had
any
questions
that
I
could
answer
them.
C
Amy
there's
a
lot
of
there's
a
lot
of
documentation
around
it
and
I
think
it's
all
really
good.
Actually,
it's
very
thorough
thanks.
G
I'll
I'll
give
a
major
hat
tip
to
brian
warner,
who
helped
craft
that,
as
I
think
actually
ours
is,
is
probably
like.
The
newest
version
of
this,
but
brian
is
the
the
pm
for
a
couple
other
foundations
as
well
and
sort
of
learned
lessons
from
what
worked
and
didn't
work
at
those
places
and
helping
us
craft
this
one.
G
G
We
actually
took
out
self
nomination
or
sorry
only
self
nomination.
So
if
you
can't
nominate
somebody
else,
you
can
go
bug
them.
If
you
think
that
they
should,
they
should
do
this
and
have
them
do
it,
but
I
actually.
L
G
L
G
Something
if
they
didn't
submit
the
form
themselves,
then,
like
that's,
not
really
a
great
sign
that
they
would
be
interested
and
if
they
end
up
getting
voted
in,
then
you
don't
have
an
engaged
person.
So
but
yes,
yeah
yeah,
if
you,
if
you
are
a
current
seat
member
and
you
want
to
just
gracefully
yield,
your
seat,
then
feel
free
to
ignore
the
form.
If
you
do
want
to
be
considered
for
the
the
next
term,
then
yeah,
please
fill
the
form
out
again.
B
I
had
someone
reach
out
to
me
and
ask
like
what
sort
of
involved
as
being
part
of
the
tsc,
which
I
obviously
did
the
best
I
could
to
answer,
but
I
was
wondering
if
you
know
one
of
the
questions
was
specifically
like
what
are
the
time
commitments
and
other
such
things,
and
I
pointed
them
to
your
your
helpful
list
of,
like
you
know,
as
a
minimum
be
available
to
vote.
You
know
whatever
there
there's
there's
not
really
concrete
time
commitments
really.
Is
there
like
it's
it's
best?
G
Like
right,
we
do
have
a
a
guideline
in
the
tsc
dock
that
describes
how
voting
works
and
I'm
actually
a
little
nervous
about
whether
we
will
be
required
to
enforce
it
or
not,
because
I
think
some
of
the
folks
who
are
not
up
for
election
this
time
around
and
therefore
will
be
voting
members
or
folks
that
either
can't
or
don't
regularly
attend
this
meeting
and
therefore
by
the
rules
their
voting
power
may
be
revoked.
G
G
The
idea
is
that
we
ideally
want
to
have
folks
who
are
semi-regularly
engaged
like
you're
not
required
to
attend
every
meeting,
but
attending
a
majority
will
retain
your
your
voting
writes
that's
the
minimum,
and
so
I
guess,
what's
that
minimum
a
couple
hours
a
month,
but
ideally
you
know
like
the
doing
the
voting
is
one,
but
the
other
piece
is
removing
myself.
G
As
a
single
point
of
failure,
so
if
you
know
picking
up
some
of
the
admin
responsibilities
and
and
helping
make
sure
that,
as
you
know,
spec
prs
are
going
up
and
around
that
we
kind
of
keep
on
top
of
them,
and
hopefully
that's
something.
G
That's
like
not
it's
not
limited
to
a
tsc
member,
but
if
something
is
falling
behind,
then
I
will
probably
look
to
the
tse
to
ask
for
help
before
I
look
to
this
whole
group
to
ask
for
help
so
sort
of
volunteering
is
a
way
to
say
that
you're
you're
kind
of
excited
to
have
that
kind
of
impact
on
the
project.
G
B
B
On
the
replay,
because
annoyingly
my
my
video
cut,
my
zoom
crashed,
but
there.
C
We
go,
oh,
no,
that's
why
we
have
video-
I
I
I
will
say,
as
an
outsider,
not
part
of
the
tsc,
just
keeping
an
eye
on
the
working
group
meetings
and
all
that
fun
stuff
over
time
that
it's
really
great
to
see.
Tsc
members
attend
this
meeting
it.
It
really
puts
out
a
good
signal
that
the
people
that
are
helping
steer
the
direction
of
the
graphql
spec
overall
are
taking
the
time
out
of
their
busy
schedules
to
attend
these
meetings
because
they
care.
I
know
it's.
G
Definitely
encouraged
and
it's
a
little
bit
of
to
be
honest,
a
little
bit
of
a
delicate
line
to
walk,
because
another
approach
here
could
have
been
to
not
really
advertise
this
much
and
except
for
this
group
like
we
meet
here
and
I
say,
hey,
which,
among
this
crew,
would
like
to
be
a
tse
member.
G
That
runs
the
risk
of
creating
kind
of
an
insular
community
and
a
number
of
the
tc
members
who
don't
regularly
attend
it's
unfortunate
I'd
like
for
them
to
attend,
but
they
do
offer
a
perspective.
That's
different
than
the
set
of
folks
who
are
regularly
here.
So
like
one
of
the
things
that
I'm
kind
of
constantly
thinking
about
is
how
do
we
make
sure
that
the
folks
who
come
to
this
meeting
is
is
constantly
diversified
and
we
get
new
faces
in
on
the
regular,
which
I
I
think
we
do.
G
We
do
get
new
faces.
There's
definitely
like
a
core
set
of
folks,
which
is
excellent,
but
I
would
love
for
that
to
happen
even
more.
I
think
that
would
be
a
sign
of
a
healthy
community,
and
so
if
we
do
have
some
tsc
members
who
take
interest
and
are
are
helpful,
active
members
who
don't
show
up
via
this
group
but
show
up
somewhere
else,
but
then
are
encouraged
to
show
up
here.
That
will
be
another
tool
that
we
can
use
to
keep
this
group
diversified.
G
So
that's
something
I
have
on
my
mind
but
yeah.
I
I
do
want
to
make
sure
that
we
encourage
those
folks
to
join
here.
There
was
also
you
know,
just
a
little
more
context
on
the
initial
framing
of
the
tsc.
There's
brian
actually
suggested
having
a
separate
monthly
tsc
call
that
was
purely
the
tse
members.
G
I
pushed
back
against
that
so
that
you
know,
one
of
the
things
I
don't
want
to
do
is
create
a
firewall
between
things
that
the
tsa
has
up
for
discussion
versus
things
that
the
rest
of
the
working
group
has
up
for
discussion
and
so
like
the
first
few
minutes
of
this
meeting
by
the
rules
is
the
tsc
meeting
and
we
just
kind
of
front
loaded
the
agenda
and
then
that
keeps
us
from
falling
down
that
path,
but
alex.
D
G
It
basically
boils
down
to
just
like.
If
you
sit
through
the
majority
of
these
meetings,
then
you
accumulate
that
because
the
the
idea
with
any
of
these
major
changes
is
that
we
get
broad
consensus
and
not
just
tsc
consensus.
G
So
if
we
do
want
to
take
a
vote
on
whether
to
move
something
forward,
then
we
can
lean
on
the
tse
in
practice.
We
actually
don't
usually
do
that
in
practice.
We
look
for
consensus
among
the
people
who
are
on
a
call
and
if
there's
any
significant
dissent,
then
we
wait
and
it's
part
of
the
reason
why
things
take
a
while,
but
it's
better
to
have
broad
consensus
to
move
things
forward
than
it
is
to
like,
have
divergence
and
have
to
have
a
tsc.
G
Take
a
majority
vote,
because,
presumably,
if
there's
disagreement,
then
the
community
broader
community
at
large
would
have
to
use
this
stuff
might
also
be
split
and
like
that's
not
something
that
we
want
to
do
so.
Certainly,
I
think,
like
keeping
abreast
of
what's
going
on
in
the
technical
project.
Is
another
reasonable
sort
of
like
minimum
requirement
and
attending
here
will
get
you
all
of
that,
but
not
the
only
way
to
do
it.
G
Which
is
what
I
do
more
than
I
probably
should
any
other
questions
about
the
tsc
process.
G
Cool
that
was
actually
really
helpful
questions.
Thank
you.
Okay,
with
that
alex
I'll
hand,
it
to
you,
tell
us,
what's
up
with
client,
controlled
nullability.
D
Yeah,
so
the
the
human
readable
written
proposal,
one
page
doc
thing
was-
was
was
merged
earlier.
So
that's
in
the
working
group
repo
there
are
pr's
up
for
this
spec
changes
and
also
a
graphql.js
implementation.
D
Looking
for
reviews
on
on
on
both
those
yeah,
I
got
questions
about
that
later
and
then
young,
who
used
to
be
at
netflix
at
square
now
he's
been
helping
us
do
an
implementation
or
an
integration
with
the
guilds
code
generator.
So
he's
been
working
on
that.
So
we
should
have
that
soon.
D
Yeah.
As
far
as
reviews
are
there
any
people,
it's
like
essential
to
get
reviews
from
is
like
the
volume
of
reviews.
Important.
If
I
go
and
like
ask
a
bunch
of
people
to
review
it,
is
that
helpful.
G
I
think
that
is
helpful.
I
think
you
probably
want,
and
actually
this
might
be
something
that's
worth,
including
on
that
that
main
issue,
I
see
you
linked
out
to
like
some
google
docs
but
like
having
something
where
you
can
keep
a
running
list
of
open
questions
and
their
their
state.
That
way,
someone
who's
reviewing
this
kind
of
knows
what
you
have
up,
that
you
consider
like
near
complete
and
what
you
have
up,
that
you
know
that
there
are.
G
There
are
already
sort
of
like
open
discussion
threads
around
so,
like
I
know
the
last
time
this
came
through,
we
talked
about
when
you
have,
when
the
type
on
the
field
in
the
schema
is
more
complicated
than
just
whether
it's
null
or
not
null.
But
it's
like
non-null
of
a
list
of
non-nulls.
It's
like
you
is
there
a
way
that
you
can
reach
into
that
list
and
and
affect
the
null
ability
of
the
items
within
that
as
well.
G
So,
like
that's
one
case
and
then
the
other
is
the
set
of
things
where
there
are
unknowns,
where
implementations
will
help
and
making
sure
that
we
get
reviews
on
those
particularly,
I
think
the
code
review
one
sorry,
the
code
generator
one
is
going
to
be
very
interesting
to
see,
because
I
know
that
was
a
concern
is:
will
this
make
code
generation
significantly
more
complicated
and
so
like
having
having
a
prototype
of
that
up
and
running,
I
think
is
gonna
be
very
impactful.
I
don't
know.
G
K
To
look
at
the
implementations
that
are
up
so
far,
but
definitely
our
code
generation
does
already
handle
the
sort
of
similar
behaviors.
So
I
don't
anticipate
it'll
be
overly
complicated
for
us.
J
The
one
thing
for
relay
is
whether
this
for
relay
means
the
exact
same
as
like
what
really
already
has
the
like
at
required,
or
whether
this
mean,
in
which
case
for
relay
this
means.
The
server
will
never
see
these
query
level
nullability
things
because
it'll
get
compiled
away
and
be
like
a
client
only
consideration,
or
whether
it's
like
something
special
that
relay
continues
to
pass
to
the
server
that
then
gets
like
fed
back.
K
Our
our
intention,
or
our
expectation,
is
that
we
are
going
to
continue
to
present
the
facade
that
these
are
scope
to
the
fragment
and
that
you
may
have
multiple
different
fragments
with
different
notions
of
their
like
nullability,
which
requires
us
to
at
least
never
send
conflicting
information
to
the
server.
So
we
could,
in
theory,
if
all
fragments
had
the
same
knowability
decide
to
send
that
to
the
server.
But
my
guess
is
that's
a
small
enough
case
that
we
wouldn't
bother
to
do
it.
G
I'm
thinking
of
so
I
know
relay
for
a
long
time
has
had
non-nala
required
or
some
version
of
that
as
either
an
experiment
or
something
that's
shipped.
I
don't
know
if
there
was
the
opposite
just
because
there
isn't
a
way
to
do
that.
Client
side
like
if
there
is
a
field-
and
maybe
this
is
irrelevant,
because
facebook's
internal
server
doesn't
have
that
many
examples
of
non-nulls
but
having
something
that
could
error
and
will
bubble
because
it's
not
null
to
be
able
to
say
no.
G
Actually,
I
want
to
catch
the
error
at
this
place
and
and
nulling
it
here
is
okay,
that's
something
that
you
can't
do
client-side
right,
but
this
proposal
would
then
allow
you
to
do
that
if
you
pass
it
through
to
the
server.
A
This
so
what
I'm
looking
at
is
also
schema
stitching
where
you
then
can,
when
you
aggregate
the
queries
to
a
downstream
service,
you
essentially
can
merge
multiple
requests
into
one
query
and
then
make
the
root
fields
of
this
merge
query,
nullable,
so
that
you
don't
lose
information.
If
one
of
the
fields
have
has
an
error.
D
That's
a
cool
idea
back
when
we
were
first
working
on
this.
We
we
did
get
an
integration.
We
we
integrated
into
apollo's
command
line
tool
which
relies
on
on
graphql.js,
and
we
didn't
test
it
very
hard,
but
codegen
like
it
seemed
to
generate
what
we
wanted
pretty
much
out
of
the
box.
We
we
want
to
make
sure
things
like
combining
the
the
required.
D
You
know
the
exclamation
point
and
and
skip
doesn't,
do
anything
wacky,
because
I
don't
know
that
interaction
could
be
nonsensical,
but
otherwise,
I
think
we're
in
a
we're
in
a
good
position.
I
think
it's
it's
more
the
smart
clients,
especially
the
ones
that
rely
on
their
caches
a
lot
are
gonna,
have
to
do
some
work
to
work
around
some
of
this
stuff.
G
Yeah,
it
would
be
great
to
see
us
list
out
what
are
all
the
things
that
are
potential
questions
and
then,
even
if
they
once
you
think
about
them,
hard
are
easily
resolved
like
great.
Then
then
we
just
end
up
building
an
faq
kind
of
block,
because
presumably
people
have
similar
kind
of
questions
so,
like
the
one
that
you
just
framed,
should
skip
and
include
interact
with
this
in
some
weird
way.
G
My
intuition
is
that
they
do,
even
though
they
are
in
a
similar
domain.
It's
like
the
thing
is,
is
or
isn't
there
it's
like
they're
the
way
in
which
they
do.
That
is
different
enough,
that
they
probably
shouldn't
interact,
but
I'd
love
to
know
that
that's
confirmed,
you
know,
see
some
test
cases
that
prove
that
and
then
have
an
faq
that
states.
It.
K
I'll
just
raise
from
the
relay
side
is,
of
course
we
have.
We
have
three
flavors
of
this.
We
have
one
which
does
the
behavior
defined
in
the
spec
or
the
proposal,
and
one
which
just
does
that
same
thing,
but
also
logs
it
as
like.
Oh
there's,
something
suspicious
is
going
on
here.
Someone
should
follow
up
and
one
which
actively
throws.
We
anticipate
that
we're
going
to
continue
to
use
a
directive
for
the
the
behaviors
that
don't
match
this
proposal.
K
K
What
expect
here
so
throw
behavior
makes
sense,
really
mostly
in
in
react
where
we
have
this
concept
of
arrow
boundaries,
so
throw
throws
at
read
time.
So
when
you
go
to
render
a
component
that
reads
out
a
required
field,
it
will
throw
and
will
blow
up
that
component
up
to
its
parent
error
boundary.
So
it's
like
idiomatically
makes
sense
in
a
react
world,
but
I
don't
think
is
generally
applicable
like
outside
of
react.
Matt.
J
So
so
alex
I
actually
had
somewhat
similar
questions
and
I
read
the
spec
pr.
The
most
recent
spec
vr
alex,
I
think,
can
basically
I
think
that
this
could
compose
with
realized
behavior,
because
there
is
like
when
you,
if
name,
is
in
fact
null.
It
becomes
an
error
in
the
like
errors
path,
in
which
case
a
like
relay
style
at
required.
That
says,
oh
treat,
the
parent
as
null
when
it
hits
that
null.
Can
you
know
bubble
up,
it
can
say,
oh
bubble,
that
up
when
it
hits
the
when
it
hits.
J
H
J
G
Sure
I
wonder
if
that's
like,
if
that's
a
90,
would
you
flip
it?
Would
you
say
like
if
you
see
an
exclamation
point
on
a
field?
You
interpret
that
as
don't
render
the
component
and
throw
it
to
an
air
boundary
unless
there's
some
directive
that
says
just
like
you
know
bubble
this
up
to
the
I
don't
even
know
what
you
would
call
that,
but
if
yeah
that's
90.
K
D
Yeah,
I
I
I
linked
the
doc
we
were
talking
about
in
the
in
the
zoom
chat.
The
the
other
things
here
are
our
are
being
able
to
customize
behavior
like
like
what
really
is
doing.
I
don't
think
we
have
a
very
good
upgrade
path
for
that
right
now,
like
I
think
the
upgraded
path
for
being
able
to
mark
like
list
items
required
is
doable.
It's
pretty
pretty.
I
mean
not
straightforward,
but
it's
doable.
D
I
don't
know
what
what
an
upgrade
path
for
more
customization
look
like
and
then
the
other
thing
in
here
I
have
is
caching,
it's
it's
outside
the
scope
of
of
this
proposal,
because
it's
it's
all
gonna
be
client-side,
but
I'd
like
to
have,
you
know,
be
able
to
give
people
some
idea
of
of
how
that's
going
to
work.
J
D
G
Yeah,
that's
not
crazy,
I
can
see
it,
you
know,
would
you
probably
still
like?
If
it's
a,
I
guess
you
could
decide
whether
or
not
you
wanted
to
pass
a
partial
result
through
to
be
used
by
a
component
or
ui
or
whatever
it's
going
to
use
the
data,
but
skipping
cache
for
something
that
is
not
complete
seems
smart,
otherwise,.
H
J
Just
as
that
might
not
make
sense.
J
J
G
G
If
you
have
something
marked
exclamation
point
that
comes
back
null
or
you
explicitly
have
to
have
a
question
mark
operator
somewhere
higher
up,
so
it's
kind
of
like
a
java
or
javascript
style,
try
catch
or
throw
catch
kind
of
mechanic,
but
if
it's
purely
a
client-side
mechanic
like
that
idea
of,
if
the
errors
field
has
anything
in
it,
then
just
throw
the
whole
thing
out
like
that's.
That's
the
third
variant
right.
K
K
The
exclamation
mark
is
like
this
is
an
assert
and
the
question
mark
is
like
this
is
nullable,
and
then
you
can
like
use
those
together,
but
I
do
think
that
the
the
throw
variant
doesn't
make
sense
on
the
server
as
much
because
it's
so
destructive
it's
destructive
enough
on
the
client,
and
it's
only
mitigated
by
the
fact
that
this
is
like
that
we
have
these
error.
Boundaries.
Contracts
didn't
react,
but
it
just
feels
exceptionally
heavy-handed
in
the
response
to
me.
G
That
maps
well
to
other
conversations.
I've
had
around
this
one
interesting
context:
we're
works,
exploring
a
particular
install
graphql
at
robinhood
and
the
the
primary
problem
that's
been
raised.
That's
been
brought
up
right
now
is
actually
the
air
boundaries
thing,
so
it's
not
even
about
hey.
This
could
be
null
on
the
server,
and
I
want
to
enforce
that.
I
have
data
on
the
client.
It's
what
happens
if
something
blows
up
and
a
part
of
the
the
response
is
is
gone.
I
want
the
ability
to
say
that's.
G
Okay,
like
please,
stop
blowing
things
up
at
this
point,
and
it's
okay.
If
that
requires
my
client
side
to
be
required
to
handle
the
null
case
and,
and
so
like,
it's
actually,
it's
like
the
opposite
of
the
the
intent
for
this
original
proposal.
G
M
Up
steven,
you
know
when,
when
we
before
we
implemented
this
at
netflix,
we
considered
you
know
some
different
options
and
one
of
them
was
a
it's.
M
You
know,
admittedly,
kind
of
a
more
drastic
approach,
but
basically
on
on
the
server
side,
allowing
to
change
the
semantics
slightly
of
non-null
to
to
signify
that
you're,
indicating
that
this
thing
should,
like
semantically,
be
nullable
or
not,
and
and
so
then
you
know
concretely
what
that
means
is
that
if
it
is
ever
returned
null,
there
will
be
an
error
present
in
the
errors
array
and,
and
so
that
allows
you
know,
clients
that
you
know
choose
to
just
explode
on
errors
being
present
to
to
go
ahead,
and
you
know
bubble
that
up,
but
it
also
allows
clients
that
choose
to.
M
You
know
accept
partial
results
to
to
do
that,
and
but
you
know
the
main
challenge
there
is.
That
kind
of
you
know
it's
hard
to
make
is
backward
compatible.
It's
like
you
need
to.
You
know,
make
like
a
strict
mode
or
something,
and
and
also
if
you're,
going
to
take
that
approach.
Probably
you'd
want,
in
practice
to
to
invert
semantics
and
use
like
a
question
mark
in
the
schema
to
say
that
you
know
most
things
aren't
shouldn't.
M
You
know
like
aren't
intended
to
actually
have
null
be
a
significant
value,
and
then
occasionally
it's
a
you
know
it's
a
maybe
and
that's
you
know.
An
intentional
thing
is
that
is
that
or
something
we'd
consider
like
adding
a
maybe
to
the
sdo.
G
I
mean
I,
I
can
see
an
alternate
reality.
I
I
agree.
We
can't
really
do
this
because
it
would
be
way
too
breaking,
but
had
this
concept
and
proposal
been
raised
long
long
ago,
like
before
the
the
type
system
itself
was
really
solidified,
then
like
I'm
talking
like
2013
2014,
then
you
know,
maybe
maybe
it
wouldn't
make
sense
to
say
everything
on
the
server
is
assumed
to
not
include
null
as
a
valid
response
unless
explicitly
described.
G
As
such,
I
mean
the
main
reason
why
we
considered
it
and
explicitly
decided
not
to
do
that
just
because
of
the
blow
up
problem
you
get
one
thing
down
the
tail
that
someone
just
assumed
would
always
be
a
string,
but
like
actually
in
fact
it's
string
or
null,
and
then
you
go
ship
and
then
it
turns
out
that
thing
blows
up
all
the
time
and
it
blows
up
the
entire
query
and
now
you've
like
shipped
like
a
showstopper
bug,
and
we
thought
that
was
like
way
too
big
of
a
foot
gun.
G
But
if
your
client
language
had
the
ability
to
say,
like
I
explicitly
put
air
boundaries
in
my
queries
and
here's
where
I
put
them
and
then
I
think
maybe
that
would
have
been
a
more
viable
reality,
but
I
think
we
are
where
we
are
with
the
type
of
system
fields.
Fields
will
be
nullable
unless
sparked
non-null.
I
think
that's
probably
I
yeah
the
idea
of
introducing
strict
mode,
seeing
how
well
strict
mode
went
for
every
other
language.
G
That's
tried
to
do
something
like
that
makes
me
shudder
so,
but
the
but
the
I
think,
the
semantics
that
you
described
for
the
query
language
are
the
ones
that
we
have
unless
they
misunderstood
something
right
where
you
mark
something
with
exclamation
point
that
that
will
that
should
still
introduce
an
error
into
the
errors.
Log
that
that
behavior,
I
think,
is
I
don't
know
if
it's
explicitly
stated.
I
think
it's
emergent.
G
Maybe
it
makes
sense
to
explicitly
state
it,
but
if
right
now
the
way
the
spectex
reads
is
you
take
the
field
type
off
the
field?
G
And
then
you
modify
it
by
applying
your
question
marks
and
exclamation
points,
and
then
that
ends
up
being
the
type
that
you
assume
that
the
field
is
when
you
go,
do
execution
and
value
completion
and
all
of
that,
and
so,
if
that's
a
non-null
type
and
then
you
end
up
with
the
null
value,
you
say:
hey,
that's
not
allowed,
that's
an
error
and
you
that
gets
logged
into
errors
field
before
the
rest
of
the
behavior
occurs.
So
I
do
think
that
behavior,
at
least,
is
the
same.
G
K
So
that
that
just
makes
me
question
like
is
this
another
like
potential
decision
where
clients
might
choose
like
similar
to
what
relay?
Would
I
ideally
want
to
do
to
have
this
like
throw
throws
to
semantic
like?
Is
that
a
place
where
there
might
be
a
larger
population
of
clients?
Who
would
want
that
behavior?
G
The
whole
sort
of
like
the
whole
work
that
has
been
happening
around
defining
errors
within
your
domain,
like
don't
rely
on
errors
getting
bubbled
through
the
errors
like
if
there's
something
that
could
go
wrong.
That's
part
of
your
domain
then
map
it.
There,
like
sasha's,
done
a
ton
of
work
in
that
space.
G
L
G
G
Is
that
already
the
case,
though,
because
there
are
like,
if
you
have
a
field,
that's
not
null
that
and
at
run
time
you
get
a
null,
but
I
guess
I
see
what
you're
saying
like
there's
what
we're
doing
in
in
the
scenario
where
your
schema
defines
something
is
non-null
and
then
under
the
hood.
G
A
null
occurs
then
like
something
has
gone
terribly
wrong
under
the
hood
and
that
generating
like
a
an
exception
style
error
makes
a
lot
of
sense,
whereas
the
schema
saying
and
null
is
completely
possible
here
and
then
you
as
a
client
saying
I
understand
that.
But
I
don't
want
that
case.
K
L
Yeah
one
thing
that
we
can
do
to
kind
of
like
convey
with
schematic
proximatic
on
the
server
is,
instead
of
just
just
replacing
type
with
non-noble
like
wrapping
it
in
no
nobody
during
execution.
We
can
change
a
little
bit
of
how
we
we
do
errors,
so
we
can
inside
the
error
that
blew
up
with
like
sub
3.
We
can
include
partial
result.
L
G
Yeah,
I
wonder,
if
that's,
I
feel,
like
that's
orthogonal,
to
the
thing
that
I'm
nervous
about
it's
less
about.
If
you
get
an
error,
are
you
then
missing
data
like
the
client,
presumably
would
put
an
exclamation
point
somewhere
to
explicitly
state
that
they're
they're
totally
comfortable
missing
the
scenario
where
something
is
not.
G
L
L
I
don't
know
about
throwaway
one
because
of
merchant
rules
for
validation,
but
simply
requires
that.
Don't
do
like
a
imagine
bunch
of
stuff,
but
you
want
to
do
error
boundaries.
It's
like!
L
G
I
wonder
if,
if
a
happy
medium
here
like
it
seems
like
the
direction,
we're
saying
here
is
like
what,
if
the
answer
is
more
information,
and
like
is
the
behavior
of
if
your
errors
field
has
anything
in
it
through
it,
all
out
is
just
like
too
simplistic
of
a
behavior.
G
Just
because,
like
we
don't
have
enough
information
there
to
make
any
better
call,
but
like
I
could
see
an
alternative
here
being
whether
you
use
an
exclamation
point
or
not
like
some
error
occurs
and
it
starts
to
bubble
and
that
error
is
going
to
get
logged
in
the
in
the
errors
field.
Now,
if
you
had
a
question
mark
somewhere,
presumably
that
says
I
want
to
catch
that
arrow
here.
I
want
to
catch
it,
and
then
I
want
to
like
trim
my
response
at
this
point.
G
If
you
do
that,
like
imagine,
if
you're
a
relay
or
a
facebook
native
client
or
somewhere,
where
you
know
having
an
error
somewhere,
could
could
meaningfully
blow
up
your
whole
component
or
block
the
whole
entire
request,
would
we
want
to
interpret
the
use
of
a
question
mark
as
saying
like?
No,
actually,
please
don't
blow
up.
G
G
So
maybe,
if
you
explicitly
use
question
mark,
then
we
say
this
error
was
caught
at
this
location
and
then
you,
you
could
decide
if
your.
If
your
client
wants
to
have
a
behavior
where
it
allows
partial
results.
If
you
opted
in
with
the
question
mark
to
say
all
right
I'll,
just
I'm
gonna
go
look
through
my
errors
and
as
long
as
all
the
errors
listed
here
say
that
they
were
caught,
errors
then
I'll
proceed.
G
But
if
any
of
them
say
that
they
weren't
caught,
then
I
will
throw
the
whole
thing
out
and
then
that
actually
gives
you
a
meaningfully
different
behavior.
If
you
have
a
field
that
is
nullable
and
a
field
that
is
nullable
with
a
question
mark
on
it
like
in
the
current
way
the
spectex
is
written,
those
are
identical.
The
question
mark
does
not
view
any
new
behavior.
G
Maybe
this
is
actually
interesting
information
to
include
kind
of
completely
orthogonally
to
this
proposal,
because
this
question
comes
up
of
hey.
Okay,
I
see
that
this
field
is
null.
Is
that
field
null?
Because
it
was
the
value
itself,
was
null
or
is
that
field
null
because
it
caught
an
error
and
like
that
was
happened
to
be
the
lowest
nullable
field
and
therefore,
like
real
data
got
dropped
there
and
right
now
you
can
kind
of
figure
that
out
by
looking
at
your
errors
array
and
seeing
all
right,
what
was
an
error
thrown
below
that
field?
G
And
if
so,
then,
then
likely?
It
is
the
case,
but,
like
I
don't
know,
maybe
something
else
happened
too,
but
like
that's
actually
kind
of
a
slightly
confusing
thing
to
do,
but
like
it's
maybe
interesting
to
like
this,
would
give
us
a
way
to
say
client
intent
to
catch
an
error,
as
opposed
to
like
the
schema
just
happened
to
define
this
as
a
nullable
field
and
therefore
safe
to
turn
into
null
yeah.
J
J
J
Yeah
so
like,
if
we,
if,
if
there
was
a
way
for
you
to
encode,
hey
this
field,
could
be
an
error
or
even
if
we
said
for
any
field,
if
there
is
an
error
thrown
instead
of
like
putting
this
in
the
errors
of
re,
we
give
you
an
error,
object
with
some
message
at
that
point
in
the
response,
and
then
that
error,
could
you
know
also
you
could
have?
J
J
J
And
basically,
would
it
so
if
we
had
first
class
errors
of
some
form,
would
it
would
we
radically
alter
how
we
would
approach
this
problem?
If
so,
is
it
is
it
the
kind
of
thing
that
we
should
like
really
spin
up
something
real,
quick
to
try
to
like
throw
together?
What
would
first
class
errors
look
like
and
decide?
Yes,
we
want
to
block
on
it
or
not,
but
I
don't
know
if
that's
even
worth
considering.
G
I
anticipate
that
having
an
error
object
appear
directly
in
the
response
rather
than
side
loaded
would
meaningfully
change
enough
things
that,
like
that
alone,
would
force
a
different
interpretation
like
we
considered
that
right,
like
the
reason
why
we
ended
up
sideloading
them
rather
than
putting
them
in
is
a
naive
client
wants
to
be
able
to
just
like
write.
You
know,
food.bar.bass
and
expect
to
get
a
value
and
if
there's
an
object
there,
but
it
happens
to
be
a
different
kind
of
object.
It's
an
object
with
like
an
error
message
in
it.
G
You
get
into
confusing
potential
results
and
also
like
that
then
occludes,
your
ability
to
have
fields
a
particular
name.
Maybe
you
want
to
have
message
as
like
a
field
in
that
error
object.
Now
you
can't
have
a
field
called
message,
because
if
I
wrote
food.message,
maybe
it's
the
message
from
my
schema.
G
Maybe
foo
aired
out,
and
now
I'm
getting
an
error
message
so
like
that
that
was
the
main
reason
why
we
decided
to
sideload
them,
but
you
know
assume
that
we
had
something
better
than
json
and
it
let
us
sort
of
like
have
a
first
class
object
type
in
the
payload.
Then
I
would
anticipate
you
kind
of
similarly
to
what
we
have
with
null
like
what
a
client
really
wants
is
the
ability
to
say.
If
I
say
this
is
a
string,
it's
a
string,
it's
not
a
string
or
a
null.
G
It's
not
a
string
or
an
error.
It's
a
string
so
when
I
start
accessing
properties
of
it
or
start
doing
stuff
with
it,
I
don't
always
have
to
like
refine
my
left
right
type
or
my
maybe
type
before
I
start
like
doing
work
with
it,
and
if
I
have
to
do
that
at
every
single
point
along
the
way,
like
that's
very
annoying
and
that's
actually
kind
of
the
motivation
here
right.
G
So
in
that
mode
I
would
still
expect
us
to
be
able
to
say
either.
You
have
like
explicit,
like
throw
catch
points
or
like
some
way
for
a
client
to
say
I
only
care
about
handling
errors
at
this
particular
point
and
then
maybe
like
with
the
first
class
error.
You
would
say
you
know
errors
always
bubble
until
they
hit
one
of
those
things
I
mean.
If
you
have
a
question
mark,
then
you're
explicitly
opting
in
to
say
this
is
a
whatever
type
you
described.
G
It
is
or
it's
a
error
type,
maybe
like
an
alternate
way
to
do
that,
but
I
think
so
many
things
would
change
that.
That
might
be
tricky,
but
brian,
I
say
your
hand
go
up.
First,.
E
Well,
yeah,
one
thing
I
will
say,
as
I
think
about
like
nulls
and
graphql,
is
that
it's
it's
all
very
much
influenced
or
by
maybe
maybe
like
there's
like
an
oversized
influence
of
javascript
and
json
and
the
semantics
of
null
in
javascript
and
json,
specifically
the
idea
that
there
is
a
distinction
between
like
a
positive
like
null
versus
a
negative
undefined
or
missing
whatever
right,
like
that
million
dollar
mistake
or
whatever.
I
don't
know
how.
We
count
that
as
a
design
decision
like
how
much
what
the
cost
of
it
is.
E
But
so
there's
that,
and
I
always
always
wonder
if
like
what,
if,
instead
of
having
just
like
no,
we
just
excluded
stuff
from
the
shape
if
it
was
missing.
But
we
don't
have
to
go
over
that
but,
like
I
think,
there's
a
similar
argument
to
be
made
for
errors,
because,
like
again,
javascript
has
its
own
semantics
about
how
errors
work,
and
it's
it's
wildly
different
in
in
all
these
other
languages.
So,
like
I
worry
about
trying
to
add
this
sort
of
stuff
to
the
specification
and
like
how
would
that
work
for
swift?
M
Yeah,
you
know,
with
with
the
you
know,
matt's
suggestion,
there's
kind
of
two
parts
that
I'm
hearing
is
one
is
a
little
bit.
You
know
a
little
bit
more
structure
around
like
different
types
of
errors,
and
then
the
second
is
you
know:
where
do
we
put
them?
Are
they
in
the
graph
versus
you
know,
side
loaded,
and
I
think
we
could
consider
those
separately?
I
mean
in
theory.
If
you
have
a
path
in
the
error,
a
a
client
should
be
able
to.
M
You
know,
intelligently,
insert
them,
and
so
you
know
a
naive
client
can
just
you
know,
you
know
just
get
the
string
or
not,
and
then
another
client
could
kind
of
make
that
you
know.
I
guess
it's
basically
an
implicit
union
of
every
you
know
of
every
belief
in
practice.
I
feel
like
the
path
I
just
don't
see
it
used
much
programmatically
are
there
other
reasons
for
that,
like?
Is
that
insufficient
like
something
that
we
need
to
push
on?
Or
is
it
just?
M
Yeah
well
like
using
the
path
in
the
client
to
like
attach
errors
to
where
they,
you
know
where
they
happened
in
the
graph,
for
example,
you
know
like
tooling
that
that
uses
the
path,
because
what
what
I
seem
to
see
in
practice
is
that
you
know.
Basically,
we
see
any
errors,
we
explode
and
then,
if
a
path
is
used,
it's
just
kind
of
by
a
human
debugging.
It
does
that
make
sense.
G
It
does
yeah
because
you're
right,
you
all,
the
information
exists
to
take
the
data
field
in
the
errors
array
and
then
use
path
to
merge
them
together
to
insert
error
objects
in
the
result.
Right.
You
use
the
path
to
do
that.
That's
a
completely
doable
client-side,
transform.
J
G
I
would
say,
like
maybe
the
the
difference
is
like,
if
you
think
about
the
developer
ergonomics
of
that
it's
super
annoying,
because
now
every
single
field
could
is
now
like
a
left
right
type
and
so
like
if
you're,
writing,
typescript
or
swift
or
kotlin,
or
anything
where
you
have
like
the
operators
to
like
dig
into
something
having
to
like
explicitly
unpack
all
the
way
along.
The
way
is
just
going
to
be
super
annoying
and
so
like.
G
Maybe
actually,
the
missing
piece
is
an
explicit
concept
of
an
air
boundary
which
is
kind
of
part
of
what
we're
proposing
here
and
if
you
did
have
like
a
this
part.
Right
here
is
question.
Marky
or
maybe
this
like
could
be
prototyped
with
the
directive.
Let's
say
like
error
at
airbendery
and
like
that
is
the
spot
at
which,
like
a
client,
will
look
at
that
and
below
that
say.
If
I've
got
any
errors
with
pass
below
this
air
boundary,
then
then
I'll
left
right
type.
G
G
D
Just
really
quick
what
you're,
describing
with
the
the
error
boundary
it
wouldn't
have
any
additional
server-side,
behavior
right,
it'll
just
be
information
for
the
client
yeah
yeah.
This
is
getting.
G
At
like
stephen's
suggestion
of
like
hey,
why
is
it
that
we
don't
actually
see
this
transform
and
I,
I
think,
we're
just
like
missing
a
key
piece
there
and
then
I
guess
maybe
the
other
motivation
is
like.
Do
we
care
right?
So
facebook's
native
implementation
says,
if
there's
any
error
anywhere
like
through
the
whole
thing
out,
and
presumably
that's
working?
G
Okay,
because
if
it
didn't,
then
you
would
probably
see
a
bunch
of
product
engineers
griping
their
screens
are
busted
all
the
time
and
would
start
begging
for
something
like
an
air
boundary
and
the
fact
that
they
haven't
maybe
is
an
indication,
at
least
within
that
particular
domain.
That's
not
needed,
but
that's
a
super,
interesting
question
yeah.
Why
aren't
we
seeing
that
more
jordan,
your
hands
up
too
go
for
it.
K
Just
going
back
to
this,
like
notion
of,
we
have
like
throw
versus
bubble
semantics
like
it
just
occurred
to
me,
and
maybe
this
is
actually
all
kind
of
what
you
were
saying
lee
that
like,
if
we
decided
that
client
signal
ability
and
service
annual
ability
were
were
somewhat
different,
you
could
theoretically
say
exclamation
point
is
an
assert
it
throws
and
it's
caught
at
the
at
the
neck,
at
the
parent,
client
defined
error,
boundary
and.
K
Describe
the
like
expected
behavior
of
the
like
the
current
proposal
using
those
primitives
so
like,
if
you
just
want
to
bubble
to
the
parent,
you
would
say
exclamation
point
parent
question
mark
on
the
immediate
parent.
But
if
you
wanted
to
throw
semantic
on
on
your
client,
then
you
would
just
omit
the
question
mark
and
then
like
this,
I
think
would
allow
you
to
express
something
similar
to
what
relay
wants
and
also
to
express
something
simpler.
You
know
which
is
just
a
simple
bubble
semantic,
but
I
don't
know.
J
Yeah
relay
is
interesting
in
that
the
air
boundaries
are
fragments
and
fragments.
Don't
exist
right
so
like
how.
How
would
relay
like,
if
relay
wanted
the
throw
semantic
on
a
fragment
like
if
you
want
to
yeah,
not
that
this
should
affect
it,
but
like
really
can
treat
fragments
as
essentially
functions,
whereas
the
graphql
executor.
K
Really
would
continue
to
present
this
facade
of
fragment
isolation.
I
guess
the
maybe
one
flaw
with
this
idea
or
one
of
perhaps
many
is
that
if
you
say
okay,
we're
just
going
to
throw
at
this
point
and
it's
up
to
you
to
catch
it
somewhere.
If
you
neglect
to
catch
it
anywhere,
then
you've
just
like
introduced
a
giant,
you
know
cough.
G
Yeah
that
that
was
kind
of
what
I
was
trying
to
get
at
before
with
like
how
relay
might
want
to
interpret
this,
because
it
is
like
before
this.
G
There
is
no
way
for
a
client
to
describe
this
intent
other
than
having
some
tool
specific
directive
in
place,
but
it
doesn't
seem
crazy
to
me
that
a
client-side
tool
like
relay
or
apollo
client
would
say
you
know,
because
you
have
these
fragment
boundaries
that
like,
if
you
use
exclamation
point,
then
we'll
treat
that,
like
a
fragment,
defined
assertion
that
will
blow
up
the
component,
that's
linked
to
that
fragment
unless
contained
also
within.
That
is
a
question
mark.
G
So
you
can
imagine
who
bar
baz
and
baz
has
an
exclamation
part
and
bar
has
the
question
marks
now
you've
got
like
okay
bounce
there's,
an
error.
You
know
bar
catches,
it
and
all
that
is
contained
within
the
same
fragment,
then
like
great,
don't
blow
up
your
fragment,
because
your
your
developer
has
told
you
that
it's
safe
to
catch
such
an
error.
G
Right
here
I
guess,
like
our
question,
is
how
much
of
that,
how
much
of
this
kind
of
behavior
do
we
want
to
put
on
the
server
and
therefore
in
the
spec,
and
how
much
of
this
is
space
for
clients
to
have
some
additional
behavior?
And
if
so,
do
we
have
the
appropriate
information
such
that
they
can
do
that?
Are
we
missing
something
so
that
doing
that
kind
of
client
behavior
is
too
fiddly
or
like
error-prone
or
confusing.
K
K
A
little
bit
concerned
about
having
the
semantics
of
it
in
one
client
differ
from
the
semantics
of
it
in
another
client.
You
know
where
I
mean
obviously
there's
already
this
facade
of
fragment
isolation,
but
like
this
would
be
going
further
than
that.
Oh
this,
in
one
in
one
domain,
is
you
know
just
a
bubbling
thing
up
to
the
parent
and
then
another
domain
is
more
destructive.
K
N
L
J
E
J
Make
the
argument
that,
given
all
the
discussion
about
question
mark
being
a
potential
error
boundary
that
maybe
we
want
to
preserve
that
separately
from
the
exclamation
mark,
like
not
necessarily
introducing
them
to
the
spec
at
the
same
time?
But
I
could
be
wrong.
G
I
think
it's
tough
to
talk
about
one
without
talking
about
the
other,
especially
if
the
semantics
of
their
narrow
boundary
implies
something
different
about
how
in
it
like.
If
the
question
mark
is
air
boundary,
just
purely
means
yeah
just
go
ahead
and
treat
that
field
as
if
it
was
nullable,
which
is
how
the
spectex
is
currently
written,
is
slightly
different
from.
G
G
Unless
you
have
a
question
mark-
and
in
that
case
it
would
that
would
give
it
semantics
much
more
similar
to
sort
of
traditional
throw
catch
if
we
did
that,
that
would
be
more
destructive.
Maybe
that's
that's
kind
of
the
foot
gun
that
you
know,
maybe
that's
a
little
too
scary
but
like
if
we
went
down
that
path
like
you
couldn't
have
that
conversation
without
question
mark
being
part
of
it.
So.
B
I
I
agree
with
that.
I
think
that
the
the
question
mark
and
the
exclamation
point
need
to
be
solved.
At
the
same
time,
I
since
lee
suggested
adding
the
question
mark
when,
when
this
topic
was
raised
in
a
previous
working
group,
it
has
made
me
rather
like
nervous
it
just
doesn't.
It
doesn't
feel
quite
right,
and
this
discussion
has
helped
me
figure
out
why
I
feel
less
comfortable
about
that.
B
I
think
it
can
allow
issues
in
your
in
your
data
model
to
to
come
up
that
wouldn't
otherwise
come
up
so
where
something
might
be.
You
know
if
there's
a
non-nullable
assertion
that
would
then
like
throw
and
throw
through
a
layer
if
you,
if
we
were
to
naively
apply
the
question
mark
as
just
effectively
changing
the
underlying
type
of
this,
then
it
would
potentially
allow
that
object
or
allow
its
pair
yeah.
B
I
don't
know
I
need
to
write
it
down
on
paper
to
make
sense,
but
what
I
think
I'm
getting
at
is
that
the
the
question
mark
might
be
more
subtle
than
merely
changing
the
type
and
then
piping,
this
new
type
through
the
executor
it
feels
like
it
does
something
different,
and
I
think
that
if
the
underlying
thing
would
have
thrown
an
error
anyway,
it
probably
should
still
throw
an
error.
Like
I
see,
the
question
mark
is
more
of
a
here
is
a
point
at
which
we
can
catch.
B
G
Yeah,
that's
super
interesting.
I'm
I'm
always
hesitant
to
have
slightly
different
behaviors
for
two
things
that
both
kind
of
describe
themselves
as
errors.
As
soon
as
we
have
like
a
client
side
flavor
or
like
a
query
defined
flavor
of
error
versus
server
defined
flavor
of
error.
G
G
How
will
people
want
to
use
this,
and
obviously
we
want
as
much
of
a
diversity
of
opinion
as
possible
on
that,
so
we
don't
overly
constrain
it,
but
even
just
having
this
conversation
now
has
been
really
helpful
to
like
think
through.
Oh,
like
the
idea
that
90
of
cases
of
wanting
a
nominal
are
actually
throw
cases
like
that
having
this
desired
behavior
of
actually
wanting
to
blow
up
some
localized
scope
is
actually
very
interesting,
and
it
implies
that
you
know.
G
I
guess,
like
our
action
item
here
is
to
like
add
to
our
list
of
unanswered
questions.
Question
mark
is
not
simply.
This
is
client
defined
null.
It's
more
like
this
is
probably
somewhere
in
the
domain
of
error
boundary,
but
the
semantics
of
that
there's
some
options
in
that
space
with
maybe
some
different
trade-offs,
and
we
should
guide
ourselves
to
the
one
that
yields
the
most
developer
value.
G
Yeah
from
for
me,
I
think
it's.
The
trade-off
is
between
biasing
towards
more
information
or
biasing,
towards
an
immediate
structure
that
you
can
use.
So,
if
you're,
a
very
sophisticated
client
like
relay
or
apollo
client,
you
want
maximal
information
because
you're
you're
doing
post-processing
anyway,
and
if
the
information
can
give
you,
as
you
know,
tons
of
info
about
what
happened
on
the
server
and
how
to
appropriately
act.
That's
a
good
thing.
G
If
you're
a
shell
script,
calling
curl
then,
like
you,
probably
really
don't
want
extra
information,
especially
if
that
information
is
like
here.
Here's
the
next
steps
that
your
client
should
probably
do
with
this
before
you
start
interpreting
the
data
you
just
you
want
like
a
final
payload.
That
is
as
close
to
the
thing
you
want
as
possible,
but
this
is
ends
up
being
a
trade
when,
if
the
final
payload
is
just
is
destructive
right
like
and
that's
why.
G
I
think
this
is
super
tough,
because
if
it
was
purely
about,
oh,
you
know,
let's
just
put
the
error
in
the
right
spot
and
call
it
a
day,
but
if
doing
that
removed
information,
which
I
can
see
being
the
case
like
if
you
said
all
right,
yeah
exclamation
point
means
fatal
that
that's
just
like
always
going
to
bubble
up
to
the
parent.
All
of
a
sudden,
this
becomes
like
a
giant
data
deletion
gun
where
you
put
that
there
and
then
it
just
completely
blows
up
queries
where
like.
G
G
If
we
decide
to
have
to
have
that
behavior,
maybe
graphql
ends
up
with
a
validation
rule
that
requires
that
it's,
like
you,
got
to
put
it
somewhere.
Even
if
the
place
you
put
it
is
on
the
parent
field,
like
any
use
of
an
exclamation
point,
must
also
come
with
the
question
mark
if
it
ends
up
with
that
kind
of
semantic,
it's
a
viable
direction.
But,
like
I
don't
know,
this
is
a
tough
trade
like.
G
I
think
we
probably
want
to
just
start
writing
out
like
what
isn't
what
is
the
air
boundary
and
what's
its
relationship
to
an
exclamation
point
and
client
controlled
nominal
ability
and
like
option
a
option
b,
option
c
trade-offs
pro
cons.
I
think
that's
probably
our
next
step
for
something
like
this.
D
G
Yeah,
hopefully
not
entirely
on
you
alex,
maybe
you
can
help
facilitate
and
like
prod
people
until
they
give
you
that,
what's
your
friend.
E
Yeah,
I
really
like
this
framing
of
in
terms
of
like
first
principles
like
what
did
developers
want
and
what
I've
seen
that,
like
my
limited
understanding
of
what
developers
really
want
when
with
these
two
operators,
is
just
the
ability
to
stop
making
schema
changes
which
are
breaking
like
it's
like
both
making
a
a
field,
non-nullable
or
non-novel,
like
both
of
those
changes,
are
breaking
changes
because
of
the
way
that
code
generation
works
and
like
across
all
clients.
E
So
that's
the
main
thing
I
would
like
to
preserve.
Whatever
happens
with
this,
like
error,
boundary.
G
Stuff
yeah,
so
you
mean
so
the
value
there
being
rather
than
the
server
changing
this
and
therefore
cascading
breaking
changes.
The
client
changing
is
implies
that
they
know
what
they're
doing
and
the
fail
and
test
related
to
the
code.
Generator
then,
like
that's
their
fault,
because
if
they
change
the
client
query
locally,
they
should
also
change
the
code
that
consumes
it.
K
K
Like
you
know,
our
code
looked
like
one
graphql
query:
half
the
code
is
null
checks
and
then
half
the
code
is
actually
business
logic
and
that's
the
problem
that
they
want
to
go
away,
so
it
maybe
is
different
in
different
schemas,
depending
on
how
heavily
they
lean
into
the
pervasive
null
ability,
yeah.
That
was
exactly
the
same
motivation.
M
D
Yeah
yeah,
that
was
that
that
was
up
us
too.
We
end
up
writing
just
tons
of
rapper
types
and
every
code,
gen
type,
pretty
much
immediately
gets
thrown
away
like
it's
not
useful,
because
we
have
to
you
know
null
check
every
field.
G
Always
maintaining
data
with
the
good
developer
experience
like
we,
we
expect
so
like
I'm
I'm
operating
on
financial
data.
G
You
really
don't
end
up
in
a
situation
where,
like
you,
throw
out
queried
financial
data
if
you're
able
to
deal
with
a
partial
response,
so
we're
even
considering
like
crazy
stuff
like
having
dual
schemas,
one
of
which
has
non-nulls
in
the
right
places
and
one
of
which
that
like
is,
is
basically
copies
it
over,
but
strips
all
the
non-nulls
out,
so
that
if
you
wanted
to
query
something
and
like
basically
that
way,
your
default
behavior
is
something
that
allowed
you
like,
safe.
G
You
know
dotting
in
and
not
having
to
deal
with
nulls
until
the
case
that
you
do,
and
so
in
that
case
it's
like
less
about
the
exclamation
point
operator
being
value
edition.
It's
more
about
the
question
mark
operator,
being
value
edition
and
saying:
hey
something
below
this
could
break,
but
if
it
does
like,
please
don't
ruin
anything
outside
of
the
space
like.
I
want
to
create
a
boundary
here
and
like
that.
G
That's
actually,
and
that's
part
of
the
reason
why,
when
the
proposal
came
up,
I
was
like
we
were
already
having
this
conversation
on
one
of
my
teams.
I
I
should
flag
that,
like
the
air
boundary
cases
is
actually
going
to
be
really
compelling
to
us
so
that
that's
actually
the
thing
that
our
team
will
care
the
most
about,
but
that's
good.
That
gives
us
like
a
broad
set
already
of
things
that
we'll
want
to
maintain
like
both
making
sure
that
we
we
don't
blow
up
stuff.
We
don't
want
to
blow
up
like.
G
If
a
client
cares
about
a
partial
response,
then
they
should
be
able
to
describe
that
right
now.
They
can't
and
if
a
client
does
not
care
about
null
values
and
wants
to
just
like
hammer
in
through
some
data
right
now
they
can't
describe
that
intent
and
they
want
to
be
able
to
describe
that
too.
So,
we've
got
kind
of
both
sides
of
the
coin.
G
We
went
well
over
our
10
minutes,
but
I
think
that
was
actually
a
super
helpful
discussion.
I
feel
like
I
learned
something
about
this
proposal.
Can.
G
Question
sorry,
I
I
I.
C
Don't
mean
to
cut
into
your
and
benji's
review
time,
but
I
think
we've
kind
of
eaten
alex
list
elements
is
that
is
the
plan
still
to
kind
of
move
ahead
with
this
spec.
These
spec
changes
without
considering
list
elements,
or
are
you
still
waiting
for
more
feedback?
There.
D
We
we
have
something
written
down
in
the
doc.
I
shared
that
we
could
use
like
it's
some
possible
syntax,
yeah
talking
to
netflix
and
relay
it
seems
like
they
haven't
run
into
any
problems.
Yet
with
us
like
like
it's,
not
something.
That's
that's
that's
been
needed
so
far.
We
we
can
add
it,
but
you
know
this
was
just
me
airing
on
the
side
of
like
doing
nothing.
K
K
Whereas
I
could
imagine
if
it
is
simply
bubble,
you
would
often
want
to
be
constructing
a
very
careful
chain
where
every
single
item
in
the
whole
chain,
leading
up
to
a
certain
point
is,
is
non-nullable,
and
maybe
we
sort
of
sidestepped
that
by
having
to
throw
semantics.
So
that's.
D
Yeah,
I
mean,
if
you
know,
if
you
or
apollo,
has
like
a
good
use
case
or
a
strong
need
for
it
still
open
to
doing
it.
C
Yeah,
I
I
think,
there's
going
to
be
some
information
coming
on
that
for
sure
shortly,
it'll
probably
be
on
the
pr
as
feedback.
But
yes,
okay,
that's
great.
M
G
It
could
also
be
that,
should
we
decide
not
to
have
something
that
would
support
digging
into
lists
that
it
still
ends
up
being
valuable
to
explore
potential
syntax
for
them,
so
that
whatever
it
is
that
we
do
end
up
agreeing
on
doesn't
like
explicitly
block
our
ability
to
go
describe
that
in
the
future.
So
if
we
find
out
that,
like
oh
exclamation,
point
question,
mark
alone-
I
don't
know,
but
maybe
that's
like
ambiguous
with
regard
to
lists,
then
we'll
want
to
resolve
that.
G
But
hopefully
it
means
like
we
don't
have
to
decide
like
definitionally.
We
will
or
won't
support
lists
like
another
option,
is
defer
that
conversation
until
a
later
proposal
to
like
extend
this
behavior
to
to
go
into
lists
in
the
future,
it'd
be
better
if
we
answered
it
up
front,
but
preserving
that
seems
good.
D
G
That's
awesome
totally
totally
understandable
so
having,
I
think
like,
I
would
consider
stage
two
the
point
where
you
can
like
actually
start
doing
stuff,
with
real
prototypes,
like
you've
got
code
landed
in
a
pr
code,
landed
in
one
of
the
implementations
of
code
of
a
code
generator,
that's
like
not
explicitly
required
for
stage
two,
but
I'd
say
like
that
would
set
you
up
very
very
strongly,
I'm
seeing
if
I
can't
pull
up
my
participation
guidelines
or
is
it
something
else
I've
got
it
written
down
somewhere.
G
We
have,
we
actually
do
have
rules
or
guidelines
that
help
us
describe
each
stage.
It's
not
great
that
I
have
forgotten
what
they
are
here.
We
go
stage
two
draft,
this
consensus,
that
the
solution
is
broadly
preferred.
So
I
think
actually
we
we
are
pretty
close
to
that
one.
It's
like
hey
is
this
the
idea
that
doing
this
via
syntax
and
the
location
that
you
have
the
roughly
the
behavior
that
we're
describing
like
that?
G
That's
the
one
that
we
generally
all
agree
is
the
right
one
to
have
that
we've
resolved
all
of
our
identified
concerns
and
challenges
that
one
it
seems
like.
We
don't
have
like
we've
identified
them.
I
don't
know
that
we've
resolved
them
yet
precisely
described
everything
with
spec
like
basically
like
the
spec
might
not
have
all
of
the
edits
applied,
but
like
broad
strokes,
everything
that
needs
to
be
in
is
in
and
then
pull
requests
are
at
least
in
the
right
places,
if
not
merged.
G
And
then
the
the
difference
between
that
and
being
accepted
is
that,
like
review,
passes,
have
gone
over
everything
and
we've
made
sure
that,
like
not
only
is
the
description
in
the
spec
there,
but
like
all
the
non-normative
notes
are
good.
Like
everything's,
like
you
know,
spit
polish
is
basically
the
difference
between
two
and
three
okay,
excellent,
angry,
much
sweet,
very,
very
valuable
conversation.
Thank
you
for
helping
us
leave
that
alex
and
thanks
for
your
work
so
far
on
this
you've
made
a
lot
of
progress.
So
great
work,
of
course,.
B
Thank
you
cool,
so
we
should
probably
acknow
acknowledge
that
we
did
the
october
2021
spec
cut.
G
G
Because
I
got
no
real
action
to
ask
from
this
group,
but
sorry
for
it
being
so
late.
L
G
Celebrate
that
is.
G
I
wrote
a
blog
post
about
some
of
the
backstory
behind
it.
That
talked
a
little
bit
about
why
why
the
graphical
foundation
exists
in
the
first
place
and
how
that
made
this
slightly
more
challenging
of
a
release
than
than
before
huge
shout
out
to
brian.
I
don't
know
if
everybody
here
has
gotten
a
chance
to
meet
brian
yeah
brian
had
to
go
through
the
change
log
of
not
just
the
changes
that
were
made
in
the
last
couple
of
years,
but
literally
every
change.
G
That's
ever
been
made
to
the
graphical
spec
and
make
sure
that
the
author
of
that
agrees
to
our
like
new
distribution
rules,
which,
like
seems
like
maybe
a
painful
exercise,
but
like
the
reason
for
that
is
very
important,
because
presumably
anyone
could
show
up
and
be
like
yeah
yeah
mit
is
a
thing
but
like
actually
I'm
not
okay
with
company.
I
don't
like
x
using
my
work
and
I'm
gonna
like
sue
them
now,
and
this
is
actually
seems
theoretical.
G
But
it's
actually
like
a
huge
reason
why
we,
we
created
the
foundation
in
the
first
place,
is
like
allowing
any
one
company
or
individual
the
ability
to
like
jump
in
and
say
I
revoke.
The
thing
that
I
contributed
is
is
like
hugely
painful.
Luckily,
everyone
here,
I
know
is,
is
well
intentioned,
but
there
are
other.
There
are
other
open
source
foundations
in
which
that
is
not
the
case,
and
you
get
like
big
companies
that
fight
with
each
other.
G
There's
there's,
unfortunately,
legal
precedent
behind
all
these
things,
so
brian
did
like
a
huge
amount
of
legwork
to
do
that,
and
that's
a
big
part
of
the
reason
why
it
took
so
long
is
getting
getting
to
the
point
where
the
linux
foundation's
legal
team
also
backed
him
up
and
like
got
to
the
point
where
they're
like
felt,
very
confident
that
we
were
in
a
good
legal
standing
to
cut
it.
G
So
when
we
say
that
this
is
the
first
cut,
that's
under
all
the
guidelines
of
the
graphql
foundation
like
that
actually
has
heavy
weight
to
it.
There's,
like
all
of
the
like
actual
legal
texts
that
we've
written,
is
now
enforceable
and
and
solid
so
that
I'm
I'm
super
excited
about.
You
know.
Lots
of
really
great
technical
work
went
into
that
draft
as
well.
Although
I
feel
like
since
then,
we've
we've
already
done
a
considerable
amount
of
pretty
high
quality
work,
so
hopefully
we'll
going
forward.
G
This
will
be
a
slightly
less
dramatic
and
regular
annual
process,
but
yeah
celebrate.
If
you
all
want
to
write
any
blog
posts
about
it,
please
feel
free
talk
about
it
at
conferences.
Definitely
do
that.
Let
me
know
if
you
want
my
help
with
reviewing
any
content,
if
you,
if
you
ever
end
up
doing
anything
like
that,
but
yeah
it's
out.
G
Okay
with
that
we'll
wrap
up
the
meeting
benji,
and
I
only
have
a
few
minutes
left,
but
still
sometime
rather
than
others,
so
I'll
stick
around
for
anybody
who
wants
to
quickly
go
through
some
actions.
But
thank
you.