►
From YouTube: GraphQL Working Group (Primary) - 2023-09-07
Description
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. Get Started Here: https://graphql.org/
A
B
F
D
Right
well,
it
seems
like
the
majority
of
us
are
here
so
I'll
get
us
started.
Lee
can't
make
it
today.
So
he's
asked
me
to
host
this
meeting.
D
So
just
want
to
point
out
that
by
being
here,
we
have
all
already
agreed
to
the
specification
membership
agreement,
the
participation
guidelines,
the
contribution
guide
and
the
code
of
conduct.
Links
to
all
of
these
can
be
found
in
the
agenda
file
for
anyone
who's
watching
on
YouTube
and
wants
to
join
us
in
a
future
meeting.
D
G
I
think
I'm
on
there
second
I'm
Alex,
hey.
H
I
Miami
tomorrow,
I
work
on
infra
at
meta.
C
I
think
tianyu
is
not
here
today,
but
I'm
Jordan,
I
work
on
relay
at
meta
and
I.
Think
Monica
is
also
not
here
yet
Perhaps.
So
we
can
go
to
Ernie
yeah.
J
C
J
Ernie
I
work
on
kind
of
devex
and
data
layer
stuff
at
coombies.
L
B
Hi,
my
name
is
Young
and
I
work
at
the
trade
desk.
H
D
H
E
I'm
here
I
think
it's
the
last
minute.
I
Pr
that
looks
like
it
has
a
conflict
which
I
will
fix,
but
yeah
I'm,
Calvin
I'm,
with
Apollo
and
in
Vancouver.
J
F
And
I'm
Anthony
I'm
also
with
Apollo
in
Las
Vegas
Nevada
I,
just
put
my
PRN
for
the
agenda.
D
Okay,
fantastic!
Thank
you!
Everyone,
nice,
to
see
you
all
what
a
healthy
attendance
today,
fantastic,
okay!
So,
first
of
all,
since
I'm
hosting
the
meeting,
it
would
be
particularly
helpful
if
someone
else
were
to
take
head
up
taking
notes
today.
Do
we
have
any
volunteers
for
that?
It's
generally
helpful
to
have
like
two
or
three
people
helping.
D
Appreciate
that,
thank
you
so
much
and
also
everyone
else
you
can
chip
in
on
the
notes
as
well.
We've
got
this
one
live
document,
so
you
can
just
contribute.
It's
particularly
useful
when
young
Orca
are
talking
for
other
people
to
continue
to
take
notes.
During
that
time
we
should
review
the
prior
meetings,
but
I
have
a
feeling
that
August
was
a
busy
time
for
us
all.
D
It
looks
like
the
APAC
meeting
didn't
go
ahead
and
the
same
probably
for
the
EU
meeting,
so
I,
don't
think,
there's
actually
anything
to
recap.
So
we'll
move
on,
we
have
reviewed
the
previous
meetings,
action
items.
D
Which
would
be
fun
I
wonder
if
I
actually
followed
them,
so
that
would
be
the
first
question.
D
Where's
our
projects,
there
we
go,
I
don't
see
any.
There
might
not
have
been
any
if
we
look
at
the
ones
ready
for
review,
though
there's
two
one
as
a
reminder
to
go
through
all
your
old
action
items
and
we'll
be
closing
them
soon.
D
So,
if
they're
still
relevant,
please
comment
on
them
to
say
so,
if
they're
not
relevant,
please
comment
on
them
to
say
so,
and
there
is
also
one
from
me
that
says
that
it's
ready
for
review
clarify
the
selection
set
in
the
example,
is
a
selection
set
and
not
a
document?
D
D
We
won't
go
through
that
now.
So
let's
go
ahead
and
review
the
agenda.
D
It
looks
like
we
will
be
looking
at
explicit
block
string
definitions,
then
talking
about
the
full
schemas
proposal
from
Martin
relay
error,
handling
from
itamar
and
then
talking
about
changing
the
execute
selection
set
to
execute
grouped
field
set,
which
is
something
that
Yakov
has
proposed
previously
and
I
have
an
alternative
proposal.
D
I,
don't
think
Jacob
is
with
us
today
and
finally,
on
to
the
client
controlled
nullability
updates.
So
let's
get
it
started.
I
guess:
I'll
kick
us
off
with
the
first
one,
which
is
the
explicit
block
string
definition.
D
This
one
is
a
graphql
spec
pull
request,
1042,
it's
an
incredibly
simple
pull
request.
Basically,
we
don't
Define
a
key
or
a
entity
in
the
grammar
for
a
block
string.
Instead,
it's
just
one
of
the
definitions
of
a
string
and
yet
somewhere
in
the
spec.
We
refer
to
block
string,
so
it's
not
defined.
So
all
I've
done
is
expanded.
The
grammar
to
include
a
definition
for
Block
strings,
so
I've
just
taken
its
inline
definition
and
just
moved
it
to
a
top
level
thing,
and
that's
really
all
there
is
to
it.
D
So
some
reviews
on
that
would
be
nice
if
anyone's
got
any
feedback
or
hesitations
on
this
now
would
be
a
good
time
to
raise
them.
D
All
right
General
thumbs
up.
That's
it
just
wanted
to
bring
it
to
your
attention.
If
anyone
wants
to
actually
comment
on
the
pull
request
or
even
just
approve
the
pull
request,
that
would
be
appreciated.
But
let's
move
on
to
Martin's
topic,
which
is
full
schemas
Martin.
H
Yes,
thank
you.
Thank
you
Benji.
So
this
is
a
follow-up
from
last
Working
World
meeting
about
housekeepers.
So
this
time,
I
made
a
few
slides
which
I
wanted
to
share
with
you
just
to
give
a
little
overview
of
the
problem.
It's
trying
to
solve
so
I'm
working
on
Apollo
kotlin,
which
is
a
polo
client
for
Android,
and
we
tell
all
of
our
users.
We
support
three
different
types
of
files.
G
H
H
The
problem
when
they
do
so
is
that
sometimes
they
bump
into
this
kind
of
Errors
like
if
they
have
built-in
type
definitions
inside
the
sdl
they
get
errors
here
is
from
the
integ
plugin,
it's
a
cartwheel,
IntelliJ
plugin.
They
do
to
compete
and
all
this
kind
of
fun
stuff
with
with
sdl,
but
they
do
not
like
it
when
you
redefine
the
existing
type
definitions-
and
this
is
expected
because
the
spec
actually
has
some
language-
that's
the
scalar
definitions,
not
Visa,
or
they
must
be
omitted
or
directives.
H
There
is
language
that
says
they
may
be
omitted,
but
they
maybe
not
and
there's
nothing
about
introspection
types.
The
problem
is
for
us
to
validate
completely
an
operation.
We
actually
need
those
built-in
definitions.
We
need
to
know-
and
this
goes
in
the
in
the
wheels
of
future
discovery
that
you
might
talk
about
it.
A
bit
later,
or
maybe
we
need
to
know
what
the
server
supports.
So
a
simple
example
is
there
is
no
input
value.
The
deprecation
reason
if
we
want
to
validate
that
we
need
the
built-in
definitions
so.
H
So
it
takes
the
regular
schema.
I
didn't
find
a
better
name
for
it
and
it
adds
the
built-in
definitions
on
top
of
it,
to
make
this
process
a
bit
easier.
I'm
also
suggesting
we
use-
and
we
add
a
new
appendix
to
the
spec,
which
contains
all
the
built-in
definitions,
and
they
are
a
little
bit
present
today,
but
they
are
a
bit
scattered
and
sometimes
not
matching
100
between
the
implementations.
H
We
might
not
be
able
to
answer
everything
today,
but
I'd
like
to
get
a
general
like
a
show
of
hand
today,
and
also
what
I'm
going
to
try
to
do
next
is
shut
down
this
proposal
into
smaller
ones
like
since
we
can
merge
incrementally
like
appendix
C
for
an
example.
This
is
something
that
does
not
change.
Any
validation
at
all
does
not
change
any
Behavior,
so
maybe
we
can
move
forward
with
this.
Maybe
there
is
something
about
as
their
definitions.
This
is
my
point
number
two
here
like
from
last
working
a
meeting.
H
A
H
H
Maybe
this
one
is,
there
is
a
actually
no.
This
one
is
a
good
one,
because
when
you
type
your
query
in
SDR
you
type
type
query,
open,
brace
and
then
you
never
add
the
underscore
underscore
schema
field,
and
if,
after
that
you
would
start
adding
the
schema
type,
then
it
feels
a
bit
weird
and
I.
Think
Ivan
was
mentioning
that
until
now
we
did
not
want
to
do
that,
but
maybe
someone
has
more
content
more
context
here.
H
H
H
H
K
K
I
I
don't
know
if
this
is
an
example.
That
kind
of
so
one
example
I
was
thinking
about
was
integer
definition,
where
I
think
we
we
specifically
said
graphql
needs
to
use
like
32-bit
interest
instead
of
like
64.
K
H
A
A
H
So
moving
forward,
if,
if
you
want
to
take
a
look
at
these
pull
requests,
I
don't
know
what
the
process
is
like,
typically
for
this
kind
of
stuff.
So
this
pull
request
is
about
adding
appendix
C.
H
It's
quite
convenient,
I
mean
even
for
Apple
kotlin.
Having
this
other
source
of
Truth
means
that
we
can
just
copy
paste
it
and
be
lenient
to
what
the
user's
inputs
like.
If
they
give
us
directive
definitions,
we
are
going
to
reuse
the
user
provided
once,
but
if
they
don't,
we
can
reuse
the
spec
provided
once
so.
It's
a
nice
centralized
place
to
to
do
this.
One
question
on
this
I
realized
earlier
today.
Is
it's
adding
descriptions
to
the
type
definitions?
A
H
L
I
really,
like
the
appendix
I,
think
that's
useful
independently.
We
have
in
the
relay
compiler
I
know
we
have
basically
an
sdl
of
these
scalar
types
that
we
use
as
like
when
we
create
the
schema
object.
It's
like
yeah,
we
always
read
in,
and
so
it
would
be
nice
if
we
could
actually
just
use.
What's
in
the
spec.
H
F
H
So
10
36,
which
suggested
that
we
added
a
note
about
introspection
types
I,
don't
want
to
go
too
too
deep
in
the
in
the
thief,
but
this
is
it
so
maybe
what
I'm
going
to
do
next
after
this
scroll,
unless
there
are
other
like
opinions,
is
actually
change.
This
pull
request
to
remove
language
and
remove
some
of
this
must
and
May
and
just
leave
it
open
to
and
add
some
language
to
say.
This
is
open
to
interpretation
for
two
links.
L
Tools
yeah,
it
might
be
that
what
we're
really
trying
to
do
here
is
basically
what
you
provide
in
the
sdl
is
what
your
consumers,
like.
You,
provide
the
information
in
the
sdl
that
your
consumers,
your
tooling
consumers,
essentially
need,
and
so
sometimes
that
might
be
like
if
you're
handwriting,
an
sdl,
you
don't
want
to
be
handwriting
all
of
the
like
underscore
underscore
or
eat
stuff.
L
L
Yeah
I
think
of
the
STL,
does
a
few
things
right
now.
It's
like
it's
used
for
people
to
write,
schemas
like
handwrite
and
do
schema
First
Development,
and
then
it's
used
for
tooling,
for
instance,
for
Ides
and
like
the
schema
that
you
hand
write
well,
your
tooling
might
have
a
whole
bunch
of
types
that
are
generated
between
the
handwritten
schema
or
the
like,
resolver
first
schema
that
is
produced
and
the
schema
that
you
want
the
tooling
to
actually
consume
like
we
have
a
bunch
of
like
for
each
type.
L
G
L
Do
need
it
in
our
tool
link
and
like
we
use
the
sdl
for
that.
It's
not
like
a
spec
compliant
usage
of
the
sdl.
Should
it
be
spec
compliant
I.
Don't
know
like
do
we
want
to
make
it
so
that
any
tooling
usage
of
the
sdl
is
spec
compliant
or
is
the
spec
sdl
truly
like?
If
you
have
a
graphql
ecosystem
like
this,
is
the
shape
that
the
spec
must
be,
and
then
you
can
do
whatever
transforms
or
the
shape
of
the
sdl?
And
then
you
can
do
whatever
transforms.
H
But
language
like
scalar
definition
must
not
be
in
sdl
like
this
is
the
dangerous
thing,
because
we
are
all
using
sdl
in
a
lot
of
places
and
someone
that's
new
to
the
specification
is
just
going
to
to
look
at
this,
and
actually
this
was
in
the
issue
like
it's
a
real
problem,
because
it's
in
the
spec
yes,
but
turns
out.
L
I
think
that
there's
I
I
actually
am
talking
through
this
a
little
I
think
I
would
lean
towards
having
one
spec
definition,
which
is
basically
like
the.
If
your
server
gives
you
an
sdl
like
this
is
what
the
sdl
will
look
like.
This
is
what
will
be
available
from
like
basically
the
default
sdl.
Anybody
can
access
any
server
that
provides
a
mechanism
of
like
downloading
its
sdl.
This
is
this
is
the
shape
of
that
STL,
so
it
doesn't
include
the
scalers
it
doesn't
or
it
doesn't
include.
L
The
built-ins
doesn't
include
whatever
blah
blah
and
then
on
top
of
that,
like
the
sdl
provides
a
means
of
having
those
built-ins
like
you
can
use
those
built-ins.
But
that
is
not
what
the
like.
If
you
just
ask
a
server
for
their
sdl,
you
will
not
be
getting
those
built-ins
or
or
vice
versa.
Maybe
we
always
give
those
bills
a
time,
but,
like
I,
think
there
is
value
in
having
a
known
shape
of
what
to
be
spec
compliant.
Every
sdl
producer,
like
every
graphql
executor
that
produces
an
sdl,
will
produce.
L
L
Yeah,
it's
like
the
syntax
is
valid
if
we
include
the
built-ins,
but
that
is
not
what
the
server
will
or
like
the
server
will
only
provide
built-ins.
If,
for
instance,
it
is
not
conformant
or
if
it
doesn't
include
these
things
or
or
maybe
we
just
always
include
the
built-ins,
always
because
we
really
should,
or
some
subset
of
built
I
don't
know.
D
I
think
I
can
weigh
in
on
on
some
of
this.
Basically,
when
you
want
to
build
a
graphql
schema,
you
can't
build
a
graphql
schema
from
arbitrary
sdl,
for
example,
stuff.
That
includes,
let's
say
the
the
one-off
directive
or
other
things.
If
your
actual
implementation
doesn't
support
that,
so
you
can't
give
an
STL
that
has,
for
example,
a
new
scalar
type
that
graphql
has
specified,
but
your
server
doesn't
support.
D
So
what
you
effectively
need
is
this
sdl
with
all
of
those
things
removed
and
then
you
build
the
schema
and
you
add
the
introspection
and
the
built-in
scalers
and
the
built-in
directives
that
you
support.
On
top
of
that,
so
that's
one
use
case
for
the
STL
is
building
the
schema,
but.
G
H
That
first
use
case
your
server
could
very
well
do
an
error
if
it
sees
something
that
it
doesn't.
Support
like
it
doesn't
support
one
off
and
you're
feeding
it
the
one
of
the
active
it's
an
exception.
H
D
H
H
D
The
problem
with
that
is,
you
would
be
setting
up
a
situation
where
you
say
here
is
an
STL
that
I
want
you
to
implement,
and
if
I've
missed
something
out
of
introspection,
then
you
must
not
Implement
that
at
which
point
it
doesn't
actually
conform
to
the
graphql
spec,
perhaps
or
at
least
not
maybe
to
the
latest
version.
There's
a
lot
of
that
you'd
be
interested
you'd,
be
introducing
a
huge
number
of
edge
cases
there
and
making
sure
that
the
sdl
that
you
feed
into
the
server
is
something
that
it
a
can.
D
Implement
and
B
is
complete,
is
I,
think
going
to
be
quite
challenging.
A
H
A
H
D
But
if
your
server
has
no
usage
of
32-bit
end,
then
a
it's
not
only
in
the
STL
already
and
B,
even
if
we
included
everything
that
was
in
the
sdl
that
one
wouldn't
be
included
because
you
haven't
used
it,
but
I
know
that
that's
one
of
the
other
questions
that
you've
got,
which
is
about
the
all.
Only
things
that
are
used
should
be
included.
D
So
actually,
what
I
said
I
think
might
not
be
completely
correct,
because
introspection
has
usage
of
int,
so
I
think
if
you
were
to
try
to
not
support
int.
Yes,
then
you
couldn't
implement
the
specific
the
specification,
because
you
couldn't
Implement
introspection,
so
you
then
wouldn't
be
graphql
anymore.
Yes,.
H
L
We
probably
need
to
have
to
figure
out
what
are
the
situations
where
that
needs
to
be
true,
or
ought
to
always
be
true,
because
I
do
think
that
they're
you're
getting
at
something
important,
which
is
you
should
be
able
to
have
a
sdl
document
that
your
tooling
can
read.
That
does
include
these
scalar
definitions.
How
we
get
there
is
a
little
bit
like
it
might
require
redefining
what
we
mean
by
your
sdl
like
should
not
be
including
these
built-in
scalars,
like
what
does?
What
do
we
mean
by
your
sdo
or
the
type
system?
L
D
L
I
I
think
that
there
should
be
a
name
for
the
type
system
defined
document.
It's
like
the
executable
type
system
document
is
almost
or
like
the
resolver
type
system
document,
which
is
different,
but.
H
H
I
say
I
think
we
will
have
to
go
through
that.
Anyways
is
somewhat
important,
like
I
I
also
had
the
question
about
type
system
definition:
language
where
we
all
use
sdl,
so
that
might
also
some
be
something
we
want
to
to
iterate
on,
but
again
I
don't
want
to
get
too
much
into
the
big
picture
and
I'll
try
to
focus
on
these
small
things.
H
H
D
Awesome
I
suspect,
with
the
graphql
conf
coming
up.
People
might
be
a
bit
short
on
time
for
reviews
like
this,
but
hopefully
we'll
get
some
and
if
you're
there
we
can
always
discuss
it.
Okay,
let's
move
on
to
relay
error
handling,
so
itema.
I
Hey
everyone,
so
let
me
just
share
my.
I
J
I
Yes,
awesome
so
hi
everyone
I'm
me
tomorrow,
I
work
on
infrared
meta
and
I
work
with
Ryan,
holdren
and
I'm
we're
working
with
Jordan
and
Eldridge
and
Tiana
on
the
specific
feature
in
relay
that
we
wanted
to
present
the
proposal
for
today.
The
reason
we're
presenting
The
Proposal
is
so
that
people
are
aware
of
the
direction
that
we're
thinking
of
taking
Can
comment
on
it.
I
I
I
I
So,
first
of
all,
the
the
current
state
of
the
world
right
now
is
that
a
in
graphql
when
a
server
throws
an
exception.
Graphql
coalesces
it
into
a
null
and
the
errors
themselves
actually
do
end
up
on
the
client
side.
But
they
end
up
in
the
form
of
metadata
that
isn't
currently
used
by
any
client.
I
As
far
as
I
know,
and
and
that's
as
opposed
to
like
what
some
people
think
that
happens,
is
people
expect
it
to
actually
throw
like
you
know,
like
a
network
network
request.
Would
the
problem
with
that
is
that
it
kind
of
creates
like
an
ecosystem-wide
trade-off,
where
you
have
to
decide
whether
you
want
to
discard
the
query
entirely,
meaning
I
have
it
like.
I
If
it
throws,
then
then
you
just
have
a
null
and
do
nothing
with
it
or,
and
you
also
need
to
you-
have
the
problem
where
you
can't
discern
whether
a
null
is
valid
and
all
meaning.
It's
supposed
to
be
no
or
if
it's
a
no
that's
derived
from
an
error.
I
So
the
options
are
basically,
you
can
opt
for
robustness
where
you're
kind
of
quote
unquote,
rendering
at
all
costs
and
the
null
is
there
to
do
that
right.
I
So,
if
one,
if
one
field
errors,
then
everything
else
still
renders
properly
and
we
just
kind
of
return
that
one
field
as
null
the
problem
with
that
is
that
we
are
aren't
able
to
delineate
the
nulls
from
the
errors
and
also
we
a
lot
of
Engineers
kind
of
forget
that
this
is
how
graphql
Works,
so
they
just
kind
of
like
handle
the
null
the
null
type
case
and
forget
that
that
null
type
case
can
possibly
mean
that
something
went
wrong
on
the
server
side.
I
It's
completely
transparent
to
them.
They
don't
realize
it
sometimes
and
actually
from
talking
to
Engineers
to
product
Engineers.
A
lot
of
them
will
find
out
about
it
then
forget
about
it
and
continue
continue
to
work
with
that.
So
it's
actually
a
really
big
problem.
The
other
option
is
correctness.
I
So
that
means
basically,
if
anything
in
this
query,
if
anything
in
this
query
is
erroring
on
the
server
side,
throw
the
entire
thing
out,
meaning
throw
at
the
query
level
and
nothing's
rendered
basically
ensuring
that
you
don't
render
incorrect
information
by
mistake.
I
Other
significant
side
effects
of
this
are
also
that
that,
if
you're,
if
you're,
writing
after
reading,
you
can
inaccurately
write,
nulls
back
to
the
server
side
and
also
a
big
problem-
is
that
null
can
of
course
be
coerced
into
a
zero
in
JavaScript
which
can
cause
you
to
render
wildly
inaccurate
information.
Imagine
you
know,
like
you,
know,
you're
supposed
to
render
an
actual
number,
and
then
you
receive
null
and
render
that
as
a
number.
Instead,
it
can
be.
I
It
can
very
widely
and
be
very,
very
destructive
to
any
product,
so
incomes
relay
are
handling.
Essentially
I'm
gonna
go
through
the
the
different
features.
There
are
only
about
two
features,
but
the
illustrations
hopefully
will
help.
You
understand
the
direction.
The
first
is
that
we
would
be
switching
fields
from
returning
null
to
throwing
by
default.
I
That
would
mean
that
it
would
actually
throw
a
JavaScript
exception
if
a
if
there
is
a
server
error,
and
you
would
still
be
able
to
opt
in
to
the
previous
Behavior
with
the
directive
with
a
an
argument
on
a
catch
directive
right
so
we
are,
we
would
be
providing
a
way
to
opt
back
into
the
old
Behavior.
That's
incredibly
important,
especially
for
migration.
I
You
see
two
examples:
you
see
an
example
where
there's
absolutely
no
catch
and
basically,
if
name
throws
everything
throws
and
in
the
second
example,
you
see
a
functional
component
in
react
when
you
use
a
react
hook
with
a
graphql
query
in
in
the
new
Behavior,
essentially
throwing
the
exception
would
allow
you
to
wrap
this
function
in
an
error
boundary
and
which
I'll
talk
about
a
little
bit
later
and
continue
to
render
the
rest
of
the
page
appropriately.
But
not
this
component.
I
The
catch
directive
will
allow
you
to
to
Mark
a
field
as
catch,
and
that
would
mean
that
any
field
that
throws
an
exception
on
the
server
side
below
that
field,
a
field
that
has
that
that
directive
would
surface
the
exception
and
would
not
would
not
return
the
data
below
it
and
then,
and
then
the
user
can
handle
that
data
appropriately.
I
I
I
There
is
an
example
of
the
catch
directive
performing
a
catch
so
in
this
example,
if
you,
if
you
have
catch
on
name
and
Nate
and
and
name
errors,
then
you
would
have
name,
then
the
current
behavior.
Sorry,
the
graphql
response
would
have
a
null
a
name
and
the
metadata
of
Errors
would
have
the
error,
and
what
relay
would
provide
is
the
breed
appropriately
and
then
name
would
have
an
exception
on
it
to
be
handled
without
throwing
an
exception
itself.
I
Here's
an
example
where
you
have
catch
on
a
parent.
The
same
exact
case
name
throws
right,
but
at
this
point
the
only
difference
is
the
graphql
response
is
exactly
the
same.
Relay
response
would
be
that
pet
would
have
the
the
exception
on
it,
because
that's
where
the
catch
directive
is.
I
Okay,
again,
opting
back
into
null
would
look
something
like
this.
You
just
have
an
argument
on
the
directive
and
then
it
would.
It
would
provide
the
response
that
you
receive
now
nowadays.
I
Some
positive
side
effects
of
this
are
full
control
over
the
response
handling.
You
no
longer
have
ambiguity
over
what
a
null
means.
You
don't
have
the
trade-off
of
robustness
versus
correctness.
I
I
Basically,
the
required
directive
says
that
that,
if
you
put
that
that
directive,
the
null
values,
then
then
the
field
is
not
null
and
it'll
throw
an
exception.
If,
if
it
is
the
the
decisions
we
came
up
with
over,
there
is
that,
if
required,
throws
below
a
catch,
the
catch
would
handle
that,
as
as,
if
it
were
just
a
server-side
exception,
and
a
side
note
also
is
that
eventually
required
at
required
can
be
replaced
by
ccn's
exclamation
mark
in
terms
of
client-controlled.
I
So
when
CCN
is
implemented,
exclamation
points
would
be
the
same
as
required
inside
a
cache
like
I
just
said,
and
the
difference
between
catch
to
null
and
CCN
question
mark
would
be
that
the
the
question
mark
in
CCN
makes
Fields
nullable,
whereas
the
catch
null
returns
a
no
when
something
is
thrown
in
on
the
server
side.
So
there
is
a
slight
difference
there.
We
we
definitely
like
took
that
into
account
some
notes
on
our
progress.
I
I
Jordan
also
shared,
like
kind
of
a
wider
view
of
true
null
ability
that
this
kind
of
fits
into,
we
do
have
a
straw
man,
that's
nearly
ready
to
be
published
widely.
I
We
just
have
a
couple
kind
of
ergono
ergonomic
things
to
work
out,
including
kind
of
like
what
the
response,
what
the
user
experience
for
product
engineer
would
be
when
using
the
response
from
this,
which
is
very
important,
and
we
are
implementing
a
prototype
already
we're
about
50,
complete
yeah
and
we're
just
really
really
excited
about
this
I
think
it'll
be
a
really
good
Improvement
to
the
user.
Experience
on
the
relay
side.
K
So
I
have
some
question
on
like
how
this
oh
I
guess:
Alex
and
Anthony
both
have
hands
up,
but
I'll
I'll
just
quickly
go
first.
So
the
question
is
related
to
like
how
the
engineers
are
going
to
kind
of
call
into
the
Getters
API.
Are
you
essentially
gonna?
So
this
is
more
on
the
JavaScript
side.
Are
you
gonna
like
represent
all
these
like
generated
types
as
a
union
now?
K
I
Yeah,
so
we
have,
we
have
a
couple
of
this
introduces
kind
of
like
a
a
couple
of
different
options
in
that
way
for
the
user
experience,
so
one
option
is
to
just
have
a
regular
Union.
That's
you
know,
type
or
error
right
and,
and
just
have
the
user
provide
for
the
type
is
generic
and
handle
it
accordingly.
I
The
other
would
be
to
provide
like
a
discriminated
Union
which
has
like
a
type
failure
type
success,
and
then
the
value
or
the
error
itself,
and
that
kind
of
like
type
system
wise,
is
really
helpful
to
to
discriminate
and
further
down
the
line
not
have
to
worry
about
it.
I
The
other
interesting
option
that
we
have
that
we're
kind
of
playing
around
with
is
introducing
a
class
that
that
you
can
access
the
value
through
a
two
Val
to
value
or
provide
like
default
if
it
does
throw
an
exception
and
all
kinds
of
It
kind
of
opens
the
world
of
having
custom
methods
on
it.
I
So
that's
an
example
of
something
that
we're
still
working
through.
We
are
actually
working
directly
with
the
team
that
was
originally
working
on
relay
and
Consulting
with
them,
and
we
have
a
meeting
with
them
later
today
and
that's
one
of
the
things
we'll
be
discussing.
So
like
really
good
question
and
and
yeah
we're.
That's
one
thing,
that's
really
top
of
mind
for
us.
G
I
can
go
I
apologies
if
I
missed
saying
this.
I
just
want
to
clarify,
what's
being
proposed
for
myself,
so
the
catch
would
be
a
directive
defined
in
the
graphql
schema.
Is
that
right.
C
Yeah,
this
would
just
be
a
directive
that
is
handled
by
relay
and
is
interpreted
entirely
client-side.
So
this
proposal
doesn't
need
participation
from
the
server,
and
so
it
would.
It
would
be
a
valid
Insight
of
relay
code
for
the
schema
that
relay
presents
to
to
tooling
but
would
not
would
be
compiled
out
by
relay.
I
Yeah,
this
is
kind
of
why
I
preface
this
by
by
saying
that
this
was
a
relay
feature
and
we're
presenting
this
here
as
kind
of
an
FYI
and
to
get
feedback
and
questions
if
there
were
any.
But
it's
not.
It's
not
like
a
graphql
spec
proposal.
G
Okay,
that
actually
clarifies
I
think
everything
for
me.
Thank
you,
sorry
about
it.
E
I
guess
my
question
is
kind
of
related
to
that.
First
of
all,
I
just
want
to
say
I
love.
This
idea,
some
of
the
CCN
conversations
that
have
come
up
recently
around
the
error
bubbling
have
really
like
I
think
maybe
inspired
this
or
influenced
this
coming
up,
but
I
honestly
think
that
we
should
do
something.
E
That's
similar
to
this
on
Apollo
client
as
well,
when
when
we
Implement
CCN
is
there
any
first
of
all
my
question,
I
guess
is:
does
this
unblock
relays
use
case
with
the
relays
concerns
about
the
CCN
proposal
around
both
the
bang
and
the
question
mark
operator,
and
is
there
any
possibility
of
this
going
from
being
a
client-side
directive
to
something
that
we
want
to
like?
We
intend
to
make
a
spec
proposal
about
this
in
the
future.
E
I
This
processing,
so,
first
of
all
to
your
point
about
Apollo,
that's
definitely
like
our
hope.
Our
hope
is
that
that
other
clients
also
adopt
this.
We
think
it's
a
good
direction
to
your
second
question,
I
think
Jordan.
If
you'd
like
to
answer
that,
because
you,
you
definitely
thought
deeply
about
the
true
null
ability
and
the
interplay
with
CCN,
would
you
like
to
address
that.
C
Yeah
I
think
there's
pretty
good
alignment
with
CC
and
I
outlined
it
a
little
bit
in
the
the
post
I
made
in
the
CCN
working
group
about
how
this
fits
into
a
larger
story
of
allowing
allowing
smart
clients
to
expose
the
sort
of
true
null
ability
of
graphql
resolvers
to
the
client
in
a
way
that
preserves
some
degree
of
robustness
in
terms
of
support
on
the
server
I'm
I'm,
not
sure
I
think
it
makes
sense
to
have
this
for
smart
clients.
I.
C
Think
like
the
the
Gap
is
like
the
the
server
response
models,
data
that
has
errors
in
those
locations
and
it's
sort
of
an
encoding
trick
that
we
keep
that
as
metadata
rather
than
putting
those
in
line
and
smart
I.
Think
smart
clients
have
the
ability
to
do
better
than
that
and
to
sort
of
present
those
as
inline
to
the
user.
C
L
One
thing
to
point
out
that
Jordan
has
in
his
write-up
is
specifically
when
you
have
non-nullable
Fields,
so
NMR
didn't
get
deep
into
this,
but
when
you
have
non-nullable
Fields
they
blow
up
beyond
the
scope
of
just
the
field
and
Benji
pointed
out.
Oh
really,
I
could
just
start
putting
question
mark
on
all
the
fields
and
that's
true,
that's
exactly
how
like
client
control
nullability
gives
us.
L
We
could
basically,
as
Jordan
points
out
in
his
post,
that
we
could
basically
migrate
towards
a
world
where,
on
the
server
you
give
your
true
null
ability
in
smart
clients
put
question
marks
where
they
don't
want
that
non-nullable
field
to
blow
up
beyond
their
current
point,
but
they
can
still
use
catch
to
handle
when
there
is
in
fact
a
true
error.
So
it
allows
yes
in
this
response
format.
There
will
be
a
null
at
this
point
like
this
field.
That
is,
never
nullable
will
be
null.
E
I
H
Presentation
I
had
two
questions.
The
first
one
is
really
quick
is.
Can
you
share
your
sleigh
in
your
slides.
I
Yeah
yeah
definitely
I'll
share
them
after
this
call,
I'll
show
them
in
the
a
pull
request.
Thank.
H
You
and
second
one
was,
if
you
have
I,
think
you
do
like
you,
you
merge
fragments
in
the
relay
compiler
right
like
if
two
components
have
used
two
different
fragments
they
are
going
to
be
made
in
the
in
a
root.
Query
am
I
correct
that.
I
I
believe
so
Jordan.
Can
you
confirm
that.
C
Yeah
so
because
this
is
implemented
entirely
by
by
relay
entirely
at
read
time,
it
doesn't
actually
affect
how
the
response
gets,
sent
or
received
from
the
server
it
does.
It
doesn't
impact
what
we
ask
the
server
to
do.
It's
simply
a
function
of
how
we
read
out
that
particular
fragment,
so
it's
isolated
per
fragment.
So
if
one
fragment
marks
a
field
as
catch
and
another,
doesn't
they
will
observe
different
behaviors.
C
Required,
similarly,
is
implemented
entirely
at
read
time
and
so
different
fragments
can
have
different,
like,
whereas
CCN
struggles
with
the
the
lack
of
fragment
isolation
in
the
in
a
required
field
in
a
field
of
requested
by
two
sibling,
fragments
must
have
similar
require
similar
CCN
annotations
relays
required
is
not
constrained
by
that,
because
it's
implemented
at
read
time.
So
two
different
fragments
can
read
out
with
different
semantics.
Okay,.
I
Was
my
second
question?
Awesome
Ernie.
J
Yeah
kind
of
similar,
like
two
two
questions,
I
just
like
to
clarify
like
the.
If
you
go
to
the
slide,
that
actually
shows
where
that,
like
error,
type
kind
of
like
construct,
looks
like
yeah
right.
So
I
I
assume
that,
like
the
error
that
you're
in
that
in
that,
like
type
failure
thing
like
that
error
has
the
message
that
the
server
responded
with
right
like
that
is
the
like.
It
gives
you
that
detail.
If
you
have
that
information
right,
yeah.
I
Yeah,
like
I,
said
the
like
the
synthetics.
I
Ergonomics
of
the
response
are
that
this
is
just
for
illustration
purposes.
You
can
see
yeah
Reed
isn't
even
wrapped
in
anything.
It
just
provides
the
value
right,
that's
right,
but
in
general
yeah
the
the
error
itself
will
be
like
the
user
will
have
the
ability
to
use
whatever
error
was
surfaced
in
the
metadata.
C
Yeah
one
one
piece
of
color
there
is
that
we
are
actually
intending
to
add
support
for
intentionally
making
some
types
of
Errors
opaque
or
for
like
sort
of
allow
listing
only
certain
errors.
We
believe
that
giving
product
Engineers
access
to
Raw
errors,
which
may
be
just
you
know,
like
error
messages,
unintended
for
user
consumption
and
which
are
not
typed,
is,
is
a
recipe
for
danger.
C
So
we
we
have
a
certain
subset
of
Errors,
which
we
know
are
safe,
which
we
allow
through.
But
we
intend
to
make
that
like
user
configurable.
J
K
J
It
might
encourage
people
to
like
start
displaying
these
messages,
which
are
like
not
translated,
or
you
know
any
of
the
issues
that
come
fall
out
of
that,
but
the
other,
the
other
question
I
had
was
the
like.
That
directive
had
a
couple
like
like
it
was
like
the
two
null
option
that
you
had
on
there
like.
Are
there
other
any
other
options
like
you've
discussed
like
that?
That
would
support
other
than
just
like
saying
set
this
back
to
normal
dollars.
That,
like
is
that
bad
for
so
far.
I
That's
that's
a
that's
a
good
question,
so,
right
now,
right
now
as
it
stands,
our
proposal
has
only
two
null
or
two
result,
which
essentially
just
means
catch
without
any
argument.
I
The
reason
we
decided
to
go
with
that
is
because,
because
the
queries
are
kind
of
like
statically,
typed
and
and
and
just
written
out,
and
and
that's
it,
they,
you
can't
like
pass
a
variable
dynamically
into
it
into
that
definition
itself.
We
decided
that
it
would
be
better
instead
to
let
the
user
provide
whatever
defaults.
They
want
or
anything
like
that
at
handling
time.
Instead,
right.
M
Hi
so
I
have
a
few
questions
about
I
guess
two
questions.
One
is
about
the
behavior
of
let's
say,
multiple
errors
occurring
in
a
selection
set,
and
especially
with
respect
to
statically
typing
that,
and
also,
if
Ace,
if
this
is
currently
supported
only
in
relay,
but
we
would
ultimately
like
to
support
you
know.
More
more
clients
would
like
to
support
I
want
to
ask
about
what
the
schema
will
look
like
in
the
end.
M
So
first
question
like:
is
there
a
path
forward
for
how
are
multiple
errors
in
a
selection
set
going
to
be
handled
in
that?
Like
are.
M
To
have
an
error
array
at
the
catch
boundary,
are
these
errors
going
to
be
associated
with
the
field
that
errored
out
or
is
it
going
to
be
just
like?
This
is
a
a
bag
of
errors
that
occurred?
We
don't
know
exactly
where.
Maybe
you
can
introspect
them
to
determine
where
and
likewise
like,
if
a
given
field
only
produces
an
error
of
a
of
a
single
kind
like
a
the
name,
is
too
long?
That's
the
only
possible
error
when
you
select
the
name
field.
M
Does
that
type
information
is
that
type
information
preserved
at
and
accessible
to
the
reader.
I
D
I
So
that's
that's
the
answer
to
the
first
one,
the
second
one
about
the
the
schema
is
that
again,
this
is
a
fully
client-side
feature.
We
don't.
We
don't
intend
to
propose
any
schema
changes
in
this
specific
proposal.
It's
not
to
say
that
there
wouldn't
be
future
ones,
but
this
one
doesn't
include
any
of
them.
M
Okay,
I'll
clarify
the
second
question.
Sorry,
so,
if
you
get
a
single
error,
you'll
get
both
the
path,
and
the
error
is
that
right
of
which
subfield
aired
out.
Okay,.
M
But
it's
good
to
know
that,
like
thank
you
for
answering
that
my
question
about
the
schema
is,
it
seems
like
this
is
ultimately
working
around
the
fact
that
the
type
of
the
let's
say
the
name
field
is
just
string
or
null
or
just
string,
depending
on
whether
it's
nullable,
but
really
we
would
like
the
type
of
the
name
field
to
be
some
sort
of
Union,
of
like
error
of
an
error
type
and
a
an
okay
type.
M
So,
given
that
this
is
working
around
that
in
the
long
term,
like
does
relay
want
to
support
schemas
where
you
get
the
same
behavior.
But
the
actual
type
of
the
name
field
is
this
is
the.
M
Is
the
union
type
and
I
asked
that
because,
like
if
I
was
currently
designing
a
schema
from
ground
up
and
adopting
relay,
it
would
be
preferable
to
just
like
type
all
of
the
fields
as
some
sort
of
Union
of
okay
and
error
types,
and
then
it
would
be
unfortunate
if
I
had
to
type
that
name
field
as
a
just
as
a
string
and
therefore
lose
the
static
type
information
about
what
kind
of
errors
are
allowed
on
that
field
and
for
there
to
be
no
sort
of
no
upgrade
path.
L
Rob
you're
describing
the
desire
for
generic
types,
or
at
least
an
extra
result,
type
which
yeah.
That
would
be
it.
M
L
Yes,
yeah
we've
had
discussions
about
generics
that
goes
beyond
the
scope
of
this,
but
yeah.
It
would
be
great
if
we
had
generics
and
graphql
and
we
do.
The
list
type
is
a
generic
type.
It.
I
Yeah
I
mean
I
I.
Think
that,
like
on
the
on
the
relay
side,
I
mean
like
I,
suppose
we
we
could
consider
adding
a
generic
error
response
as
well,
but
I
feel
like
that
would
be
I
feel
like
having
a
uniform
error
response
is
probably
the
the
best
place
to
to
put
the
line
at
this
proposal.
F
I
Thanks
yeah
and
yeah:
does
anyone
have
any
other
questions.
I
Awesome
we're
a
little
bit
overtime,
I
think,
but
if
there.
D
Thank
you
for
sharing
that
excellent
work,
very
interesting.
D
Okay,
so
we
are
really
shy
on
time.
We've
got
about
22
minutes
left
and
two
20-minute
topics
to
go.
So
what
I'm
gonna
do
is
I'm
just
gonna
mention
mine
and
then
we'll
move
straight
on
to
the
other
one.
So
you
may
have
heard
this
topic
before,
whilst
working
on
the
incremental
delivery
pull
requests.
D
Both
yaakov
and
myself
have
found
that
there's
this
common
refactoring
that
we
want
to
do
to
the
specification
itself,
and
essentially
it
means
changing
the
core
algorithm,
which
is
execute
selection
set
to
instead
be
excellent,
execute
grouped
field
sets,
which
is
actually
what
we
do
under
the
hood
so
effectively.
D
The
first
line
of
execute
selection
set
is
right,
turn
this
selection
set
into
a
grouped
field
set,
and
then
we
run
that
so
effectively
it's
defining
or
renaming
that
algorithm,
removing
the
first
line
refactoring
in
the
various
places
where
it's
cooled,
and
it
also
means
that
we
no
longer
need
to
create
this
sort
of
virtual
selection,
set
that
we
used
to
Via.
D
There
are
some
interesting
questions
in
there
if
you
want
to
help
with
the
naming
of
things.
So
you
know
if
you
like
that
problem,
please
get
involved,
but
also
yeah.
If
you
have
General
feedback
on
that,
I
think
it
would
be
nice
one
of
the
things
that
I
find
quite
pleasing
about
this.
Is
it
actually
simplifies
down
the
execute
query,
execute
mutation
and
execute
subscription
event,
algorithms,
because
it
pulls
out
more
of
that
common
logic,
which
is
very
pleasant.
D
One
thing
that
I'm
not
super
keen
on
is
that
it
makes
whether
or
not
we're
executing
it
serially
a
argument,
rather
than
like
a
flowery
language
that
we
put
around
it.
So
that
will
be
a
fun
one
but
yeah
anyone
interested
in
this
topic
please
weigh
in
and
that
pull
request.
It
is
graphql
spec,
pull
request,
number
1039.
D
Okay,
that'll
do
for
me
so
on
to
Young
to
talk
about.
Oh
sorry,
client
controlled
nullability
is
what
we're
talking
about
now
so
on
to
you
again.
B
Cool
so
I'm
glad
we
talked
about
a
lot
of
the
liability
related
things
today.
B
So
this
is
so
we
made
a
about
two
months
ago
in
the
working
group
meeting,
we
talked
about
it's
just
stripping
down
the
proposal
down
to
the
very
Basics
which
is
to
just
have
the
bank,
and
we
found
that
the
the
semantics
of
the
question
mark
was
very
unclear.
We
talked
about
whether
it's
like
errors,
throwing
and
catching
Behavior,
or
is
it
changing
just
availability
of
the
field
from
the
client
side,
and
we
just
found
that
over
the
past
two
years.
B
That
just
is
the
issue
that
blocks
the
unproposal
to
go
forward.
So
we
wanted
to
strip
out
the
question
mark
from
the
the
RFC
and
just
include
the
bank
and
reach,
and
then
the
bank
semantics
will
be
to
just
change
the
the
liability
of
the
field
from
if
it's
no,
then
to
not
know
so
that
the
type
generation
the
concept
can
reflect
that,
and
so
we
want
to
go
to
the
next
stage
on
stage
three
with
that
kind
of
simplified
proposal.
B
I
want
to
see
if
there
are
any
concerns
about
stripping
out
the
question
mark
from
The
Proposal
and
and
it's
from
what
we
just
talked
about
for
Relay
error
handling.
It
looks
like
the
expectation
from
the
release
side
is
that
the
question
mark
will
act
as
a
simple,
no
designator,
which
just
change
the
null
to
null
at
the
execution
time
and
I,
so
just
kind
of
I'm
curious
what
it
really
thinks
about
it
and
what
others
think
about
not
having
a
question
mark
at
this
stage.
C
Yeah
I
can
jump
in
there.
I
think
we
are
very
interested
in
the
question
mark
in
the
long
term,
as
we
sort
of
as
I
highlighted
in
the
post,
that
I
shared
I
think
it
does
give
us
a
path
towards
an
actual
fundamental
solution
to
the
problem
that
client
control
notability
originally
sought
out
to
solve,
without,
like
requiring
client
developers
to
sort
of
operate
blindly
by
peppering
the
world
with
exclamation
points
where
they
don't
actually
have
the
knowledge
of
whether
that
field
is
truly
null
or
not
so
like.
C
This
is
like
a
I
know
it's
taken
years,
but
like
this
is
a
realization.
I
only
recently
had
and
that's
as
came
out
of
this
discussion,
we
had
around
error
handling
and
like
if
clients
can
all
can
actually
Shield
the
user
from
error
nulls,
then
it
opens
up
a
whole,
a
whole
different
world.
C
That
said,
like
I,
don't
I
would
rather
us
like
wait
to
do
the
question
mark
annotation
then
do
it
in
like
the
wrong
way,
so
I
think
if
we
could
move
forward
with
it
like,
like
you,
said,
being
like
this
for
the
purpose
of
execution
of
this
selection.
It
simply
changes
this
field
to
be
treated
as
if
it
were
nullable.
C
That
is
like
an
excellent
outcome
for
us,
but
if
it
needs
to
be
done
as
a
second
phase,
I
think
that's
not
the
end
of
the
world
for
us.
So
it's
not
something
that
we're
like
hard
blocked
on
immediately.
L
I
was
just
going
to
take
on
the
the
outcome
from
the
error
handling.
Basically,
workshopping
we
did
was.
It
is
the
end
state
of
client
control,
nullability,
basically
reflecting
exactly
the
server
semantics
of
what
it
means.
So,
if
you
have
a
question
mark
that
means
that
this
field
is
treated
as
nullable
at
this
point
and
child
non-noble
Fields
bubble
up
to
null
there.
L
That's
like
total
ideal
for
error
handling
that
lets
us
start.
Transforming
is
like
one
of
the
big
problems
we
have
is
our
server
definitions
like
we
have
resolvers
that
in
the
actual
PHP
code,
like
the
field,
the
PHP
code
is
not
nullable,
but
we
mark
it
as
nullable,
because
dealing
with
non-nobile
fields
that
have
errors
is
really
harsh
for
us,
and
that
would
like
give
us
a
migration
path
to
having
the
client
under
truly
understand
what
the
server
nullability
is,
which
is
good.
C
I
think
one
other
piece.
Sorry,
just
a
tag
on
the
one
other
piece
about
the
question
mark
is
that
they're,
like
any
client
that
uses
a
normalized
store
or
consistency
store,
is
like
sort
of
that
that
can
cons.
Normalized
view
of
the
world
is
actually
like
damaged
by
null
bubbling,
where
we
actually
end
up
writing
bad
data
into
the
store
in
a
way
that
affects
others.
So
the
question
mark
would
also
be
valuable
for
us.
C
From
that
perspective
and
the
ability
to
opt
out
of
that
null
bubbling,
we
can
still
present
the
facade,
no
bubbling
to
the
clients
to
the
product
code,
but
for
our
ability
to
keep
our
store
consistent
and
not
like
end
up
with
artificial
nulls
in
the
response
that
we
then
have
to
normalize
into
the
store
would
be
super
valuable
too.
E
So,
like
I
said
before,
I
I
love
this
at
catch
director
that
you
guys
are
building
over
at
relay,
but
as
far
as
the
CCN
proposal
goes,
my
understanding
was
that
the
proposal
to
remove
the
question
mark
operator
from
CCN
for
this
first
phase
was
directly
a
response
to
the
concerns
about
error
handling
here.
That
seem
to
now
be
resolved
by
this
at
catch
directive.
So
for
the
people
who
are
working
on
CCN
actively,
is
that
does
that
change
what
you?
What
direction
you
want
to
head
in
here?
E
Do
we
want
to
still
proceed
with
this
simplified
version?
That
only
includes
the
bang
operator,
or
do
you
think
it's
now
more
viable
to
move
forward
with
both
with
the
initial
proposal
or
the
proposal
a
few
months
ago
that
we
had?
You
know
iterated
on
that
included
both
operators
and
then
perhaps
write
something
up
that
kind
of,
if
not
adding
it,
to
the
spec
kind
of
or
gives
a
formal
example
of
what
a
client
side
a
smart
client's
catch
directive
could
do
that.
E
Could
utilize
this
and
make
that
you
know
some
sort
of
it
doesn't
necessarily
be
in
the
spec,
but
something
that
allows
all
these
questions
and
all
these
issues
around?
How
do
we
handle
the
air?
The
error
handling
with
the
question
mark
on
clients,
there's
a
solution
for
that,
since
we
have
that
solution,
does
it
make
sense
to
go
back
or
to
having
the
question
mark
or
do
we
feel
like
it's
better
to
continue
on
with
this
incremental
approach
of
just
starting
with
the
bang
operator.
B
I
think
my
I
am
curious
to
hear
your
thought
Alex
too,
because
you
have
probably
more
historical
context,
but
my
I
know
that
I
think
relays
concerns
will
be
probably
that
result
given
like
Jordan
and
itamar
said,
but
I
do
worry,
that
there
are
like
I,
think
two
or
three
kind
of
kind
of
different
semantics
that
we're
considering
for
the
question
operator
and
then
I
just
do
not
want
to
open
that
conversation
again
like
not
to
say
that
the
end
state
of
the
CCN
is
without
the
question
mark
But
I
don't
want
to
can
reopen
that
and
maybe
have
another
like
three
to
six
month.
G
Yeah,
that
was
that
was
that
was
kind
of
my
take
too
like,
like
you
know,
relay,
had
concerns
about
the
semantics,
but
so
did
a
lot
of
other
people,
so,
like
I
I
think
you
know
like
I
I,
don't
think
the
question
mark
is
bad
I.
Think
it's
fine,
like
some
version
of
it
is
probably
great
but
I.
Think
the
the
original
bang
makes
something.
Non-Nullable
is
popular
and
easy
to
justify
and
would
be
easy
to
merge
like
I.
G
Don't
know
it's
not
fun
to
say,
but
it
it
it's
it's
like
you
know
political
right
like
just
merge
the
thing
that's
popular
and
then
we
can
talk
about
merging.
You
know,
figuring
out
the
stuff.
That's
less
popular
later.
L
L
Question
mark
needs
a
different.
It
needs
a
different
champion.
H
Maybe,
that's
one
risk
to
merging
the
exclamation
mark.
Now
is,
if
we
say
the
end
goal
is
we
want
to
have
true
null
ability?
H
G
That's
true
and
that
I
I
thought
Jordan's
thing
was
was
really
interesting
because
we've
been
our
our
goal
with
the
the
bang
operator
with
a
client
controlled
null
ability
to
has
been
to
adapt
to
behavior
that
server
developers
are
are
adopting
because
of
just
the
semantics
of
graphql
as
a
whole,
and
so
that's
one
way
to
look
at
it
and
then
Jordan
was
talking
about
how
the
other
way
to
look
at
it
is.
G
Maybe
we
can
actually
fix
the
behavior
of
server
developers
by
changing
the
way
you
know
get
changing
the
tools
that
that
client
developers
have
which,
which
is
interesting
and
maybe
there's-
maybe
maybe
that's
better
I,
don't
I
I,
don't
know
I'll
leave
that
up
to
folks
to
discuss,
maybe
that's
better
or
maybe
that
the
adapting
to
to
server
developer,
behavior
and
then
trying
to
get
people
to
shift
to
correct
behavior
is
is
like
it's
like
a
good
stepping.
H
Stone
I,
don't
know
sure
what
I'm
saying
is
as
a
community
as
a
limited
attention
span
as
well,
so
adding
more
Concepts
takes
time.
If
we,
if
we
introduce
a
bank,
we
have
to
explain
the
bank
and
blog
about
it
and
everything.
And
then,
if
six
months
later,
we
add
the
question
mark
and
we
say
remember
the
bangs
and
forget
about
it-
we're
changing
everything
again,
and
this
has
a
cost
which
we
might
be
okay,
with
just
pointing
out
like
in
southern
coast.
C
My
my
sense
is
that
they
like,
just
like
the
question
marks,
are
natively
like
arose
as
a
as
a
foil
to
to
the
bang.
I
think
they
do
make
sense
as
like
just
The
Primitives
that
make
sense,
and
also
just
you
know,
like
you
said,
the
community
moves
slowly,
even
if
we
do
say
like
hey,
we
have
a
picture
of
a
better
world.
C
It's
going
to
take
people
a
long
time
to
get
there
and
they
they
probably
need
Bank,
they'll,
probably
wait
to
get
there
so
I
I'm,
not
too,
like
while
I
do
I
do
think
that
we
can
get
to
an
end
state
where
bang
is
discouraged.
J
Yeah
I
think
the
only
thing
I
was
going
to
say
is
that
there
there
is
that
risk
of
like
if
you
introduce
the
bang
without
the
question
mark
people
won't
be
able
to
consume
one
without
the
other,
in
that,
like
I,
I
need
to
be
able
to
like
control
the
the
note
bubbling
that
happens
in
my
application
and
if
I
can't
do
that.
With
the
question
mark,
then
I
can't
like
adequately
adopt
the
bang
potentially
right,
like
there's
that
risk
of
like
I,
don't
want
this
I,
don't
wanna
I.
G
J
G
J
G
J
D
I'm
generally,
an
advocate
of
the
simple
bang
and
question
mark
operators.
I.E
just
changed
the
null
ability
just
seems
very
simple
and
straightforward
to
me.
That
said,
one
of
the
things
that
itamar
raised
in
the
presentation
was
effectively
when
you
have
this
null
bubbling.
You
can't
do
this
this
caching
anymore.
It's
not
safe
to
do
so
and
introducing
an
easy
way
for
people
to
cause
that
problem
to
be
more
of
a
problem.
More
often
is
maybe
not
the
best
idea.
D
M
I
was
just
going
to
point
out
very
quickly
that
so,
if
I
understand
correctly,
the
the
null
ability
bubbles
to
the
nearest
nullable
field,
and
so
if
somebody
I
I
think
it
would
be
very
appropriate
for
us
to
roll
out
just
half
of
this
and
then
message.
You
know
like
the
question
mark
operator
will
come
later
and
in
the
meantime,
if
you
want
to
play
around
with
this
add
a
magical
field
on
every
type
in
your
server.
That
is
nullable
that
just
refers
to
self.
M
And
then
this,
like
underscore
underscore
self
field,
would
be
the
would
effectively
act
as
a
as
a
catch
barrier
as
like
a
question
mark
barrier.
M
But
my
two
senses
that
I
think
it's
it's
appropriate
for
us
to
roll
forward
with
just
just
half
of
the
half
of
the
proposal.
As
long
as
we're
clear
on
the
messaging
that,
like
the
other
half,
is
coming
later,.
B
And
I
think
that
another
wrench
is
the
question.
Mark
takes
the
feature
Discovery,
or
at
least
that's.
That
was
this:
the
result
of
the
discussion
that
we
had
before
that
because
for
the
Federated
server
to
react
to
the
question
mark
correctly,
it
needs
the
future
Discovery
from
its
kind
of
dependencies
on
whether
they
support
the
the
question
mark
or
not,
and
that
would
add
a
lot
more
time
for
us
to
figure
out
so
I
think.
That's
one
more
argument
to
just
go
forward
with
the
question
mark.
This
is.
B
C
One
thing
I
want
to
I
want
to
clarify:
is
you
know
in
terms
of
the
additional
sort
of
Damage
Done
by
the
bang
right?
C
It
is
destructive,
and-
and
are
you
okay
with
encouraging
that
from
relays
perspective,
you
know
our
plan
is
to
to
implement
it
entirely
client-side
and
to
to
leave
the
server
request,
as
is
normalize
the
the
server
response,
as
is,
and
then
treat
it
similarly
to
required
today,
where
it's
actually
a
fragment,
isolated
version
of
We're,
going
to
pretend
that
fragment
isolation
exists
and
treat
it
as
a
as
a
read
time
semantic
which
gives
the
user
the
look.
C
You
know
when
they're
reasoning
locally
about
one
fragment
they,
they
observe
the
behavior
of
the
exclamation
point,
but
it
allows
us
to
have
a
scalable
app
where
not
every
component
has
to
know
about
every
other
potential
sibling
component.
H
One
issue
with
that
is:
if
your
users
start
copy
pasting
their
queries
in
graphical,
they
won't
get
the
same
result
as
what's
executed
by
relay.
Are
you
okay
with
that.
F
C
Existing
fragments
are
not
are
not
something
you
can
view
in
in
graphical
today.
H
The
thing
is
at
required
is
a
directive,
so
it
feels
okay
to
strip
like
bang
feels
really
core
to
the
language.
H
C
C
F
H
Yeah
that
wasn't
going
to
be
short
so
Christian
was.
Do
we
there's
a
question
whether
we
want
to
add
support
to
the
servers
and
if
we're
saying
everyone
is
going
to
use
the
bank
on
sophisticated
client
and
only
client
side,
I
mean
on
Apple
record
clean.
They
can
see
us
using
it
100
client
side
as
well.
So
considering
everything
do
we
still
want
to
include
the
back
end
and
execution
in
The
Proposal.
B
C
Playing
and
our
server
may
not
I
think
that
may
also
solve
the
graphical
problem
right,
like
our
server
won't
actually
support
bank
it'll
be
implemented
entirely
in
our
clients,
and
so,
if
you
try
to
paste
it
into
graphical,
the
server
will
be
like
what
is
that
I?
Don't
know
what
you're
talking
about
yeah
very
nice.
D
Okay,
thank
you.
Everyone.
This
has
been
an
excellent
discussion,
as
always
for
those
of
you
coming
to
graphqlcon
I,
look
forward
to
seeing
you
in
a
couple
of
weeks
time.
Otherwise
there
are,
there
is
still
I,
think
another
working
group
next
week,
I'm
not
sure,
what's
happening
with
the
one
after
that,
I
assume
we're
canceling
it,
because
it's
during
graphql
conf,
maybe
it'll,
be
in
person.
I,
don't
actually
know
otherwise,
see
you
next
month.
Thank
you.
Everyone,
zero.