►
Description
Presented by Rouven Weßling, Developer Evangelist (Contentful).
By stitching together multiple GraphQL schemas we can take away the overhead of having to remember where data is located and how to resolve references between them. In this talk, you’ll learn how to use schema stitching to annotate the GitHub API with metadata about the repositories and users in an organization, resulting in a more powerful API that’s ready to build great tooling with less effort.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
Hey
everyone
I
hope
you
all
had
a
great
conference
so
far.
Thank
you
for
joining
me
to
talk
about
API
measure
ups
and
how
to
combine
api's
using
graph,
kresge
master
Ching
first
or
what
about
myself.
My
name
is
Ruben
I'm,
a
developer,
evangelist,
I,
love
av
eyes
and
I
love
cake.
You
can
fight
me
later
at
the
cake
place
if
I'm
not
eating
Kate
and
not
coding,
I'm,
probably
running
to
the
streets
of
Berlin,
where
I
live
I
mostly
run
so
I
can
eat
more
cake.
So
I
don't
do
a
lot
of
pleasure
I.
A
Do
it
out
of
necessity,
I
work
for
a
start-up
called
contentful.
What
we
do
is
we
have
a
Content
infrastructure
that
allows
you
to
separate
your
content.
Management
means
completely
from
the
application
stack
I'm,
not
gonna,
talk
about
this
any
further.
If
you're
interested,
please
come
up
to
me
afterwards.
I
also
have
really
cool
socks.
That
I
would
love
to
give
to
you
so
api's
api's
are
awesome.
I'm
preaching
to
the
choir
here.
A
Most
of
us
are
developers
and
when
I
explain
api's
to
new
developers
or
people
who
aren't
developers,
I
likes
to
say,
they're,
Legos,
they're,
tiny,
building
blocks
that
I
can
put
together
to
something
bigger.
I
might
have
to
use
some
glue
from
baiting
a
really
big
model,
but
the
individual
pieces
contribute
a
lot
to
it
and
the
times
of
black
boxes
just
do
what
I
tell
them
to
do
and
developers
love
api's.
A
If
you
look
what
the
current
hotness,
what
the
cursed
trend
in
api's
is
the
stuff
that
comes
up
again
and
again
is
graph
QA
and
when
I
give
you
a
very
short
introduction
to
graph
career
because
necessary
to
understand
the
rest
of
the
talk.
But
the
purpose
of
this
talk
is
not
to
explain
graphically
as
a
whole,
but
just
one
specific
use
case
for
it.
A
A
I
can
specify
exactly
what
data
I
want
and
get
just
that
data
and
I
can
get
all
the
data
I
want,
with
just
one
API
request,
so
I
don't
have
to
go
back
and
make
multiple
requests
to
one
API
just
to
get
all
the
data
I
want
and
and
I
think.
This
is
the
reason
why
it
becomes
so
popular.
It
enables
front
and
driven
data
selection.
A
So,
if
you
add
in
your
project
at
your
company
in
your
team,
wanna
start
using
web
gray,
you
might
have
a
conversation
like
this
one.
That's
supposedly
happen
at
Airbnb
graph.
Ql
is
very
scary
for
back
end
engineers
like
me,
because
we
don't
think
front-end
developers
know
whole
databases
work
and
we
don't
trust
you
with
databases.
Really
the
thing
you're
gonna
bring
everything
down.
A
Folks,
like
me,
just
think
it's
really
really
terrifying.
So
there
are
pitfalls
here.
Graph
QL
is
not
an
easy
technology.
It's
not
just
something!
You
just
hash
over
your
existing
API
and
you're
in
magic,
unicorn
fairyland.
It
actually
are
hard
amount
of
work
to
get
at
work
reliably,
but
what
unlocks
is
really
really
powerful?
A
So
I
want
to
give
you
a
really
quick
example.
What
goes
into
a
graph
QL
API,
the
core
part
of
every
graph
QL
API
is
its
schema.
There's
a
tiny
excerpt
from
the
github
graph,
QL
API,
it's
the
type
repository
that
implements
an
interface
called
node
and
some
of
the
properties
you
have
on
the
interface
you
see
it
has
an
owner
which
is
another
object,
type
called
repository
owner.
The
bang
at
the
end
means
it's
never
died,
it's
always
defined.
It
also
has
a
URL
as
a
connection
to
the
star
gazers.
A
Next
I'm
gonna
write
a
query.
This
is
what
I
write
to
access
the
github,
API
and
I
say
for
the
repository
content
for
in
the
organization
contentful
with
the
name
content,
folder
Jas,
which
is
our
Java
SDK
I.
When
I
get
the
following
information.
I
want
to
know
what
is
the
URL
to
access
the
repository
I
wanna
know
how
many
star
Gators
are
there
and
I
wanna
know
in
which
organization
does
it
exist
and
what
I
get
back
is
a
JSON
object?
A
Now,
if
you
look
closely,
you
see
that
the
structure
of
the
JSON
object
matches
exactly
the
structure
of
my
query.
So
even
if
it's
an
API
I
have
never
touched
before.
If
I.
Just
look
at
the
query
that
somebody
has
written
I
can
already
reason
about
the
data.
The
API
will
return
to
me
without
having
to
read
any
sort
of
documentation.
Just
by
looking
at
the
code
right
in
front
of
me
that
becomes
really
powerful
when
you're
working
with
API
is
that
are
unfamiliar
to
you.
So
how
do
I
write
a
graphical
API?
A
A
First
I
always
have
to
write
a
schema.
In
this
case.
The
schema
contains
just
one
query:
with
the
name:
hello,
there's
going
to
return
a
string
now
with
a
query,
I
only
define
our
table
schema.
I've
only
find
what's
possible.
I
still
need
to
write
the
code
that
actually
responds
to
any
incoming
graph
query
for
that
I've
write
a
resolver
for
every
query
for
every
object
type.
You
write
a
resolver
function
that
you
pass
to
a
pull
server
that
returns
the
data
requested
by
the
user.
In
this
case,
it's
very
easy.
A
I
just
need
to
write
a
resolver
for
hello
that
returns
a
string,
so
that
looks
like
this
and
now
I
simply
start
Apollo
server
and
if
I
access
this
to
a
graph
client
again
I
can
see
my
schema
I
can
introspect.
My
schema
I
have
a
query
that
simply
queries
hello
and
I
get
the
word
word
back,
which
is
a
string,
so
it
matches
the
schema
and
again
the
result
nationals
exactly
the
structure
of
the
query.
So
that's
all
similar
to
start
with
a
graph
QL
API.
A
Now,
let's
get
back
to
talking
about
our
little
Legos,
we
mentioned
before
developers,
love
api's.
How
much
do
developers,
love
Feis?
That's
the
question,
and
so
there's
a
lot
AB
speech
today:
50%
have
2
to
5
api's
news,
9%
use
more
than
25
api's,
1f
and
I
didn't
make
this
up.
I
have
a
salt
on
this
data.
A
A
So
with
this
many
api's,
what
you
need
to
know
about
them?
Well,
you
need
to
know
which
api
holds
which
data
I
want
to
render
a
view.
I
need
to
know
which
API
you
have
to
query
for
it.
How
do
I
authenticate
against
each
of
these
API?
How
do
I
have
how
do
I
get
the
necessary
access
permissions
and
crucially,
which
feeds
in
my
API
respond
indicate
a
reference.
A
foreign
key
and
database
speak
to
another
API
and
then
how
do
I
find
that
API?
How
do
I
resolve
that
with
25
API
on
a
project?
A
That's
a
lot
of
complexity,
and
knowing
all
of
this
is
quickly
a
Herculean
task
and
graphically
I
makes
some
of
that
easier
already.
Even
if
all
your
API
eyes
are
using
web
QA
just
covering
how
api's
would
and
what
data
is
available
becomes
a
lot
easier,
but
the
real
power
starts
somewhere
else
and
the
question
that
I
ask
myself
is
what,
if
we
had
just
one
API
for
all
the
data
I
need
for
project
and
what,
if
Legos,
are
the
wrong
metaphor
for
describing
api's
what?
If
we
could
treat
them
like
music?
A
Who
here
has
sort
of
measures
before
music
and
mashups?
Alright,
most
of
you,
a
good
half.
Alright,
a
music
and
mashup
was
really
big
in
the
70s
80s,
as
a
song
is
created
by
blending.
Two
existing
songs
together,
I
could
take
the
the
lyrics
from
one
track.
The
singing
and
take
the
the
tunes
from
another
track,
for
example,
and
a
great
mashup
will
be
a
good
song
in
itself,
but
it
will
also
leave
the
two
songs
that
made
that
measure
possible
recognizable.
A
A
A
A
So
let
me
give
you
an
example:
how
we
can
use
this
concept
and
apply
to
api's
at
content.
We
have
a
lot
of
open
source
projects.
In
fact,
just
our
main
content
content
for
data
organization
has
over
a
hundred
open
source
repositories
and
it's
starting
to
be
really
hard
to
keep
track
of
them.
What
we
need
is
a
dashboard
that
gives
me
an
overview
of
what's
happening
in
our
open
source.
Ecosystem
I
want
to
pull
that
information
on
github,
because
many
lament
training
data
is
lame.
A
I
want
to
store
some
metadata
in
contentful
and
I
also
want
to
involve
other
services.
For
example,
Travis
CI
already
knows
whether
the
test
succeed
for
this
given
project
or
not
I,
don't
need
to
replicate
that
somewhere
else.
So
first
thing
I
did
is
I
store.
All
the
data
that
github
doesn't
know
about.
A
My
project
in
contentful
I
can
model
my
own
data
there,
so
I've
modeled
a
repository,
a
team,
a
group,
a
department
so
I'm
just
containing
the
information
which
which
Paulo
Torre
is
owned
by
which
team
in
contentful
and
now
I
have
these
two
api's
I
have
github
the
indie
rock
band
of
open
source
and
I
have
content
for
the
Berlin
style
electronic
startup.
But
what
I
want
is
I
want
to
have
a
unified
version
of
this
data
and
that's
my
stitching
proxy.
A
A
To
create
a
remote
Seema,
I
need
to
configure
an
HTTP
link.
The
HTTP
link
simply
goes
to
github
square
ql
api,
and
I
also
take
care
of
authorization
in
this
step.
So
I
simply
pass
in
a
giving
up
token
with
the
necessary
access
privileges
that
I
need
for
this
project
and
the
context
manipulate
every
request
before
going
out
to
that
link
and
adds
the
header
with
the
necessary
talking
to
it.
A
Next
up,
I'm
calling
introspect
schema
to
that
link.
Introspect
schema
will
simply
download
the
schema
from
the
API
and
makes
it
available
locally
for
me
to
manipulate
and
then
I'm
making
the
schema
executable.
Making
a
scheme.
Executable
in
this
case
simply
means
any
call
to
a
query
or
type
in
the
schema
is
deferred
to
this
link,
so
it
simply
passed
along
and
I
can
start.
A
My
server
and
I
have
a
local
proxy
for
my
github
API
that
takes
care
of
authentication
already
good
first
step,
but
not
really
what
we
need
porque,
no
los
dos
we
need
to
API
is
to
make
a
measure
so
we're
simply
doing
the
very
same
thing
with
contentful
we're
getting
the
executable
schemas
for
both
these
api's
and
then
we're
merging
them
together.
Most
schemas
from
graph
care
tools
simply
combines
everything
into
one
big
schema,
but
intelligently
remembers,
which
query
belongs
to
which
API
and
delegate
them
correctly.
A
At
this
point,
things
simply
exist
in
one
schema,
without
any
references
between
them
and
again,
I
start
my
server,
and
this
is
what
the
schema
looks
like
individually.
We
have
a
github
schema
with
the
data
from
github
and
we
have
a
contentful
schema
with
the
data
I
store
in
content.
For,
but
that's
a
problem,
if
you
noticed
these
schemas
conflict
because
they
have
the
same
name
for
the
type
and
every
type,
every
query
in
a
graphical
schema
has
to
be
unique.
A
So
this
won't
do
because
I
will
only
be
able
to
curvy
one
of
those
two
api's,
not
both,
but
the
great
thing
is
the
graphical
spec
is
very
well
defined
and
there's
a
defined
abstract,
syntax
tree
underlying
the
schema
and
I
can
use
this
abstract
syntax
tree
to
paniculata.
The
schema
programmatically.
A
So,
there's
a
little
bit
more
code
involved,
first
off
I'm,
taking
my
content
of
schema
setting
it
up
like
I,
have
before
and
I'm
passing
it
to
transform
schema
and
now
I
can
give
it
an
array
of
transformations
to
make
sure
the
schema
is
a
reformer
that
works
for
my
use
case
in
this
case,
I
want
to
rename
all
types
that
contain
the
word
repository
and
simply
replace
them
with
repository
metadata.
I
also
need
to
take
care
of
the
top-level
queries.
A
Those
are
called
root,
fears
and
both
api's
have
a
root
field
called
repository,
so
I'm
also
renaming
that
one
to
repository
metadata
and
now
my
schema
will
look
like
this.
I
still
have
exactly
the
same
schema
from
github,
but
I
modified.
The
contentful
schema
to
rename
every
type.
Every
query
that
has
the
word
repository
to
be
repository,
metadata
and
breath
care
tools
is
advanced
enough.
That
would
seamlessly
stay
pass
on
the
data
to
the
right
API.
A
So
that's
the
schema,
but
I
also
need
to
write
a
resolver
now
again
to
actually
resolve
those
fields
for
those
objects.
So,
let's
first
take
the
content
for
repository
metadata
object,
I'm,
defining
that
the
field
github
repository
unwrapped
object
will
be
resolved
by
this
function.
The
first
thing
we're
adding
is
a
fragment.
A
fragment
is
a
small
piece
of
reusable
graph
query
in
this
case
I'm
saying
whenever
you
query
for
the
github
repository
field.
A
Add
this
fragment
to
the
query
in
this
fragment:
queries
for
the
github
name
and
get
up
login,
that's
necessary,
because
I'm
gonna
use
these
to
then
ask
the
github
API
for
this
data
to
ask
for
this
data
I'm
using
merge,
enforced
delegated
schema
I'm.
Simply
instructing
my
server
that
the
information
the
user
is
seeking
lives
in
this
other
schema,
so
I'm
delegating
through
it
and
I'm
delegating
to
it.
By
querying
the
repository
career
with
the
github
log
in
and
get
up
name
of
the
correct
repository
there's
a
data
I
only
got
for
my
fragment.
A
That's
pretty
easy,
that's
very
straightforward!
But
what?
If
it's
not
that
straightforward?
What
if
the
api's
don't
fit
so
nice
lead
lightly
together
what
if
the
data
is
not
directly
available
in
the
format
that
I
wanted
to?
What?
If
there's
not
a
clear
query
to
just
ask
for
this
one
piece
of
data
that
I
need
what
I
have
exactly
that
problem,
but
I'm
craving
contentful
for
data
contentful
has
little
quirk
in
that.
You
can
only
ask
for
a
collection
of
objects.
You
can't
ask
for
an
individual
object
by
one
of
its
fields.
A
So
again,
I'm
defining
a
fragment
that
simply
says
me:
I
need
the
name
and
the
owner's
log
in
which
is
the
organization
name.
Whenever
I
query
for
content
for
media
data
and
I'm
gain
I'm
delegating
to
a
schema
with
a
query,
but
as
you
can
see,
I'm
actually
caring
for
a
collection
I'm
not
just
wearing
for
an
individual
object
and
it's
a
problem
because
most
email
says
content
for
metadata
will
be
an
object,
not
a
collection
of
objects.
So
how
do
I
solve
this?
A
Why,
when
you
delegate
to
a
schema,
you
actually
can
add
a
new
transformation
to
this
query
and
the
wizard
you
get
back
from
that
query.
So
I've
done
just
that
and
Rev
query
allows
me
to
modify
the
query
for
applet
or
middle
area
connection
to
add
a
new
level
in
between.
Instead
of
just
curving
directly
for
the
data
I'm
craving
for
the
items
and
then
the
data
and
I'm
modifying
the
result
to
simply
return
the
first
item
of
the
first
entry
in
the
items
array.
A
A
One
of
my
favorite
API
endpoints
and
get
up
API
is
the
reader
file
for
my
github
repository
and
return
it
to
the
API
endpoint,
which
resurrection
endpoint,
which
well
it's
just
another
future
query
for.
But
what,
if
I,
couldn't
just
read
this
data
and
then
manipulate
it
in
my
API?
What
if
I,
can
actually
take
information
contained
in
these
files
and
expose
it
as
field
in
my
modified
gillip
API?
So
for
this
use
case
I
want
to
know.
Does
this
repository
has
a
Travis
CI
Yama
file?
A
If
it
does
I
can
query
Travis
CI
for
the
business
of
this
project?
If
it
doesn't
have
it
I,
don't
need
to
query
so
I
want
to
expand
the
type
repository
that
comes
from
the
github
graphical
API
at
a
new
Fiat
hash,
Travis
CI
and
it's
gonna
be
a
boolean.
It's
never
gonna
be
nice
and
then
I'll
write
a
resolver
first
I
need
to
have
the
fragment
I'm,
trying
github
object
in
the
master
branch
for
the
five
dots
Travis
dot,
Jana
I'm
supposed
to
treat
as
a
text
block.
A
A
We
talked
earlier
about
the
repository
endpoint
and
the
polar
Tory
takes
an
owner,
in
this
case
content
for
and
a
name
in
this
case.
Let's
say
content
for
Jas
and
now
I
can
ask
for
fields
on
that
object.
For
example
the
URL
or
the
sshd,
where
you
see
I
get
a
very
nice
autocomplete,
so
it
actually
becomes
fairly
easy
to
figure
out
what
name
is
there
this?
The
owner?
The
owner
has
some
information,
like
they
log
in,
for
example,
and
when
I
crave
for
the
data
I
simply
get
the
result
as
JSON
back.
A
If
I
have
a
more
complicated
question
about
this,
API
I
can
also
browse
the
schema
here
and
I
see
all
the
possible
queries
that
are
available
on
the
github
API
and
on
the
content
API,
because
this
is
a
stitch
stitch
schema.
So,
for
example,
the
repository
has
also
the
information
about
the
fork,
for
example.
So
let's
ask
for
his
fork
but
much
more
interestingly.
A
You
see
it
takes
a
little
bit
longer
because
not
has
to
go
to
to
api's,
but
I
get
all
the
information
about
which
team
which
department
ounces
repository
seamlessly
in
the
same
response
as
the
information
from
github,
about
which
what
this
repository
is
and
I
can,
for
example,
also
ask
for
the
star
gazers
and
see
how
popular
this
is.
Our
JavaScript
SDK
has
four
hundred
seventeen
likes
or
PHP
SDK
63,
for
example,
and
apparently
isn't
owned
by
anybody
now.
A
So
what
do
I
get
us,
stop
treating
your
api's
or
Silas
they're,
not
completely,
and
it
shouldn't
be
completely
independent
of
each
other.
There
are
relationships,
they
exist
between
them
and
when
you
start
exploiting
these
relationships,
you
can
seamlessly
access
data
across
these
api's
and
make
your
developers
life
much
easier
and
make
some
sweet
music.