►
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/
All for Naught: Client Controlled Nullability - Alex Reilly, Yelp
JW Marriott Austin, Room 402/403
Speakers: Alex Reilly
For over a year now, I along with many other developers from across the community have been working on the Client Controlled Nullability proposal. Client Controlled Nullablibliy is a new GraphQL feature that improves the client developer experience when working with null fields. In this talk we’ll go over what it is, why it came about, our experience working with the GraphQL Working Group and what I learned about working in open source as part of my job at Yelp, a platform that connects people with local businesses.
A
All
right,
yeah,
hello,
graphql
conf,
today
we're
going
to
be
talking
about
a
new
proposal.
I've
been
championing
for
the
past
year
called
client
controlled
nullability,
and
this
is
what
a
year
of
working
group
meetings
looks
like
hi,
I'm
alex
I'm
an
ios
developer
at
yelp,
I'm
on
our
data
networking
team,
whose
current
charge
is
to
transition
the
company
from
rest
to
graphql.
I
work
on
ios
tools,
libraries,
documentation
and
educational
resources.
A
A
A
quick
word
about
the
company
I
work
for
yelp
produces
mobile,
apps
and
websites
that
connect
consumers
to
great
local
businesses
and
provides
businesses
the
tools
they
need
to
thrive.
The
company
is
fairly
large
with
more
than
a
thousand
engineers.
That
kind
of
scale
means
that
investments
in
tooling
pays
dividends
that
you
wouldn't
get
at
a
smaller
company.
This
presentation
is
about
one
of
those
investments,
I'll
plug
some
positions.
A
There
are
a
few
reasons:
a
schema
author
might
make
a
field
nullable,
for
example,
a
user
may
or
may
not
have
a
phone
number.
So
for
data
modeling
reasons,
the
phone
number
field
is
made
nullable.
However,
many
schemas
adopt
the
policy
of
making
most
fields
nullable
for
data
preservation
reasons,
as
the
official
graphql
documentation
recommends.
In
this
illustration,
I
borrowed
from
apollo's
documentation.
A
A
In
this
case,
every
field
is
non-nullable,
so
the
response
data
field
field
itself
is
set
to
null
for
many
applications.
This
kind
of
data
loss
is
undesirable,
so
keeping
every
field
nullable
allows
for
partial
results,
because
if
a
nullable
field
resolves
to
null
the
total
number
of
fields
lost
is
one.
However,
this
mechanic
means
that
many
many
fields
are
nullable
that
are
never
expected
to
resolve
to
null.
In
the
happy
past,
during
normal
execution,
we
decided
to
more
or
less
follow
the
best
practices
at
yelp,
so
fields,
so
most
fields
in
our
schema
are
null.
A
This
preference
for
nullability
caused
compile
time
problems
for
developers
working
in
type
languages
like
kotlin,
typescript
and
swift,
which
explicitly
require
null
handling
and
caused
hidden
problems
for
developers
working
in
other
languages
like
javascript
and
python.
It
was
very
evident
when
we
started
running
developer
experience
surveys
with
teams
trialing
graphql
at
yelp.
You
can
see
some
of
their
feedback
here
that
problem
being
that,
in
order
to
safely
deal
with
responses,
every
field
must
be
individually
null
checked.
This
is
not
a
problem
in
our
legacy.
A
Our
interim
solution
was
to
encourage
developers
to
write,
wrapper
types
for
every
response
that
would
handle
unwrapping
every
field,
but
this
was
quite
a
lot
of
manual
labor
and
we
very
much
did
not
want
to
force
developers
into
a
new
system
that
was
worse
than
the
old
system.
If
you
do
that,
you
start
losing
trust
and
it's
very
hard
to
come
back
from
that.
A
Here's
an
example
of
one
of
those
types
that
handles
null
checking
it's
about
70
lines,
long
and
I've
chosen
it
as
an
illustration
because
it
could
reasonably
fit
in
the
slide.
Some
are
longer.
Some
are
shorter,
but
we've
got
something
like
70
of
these
across
our
ios
code
bases
and
we're
really
just
beginning
to
do
a
company-wide
rollout
of
graphql
at
yelp.
Other
platforms
are
basically
in
similar
situations,
so
obviously
this
wasn't
sustainable.
A
So
this
problem
floated
around
our
team
sinks
for
a
while,
we
evaluated
a
few
different
approaches
to
address
the
problem,
including
maintaining
forks
of
apollo's
clients
and
cogeneration
tools,
but
none
of
them
were
particularly
attractive
and
a
language
proposal
kept
surfacing
as
a
possibility.
My
co-worker
liz
created
a
backlog,
jira
ticket
for
a
cons
for
the
concept
in
august
of
2020,
and
the
code
snippet
you
see
here
would
eventually
serve
as
the
basis
for
the
proposal.
A
The
deciding
factor
came
when
we
started
talking
to
our
counterparts
at
other
companies.
When
we
had
a
meet
up
with
some
folks
at
netflix
and
they
told
us
they
were
running
into
the
same
problem.
That's
when
a
language
proposal
became
a
legitimate
contender.
This
wasn't
something
that
we
were
facing
alone.
This
is
a
problem
that
other
companies
with
more
resources
were
facing
and
at
netflix
they
decided
it
was
worth
solving
with
a
custom
directive.
We
would
later
learn
that
the
relay
team,
too,
had
been
quietly
working
on
their
at
required
directive.
A
The
proposal
was
basically
this
folks.
Folks,
writing.
Graphql
schemas
are
incapable
of
predicting
every
use
case
for
the
schema
and
that's
fine
client
developers.
Working
on
features
are
in
a
better
position
to
decide
when
a
field
is
necessary
for
their
feature
to
work,
we
will
provide
them
syntax
that
they
can
use
to
indicate
that
a
field
is
required.
A
Already
lee
was
the
first
person
to
suggest
that
the
inverse
of
the
required
designator
should
exist,
and
that
should
be
represented
by
a
question
mark.
The
reasoning
was
that
it
completes
the
story
of
control
and
provides
a
guaranteed
stopping
point
for
null
propagation
if
we're
using
the
existing
null
propagation.
Oh
I'm
sorry
and
provides
a
guaranteed
stopping
point
for
null
propagation.
If
we're
using
the
existing
null
propagation
rules,
the
feeling
was
that
introducing
the
required
designator
without
the
inverse
is
like
introducing
throw
without
catch.
A
A
Because
data
preservation
is
so
important
to
them,
they
have
the
opposite
problem
where
that
sometimes
they
want
to
be
able
to
halt
in
all
propagation,
rather
than
the
inverse
use
case,
which
this
proposal
originally
supported.
Developers
at
apollo
indicated
that
many
of
their
customers
face
problems
around
schema.
A
Breaking
where
the
solution
to
developer
experience
gripes
is
to
make
a
breaking
change
and
swap
a
field
from
nullable
to
non-nullable,
or
vice
versa,
which
can
be
a
labor-intensive
process,
since
there
seemed
to
be
a
general
consensus
that
the
inverse
of
the
required
operator
was
a
good
addition
to
the
proposal.
It
was
accepted
without
a
vote
for
the
rest
of
the
presentation.
Fields
marks
with
a
question
mark
will
be
called
optional
fields.
A
The
possibility
had
been
suggested
earlier
as
well,
but
it
was
put
off
because
neither
netflix
nor
relays,
client
controlled
null
ability
counterparts
had
the
feature
and
it
hadn't
been
a
problem
yet
for
either
of
their
use
cases.
However,
there
was
enough
interest
during
the
community
feedback
sessions
to
adopt
it
into
the
proposal.
A
Discussions
around
which
specific
syntax
to
use
happened
over
the
following
months.
This
syntax,
which
we
referred
to
as
the
bracket
syntax
during
discussions,
was
selected
for
adoption
by
majority
vote
at
the
march
3rd
2022
graphql
working
group
meeting
nine
out
of
the
ten
participants
voted
for
this
option.
A
Here
are
a
couple
other
options
that
were
also
considered
by
the
working
group.
The
folks
that
voted
against
the
first
option
felt
that
it
was
unclear
how
it
should
be
interpreted
whether
operators
should
be
applied
from
the
outside
in
or
inside
out
and
folks.
That
voted
against.
The
second
option
felt
that
it
read
like
a
typecast
and
that
the
inclusion
of
the
type
place
an
undue
burden
on
client
developers,
validation
would
fail
if
the
type
was
incorrect
and
didn't
provide
much
additional
value
beyond
looking
closer
to
the
schema
language.
A
Syntax,
there
was
one
last
big
thing
that
the
working
group
decided,
rather
than
required
fields
acting
identically
to
non-nullable
fields.
They
would
differ
slightly
instead
of
using
the
standard
null
propagation
rules
that
dictate
that
propagation
ends
at
the
first
nullable
parent.
We
decided
that
null
pr
null
should
propagate
to
the
nearest
optional
parent.
A
The
working
group
selected
this
behavior
for
adoption
by
majority
vote
at
the
march
3rd
2022
graphql
working
group
meeting,
seven
out
of
eight
participants
voted
for
this
option.
So
take
this
query
where
the
author
has
made
name
a
required
field,
and
all
fields
are
nullable
in
the
schema
prior
to
this
change.
If
name
resolved
to
null,
then
it
would
propagate
to
the
nearest
nullable
field,
which
is
owner.
So
owner
is
null
in
the
response
and
here's
where
business
has
been
made
optional.
A
A
This
was
a
mechanic
most
requested
by
the
folks
at
meadow
working
on
relay,
although
I
want
to
emphasize
that
the
working
group
ultimately
decided
that
it
was
best
for
everyone
relay
wanted.
This
behavior
for
a
few
reasons
during
execution
under
the
graph
under
other
graphql
use
cases,
fragments
are
merged
and
fields
are
resolved
a
single
time.
This
causes
issues
for
client
control
and
all
ability,
because
required
fields
and
optional
or
nullable
fields,
are
different
types
and
therefore
cannot
be
merged.
A
It
also
has
the
option
to
do
something
closer
to
the
standard
null
propagation,
but
that
too
is
bound
to
a
single
fragment
and
it's
significantly
less
popular
client,
controlled
null
abilities
as
it
stood,
would
break
the
facade
of
fragment
isolation
and
also
cause
problems
for
relay
users.
Given
the
heavy
use
of
fragments
and
strict
validation
rules.
A
Additionally,
with
the
initial
iteration
of
the
proposal,
if
users
wanted
to
guarantee
that
all
fields
through
multiple
parents
could
which
should
be
lost
in
the
event
that
a
field
is
null,
they
would
need
to
mark
each
level
of
the
field
with
an
exclamation
point.
But
the
new
null
propagation
behavior
makes
that
sort
of
thing
much
easier.
A
So
if
I've
done
my
job
you're
thinking
to
yourself,
that's
awesome,
how
can
I
use
client
control
of
nullability
right
now
and
the
answer
is
you
can
sort
of
use
it,
but
the
ecosystem
is
a
tad
fragmented.
At
the
moment,
you
can
start
preparing
your
ios
projects
to
use
it
with
apollo
ios
1.0.0
alpha
4
and
above
the
apollo
team
is
working
on
the
other
platforms,
but
at
yelp
we're
piloting,
client
control
nullability
on
our
with
our
ios
developers.
So
that's
where
we've
focused
our
efforts.
A
A
A
A
Michael,
the
maintainer
of
hot
chocolate,
c-sharp,
client
and
server
has
done
a
client
control,
nullability
implementation
as
well.
So
that's
another
option.
If
you
want
to
give
client
control
nobility
a
try,
the
working
group
is
still
mulling
over
some
of
the
details,
around
error
handling
and
null
propagation.
So
there's
definitely
still
time
to
provide
input.
A
If
you
got
any
please
swing
by
our
discussions
in
the
working
group,
repo
or
show
up
to
a
working
group
meeting
having
the
opportunity
to
work
in
open
source
for
your
job,
like
I
have
over
the
past
year,
is
somewhat
unusual.
So
I
want
to
share
what
I
learned
and
encourage
folks
to
do
similar
projects.
A
The
way
that
we
estimated
this
project
was
to
look
at
other
proposals
and
see
how
long
it
took
to
complete
them.
Our
original
estimate
was
six
months,
so
we
were
a
tad
off
the
mark.
I
still
think
this
was
a
good
way
to
go
about
estimating,
but
we
would
have
been
more
precise
if
we
had
all
the
information
that
we
have
now,
namely
that
one
being
able
to
work
full-time
on
the
project
would
not
necessarily
make
it
go
faster.
A
Most
of
the
people
we've
been
communicating
with
are
doing
this
work
on
a
volunteer
basis
or
as
a
minor
part
of
their
full-time
job.
You're,
not
working
with
your
co-workers.
You
can't
dictate
timelines.
People
get
back
to
you
when
they
want
to
get
back
to
you.
It
sounds
like
a
complaint,
but
it's
not
really
open.
Source
projects
are
not
companies,
and
you
have
to
understand
that
there
will
be
a
mismatch.
Anytime,
one
party
is
doing
full-time
paid
work
and
another
is
a
volunteer.
A
A
Most
of
the
work
by
volunteers
understandably
happens
shortly
before
after
and
sometimes
during
working
group
meetings.
So
you
have
to
really
have
about
a
week
every
month
where
you
reliably
have
most
folks
attention.
It
took
us
a
bit,
but
we
got
into
the
cadence
of
things
later
on
in
the
project.
It
really
helped
to
get
discussion
started
quickly
as
possible
after
working
group
meetings,
so
folks
could
respond
in
their
own
time.
A
Although
it's
taken
a
while
and
it's
going
to
take
a
bit
more
most
of
the
fears
I
had
about
how
difficult
this
would
be,
didn't
really
turn
out
to
be
true.
As
someone
without
an
academic
background,
I
don't
have
a
degree.
I
was
worried
that
I
lack
the
knowledge
necessary
to
work
on
the
project
and
be
judged
for
it,
but
everybody
has
been
extremely
kind
and
helpful
as
someone
who's
attempted
to
work
on
the
swift
language
before
and
gave
up,
because
it
was
far
too
difficult.
A
I
was
worried.
The
implementation
would
stop
me
in
my
tracks,
but
or
at
least
be
the
most
difficult
part
of
the
whole
project,
but
it
hasn't
been
ivan
and
the
rest
of
the
graphql
js
maintainers
have
done
an
excellent
job
and
create
an
excellent
code
base.
The
tool
they've
chosen
to
work
with
is
great
and
iteration
speeds
are
quick.
So
if
you're
thinking
of
attempting
a
similar
project
yourself
and
you've
got
time
to
kill,
you'll
need
to
be
persistent,
but
don't
let
fears
of
difficulty?
Stop
you
over
many
working
group
meetings.
A
We've
had
many
discussions
about
how
different
parts
of
the
proposal
would
work
and
something
key.
I've
learned
they've
been
able
to
turn
around
and
apply
at
work.
Are
that
polls
are
your
friend
I've
observed
during
discussions
that
people
will
typically
speak
up
to
present
a
new
idea
or
disagree
with
an
idea.
That's
already
been
presented,
but
they
won't
speak
up
to
second,
an
idea.
Unless
that's
some,
they
have
something
additional
to
add
engineers
like
ourselves,
also
a
tendency
to
explore
pros
and
cons
of
every
possible
avenue,
even
those
we
we
don't
particularly
back.
A
This-
can
make
the
field
look
much
more
divided
than
it
actually
is.
I
mentioned
vote
counts
for
lists
and
tax
and
all
propagation,
a
few
slides
back,
which
were
nearly
unanimous.
So
it
might
surprise
you
to
learn
that
discussions
around
those
in
working
group
meetings
prior
were
lengthy
and
quite
vigorous.
A
If
you
feel
like
discussions
are
going
long
and
you
need
to
move
forward,
run
a
poll,
the
results
may
surprise
you
working
group
meetings
and
github
threads,
unfortunately
have
their
limitations.
The
ability
to
go
into
extended
back
and
forth
as
folks
doesn't
really
exist
and
it's
uncomfortable
making
a
couple.
Dozen
people
sit
there,
while
you
suss
out
an
idea
for
yourself.
Walls
of
text
aren't
fun
to
read
and
exhausting
to
write
and
proofread.
A
A
Speaking
in
public
public
forum
is
a
bit
of
a
performance
and
being
able
to
get
past
that
and
see
folks
behind
the
screen
as
humans
with
families
and
hobbies
and
jobs,
where
managers
are
setting
deadlines
or
open
source
maintainers
with
needy
users
and
being
able
to
hear
all
that
and
say.
Yes,
I
understand
and
I
can
empathize
it
goes.
A
Also,
the
first
people
to
help
me
learn
typescript
and
the
tool
chain
around
it.
Jordan
was
a
great
sounding
board,
especially
around
relay's,
rather
unique
problems.
Sahaj
and
ivan
both
gave
me
guidance
and
code
review
on
the
graphql,
js
implementation
and
anthony
and
hugh
worked
with
me
on
the
apollo
ios
integration.
There
are
loads
of
other
folks
that
provided
feedback
during
the
rfc
process
and
y'all
were
incredibly
helpful.
A
Yelp
will
be
piloting,
client,
controlled,
nullability,
once
it's
in
a
stable
release,
but
we're
looking
for
other
companies
and
folks
who
are
down
to
give
it
a
shot
and
provide
feedback.
So
please
reach
out
to
me
if
you
intend
to
use
client
control,
nullability
and
I'll
do
what
I
can
to
help
once
again,
I'm
alex
riley.
I
work
at
yelp
we're
hiring,
especially
for
folks
that
want
to
work
on
ios
infrastructure.