►
From YouTube: GraphQL Working Group (Secondary, APAC) - 2023-05-10
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
C
A
B
A
A
D
Can
also
tell
it's
early
morning
and
winter
in
Australia,
yeah.
A
Yeah,
just
we're
we're
pretty
we're
not
used
to
anything
under
20
degrees.
B
Well,
I
think
it's
just
us
today,
okay
and
so
we're
good
to
go.
We
can
have
a
relatively
tight
meeting
and
then
roll
from
there
we
might
as
well
do
are
we
yeah?
We
are
recording,
so
do
a
quick
intro
for
the
benefit
of
anyone
who
catches
the
recording
afterwards,
everybody,
my
name,
is
Lee
leading
the
meeting.
B
Fantastic
and
it's
just
the
three
of
us
and
we've
already
read
the
agenda,
which
usually
got
all
the
links
to
membership
agreement,
personification
guidelines
Etc
when
you
get
on
with
business.
B
Let
me
see
if
there's
anything
interesting
to
update
y'all
on
from
the
primary
meeting
earlier
in
the
month.
Oh
yeah,
okay,
it
was
a
short
meeting.
There
was
actually
an
update
to
the
agenda
that
I
should
have
added
to
that
doc.
That
I
forgot,
which
is
relevant,
which
is
the
graphql
comp
that
is
coming
up
later
this
year,
I've
just
been
encouraging
everybody
to
submit
to
the
cfp,
and
so,
if
either
of
you
would
like
to
speak,
I'd
love
to
have.
B
Great
fantastic
well
either
way.
You
should
certainly
encourage
a
team
to
get
some
tickets.
It'd
be
awesome
to
have
everybody
come
out.
We're
gonna
have
an
international
convergence
of
graphql
folks,
gonna
be
a
good
time.
B
B
That's
when
the
topic
is
your
for
the
last
handful
of
primary
meetings,
which
has
been
led
by
Rob
Richard,
he's
really
working
through
the
last
bits
of
chaos,
of
what
is
hopefully
not
super
complicated
proposal
in
the
end,
but
he's
getting
through
all
the
corner
cases
important
any
questions
on
either
this.
That's
the
major
update,
cool,
otherwise
I
see
y'all
added
some
agenda
for
us.
Thank
you
very
much.
B
Maybe
let's
hit
this
in
upside
down
order,
so
we
can
just
talk
about
the
meeting
time
first
and
then
we
can
get
into
the
spec
wording
stuff
that
you
wanted
to
talk
about
yeah
meeting
time.
It
seems
like
our
respective
daylight
savings
couldn't
do
this,
which
makes
the
time
known
overlaps,
wonky,
8
30
is
a
little
early
in
the
morning
for
you
folks
that
the
main
push
here.
A
Yeah
I
mean
I,
don't
know
who
else
wants?
Who
else
is
coming
to
these
meetings
and
what
time
zones
they're
in?
But
if
it
is
possible
to
move
it
by
30
minutes
later?
That
will
be
easier
for
us.
Aussies.
B
Yeah,
that
seems
extremely
reasonable,
I
would
say
my
constraint
on
the
the
back
edge
of
that
is
that
at
5
00
p.m.
My
time
so
right
now
it's
3
30
p.m.
My
time
so
pushing
it
ahead
by
30
minutes
to
make
it
start
at
4
pm.
B
My
time
I
would
have
to
close
at
five
as
long
as
everyone
is
okay
with
that
I
think
most
of
our
meetings
have
cut
short
anyway,
so
I
don't
think
that's
going
to
be
too
big
of
a
deal,
but
if
there's
ever
a
topic
that
went
deeper,
I
might
have
to
jump
early
I'm
in
hand
that
meeting
close
to
somebody
else,
but
as
long
as
we're.
Okay,
with
that
being
the
trade-off,
you
can
consider
it
plan
cool.
A
B
Thanks
I've
got
the
June
meeting
coming
up
next
month.
I'll
update
the
time
for
that
one
and
then
it
looks
like
I
need
to
go.
Add
some
agenda
files
for
the
next
couple
of
meetings
after
June
anyhow,
so
that'll
just
be
what
gets
copied
going
forward.
B
Spec
wording
clarification.
Let's
dig
into
that.
B
D
Yeah
I
think
the
gift
was
that
the
spec
is
currently
unclear
on
whether
it's
valid
to
return.
Both
data
and
errors
from
a
field
fetch.
D
And
so
some
were
arguing
that
ipso
facto,
if
you
have
returned
non-null
data,
then
you
must
not
have
an
error
kind
of
thing
right,
and
that
was
the
clarify
that
was
position.
That
I
think
is
that
Benji
were
going
for
kind
of
thing
and
we
we're
pretty
strongly
opposed
to
that,
namely
so
an
implementation
terms.
D
Graphql
Java,
currently
allows
you
to
return
a
sort
of
compound
object
from
a
a
data
fetch,
which
is
both
errors
and
both
errors
and
data,
and
we've
got
pretty
strong
sort
of
feedback
that
that's
not
only
useful,
but
you
know.
D
Is
that
is
that
people
have
continually
come
back
and
asked
us
for
such
a
thing
over
the
years
kind
of
stuff
which
we
added
a
while
back
and
then
have
confirmed
you
know,
I
think
it
interesting
just
a
little
the
side.
We
we
actually
also
allow
other
things,
like
extension,
adding,
so
you
know,
a
field
can
sort
of
have
a
side
effect
of
adding
to
an
extension
at
the
same
time
and
so
forth.
But
that's
that's
a
that's
a
different
thing,
but
specifically
on
errors
and
data.
D
Our
position
is
very
much
that
errors
and
data
should
be
allowed.
D
The
kind
of
I
mean
you
can
imagine
use
cases.
The
kind
of
use
cases
we
see
is
the
sort
of
default
values.
What
might
be
an
example
where
you
sort
of
say
I
can't
talk
to
the
underlying
service,
but
here's
a
an
appropriate
default
value
very
specific.
But
why
not?
You
know
what
I
mean.
D
B
B
That's
very
helpful
context.
Thank
you,
I
did
not
know
the
graphical.
Let
you
do
that.
That's
kind
of
cool,
so
the
first
question
here
is
about
original
intent.
Original
intent
is
definitely
that
it
could
do
one
or
the
other.
B
The
thought
was,
you
can
kind
of
draw
a
correlation
here
between
or
to
languages
that
throw
so
like
a
function
either
like
JavaScript.
Even
Java
function
either
returns
normally,
in
which
case
it
returns
a
value
or
it
fails
to
complete.
Normally
it
completes
abnormally
via
throwing
and
then
there's
separate
programmatic
ways
to
handle
each
of
the
scenarios
try
catch
for
the
abnormal
case
and
just
normal.
B
You
know
value
delivery
or
value
return
into
program,
execution
flow
for
normal
execution,
so
that
was
the
mental
model
for
graphql
as
well,
that
each
field
would
sort
of
behave
as
one
of
those
functions
where
either
it
completes
normally,
in
which
case
it
Returns
the
type
that
it
describes
or
it
completes
abnormally,
in
which
case
graphql
does
this
sort
of
like
separate
air
bubbling
Behavior,
where
it
works
its
way
up
the
chain
to
figure
out
like?
Where
does
it
need
to
call
a
selection
of
the
the
graph
result
in
order
to
handle
the
error?
B
So
it's
not
just
a
matter
of
saying
this
field
is
null
and
is
an
error.
Actually,
the
fact
that
it
ends
up
being
null
is
not
because
the
field
resolver
said
you
should
let
this
be
null,
because
there
was
an
error.
It's
actually
the
result
of
the
graphical
executor
itself,
determining
where
or
along
the
boundary
can
it
cut
and
abnormally
returning
feeling
response,
yeah.
D
So
we
that
was
the
original
intent
yeah
we
we
do
have
that
as
well
in
our
implementation.
So
in
Java
terms,
if
it's
an
exception,
then
exactly
that
behavior.
You
were
saying
right.
It's
like
this
accepted
thing
and
then
we
get
into
the
whole
game
of
it's
implicitly
going
to
be
null
now.
By
the
way,
is
this
nullable
and
then
we
chain
up
the
thing
and
and
so
on,
according
to
what
the
spec
says,
but
we
we,
what
we
were
against
was
this
idea
that
effectively
you
could
complete.
D
Let's
call
it
successfully
right
and
add
both
data
and
an
error
kind
of
thing
right
that
that
would
be
implicitly
banned
by
spec
right,
so
I
guess
in
some
ways
it's
maybe
it's
worth
calling
out
the
sort
of
exceptional
path
versus
a
sort
of
non-exceptional
path,
but
data
with
error,
kind
of
style
right.
A
D
D
It's
slightly,
you
know
it
gets
in
the
gray
areas
of
like
more
functional
language.
How,
if
you
were
using
either
you,
you
probably
can't
represent
that
as
well
and
so
forth,
but
yeah.
A
C
B
Well,
you're,
right
to
point
out
that
this
is
ambiguous.
I
think
there's
not
did
not
and
expect
the
scenario
where
the
errors
feel
or
the
errors
section
would
contain
anything
other
than
caught
thrown
exceptions.
To
use
that
terminology
that,
like
anything,
that
is
in
that
list,
is
the
result
of
that
air
bubbling
behavior
and
there.
Therefore,
you
could
have
metadata
like
where
what
field
position
was
it
that
caused
the
error,
and
you
know
where
you
want
to
then
bring
it
back
into
an
ID
environment,
yeah.
D
Yeah
because
I
think
it's
the
most
common
and
sensible
case.
B
B
You
would
expect
a
functional
programming
language
to
return
a
compound
type
like
maybe
they
return
a
left
right
or
either,
or
you
know,
some
kind
of
type
or
like
some
kind
of
monad
or
something
where
it
encodes
the
fact
that
there's
two
possibilities
or
a
combined
set
of
possibilities,
which
the
pro
of
that
is
the
now
you're
treating
the
error
as
data.
It
is
in
the
payload
itself.
There's
not
like
a
side
thing
that
you
have
to
go
looking
for
for
the
errors.
B
If
a
field
in
fact
did
fail
to
fetch
correctly
and
you're
getting
compound
result,
you
have
both
the
error
and
the
result
in
the
payload,
the
downside
being
that
you
introduce
this
compound
data
structure
and,
if
you're,
in
a
scenario
where
99.9
of
the
time
there's
no
error
occurred
than
you've.
Just
created
engineering
toil
for
people
who
have
to
unwrap
those
things
all
the
time.
Yeah
yeah.
D
If
a
engine
decides
not
to
provide
it,
then
that's
fine
like
and
and
it's
and
it's
the
most
sensible
sort
of
position,
but
we
we
will
let
why,
let's
not
ban
it
in
Spec,
we
could
describe
the
Nuance,
but
not
you
know,
ban
it,
because
the
Hammers
goes
the
other
way
right,
which
is
to
say
if
the
spec
gets
clarified
and
says
there
can
never
be
anything
else,
but
data
or
an
error,
then
it
effectively
I
mean
we
would.
We
would
probably
stay
non-spec
compliant.
D
For
that
thing,
you
know
like
yeah,
which
would
which
we'd
rather
not.
You
know
what
I
mean.
B
The
direction
of
a
proposal
where
the
rough
shape
of
The
Proposal
is
the
currently
at
least
intended
way
that
we've
stated
the
behavior
is
excuse
me,
a
field
either
returns
normally,
in
which
case
value
gets
out
of
response,
or
it
fails
because
of
an
error,
in
which
case
the
error
is
logged
in
the
errors
list
and
then
the
that
errors
Behavior
bubbles
up
until
it
finds
the
first
non-nullable
play
sliced,
and
then
it
sounds
like
there's
the
the
beginnings
of
a
proposal
which
says:
there's
actually
another
way
in
which
something
can
fail,
which
does
insert
something
into
the
errors
array,
but
does
not
and
does
not
create
the
air
bubbling
Behavior.
B
Instead,
there's
sort
of
like
a
localized
yeah
catch
yep,
because
because
I
think
another
way
we
could
say
this
is
you
can
just
put
anything
into
the
errors
array
whenever
you
want,
and
we
could
maybe
do
that.
It
makes
me
slightly
nervous
that
maybe
we're
not
thinking
about
some
constraint
that
a
tool
has
made
an
assumption
about
that
will
end
up
kind
of
diminishing
the
value
of
some
part
of
the
tooling
ecosystem.
D
Yeah
I
can
back
you
on
the
on
the
tooling
aspect,
so
yeah
running
tools
right
now
treat
errors
as
a
hard
stop
right,
yeah
like
so
as
much
as
you
know,
graphql
sets
out
with
the
idea
of
saying
you
can
have
partial
data
and
a
list
of
Errors
for
this
set
of
fields,
but
not
this
most
of
the
stuff
I've
seen
out
there
just
kind
of
goes.
Oh.
D
And
they
they've
got
a
hard
stop.
So
in
practice
for
certain
for
most
clients,
you're
right
that
you
know
like
the
presence
of
an
error
is
likely
to
just
say
this
has
stopped
right,
but
I
don't
know
that
the
spec
should
outright
ban
it,
because
you
could
imagine
errors
with
extensions
that
tell
you
that
they're
informative
and
that
and
aware
client
could
decide
to
treat
it
right.
It's
not
sort
of
what
the
world
does
today,
but
but
right
like
why
sort
of
say,
the
presence
of
an
error
is
always
a
hard
stop.
D
We
already
don't
kind
of
want
that,
and
so
I
I
see
it
that
this
is
another
example
of
of
that
ability.
You.
C
C
B
The
before
open
sourcing
version
of
graphql
had
a
lot
more
metadata
around
the
errors,
but
they
just
they're
just
kind
of
very
specific
to
Facebook
systems,
and
it
didn't
really
make
sense
to
include
them
as
any
part
of
a
spec,
but
one
of
those
metadata
was
or
I
guess,
probably
two
of
them,
but
that
they
were
around
this
concept
of.
Is
it
safe
to
ignore
this
or
not
like?
Is
the
air
fatal,
and
the
local
tooling
would
actually
decide
that
if
you,
it
always
accepted
partial
responses.
B
Unless
one
of
those
errors
had
this
sort
of
a
fatal
flag,
in
which
case
it
would
throw
out
the
entire
thing
right
and
then
on
the
back
end,
you
know
the
application
Engineers
could
decide.
If
a
particular
failure
scenario
should
result
in
stop
everything
about
the
query,
throw
the
whole
thing
out,
which
in
hindsight
was
a
little
bit
silly,
because
what
we
should
have
done
is
say
just
don't
deliver
a
payload.
You
know
just
deliver
an
entire
error
and
an
empty
payload
which
the
client
could
then
be
agnostic
to
it.
B
But
that's
not
how
it
worked,
and
then
the
second
one
that
was
also
really
interesting
was.
Is
this
a
transient
error
or
not?
So
could
you
just
try
again,
because
sometimes
the
error
would
fail,
because
a
database
was
unreachable,
yeah
and
a
database
being
unreachable
is
not
like
a
permanent
State
like
it's
probably
super
temporary,
and
if
you
try
it
again
in
10
seconds,
it
would
probably
work.
B
You
know:
you'd
get
load
balance
to
a
separate
Service
as
soon
as
the
service
got
back
into
a
healthy
state,
and
that
was
also
interesting,
like
there
were
a
handful
of
clients
that
eventually
realize
that
if
any
error
ever
said
anything
about
being
transient
again
throw
the
whole
thing
out
and
just
try
it
all
over
again
with
some
exponential
fall
off
and
it's
like
you,
don't
get
one
without
an
error
and
three
tries
then
just
take
what
you
get
yes,
and
so
it's
interesting
like
I,
think
there's
like
a
separate
bit
here
about
what
is
good
metadata
on
errors
and
client
Behavior.
D
Alaskan
we
have
a
sort
of
Quasi
standard
that
we
effectively
use
status
codes,
HTTP
status
codes
to
indicate
the
the
sort
of
nature
of
the
era
right.
We
stick
it
in
here
and
Florence-
don't
tend
to
act
on
it
too
much,
but
one
other
area
that
that
we
do
act
on
strongly
is
Metro
sizing
them.
So
people
have
built
slos
on
the
basis
that
I'm
only
I.
You
know
I'm
not
getting
these
kind
of
Errors
in
the
experience
that
are
500
or
better.
D
You
know
that
that
kind
of
style,
so
there's
another
area
that,
where
that
error
metadata
feeds
into
the
operational
aspect
of
your
system,
which
is
you
know,
it's
quite
good?
Actually,
even
if
the
client
like
just
didn't,
treat
them
in
that
way,
right
so.
C
B
B
D
Well,
it's
I
mean
we
do
in
the
sense
that
there's
extensions
but
there's
no
yeah,
there's
no
extended
beyond
that
kind
of
you
know
which
is
tricky
in
the
spec,
but
you
can
imagine
a
sort
of
you
know
in
the
same
way,
something
like
WS
graphql
Builds.
On
top
of
how
to
talk
it,
you
could
imagine
you
know
a
quasi.
D
Problem
is
it's
a
yeah
it
gets
into
the
domain
of
like
this
is
a
good
idea
if
you're,
if
your
org
is
willing
to
accept
it,
you
know
what
I
mean,
whereas
a
spec
would
have
trouble.
Saying
doubt
shall
put
this
in,
and
thou
shalt
call
it
status
code
and
doubt
shall
have
an
error
categorization
or
something
like
this
right.
B
Yeah
at
some
point,
I
would
like
us
to
do
status
codes,
but
I
think
the
main
way
in
which
the
status
codes
would
be
interesting
would
not
be
application
layer
codes.
It
would
be
graphql
Behavior
layer
codes
like
is
this
a
syntax
error
in
the
query?
Is
it
was
your
something
about
your
server
broken?
It
was
like
a
500
style
level
error.
B
B
Which
is
not
great
and
also
not
great,
for
services
that
want
to
internationalize
those
messages
and
is,
is
one
of
the
things
that's
blocking
universal
test.
Automation,
we'd,
really,
love
to
be
able
to
say,
put
this
schema
and
behavior
into
your
service
and
then
we're
going
to
just
run
a
thousand
queries
against
it.
B
And
if
you
get
exactly
these
shapes
back,
then
your
spec,
compliant
and
or
at
least
your
respect,
compliant
on
the
side
of
like
you,
haven't,
missed
any
functionality,
like
maybe
added
functionality,
but
you
haven't
missed
any
functionality
and
that's
really
hard
to
do
with
that,
because,
like
every
Services
error,
messages
are
slightly
different,
you
know
just
probably
fine
yeah
and.
D
D
Because
it's
it's
not
your
service's
fault!
If
someone
throws
you
an
invalid
query,
so
that
doesn't
count
against
your
SLO,
but
the
you
know:
if
you're
not
delivering
data
appropriately,
then
you
know
you
should
start
looking
at
your
service.
So
there's
another
aspect
of
those
to
those
things
as
well.
D
You
know
that
that
would
really
deal
with
thing
and
you
can
see
it
in
resting
land
right
where
middleware
Services
just
observe
status,
codes
and
start
tracking
things
for
you
and
classifying
you
and
you're
like
give
me
a
count
of
the
500s
and
you're,
like
oh
okay,
someone's
going
to
get
paged
on
that
right,
so
totally
yeah
we're
in
that
same
world
which
would
be
helped
by
that
as
well.
B
B
I
will
write
an
update
to
that
the
GitHub
issue
that
asks
the
question
to
just
make
sure
that
that
one
is
known
and
then
second
I
think
there's
like
a
whole
there's
a
whole
domain
of
proposals
to
explore
here
that,
if,
if
you
all
would
be
interested
in
exploring,
we
should
certainly
talk
about
everywhere
from
should
it
be
allowed
to
put
something
into
the
errors
array
when
you
have
not
created
an
air
bubbling
behavior
and
if
so
like.
What
are
the
constraints?
B
We
want
to
put
around
that
where
you
could
imagine
an
extremely
permissive
version
of
that
which
is
just
a
sentence
or
two
that
says
that
you
can
just
do
it
for
whatever
reason
you
want,
but
you
can
imagine
a
scenario
where
you
put
something
into
the
errors
array
that
describes
something
different
field
like
is
that
okay,
like
does
it
always
have
to
describe?
Does
it
always
have
to
come
from
a
field
so
that
the
metadata
can
be
correct,
like
what
are
other
metadata?
B
That
might
be
wrong
if
we
break
that
assumption
so
I
think
there's
just
like
room
to
explore
there
to
make
sure
that
we've
got
the
behavior
that
makes
sense
the
status
codes.
One
is
also
really
interesting,
as
well
as
the
sort
of
not
necessarily
just
the
status
code,
but
like
behavioral
flags
of
I
think
for
a
long
time.
We've
talked
about
this.
What
does
it
look
like
to
have
a
fatal
error
that
just
hard
stops?
B
The
entire
query,
like
the
response,
stops
and
does
not
return
back,
which
is
interesting
for
incremental
delivery,
because
you
can
imagine
getting
the
first
bit
of
a
stream
completed
and
then
having
one
of
these
fatal
errors
and
needing
to
stop
midstream,
and
so
it
would
have
some
interesting
effects
on
that
yeah.
C
C
It
up
so
what.
B
Yeah
the
I
know
that
they
are
exploring
that
to
a
degree
because
at
Facebook
they
do
have
the
concept
of
a
fatal
error
which
is
not
exactly
I,
don't
know
what
it
means
in
terms
of
spec
compliance
necessarily.
D
I
think
so
we'll
put
our
position
on
that
issue
as
well
like
as
the
graphical
Java
thing.
Andy
was
a
bit
wishy-washing
when
he
said
three
weeks.
He
was
asking
for
clarification,
but
we've
we've
since
discussed
it,
and
and
we
we
have
strong
evidence
like
from
consumers
that
that
this
is
really
useful.
C
B
Cool
yeah
I
think
it
would
be
really
helpful
just
to
kind
of
capture
the
use
cases,
capture
the
constraints
and
then
propose
what
what
actually
should
be
the
boundaries
what's
allowed
and
not
allowed
yeah.
A
B
B
That's
right
all
right,
cool
discussion,
good
topic,
I'll!
Let
you
both
get
on
with
your
mornings.
Donna
I
hope
you
warm
up
there
in
Springfield.