►
From YouTube: GraphQL Working Group (Secondary, APAC) - 2023-02-08
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
A
Just
uploaded
all
the
other
videos
to
YouTube
up
until
well
yeah
whenever
the
last
one
was
two
days
ago,.
B
A
No,
we
we
really
ought
to,
because
honestly
there's
a
lot
that
often
needs
trimming
off
the
beginning
and
at
the
moment
I
just
upload
them,
as
is
because
we
don't
dedicate
time
for
that.
B
A
A
C
B
I
I
do
that
for
work
meetings,
not
for
the
recorder
ones
and
that's
my
secret
to
turning
up
on
time.
C
C
Any
overflow
time
we
have
I'm
going
to
use
to
get
our
creds
setup,
I've
been
a
little
bit
underwater
since
last
meeting
and
now
over
the
last
week.
But
it's
still
on
my
radar.
C
We'll
make
sure
we
keep
it
short,
it's
I
think
it's
just
the
four
of
us
I
see
the
unless
I'm
missing
a
pull
request.
C
Okay,
well,
he
didn't
add
himself
to
the
attendees
list,
which
means
we're
gonna
get
going
and
if
Andy
hops
in
later
then
fantastic
welcome
everybody
I'm
gonna
skip
intro,
since
everybody
here
has
definitely
already
met
each
other
and
we'll
get
on
with
business
Donna.
Since
you
are
not
here
for
last
week's
meeting
through
benefit
I'll
just
do
like
a
quick
step
through
of
the
major
points
there.
Just
in
case
you
had
any
questions:
Benji
and
Matt.
You
guys
were
both
there.
C
The
okay
I'm
just
I'm,
pulling
up
the
agenda
document
to
remind
myself
what
oil
is
there.
Tsc
election
results
got
ourselves
a
new
CSC
set
of
members.
That
was
very
exciting,
so
we
talked
a
little
bit
about
that.
Then
what
I
had
just
mentioned.
C
This
is
the
thing
that
has
an
action
about
me:
is
Ricky's
machine
got
compromised,
I
think,
or
at
least
there
was
a
fear
that
it
was
compromised
and
Ricky
had
access
to
some
of
our
npm
release
tokens,
and
so
in
the
moment,
I
turned
off
at
Ricky's
access
just
to
I.
Think
in
just
in
the
the
Russian
area,
where
there
was
something
real
there.
We
would
be
protected.
Nothing
bad
happened
so
good,
but
we
wanted
to
have
a
better
build
infrastructure.
C
Then
we
were
talking
about
schema
definition,
ambiguity
which
Benji
I
think
that's
probably
related
to
the
one
that
you've
got
to
continue
discussion.
Today
we
moved
argument,
name
uniqueness
to
stage
three,
which
was
super,
exciting
I,
think
we
actually
merged
that
one.
C
C
It's
always
a
little
bit
hard
to
tell
in
some
of
the
Steep
Dev
conversations,
and
then
we
spoke
briefly
about
yaakov's
rebasing
of
the
work
that
I
had
done
a
while
back
on
default
value
of
allegations,
which
Andy's
on
top
of
I,
think
he
actually
got
all
that
stuff,
updated
and
merged
well,
before
I
did
so
good
on.
C
Go
I'm
gonna
pop
open,
Action
items
just
in
case
there's
any
of
them.
There
they're,
not
okay,
I'm.
B
Gonna
go
at
at
11,
but
I'm
hoping
then
I
can
pass
the
Baton
to
Andy.
If
there's
anything
else,.
C
A
Okay,
well,
Matt
and
Lee
will
already
know
this
because
we
talked
about
it
at
the
last
meeting,
though
I
have
advanced
it
just
to
smidge.
Since
then,
we
have
a
little
bit
of
ambiguity
in
the
spec
or
possibly
I
mean
there's
a
little
bit
of
ambiguity
and
there's
a
little
bit
of
just
being
a
little
bit
wrong
generally.
A
So
it's
the
same
thing,
but
that
doesn't
seem
to
be
the
case
in
the
circumstance
where
you
have,
for
example,
the
query
type
called
query
and
a
type
called
mutation
that
is
not
supposed
to
be
a
mutation
type,
for
example
a
virus
mutating
you
might
track
it
with
a
mutation
type,
not
have
it
be
your
operation
type
and
the
spec
kind
of
says.
Even
if
you
have
a
schema
like
that,
you
would
print
it
out
and
say
that
that
is
the
mutation
operation
type
or
something
like
that.
A
So
we
wanted
to
clarify:
that's
not
the
case
tidy
that
up
make
it
more
consistent,
so
we've
come
up
with
a
simple
test
case
for
it,
which
is
shared
in
the
graphql
spec.
Pull
request,
987
and
I
have
implemented
this
as
a
test
in
Graco
JS
implemented
the
fix
as
well,
and
the
the
spec
text,
which
is
currently
RFC.
One
is
pretty
I
mean
to
be
honest,
it's
ready
to
be
rfc2.
We
just
wanted
to
bring
it
to
more
implementations
awareness,
hence
hello,
graphql
Java.
B
Yeah
I
did
have
a
look
at
it
earlier
this
week,
so
there's
two
things:
there's
like
a
operation,
type
definition
or
something
object
which
does
correctly
exclude
this
virus
mutation,
but
then,
in
on
the
schema
object
that
we
have.
It
does
set
the
the
mutation
type
to
be
this
virus
mutation,
so
that
behavior
is
wrong
and
I'm
going
to
fix
that
yeah.
So
it's
really
good
that
you
brought
this
up.
A
Good
Okay
cool,
so
I
mean
I
could
propose
moving
it
to
rfc2
or
we
can
leave
that
to
the
next
main
one.
What
do
you
think
Lee.
C
Thanks
for
spotting,
this
async
Donna
and
getting
on
top
of
putting
the
failing
test
in
place
and
Benji.
It
looks
like
you
got
some
typescript
written
up
that
does
the
appropriate
printing
Behavior.
C
A
I
wasn't
actually
maybe
I
can
pick
your
your
brains
on
this.
Maybe
you'll
know
the
answer.
There
was
an
issue
in
the
graphql
JS
with
a
test
case
yeah.
Here
we
go,
I
put
it
in
the
main
thing
unnecessary
test
there.
A
There
seems
to
be
a
test
where
we
create
a
schema
just
using
the
query
type
with
a
foo
field,
and
then
we
build
that
as
a
schema
and
then
we
introspect
it,
and
then
we
delete
the
fact
that
it
has
a
query
type
and
then
we
try
and
print
that
out
and
at
the
moment
we're
asserting
that
when
we
print
that
out,
it
will
just
print
it
as
like
type
query.
But
of
course,
according
to
the
narrow
corrected
rules,
the
factor
has
a
type
query,
but
it
isn't.
A
The
query
type
means
that
it
should
have
a
schema
block
to
say
that
query
is
not
the
query
type,
but
then
you'd
have
a
schema
block
with
nothing
in
it.
You'd
have
schema
open,
curlies
closed
curlies
right
because
there
is
no
operation
types,
because
it's
not
really
a
valid
schema.
So
my
question
is
why
why
does
this
test
exist
like?
Why
is
it
there.
D
A
Absolutely
it's
right
here
in
in
the
chat.
A
It's
the
JS
pull
request
and
if
yeah
it's
got
a
code
Block
in
the
top
comment
there
that
you
can
just
open
up,
but
the
the
you
know
the
main
issue
comment
description.
Oh.
D
D
C
A
B
A
Don't
know
whether
it's
a
spec
issue
or
a
graphql.js
issue,
but
yeah
like
that
was
my
first
thing
and
I
noticed
the
past
error.
Hence
other
approach.
I.
A
C
Spec
says
that
a
query
root
must
exist,
but
the
schema
printer-
it's
not
it
is
it's
not
a
requirement
of
the
schema
printer
to
only
print
valid
schema,
because
you
can
imagine
the
case
where
you
create
an
invalid
schema
and
then
there's
an
error,
and
you
want
to
be
able
to
like
illustrate
where
the
error
is,
and
so
you
need
the
ability
to
print
invalid
schema.
So
you
can
point
to
it
in
an
error
message.
A
So
my
my
solution
to
it,
which
meant
that
I
didn't
need
to
actually
edit
that
test
case
is
to
special
case
it
inside
of
the
is
schema
of
common
names,
method
inside
of
print
schema,
which
basically
just
says
if
there
is
no
query
operation
type
and
there's
no
mutation,
operation
type
and
there's
no
subscription
operation
type.
Then
just
pretend
it's
using
all
the
standard
names
I,
don't
put
a
schema
block,
I'm,
not
sure
it's
the
right
fix,
but
it
works.
D
That
might
be
right,
so
one
of
the
things
that
I'm,
assuming
that
this
might
be
a
result
of
is
internally,
we
Shard
our
schema
into
a
whole
bunch
of
files,
and
we
use
the
schema
printer
like
we
use
graphql.js.
To
actually
do
that
so
like
we
can
have
a
schema
file
that
we
print
that
has
no
mutation
or
query
or
subscription
type
inside
of
it.
D
And
in
that
case
we
don't
want.
We
want
neither
a
schema
block
nor
like
yeah,
so
that.
C
D
D
So
we
would
end
up
with
and
they
may
not
be
named.
Query
mutation
subscription
I
think
they
are
for
us,
but
they
might
not
be
like
they're
not
guaranteed
to
be
necessarily
so
like.
You
need
a
way
to
print
yeah
I
I
could
be
wrong,
and
this
might
have
nothing
to
do
with
why
this
test
exists.
A
But
this
is,
this
is
basically
the
main
as
far
as
I
see
it.
The
main
outstanding
question
from
my
point
of
view
as
to
what
the
correct
approach
is
and
I
don't
feel
that
I
know
the
answer
there.
C
Are
a
handful
of
places
so
I
think
there's
like
an
entire
domain
of
work
that
we've
just
kind
of
conveniently
not
accepted
to
all
that
much
which
is
incremental
parsing
most
of
our
parsers
sort
of
assume
a
complete
well-formed
document,
which,
if
you're
writing
a
thing
that
turns
a
file
into
a
schema,
is
great.
If
you're
building
a
IDE
tool
is
extremely
frustrating
because
you'll
be
like
halfway
through
typing
a
thing
and
then
all
of
a
sudden
It'll
like
stop
or
you'll
get
a
compile.
C
You'll
get
a
parse
error,
and
so
a
lot
of
the
folks
who
have
built
syntax,
highlighters
or
other,
like
smart
IDE
stuff,
have
had
to
roll
their
own
non-technically
non-compliant
parsers.
That
just
are
looser
and
there's
probably
a
category
of
parse
rules
that
we
have
where
we
will.
C
We
will
make
a
thing
that
where
the
parser
says
there
needs
to
be
one
or
more
of
this
thing
and
of
course
that
makes
sense
if,
like
you've,
got
to
have
one
or
more
for
that
part
of
the
schema
to
be
valid,
but
where,
like
we're,
probably
leaking
validation
logic
into
the
parser,
and
this
is
one
such
example.
C
So
Benji
I
think
everything
you
said
just
made
a
lot
of
sense,
which
is
like,
if
you,
if
you
have
no
type
called
query
mutation
or
schema,
and
you
have
no
root
types.
Then
you
of
course,
don't
need
to
print
that
block.
I.
Think
that's
the
right
thing,
because
why
print
an
empty
one,
if
there's
nothing
there,
but
if
you
have
a
a
type
that
somehow
has
a
query
type
and
a
mutation
type
and
a
schema
type
named,
but
the
none
of
those
happen
to
be
the
the
respective
root
types.
A
So
at
the
moment
we
will
print
it
and
it
is
possible,
but
when
you
pass
it
it
won't
know
that
what
was
what
you
printed
was
invalid
and
it
will
just
read
it
out
and
it'll
go.
Oh
there's
a
query
type!
Oh,
that's
a
query
operation
which
I
think
is
an
okay
failure
mode
like
if
your
schema
is
not
valid.
When
you
write
it
out
and
you
read
it
in
and
it
becomes
valid,
then
I
mean.
B
A
D
D
C
B
D
D
A
Want
to
think
about,
should
we
move
on
to
Matt
so
that
Donna's
got
a
chance
to
hear
what
we're
talking
about
as
well.
C
D
Yeah
so
fragment
arguments
I
still
have
basically
graphql
jspr
waiting
for
some
form
of
review.
I
think
so.
I
have
a
diff
that
has
basically
no
pushback
from
the
relay
folks.
Besides,
add
some
tests
for
adding
the
syntax
to
relay
making
sure
the
syntax
works
all
that,
but
we
can't
actually
flip
the
switch
to
using
the
syntax
until
the
tooling
ecosystem
starts
using
the
syntax.
D
We
don't
need
servers
to
be
using
the
syntax,
but
we
do
need
lint
and
prettier
and,
like
we,
don't
actually
need
graphical
yet
because
the
server
can't
understand
things,
so
we
can't
actually
put
stuff
into
graphical.
That's
fine,
but
yeah,
basically
like
even
to
move
from
draft
to
like
accepted.
We
will
require
the
tooling
ecosystem
like
before
any
servers
have
the
new
syntax.
We
still
will
require
the
tooling
ecosystem
to
support
the
syntax
and
I.
D
Don't
think,
we've
seen
any
pushback
since,
like
December
or
November
on
from
a
user-facing
standpoint,
what
the
syntax
should
look
like
like
there's
doesn't
seem
like
really
any
there's
like
internal
questions
about
how
exactly
does
it
work?
How
exactly
is
it
scoped,
but
like
from
a
this
should
produce
in
AST,
and
it
like
should
look
like
this
is
the
shape
that
it
should
look
like
I
haven't
heard
any
feedback
any
like
pushback,
so
so
I
guess
the
options
there
are
like
are.
D
Basically
we
could
introduce
it
in
a
flag
in
graphql.js
to
get
it
pushed
earlier,
but
not
have
people
like
running
servers
with
it
or
yeah.
Basically,
like
the
the
thing
I'm
bringing
up
for
the
working
group
is:
what
are
we
lacking
to
get
it
through
graphql.js,
and
maybe
that's
just
review.
C
I
think
it's
review
there,
so
I
think
the
the
tricky
part
about
Landing
it
without
a
flag
is
whatever
Behavior
you
produce
once
you
merge
it
and
you
get
a
version
out.
There
is
the
behavior
that
people
will
start
to
rely
on
which
really
starts
to
limit
your
ability
to
work
through
sort
of
the
final
phases
of
the
RFC.
So.
D
I
did
originally
have
a
flag,
and
then
you
recommended
I
remove
the
flag,
but
I
think
yeah
yeah,
but
that
was
like
a
year
and
a
half
ago
or
something
okay,
whatever
I
do
think
it
probably
makes
sense
to
basically
right
now.
The
diff
removes
the
fragment
variables
flag,
like
a
special
fragment
variable
syntax
flag.
D
It
probably
makes
sense
to
just
change
the
name
of
that
flag,
so
like
yeah,
if
you
were
depending
on
fragment
variables,
which
nobody
should
have
been
besides
meta,
because
we
were
the
ones
that
forced
that
now,
there's
this
new
flag
instead
and
the
parser
can
just
not
understand
things
unless
it
has
the
flag
and
that
lets
us
from
a
tooling
ecosystem
like
make
sure
that
the
tools
can
pass
that
flag
or
whatever
or
even
we
could
do
it
at
the
the
flag
could
be
after
the
parser
and
instead
in
the
we
could
have
a
validation
that
just
is
like
yo.
D
C
C
C
You
can
have
some
tests
that
apply
the
flag
and
then
do
everything
that
you
want
it
to
do,
which
should
unblock
our
ability
to,
like
you,
know,
test
the
corner
cases
and
make
sure
everything's
working
as
expected
and
then
also
unblade
unblock
the
ability
for
Relay
to
rely
on
that
version
with
the
flag
enabled
to
then
test
out
relay
as
a
dependency
and
make
sure
you
haven't
missed
anything
there's
like
some
I,
don't
know,
20
chance.
That
there's,
like
some
Edge
case,
that
you
missed.
That
really
needs.
D
Probably
action
one
is
to
add
the
flag
like
add
back
or
rename
the
flag
and
add
it
to
the
parser,
which
is
actually
the
exact
same
approach,
we're
doing
with
relay.
So
that's
fine.
B
C
D
Yeah
the
big
question
before
we
actually
like
make
it
in
like
make
it
finalize
it
into
the
spec,
is
probably
the
scoping
behavior
specifically
like
that
this
algorithm
for
how
you
can
scope,
which,
like
there
will
probably
be
iteration
there,
might
be
iteration
on
that
or
won't
be
like
it's
good
enough,
and
we
are
very
confident
that
behaviorally,
it
won't
change,
even
if
we
explicitly
add
scope
instead
of
do
this
replacement
thing
that
we're
doing
now,
but.
D
So
it's
like
an
implementation
detail
of
the
algorithm
that
we
need
to
describe
in
the
spec,
which
is
fine,
like
you
could
implement
it
in
a
different
way
and
get
the
same
result.
Foreign.
C
Cool
I'll
try
to
give
a
question
to
read
through
what
you've
got
up
anyhow,
knowing
that
you're
gonna.
Add
that
to
it
just
in
case
there's
anything
else:
I
spot
yeah.
A
Do
you
mind
if
we
Circle
back
to
my
previous
topic
for
a
moment,
yeah
go
for
it.
Cool
yeah
I
was
just
thinking
about
it.
A
little
more
and
I
I
was
thinking
about
the
past
print
pass
cycle
and
effectively
there
isn't
a
way
of
passing
and
cheers.
There
isn't
a
way
of
passing
a
schemer
that
doesn't
have
any
root
operation
types
currently,
unless
they
don't
have
the
default
names.
A
If
you
have
like
type
query
right,
literally
type
query
food
string
right
just
that,
there's
nothing
that
you
can
add
to
that
to
make
it
a
schema
that
doesn't
have
a
root
operation,
any
root
operations
as
sdl.
C
Right,
you
would
need
to
add
some
arbitrary
other
type
say
say
you
added
a
type
called
mutation
and
then
you
added
a
schema
block.
That
said,
the
mutation
type
is
called
mutation.
Then
exactly
you
would
not
have
query
right
because
you've
specified
your.
C
A
Exactly
that
that
I
believe
at
least
in
graphql.js
doesn't
pass
probably
needs
validation
to
check
that
that
is
definitely
the
case
yeah,
but
I
think
it
won't
pass.
C
C
You
don't
need
to
add
something
there
that
says
by
the
way.
By
the
way,
this
is
not
the
graphql
mutation
type,
because,
presumably
somewhere
in
what
would
then
become
the
concatenated
set
of
sdls,
you
would
have
the
schema
block,
which
intentionally
omits
that
or
maybe
you
have
a
graphql
mutations
type
or
something
that
you've
put
in
place.
A
The
only
way
to
get
into
this
situation
at
the
moment
is,
if
you
build
the
schema
through
code.
Assign
types
like
do.
New
graphql
schema,
pass
it
types,
but
don't
pass
it
query,
mutation
or
operation,
in
which
case
you
then
have
a
schema
with
no
root
operation
types
which
you
can
then
print
I'm,
not
even
sure
that
you
can
actually
construct
that
in
graphql.js
either
like
the
test.
A
D
C
Yeah,
which
is
produces
the
same
result,
it's
just
fast.
D
Although
we
might
I
think
we
may
not
have
in
the
past
before
there
was
a
sdl
AST,
which
I
think
there
was
a
point
where
graphql.js
parsed
directly
into
schema
types
which
might.
C
C
C
D
A
Oh,
it's
because
sometimes
it
can
be
null
and
sometimes
it
can
be
undefined
and
I
did
it
without
that
I
I
think
it's.
What
was
this?
There
was
a
subtlety
there.
A
Back
but
it
was
actually
worse
than
that,
one
of
them
returns
undefined
and
one
of
them
returns
so
I
think
if
you
do
like
get
query
type,
I
think
it
returns
null,
whereas
if
you
say
get
type
query
with
queries
of
string,
then
it
returns
undefined
because
I
think
it
looks
up
in
a
map
and
doesn't
find
anything.
A
So
then
I
couldn't
just
say
if
the
types
are
the
same
like
if
they're,
both
null
or
if
they're,
both
not
null
and
the
same
thing,
which
was
obviously
a
lot
neater
than
writing
a
ton
of.
If
statements
I
can
go
back
to
the
old
pattern,
you
can
see
the
old
pattern
that
was
in
there,
which
is
like
get
the
query
type
and
if
the
query
type
exists
and
its
name
is
query.
A
But
I
I
thought
that
this
was
more
straightforward
to
just
say:
here's
the
query,
operation,
type,
here's
the
query
type
or
null
or
null,
and
then,
if
they're
the
same
and
they're
always
the
same,
then
we
do
one
thing.
Otherwise
we
do
the
other.
C
Yeah,
that
makes
sense.
Okay,.
A
B
A
C
We
say
that
this
is
a
schema
of
coming.
Actually,
what
it
is
is
it's
should.
A
C
Okay,
yeah
makes
sense,
I'll
I'll
poke
at
it
and
see
if
I
have
any
opportunity
to
simplify,
but
otherwise
I
think
this
looks
great.
It's
nice
that
it
is
terse
and
it's
got
a
test,
which
is
what
you
want,
and
this
must
rank
for
one
of
the
best
test
names.
Prince
viral
schema
yeah.
It
was
going
viral
awesome
all
right.
C
I,
don't
think
so,
I
think
it's
just
a
matter
of
getting
the
initial
stuff
set
up
and
then
getting
took
into
place.
But
I
will
let
you
know
if
I
spot
anything
in
the
back
half
of
that
process.
A
Cool
when
you're,
adding
when
you're
adding
Ricky
to
the
relevant
teams,
could
you
add
me
to
them
as
well?
Please
yep,
awesome,
fantastic
and
anyone
else
that
makes
sense.