►
From YouTube: GitLab's GraphQL API
Description
Simon, EMEA Solutions Architect presents on GitLab's Graph QL API and answers questions from customer success team members.
Key Topics:
What is GraphQL?
What problems does it solve?
Live Demo of the GitLab GraphQL API
A
B
B
I've
assumed
no
knowledge
here,
but
what
we're
going
to
be
talking
about
is
graphql,
because
gitlab
is
going
graphql
first
and
we
have
been
graphql
first
for
some
time
now,
and
so,
let's
just
dive
into
what
that
means.
So,
first
and
foremost,
this
is
our
agenda.
So
we're
going
to
go
through
an
example
use
case
I
think
you'll
find
use
cases
quite
light-hearted
and
and
funny
we're
going
to
talk
about
rest
and
and
how
you
might
use
a
rest
en
endpoint.
B
B
And
then?
Finally,
with
that
knowledge
and
and
a
very
light
and
fluffy
example,
use
case
out
the
way
we're
going
to
deep
dive
into?
Oh,
I'm
going
to
show
you
gitlab's
graphql
api
running,
live
in
in
a
production
environment
and
we're
going
to
explore
that
and
show
show
you
some
of
the
power
that
that
graphql
end
point
has
so
yeah
really
for
those
of
you
that
don't
know
graphql
is
is
is
a
way
of
querying
data.
B
So
graphql
stands
for
graph,
query
language:
it's
it's
a
way
that
you
can
write
an
api
and
the
the
reason
why
it's
called
graph
is
because,
as
the
symbol
you
know
they
use
is
that
it's
meant
to
represent
a
data
graph.
So
you
quite
often
these
days
when
you're
requesting
data
from
an
api
lots
of
data
is
related.
B
Rest
endpoints
aren't
great
at
kind
of
giving
you
that
relationship
and
quite
often
you'll
have
to
kind
of
piece
to
things
together
as
you'll
see
later
with
ids
from
different
types
of
endpoints,
and
that's
pretty
much
how
the
gitlab
api
works
as
it
currently
starts,
so
the
rest
endpoint.
I
should
say
so:
let's
talk
about
the
use
case.
The
example
use
case
we're
going
to
talk
about
here.
B
B
We
want
it
to
be
responsive,
we're,
probably
going
to
want
it
to
be
mobile
first
and
all
of
the
other
good
things
that
people
expect
these
days.
So
you
know
we
want
it
to
be
a
good
best.
Practice
example,
which
is
gonna
cause
some
challenges
so,
first
and
foremost,
managing
data
in
modern
applications
is
challenging.
So
quite
often
we
have
various
different
front-end
clients,
so
it
may
be
that
we
want
to
develop
an
ios
app
for
this,
for
this
particular
example,
but
we
also
want
it
to
be
web-friendly.
B
We
may
need
to
even
have
some
customized
other
versions
of
the
application
you
know.
For
you
know,
I
don't
know
pet
breeders
or
something
each
with
different
data
requirements.
So
there's
you
know,
depending
on
where
the
application
is
being
displayed.
It
comes
with
different
data,
so
whether
it's
mobile
or
desktop
you're
working
with
very
different
screen
real
estate,
and
you
may
have
different
subsets
of
data
that
need
to
be
displayed
on
the
home
screen.
B
Just
as
a
pure
simple
example,
the
backend
service
that
actually
serves
all
the
data
to
the
clients
is
going
to
be
potentially
serving
the
data
from
multiple
different
places
as
well.
So
a
lot
of
the
data
is
going
to
be
stored
in
a
database,
but
that
could
be
a
postgres
database,
but
there's
also
redis
databases
and
memcache
and
all
the
rest
of
it.
B
So
it
may
be
that
you're
using
a
multitude
of
different
data
sources,
and
I
won't
even
talk
about
like
federated
data
sources,
so
where
you're
pulling
data
in
from
other
other
applications.
Those
considerations
as
well
and
finally
complex
state
and
cache
management
for
both
the
front
end
and
the
back
end.
So
data
changes
data
constantly
changes.
How
does
how
does
the
client
and
the
server
respond
to
those
those
data
changes
and
how
does
it
propagate
them
to
to
the
front
end?
B
So
how
do
we
solve
this
so
rest
to
the
rescue?
Maybe
so
using
rest?
The
page,
let's
just
take
a
hypothetical
example.
Hopefully
all
of
you
can
see
that
large
enough,
the
page
that
we're
developing
might
need
to
say
display
a
list
of
dogs
that
are
available,
whether
they're
suitable
for
rehoming
with
cats
and
their
current
location,
so
which
shelter
they
reside
in.
B
I
want
three
and
I
and
I
want
you
to
start
at
the
beginning.
So
here's
a
list
of
pause,
but
the
data
we're
getting
back
here
is
incomplete,
we're
just
getting
the
name
in
the
cover
photo
and
whether
they're
reserved,
because
this
endpoint
maybe
hasn't
been
designed
with
this
particular
screen
in
mind.
B
It's
been
designed
with
another
screen
in
mind,
and
so
we
get
the
poor
ids
here,
and
so,
if
we
want
to
find
out
whether
this
these
dogs
are
suitable
with
cats,
the
next
thing
that
we
need
to
do
is
go
and
then
get
each
pet.
That's
been
returned
to
individual
details,
so
we'd
need
to
query
one,
seven,
nine
or
27,
and
we
get
more
information
about
this
particular
dog.
B
B
It
might
be
actually
in
a
linked
table,
but
the
long
short
of
it
is
this
is
this:
is
a
field
that
links
this
dog
to
a
particular
shelter
which
is
probably
being
held
in
another
table
somewhere
in
a
database
and
you're
getting
a
sort
of
a
glimpse
into
the
underlying
data
structure
here,
but
you
all
you're
getting
is
this
number
three
and
we
need
more
than
that?
We
need.
B
So
this
one
puppy,
love
in
the
isle
of
docks,
london
tells
us
how
many,
what
capacity
they
have
and
how
many
guests
they
have
great.
So,
with
all
this
information,
we
can
piece
this
together
and
we
can.
We
can
display
this
screen
now,
but
this
solution
requires
multiple
dependent
network
requests,
which
is
going
to
result
in
fast,
lower
page
load
times.
B
It's
going
to
result
in
additional
battery
consumption
on
mobile
devices
or
low
power
devices,
and
the
logic
is
also
really
difficult
to
reuse.
On
other
pages
that
display
different
data,
so
you
could
argue
that,
okay,
you
know
this
could
have
been
designed
for
a
different
page,
so
one
solution
would
be
to
create
a
dedicated
api
endpoint,
for
this
particular
use
case
for
this
particular
ui
screen
that
we're
on
now
so
basically
make
one
make
one
that
returns
pause.
B
You
know
with
you
know,
might
you
call
it
pause
with
suitability
for
cats
and
shelter
and
what
it'll
do
is
it'll
return?
You
know
the
same
information
you've
got
here,
but
with
the
additional
suitable
for
cats,
and
maybe
the
name
and
the
location
of
the
the
shelter
included
in
this
response.
But
this
is
a
very
specific
api
endpoint
then
it's
very
it's
very
specific
to
the
ui
solution
that
we're
trying
to
solve.
B
So
it's
incredibly
inefficient
and
time-consuming,
because
what
you're
going
to
end
up
with
is
numerous
endpoints
that
all
have
similar
functionality
and
they're
all
going
to
return
vast
amounts
of
data.
Quite
often
much
more
than
is
required,
and-
and
so
it's
not
great
because
every
single
time,
if
someone
in
the
front
end,
wants
to
make
a
change
or
add
a
new
add
a
new
update.
B
B
What
other
issues
can
we
see
here?
So,
let's
we've
already
sort
of
talked
about
the
the
network
fetching
side
of
this,
but
there
are
other
issues
as
well.
So
let's
take
this,
this
api
endpoint
for
getting
a
single
single
dog,
so
we've
got
an
example.
Data
on
the
left
hand,
side
and
some
issues
on
the
right,
so
some
of
the
biggest
problems
with
with
rest
is
over
fetching,
so
overfetching
just
is
purely
meaning
that
the
client
is
getting
much
more
data
and
much
more
information
is
actually
required
to
be
used
inside
the
application.
B
So
take
an
example
of
the
screen
that
needs
to
display
a
list
of
dogs
with
only
their
names
in
the
rest
api.
This
app
would
usually
hit
the
pause,
endpoint
and
return
a
json
array
with
an
array
of
dog
data.
This
response,
however,
contains
far
more
information
about
the
dogs
that
are
returned
I.e.
It
returns
their
cover
photo
and
their
reservation
status.
Information
that,
quite
frankly,
is
useless
in
this
use
case
in
this
particular
use
case,
because
it
only
needs
to
display
the
dog's
name.
B
So
under
fetching
causes
n
plus
one
requests,
but
the
n
plus
one
requests
problems
so
under
fetching
generally
means
that
a
specific
endpoint
doesn't
have
all
the
data
that
you
need,
and
so
what
that
normally
means
is
that
the
client
will
have
to
make
an
additional
network
request
to
fetch
everything
else,
that
it
needs
and
then
kind
of
combine
them.
This
can
escalate
into
a
situation
where
a
client
needs
to
first
download
a
list
of
elements.
B
So
in
the
previous
example,
a
list
of
dogs
and
their
ids
and
then
needs
to
make
additional
requests
per
element
based
on
that
id
to
fetch
the
required
data.
So
in
the
previous
slide,
so
just
to
go
back
really
quickly.
We're
going
to
have
to
make
one
request
to
get
this
and
then
one
request
per
each
of
these
in
this
list.
So
that's
an
example
of
under
fetching
and
the
kind
of
problems
that
solves
other
questions
to
kind
of
ask
herrera.
What
are
the
types
of
the
return
data
set?
B
So
we're
talking
about
data
here,
like
the
client
is
it's
a
rest,
doesn't
give
you
like
any
hints.
It's
you've
just
got
a
url
to
hit
so
get
api
pause,
27,
so
you're
completely
relying
on
documentation,
so
everything's
being
done
by
contract
in
terms
of
reading
api
documentation,
ensuring
that
you're,
aware
of
all
the
edge
cases.
B
So
you
don't
know
what
the
structure
of
this
rest
endpoint
is
going
to
return
until
either
you
make
that
request,
or
you
look
in
the
documentation
and
it
very
clearly
details
what
that
what
the
data
set
returned
is
going
to
be.
It
doesn't
give
you
any
hints
as
well
about
what
the
data
types
are
even
going
to
be.
So
what
is
poor
id
is
this?
Is
this
a
number
or
is
this
a
string?
It
could
be
either.
B
We
have
no
idea
unless
it's
documented
in
the
api
documentation,
you're
not
going
to
know,
then
it's
also
some
really
interesting
questions
like
hey
this.
This
example
is
great.
So
let's
say
you
you've
queried
the
api
and
you've
got
an
id.
You
can
see
what
the
type
of
data
set
it's
going
to
return
is,
and
you
program
that
all
the
front
end
based
on
this.
B
What
if
there
is
no
cover
photo?
What,
if
you
know
it's
a
brand
new
dog,
that's
just
been
just
been
brought
in
and
it
doesn't
have
a
photo.
Yet
what's
it
going
to
return,
is
it
going
to
return
null?
Is
it
going
to
return
an
empty
string,
zero,
false
you
have
no
way
of
knowing
unless
again
it's
documented-
and
these
are
the
real
edge
cases
here.
So
what
if
there
are
no
photos,
so
the
prime
example
now
is:
we've
got
this.
This
photos
field
here,
which
is
which
is
an
array
of
other
photos.
B
What,
if
they're
uncertain
about
queen
elizabeth's
suitability
with
kids
and
trying
to
say
it
correctly
without
slipping
so
at
the
moment,
we've
got
true
and
false
down
here,
that's
great!
It's
boolean
one
or
zero,
true
or
false,
but
if
they
don't
know
how
do
they
represent,
that
is
it
going
to
be
null?
Is
it
going
to
be
undefined?
Is
it
going
to
be
a
string
saying
unknown?
You
know
how
do
we
know
all
these
kind
of
problems
cause,
of
course
headaches
for
teams
consuming
these
apis?
There's
a
lot
of
trial
and
error.
B
Also,
another
common
pattern
with
rest
apis
is
to
structure
the
endpoints
according
to
the
views
that
you
have
inside
your
app.
So
we've
just
talked
about
that
in
the
previous
slide.
This
is
handy
since
it
allows
the
client
to
get
all
the
required
information
and
for
a
particular
view
just
by
making
one
endpoint
but
requests
sorry.
But
the
major
drawback
of
this
approach
is
that
it
doesn't
allow
for
rapid
iteration
on
the
front
end
with
every
change
that
is
made
to
the
front
end.
B
There
is
a
high
risk
that
they're
now
there
is
more
or
less
data
required
than
before.
So
consequently,
the
back
end
needs
to
be
updated
or
a
new
endpoint
created,
or
that
an
existing
one
changed,
but
it
may
be
that
more
than
one
ui
front
page
is
actually
you
know
reliant
on
that
endpoint
and
so
actually,
by
removing
a
piece
of
data
or
adding
a
new
piece
of
data,
you
might
break
functionality
somewhere
else
in
the
application.
B
This
just
kills
productivity
and
slows
everything
down,
so
there's
all
the
pitfalls
of
of
rest.
So
what
is
graphql
and
how
does
it?
How
does
it
help
so
graphql
save
the
day
so
graphql
is,
is
a
actually
a
system
designed
a
schema
designed
by
facebook,
so
it
was
originally.
The
concept
was
created
by
facebook,
who
obviously
have
a
very
large
social
data
graph,
and
so
it's
a
problem
that
they
know
well
and
they
describe
it
as
as
this.
B
Okay.
What
does
that
mean?
What
it
means
is
that
really,
when
working
with
graphql,
you
really
just
have
to
follow
three
simple
steps
when
you're
either
designing
and
working
with
graphql
apis.
So
you
generally
start
by
describing
your
data.
This
is
all
the
server-side
stuff.
So
this
is
the
equivalent
of
writing
the
rest
end
points
and,
and
then
you
ask
for
then
as
a
client.
You
then
just
ask
for
what
you
want
and
then
number
three
is
you
benefit
you
get
these
predictable
results.
So
let's
take
a
look
at
this
as
an
example.
B
B
This
schema
defines
a
hierarchy
of
types,
so
here's
a
few
types
dog
and
shelter
with
fields
that
are
populated
from
your
back
end
data
stores,
notice,
stores,
plural.
You
can
actually
have
different
fields
coming
from
different
places.
The
schema
also
specifies
exactly
which
queries
and
mutations
are
available
for
clients
to
execute,
execute
against
your
data
graph.
So,
on
the
right-hand
side
here,
you've
got
the
queries
and
the
mutation
types
which
define
which
endpoints
are
available
for
your
clients.
B
B
By
defining
these
relationships
in
a
unified
schema,
we
enable
the
client
developers
to
see
exactly
what
data
is
available
and
request.
A
specific
subset
of
data
with
a
single
optimized
query:
note
that
the
schema
is
not
responsible
for
defining
where
the
data
comes
from
or
how
it's
stored.
So
the
schema
is
literally
just
saying
I'm
going
to
give
the
client
this
this
data
in
this
format,
it's
not
respond.
The
schema
itself
is
not
responsible
for
defining
where
it
comes
from.
B
B
A
graphql
schema
is
most
powerful
when
it's
designed
for
the
needs
of
the
clients
that
will
execute
operations
against
it.
So,
although
you
can
structure
your
types
so
that
they
match
the
structure
of
your
back-end
data
stores
in
your
database,
you
don't
have
to
a
single
object.
Types
fields
can
even
be
populated
with
data
from
any
number
of
different
sources,
so
in
short,
design.
Your
schema
based
on
how
data
is
being
used
not
based
on
how
it's
being
stored.
So
you
can
see
here,
we've
got
rid
of
this
shelter.
B
Id
shelter
id
is
an
irrelevant
field
when
you're
talking
about
a
dog.
The
only
reason
why
you'd
have
shelter
id
is
to
tie
it
to
a
particular
shelter.
We
haven't
included
shelter
id
because
there's
no
need.
We
can
literally
just
query
the
shelter
straight
on
the
dog.
So
we've
got
this
this
relational.
This
graph
link
from
dog
to
shelter
here
this
is
so
storing
things
like
shelter
id
as
part
of
the
dog
type
would
be.
B
So
all
of
a
sudden
we've
just
gone
from
a
rest
api
where
you
might
have
you
know
this
rest
api
returns
a
data
in
this
structure.
Id
name
cover
photo,
but
it
might
not
necessarily
tell
you
what
types
they
are
to
all
of
a
sudden,
not
just
having
a
schema
telling
us
exactly
what
will
be
returned
and
what
you
know
additional
queries
we
can
make
on
it,
but
also
what
types
they
all
are.
B
So,
for
example,
the
the
reserved
field
is
a
boolean,
so
this
means
that
yeah,
the
schema
not
only
describes
the
shape
of
the
data
that
can
be
requested,
but
the
types
of
data
that
are
going
to
be
returned.
Predictably,
this
is
going
to
make
client
development
so
much
easier
because,
rather
than
having
to
read
an
api,
it
self
documents
itself
you'll
see
it.
B
So
with
that
was
first
from
the
server
side.
Let's
talk
about
it
now
from
the
client
side,
client
side.
Great
thing
is,
it
looks
very
similar,
so
the
graphql
client
or
commonly
like
an
apollo
client,
but
you
can
even
just
use
a
simple
http
request,
almost
like
a
rest
request,
but
with
some
extra
syntax,
it's
going
to
make
use
of
the
same
querying
language,
the
graphql
query
language
to
make
and
request
data,
as
it
does
in
the
server
to
to
define
what
data
is
available.
B
So
you've
got
an
example
here,
on
the
left
hand,
side
of
a
request
being
made,
so
this
would
be
attached
as
part
of
a
http
request
and
you're
saying
hey.
This
is
a
query.
We're
going
to
call
the
query
something
you
can
give
a
name
to
your
query.
So
we're
saying
hey,
get
pause,
we're
saying
which
query
we
want
to
run
so
just
to
go
back
really
quickly.
B
We've
got
this
query
type
being
defined
on
the
server
and
one
of
the
queries
that's
defined.
Is
this
pause
and
you
say:
hey:
we've
got
a
limit
and
an
offset.
So
we've
talked
about
typing
for
the
data
types.
The
other
great
thing
is
it's
typed
and
very
specific
for
all
the
queries
and
the
mutations
as
well.
So
instead
we
get
a
list
of
all
the
options
that
we
have
available
to
us.
B
In
terms
of
this
request,
and
if
I
was
to
change
this
three
to
a
string
three
so
in
quotations,
it
would
throw
an
error
and
say
you're
using
a
string
where
you
need
to
have
an
int
and
so
straight
away.
The
server
can
be
more
predictable.
The
client
could
be
more
predictable,
so
in
this,
in
this
example,
here
we're
recreating
the
requirements
used
on
the
rest,
query
example,
so
just
to
go
back
a
few
slides
apologies.
B
B
If
you
remember
that
that
took
us
three
separate
queries
each
dependent
on
the
previous,
causing
three
round
trips
of
request
responses,
at
least
to
get
the
data
that
we
needed,
so
here's
an
example
of
how
we've
managed
to
reduce
it,
to
a
single
query,
and
not
only
that,
but
we've
managed
to
ask
for
the
exact
information
that
we
require
not
anymore
and
not
any
less.
So
what
we're
doing
here
is
we're
saying:
hey.
We
want
all
the
pause,
the
return
type
of
the
pause.
Query.
B
So
here
we've
got
basically
the
the
query
being
executed
and
these
fields
are
on
type
dog.
So
we're
asking
for
the
id
we're
asking
for
the
name,
the
cover
photo,
whether
it's
reserved
and
finally,
whether
it's
suitable
with
cats
and
because
we
need
to
know
where
it
is
we're
just
saying
hey
for
this
dog
for
the
shelter
that
it
it
currently
resides
in,
give
us
the
name
in
the
location
of
it.
B
So
what
if
we
actually
solved
it?
So
that's
pretty
obvious.
Really,
we've
solved
most
of
the
key
problems
we
identified
so
over
fetching
and
affecting
is
no
longer
an
issue.
We've
got
exactly
the
data.
We
need
no
more,
no
less,
keeping
the
transmission
of
data
as
light
as
possible
for
these
low
low
powered
clients.
B
What
are
the
types
of
the
return
data
set?
So
we
know
that
the
api
tells
us
the
type.
So
we
know
that
that
problem
has
been
solved.
What
if
there
is
no
cover
photo?
Well,
I'm
going
to
go
back
a
step
just
to
show
you
why
this
is
interesting,
so
cover
photo.
You
can
see
here,
it
says
string.
You
might
wonder
why
some
of
these
have
exclamation
marks
and
some
have
not
so
the
exclamation
mark
in
graphql
syntax
tells
you
that
the
field
is
non-nullable.
B
B
What
this
means
is
that
photos
will
always
return
an
array
because
it's
non-nullable,
so
you
can't
have
null
as
a
result
for
photos,
so
it'll
always
be
an
array,
but
it
could
be
empty,
but
if
it
does
contain
something
the
thing
inside
the
array
must
be
a
string.
It
can't
be
null
again,
so
it
tells
you
very
clearly
what
the
data
structure
is.
So
with
that.
We
know
that
if
there
is
no
cover
photo,
it
can't
happen.
We
don't
have
to
worry
about
that.
It's
impossible.
There
will
always
be
a
string
there.
B
Let's
just
again
we'll
go
back
you'll
notice
that
the
suitability
with
kids
and
cats
and
dogs
is
a
boolean,
but
it
does
not
have
that
exclamation
mark
on
the
end.
What
that
means
is
that
it
could
be
true.
It
could
be
false.
It
could
be
null
there's
a
very
clear,
very
clear
understanding
there
given
to
the
client
that
hey
you
actually
have
to
deal
with
all
three
eventualities
of
that.
So,
if
it's
not
known,
it's
null,
it's
fine.
B
Finally,
the
last
problem
we
highlighted
was
apis
are
often
tied
to
views
and
uis
causing
loads
of
back-end
changes.
Whenever
a
new
ui
sort
of
comes
about,
the
api
is
only
tied
now
to
the
data
that
it
can
possibly
deliver.
The
client
applications
can
decide
exactly
what
they
want
and
how
it's
structured,
giving
them
complete
freedom
to
iterate
without
api
changes
most
of
the
time
so
we've
decoupled
the
back
end
from
the
front
end,
which
means
that
front-end
development
can
just
press
ahead
and
get.
B
C
B
B
So
the
things
to
note
really
here
are
that
the
gitlab
graphql
api
endpoint
is
located
at
api
forward.
Slash
graphql,
not
b3
v4,
which
obviously
the
rest
endpoint,
there's
a
there's,
a
fair
amount
of
documentation.
It's
mostly
developer
focused
but
do
keep,
do,
have
a
look
at
the
documentation
for
for
graphql
in
our
docs
and
then
finally,
I'm
going
to
show
you
something
called
graphical,
which
is
a
really
interactive,
graphql
explorer.
B
So
I've
already
got
it
pre-loaded
here,
and
so,
if
you
go
to
gitlab.com
forward,
slash
dash
forward,
slash
graphql
explorer
you'll
be
presented
with
this
page,
and
this
is
a
a
graphql
explorer,
but
it's
actually
just
a
full
graphql
client.
You
can
do
whatever
you
want
with
it,
so
get
rid
of
that
first,
so
you
might
be
staring
at
this
straight
away
going.
Where
do
I
go
from
here?
So
first
and
foremost
docs
are
built
in,
and
this
is
another
great
thing
about
graphql
self
documents.
B
One
of
the
one
of
the
endpoints
that
a
graphql
server
actually
provides
is
the
schema
endpoint
and
it
will
deliver
this
full
schema
to
any
client
that
asks
for
it.
So,
as
a
result,
here
you
can
see,
we've
got
two
root,
types,
queries
and
mutations.
That's
always
the
same
in
most
in
you
know
in
all
graphql
endpoints.
Sometimes
you
might
see
subscriptions
as
well,
which
is
actually
a
way
of
live
updating
data
with
graphql.
B
But
we're
going
to
look
at
this,
this
query
endpoint,
so
you
can
click
on
query
and
all
of
a
sudden.
Now
you
can
see
every
single
query
you
can
make
in
in
graphql
now
I
know
there's
a
few
that
I
would
like
to
use
so
we're
just
going
to
write
a
query
and
we're
going
to
do
live
demo,
query
and
we're
going
to
we're
going
to
ask
for
something.
B
I
know
that
I
want
to
look
at
projects
so
we're
going
to
look
at
projects
and
if
I
mouse
over
projects
now
it
says
it
needs
a
must,
have
to
have
a
selection
of
subfields,
and
so
I
need
to
define
a
what
it
is.
I
I
want
from
projects,
but
also,
if
I
don't
know
how
you
know
what
options
are
available
to
query,
I
can
open
a
bracket,
and
it's
going
to
tell
me
everything-
that's
available
on
this
query.
B
So,
for
example,
I'm
going
to
use
search
and
if
I
don't
know
what
search
is
I
can
mouse
over
search.
It
tells
me
that
it's
a
string,
if
I
want
to
I
can
I
can
even
click
on
this
and
it'll.
Take
me
straight
to
the
documentation.
So
you
can
see
exactly
what's
queryable
and
even
more
descriptions
as
to
what's
available
there.
B
It's
almost
explicitly
expected
that
there
is
an
id
and
there's
a
couple
of
extra
bits
of
syntax
when
we're
talking
about
our
our
end
point,
so
you
quite
often
see
this
syntax
being
used
so
edges,
nodes,
nodes
and
page
info.
There
is
a
link
in
the
deck
which
is
in
fact
the
very
first
link
in
the
further
reading,
which
is
talking
about
edges,
nodes
and
cursors.
B
It's
really
mostly
to
do
with
pagination
and
cursor-based
pagination
and
how
you
go
about
doing
that,
and
it
relates
to
edges
of
the
lines
between
the
nodes
in
the
graph
et
cetera,
there's
lots
of
information.
There
do
take
a
look
at
it
but
effectively.
If
you
just
think
of
nodes
as
the
result,
this
is
now
a
project.
So
we
can.
B
We
can
see
name
and
if
I,
if
I
just
run
that
query
so
just
by
pressing
command
enter
for
me
or
just
pressing
this
button
up
here,
you're
going
to
get
the
result
back
and
so
instantly,
you
can
see
hey
we've
searched
for
a
gitlab
environment
toolkit
and
I
can
see
some
data's
come
back.
I
can
see
there's
projects
and
I
can
see
there's
nodes
and
it's
an
array
of
an
array
of
projects
and
if
I
mouse
over
nodes
again
here
on
the
left
hand,
side
here.
D
B
Should
see
it's
nodes
returns
an
array
of
type
projects.
If
I
want
to
see
what
fields
are
available
on
the
project,
I
can
click
on
that
and
I
can
see
all
the
different
fields
that
are
available,
including
queries
themselves.
So,
like
name,
is
fine,
there's
also
a
name
with
namespace.
So
if
you
want
to
know
exactly
where
they
are,
it
tells
you
where
they
are,
which
is
quite
cool
and
when
it
comes
to
the
rest,
endpoint.
B
This
is
pretty
much
the
level
you
can
get
to.
You
can
say:
hey
I'd
like
a
project
or
I'd
like
to
search
for
projects,
and
the
only
thing
you
can
query
is
things
that
exist
on
this
project,
but
this
is
graphql,
so
let's
go
a
bit
crazy.
So
all
of
a
sudden
we
can
query
issues,
issues
aren't
stored
in
the
same
place
and
we
can
get
an
id.
B
We
can
get
probably
an
assignee
yeah,
let's
go
for
an
assignee
or
even
even
more
crazy
than
that
so
it'll
also
auto,
auto
populate
things.
If
you
missed
something
out
so
assignees
is
actually
because
it's
an
array,
I
actually
forgot
that
assignee.
Obviously,
we
can
have
more
than
one
user
assigned
to
an
issue,
it's
an
array,
so
it's
auto
populated
edges
and
it's
also
populated
nodes
and
ids,
and
what
you'll
probably
find
here
oops
is
username.
B
So
if
I
do
that,
so
all
of
a
sudden
now
we
have
nodes.
So
each
of
these
nodes
represents
a
project,
and
this
is
this.
This
project
has
no
issues
fine,
but
down
here
you
can
see
the
get
lab.
Quality
and
gt
project
has
quite
a
few
issues.
So
we've
got
some
issues
here
with
some
ids
and
nobody's
assigned
and
then
see
down
here,
we've
got
grant
being,
not
surprisingly
grants
assigned
to
all
of
them.
You
know
there
we
are,
but
you
can.
What
I'm
saying
is.
B
B
User,
which
is
probably
a
bit
dodgy,
but
we'll
start
going
down
into
this-
I
can,
I
can
add,
more
and
more
data
to
this,
and
I
can
remove
data.
It
will
so
hopefully
that
kind
of
gives
you
an
idea
as
to
the
kind
of
power
you
can
have
with
this
graphql
query
system
do
use
the
graphql
explorer,
have
a
play.
There's
a
lot
here
and
it
is
set.
Like
I
said,
self
documenting.
The
most
important
thing
is
basically
start
off
with
a
query.
B
You
can
start
off
with
that,
and
that
is
all
you
need,
and
then
you
can
pretty
much
from
there
just
look
and
explore
from
from
what's
available
in
the
api.
There
is
also
authentication
you
might
have
noticed
at
the
moment
that
I'm
requesting
a
public
project
and
there's
a
reason
why
it's,
because
I'm
not
logged
in
yet
and
down
here
at
the
bottom
you've
got
query
variables.
You
can
attach
headers
and
authentication
mechanisms
as
part
of
the
query
variables.
There
are
other
ways
of
doing
it.
B
C
Okay,
verbalize:
I
think
this
is
actually
confirmed
by
the
engineering
side
so
on
the
vulnerability
management
gitlab.
I
think
they
went
graphql
first
on
the
data,
so
say.
If
you
have
a
customer,
that's
trying
to
pull
information
together
or
they're
trying
to
make
their
own
vulnerability.
Dashboard
suggests
the
graphql
endpoint,
because
right
now
the
rest
endpoint
is
missing
a
few
properties
and
I
think
they're
they're
trying
to
close
a
gap
on
that.
But
that
was
just
something
that
came
up
and
might
be
uncomfortable.
B
Yeah
the
downside
to
being
graphql
first,
as
a
I
mean
in
the
grand
scheme
of
thing,
we've
been
graphql
first
now
for
quite
some
time,
but
there
are
still
plenty
of
rest
endpoints
that
haven't
been
as
yet
updated,
and
so,
as
a
result,
they
haven't
had
that
graphql,
love
and
and
they're
not
necessarily
available
there.
Yet
so
it
is
a
bit.
There
are
some
things
that
are
still
definitely
missing
from
the
graphql
schema.
B
The
I've
seen
a
massive
massive
amount
of
work
being
done
on
it
on
the
last
probably
six
to
nine
months.
So
it's
it's
constantly
getting
more
and
more
stuff
added
to
it,
and
you
really
have
the
flexibility
to
query
whatever
the
hell
you
like
really,
which
is
which
is
fantastic
so,
unlike
the
rest,
rest
endpoints,
so
yeah
questions.
D
Yeah
thanks
for
the
presentation,
simon,
that
was
really
awesome,
so
I
think
that
the
first
two
questions
are
basically
related.
The
first
one
is
basically
are
people
using
the
graphql
endpoints
that
you've
seen
in
practice,
so
customers
partners?
Is
it
something
that
people
know
about
yeah?
So
that's
the
first
question
and
the
second
one
is
about
versioning.
D
So
someone
put
a
link
about
you
know,
philosophy
behind
versioning,
graphql
endpoints.
They
basically
said
not
to
do
it
yeah.
So
I'm
just
curious.
I
I
guess
sort
of
like
a
related
question
is
in
our
documentation.
We
talk
about
eventually
creating
potentially
another
version
of
our
rest,
api
version
5
and
how
that
have
a
better
synergy
with
graphql.
So
when
is
that
happening?
If
there's
any
plans
to
actually
do
that.
B
End
changes
what
the
the
other
best
practices
start
small,
it's
much
easier
to
add
things
than
it
is
to
remove
things
from
a
graphql
schema,
because
of
that
every
very
reason,
because
it's
not
versioned
there
is
actually
a
way
in
certain
servers.
So
apollo
server
has
a
flag
to
mark
a
field
as
deprecated,
and
so
that
will
warn
you
every
single
time.
You
make
a
query
to
that
field
that
hey
this
feature
is
deprecated
and
it's
going
to
be
removed.
So
there
are
ways
of
deprecating
fields.
B
It's
generally
considered,
like
the
last
resort,
though
so
yeah
are
there
any
customers
using
graphql,
not
directly.
I
think,
but
I
think
more
and
more,
like
I've
definitely
got
some
customers
who
are
using
our
graphql
endpoints
with
scripting
tools.
You
know
their
internal
tools,
that's
really
the
main
use
case
for
at
the
moment,
and
and
to
be
honest
like
as
I
alluded
to
earlier,
it
was
missing
in
some
pretty
key
functionality
until
fairly
recently.
D
B
The
part
of
the
reason
we're
graphql
first
means
that
any
new
feature
being
added
to
the
product
now
must
have
a
graphql
endpoint,
first
and
foremost,
and
it
may
not
get
a
rest
endpoint
that
inevitably
will
drive
users
over
to
using
graphql
over
time.
If
we
continue
down
that
route,
that
is
more
of
an
engineering
decision
than
I'm
aware
of
there's.
There's
an
engineering
there's.
Actually
a
graphql,
weekly
or
bi-weekly
meeting
for
any
graph.
Graphql
related
queries
that
the
engineering
team
holds.
B
E
Yeah
I've
seen
even
in
some
cases
the
rest
apis
are
being
deprecated
in
favor
of
graphql,
for
example.
If
you
want
to
pull
the
results
from
security
scans
that
you
know,
I've
been
exploring
that
with
the
customer
and
was
told,
definitely
go
the
graphql
route,
because
it's
more
complete
and
they're,
not
that
they're,
probably
going
to
pull
the
apis.
B
B
So
what
you'll
do
is
it'll
run
the
run,
the
resolvers
for
the
query
that
you've
got
so
it'll
run
that
query
for
the
dog
and
it
would
resolve
all
of
those
fields
making
database
requests
and
then
what
it
would
do
is
it
would
pause
and
wait
one
one
millisecond
to
kind
of
do
another
loop
and
then
it
would
realize
that
it
needs
to
go
and
get
the
the
shelter
information.
Then
it
would
go
and
do
that
and
what
it's
doing
is
it's
it's
very
efficiently
going
and
getting
all
that
data
in
in
one
go.
B
If
you
quite
often
one
of
the
biggest
problems
with
rest
is
over
fetching
and
actually
causes
extra
headache
for
the
the
server
as
well
you're
you're,
asking
for
far
more
data
than
you
actually
need
it
to
provide.
So
there
is
some
pretty
big
efficiency
savings
as
well
as
graphql
on
the
back
end,
as
well
as
the
front
end.
D
Yeah
follow-on
question
for
that.
I
think
that
that's
really
interesting
what
you're
talking
about
from
a
performance
perspective,
I'm
wondering,
obviously
we
know
about
gitlab
being
slow
and
how
that's
like
something
that
we're
trying
to
work
on.
I'm
wondering
if
anyone
knows
if
our
new
user
interface
views
actually
leverage
graphql
versus
rest
for
when
they're
fetching
data
like.
Are
we
doing
this
ourselves?
Like
I'm
curious?
If
anyone
knows
that.
B
F
Yep
selfishly,
I
was
hoping
to
jump
us
back
to
one
of
the
earlier
questions
chris
had
asked
about
customers
using
the
graphql
endpoint.
Our
scalability
folks
had
pushed
me
to
push
up
one
of
our
customers
to
to
adopt
this
because
of
that
n
plus
one.
You
know,
fetching
problem
you
get
with
rest
and
the
biggest
pushback
I
got
from
this
customer
was
well.
F
You
know
we're
using
a
library
that
you
know
that
basically
exposes
in
a
very
elegant
way
for
our
code,
all
the
rest,
endpoints
and
you
know
their
their
supposition
was
well.
You
know
until
that
library
or
a
similarly
good
library,
that's
actively
maintained
sort
of
offers
that
for
graphql
we're
not
really
incentivized
to
switch,
but
but
in
asking
that
question
I
think
I'm
realizing.
F
B
You
know,
live
while
you're
editing
view
of
whether
you're
coding
correctly
for
the
types
that
are
expected
from
the
endpoint
you
and
the
requests
you
can't
it's
very
common
practice,
like
you
say,
to
wrap
rest
end
points
in
sort
of
cli
tools
or
those
kind
of
things
because
they're
complex
and
they
can.
You
can
make
easy
mistakes.
The
the
idea
with
graphql
is
because
it's
typed
error,
checked
and
and
self-documenting
you.
You
don't
really
need
to
do
that.
Yeah.
B
Okay,
yeah,
I
mean
so
the
the
biggest
challenge
I
would
say
with
graphql
at
the
moment
is:
if
you
don't
use
a
client,
you
can
just
make
graphql
requests
using
http
requests
just
to
be
completely
clear.
At
that
point
it
is
kind
of
a
bit
clunky
because
you're
not
getting
any
of
that
integration
and
you
also
aren't
managing
cache
and
state.
So
part
of
this.
One
of
the
other
great
things
about
graphql
is:
if
you've
got
this
data
coming
from
the
server
and
you've
got
ids.
You
know
what
types
they
are.
B
You
can
actually
store
that
information
on
the
client
and
then,
if
another
query
on
another
page
requests
the
same
the
same
data,
it
doesn't
request
it
from
the
server.
It
actually
requests
it
locally
from
the
cache
and
that's
part
of
what
apollo
client
does
again.
There's
links
on
the
last
page
in
the
resource
slides
to
learn
more
about
that,
but
there's
a
there's
a
lot
there.
You
get
a
lot
of
benefits,
but
apollo
client
is
really
the
thing
that
makes
this
much
much
much
easier.
There
are
other
clients
for
graphql
available,
yeah.