►
From YouTube: Collaborating across the stack with GitHub and GraphQL - GitHub Universe 2018 - GitHub Universe 2018
Description
Presented by Adam Zionts, Cloud Services Engineer (Apollo GraphQL).
We'll dive into the software collaboration space and take a look at how teams collaborate on building and consuming APIs via GitHub today. We'll take a look at the nuts and bolts of how we've used the GitHub platform and the Checks API to enhance this collaboration with an API management and collaboration tool. Finally, we'll explore the next steps for expanding GitHub and Apollo's shared vision of enhancing software collaboration. Throughout the talk, I plan on using the GitHub GraphQL API itself as our prototypical example to tie the story together.
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
Hi
everyone-
it's
really
great
to
be
here,
we
are
talking
about
I,
have
a
slide,
collaborating
across
the
stack
with
github
and
graph
QL,
but
before
we
get
started
I
should
let
you
know
a
little
bit
about
myself.
My
name
is
Adam
I
work
at
Apollo.
If
you
know
about
graph
QL,
you
might
know
about
Apollo.
Don't
worry
if
you
don't
know
about
graphical
we're.
Gonna
talk
a
little
bit
about
that
and
what
I
do
at
Apollo
is
cloud
systems,
engineering,
cloud
engineering,
data
engineering,
whatever
you
wanna
call
it
doesn't
matter.
A
The
reason
I
want
to
tell
you
that
is
for
two
reasons:
one
is
I
collaborate
on
api's,
all
the
time,
I'm
working
with
front-end
developers
and
back-end
developers
around
what
changes
we're
going
to
make
to
our
API
what
data
we
need
it
in
our
integrations
and
in
our
app,
and
the
second
reason
is
I-
want
you
to
think
carefully
about
the
designs.
I
have
and
remember
that
I'm
a
cloud
engineer
in
my
slides.
So
when
you
look
at
those
just
keep
that
in
mind.
A
So
what
we
do
at
Apollo
is
essentially
all
around
graph
QL
and
we
work
with
we've
been
working
with
graph
QL,
since
it
was
launched
in
2015.
We
work
with
lots
of
different
customers
around
graph
QL.
One
of
them
is
Airbnb
and
I
threw
this
quote
up
there,
so
you
can
see
what
it
means
to
them,
but
hopefully
it
means
a
different
thing
to
you
guys
out
in
the
crowd
and
at
Apollo.
A
We
want
to
build
the
graph
QL
platform,
a
whole
solution
for
it
before
I
dive
into
what
that
means,
with
a
show
of
hands.
How
many
of
you
guys
have
heard
of
graph
QL
awesome,
that's
great.
How
many
of
you
guys
have
used
touch
tinkered
with
graph
QL
wow?
That
is
tremendous
and
how
many
of
you
guys
are
using
graph
kill
in
production?
Okay,
still
a
good
number
and
that's
huge,
because
oh.
A
Because
in
2015,
just
a
few
short
years
ago,
graph
QL
was
originally
launched
at
reactor
Europe
and
originally
introduced
before
that.
A
react
conf
and
there
was
no
tooling
around
in
other
than
a
reference
in
pation
until
2016,
when
Apollo
client
was
born,
one
of
the
first
tools
to
work
with
graph,
QL
and,
of
course,
the
namesake
of
Apollo
and
how
we
got
started,
and
this
is
only
in
the
last
year.
A
A
And
in
graph
every
year
we
have
an
annual
graph
QL
summit
to
talk
about
what's
happening
in
graph
Q
on
the
very
first
graph
killed,
something
we
had
wasn't
2016
less
than
a
year
after
its
launch,
and
already
there
were
early
adopters
using
it.
Github
had
released
or
was
working
on
the
very
first
public
graph,
QL,
API,
Shopify
and
Coursera
were
using.
A
It
in
Facebook,
of
course,
had
originally
led
the
charge
on
graph
QL
and
invented
it,
and
now
we're
standing
today
with
tons
of
different
companies
using
graph
QL,
whether
they're,
using
it
in
production
for
their
internal
developer
tools,
or
they
have
engineers
tinkering
with
it.
A
lot
of
more
people
have
heard
about
graph
QL
and
we're
gonna
talk
a
little
bit
about
what
kind
of
opportunities
graph
DL
provides
specifically
for
collaboration,
but
in
order
to
motivate
that
I.
A
Why
we
need
a
universal
language
for
data
what's
important
about
it,
then
I
want
to
touch
a
little
bit
on
what
our
mission
is
at
Apollo
and
then
I
want
to
take
a
step
back
from
graph
QL
and
from
Apollo
and
think
about
just
collaboration
in
general,
taking
specific
motivation
from
github,
which
is
why
we're
here
today
to
celebrate
github
and
the
motivations
that
we've
gleaned
from
in
the
work
that
we've
been
able
to
do
around
it.
And
lastly,
I
want
to
talk
about
the
actual
topic
which
is
collaborating
with
graph
QL.
A
So
the
first
thing
is
the:
why?
And
what
of
graph
QL-
and
the
reason
is
very
simple:
I
alluded
to
it
a
little
bit
earlier
and
it's
data,
so
this
is
actually.
This
is
github
data
model
all
of
github
data
models.
So,
as
you
guys
might
know,
github
has
a
public
graph,
QL
API
and
there's
a
tool
called
graphical
Voyager.
You
can
use
to
visualize
all
of
all
of
the
data
in
a
company,
and
you
can
see
this
isn't
even
all
the
entire
data
model.
A
But
at
least
it's
a
way
to
talk
about
data
in
a
universal
way
which
is
English,
but
I
think
that
we
could
have
an
even
more
Universal
way
to
talk
about
data,
and
this
isn't
an
old
concept.
This
isn't
a
new
concept.
This
is
very
old
concept.
Called
a
lingua
franca.
Leer
is
heard
of
what
a
lingua
franca
is
sure.
So
for
those
of
you
who
haven't
it
is
a
language
that
you
can
systematically
use
to
talk
with
someone
else
who
might
not
speak
the
same
language.
You
do.
A
This
is
a
really
common
term
in
business.
When
you
have
people
from
different
countries
from
different
continents
from
different
cultures
and
backgrounds,
have
a
language
that
they
can
use
to
negotiate
to
trade,
to
make
deals
and
I
think
that
we
can
have
the
same
thing
for
data.
We
can
have
a
lingua
franca
for
data
and
I.
A
Think
that's
what
graph
QL
is,
and
it
serves
a
really
vital
point
of
in
our
infrastructure,
where
you
have
your
application
code
and
your
application
team
that
needs
certain
data
so
that
they
can
expose
it
to
your
end-user,
whoever
that
might
be,
then
you
have
your
services
and
your
databases
and
all
that
underlying
technology
that
has
some
capability
of
giving
you
data,
giving
you
information
and
graph
QL.
Is
that
vital
layer
in
between
that
maps?
Those
requirements
to
those
capabilities?
A
It's
a
language
to
map
those
two
together
and
to
talk
about
data,
and
to
give
you
a
really
brief
peek
of
what
that
language
is
I,
know
a
lot
of
you
guys
said
that
you've
touched
it.
Are
you
familiar
with
it,
but
it's
two
things
its
first
on
the
on
the
left-hand
side.
You
have
the
type
system.
Graph
kill
is
a
strongly
typed
language,
and
this
is
exposing
what
the
capabilities
are,
what
language
is
available
and
you
can
explore
it.
A
This
offers
two
things:
it
offers
specificity,
which
is
really
important
on
your
client-side
code,
and
it
also
offers
flexibility
which
is
really
important
from
from
both
ends,
because
you
can
build
up
and
expand
your
graph
QL
API,
any
way
that
you
see
fit,
which
is
not
something
that
you
can
easily
accomplish
with
other
other
frameworks,
but
hold
on
I
feel,
like
we've
heard
this
before,
we've
heard
this
mantra
of
I.
Have
this
thing
for
you?
It's
amazing.
It's
gonna,
standardize
everything
that
you
want
amazing,
but
this
is
exactly
what
happens
and
I'm
sure.
A
Some
of
you
guys
have
seen
as
xkcd
comic
before
there
are
14
standards
for
collaborating
unrest.
Api's
and
here
are
all
of
them,
and
it's
terrible.
We
really
need
one
to
unify
all
of
them,
so
we
make
a
15
standard,
but
I
think
that
graph
scale
is
different.
I
really
do
and
the
reason
I
think
it's
different.
Is
that
developers
actually
like
using
it
and
I?
A
Don't
know
if
this
could
work
make
some
noise
if
you
like,
using
graph
QL
out
there,
yeah
and
I
love
using
it
and
just
to
give
you
kind
of
a
quick
peek
of
what
it
is
to
use
graph
QL
if
I
get
this
to
work.
This
is
a
video
of
using
the
github
graph,
QL
API,
and
you
can
go
to
that
link.
I
have
at
the
bottom
to
use
github
graph,
QL
API
immediately
just
sign
in
you
get
your
tokens.
You
can
run
queries.
A
I'm
not
gonna,
go
too
much
deeper
into
what
graph
QL
is,
but
I
will
say
that
there
is
an
awesome
book
if
you
guys
aren't
familiar
with
it
or
want
to
learn
more
about
the
nuts
and
bolts
of
how
to
spin
up
a
graph,
QL
server
and
consume
client
code
and
merge
schemas
together.
This
book,
I
have
right
in
front
of
me,
is
really
tremendous
at
getting
started
and
I
have
a
whole
bunch
of
copies.
So
come
find
me
after
the
talk,
I'm
happy
to
give
them
away
as
while
supplies
last.
A
A
I
really
have
to
take
note
of
the
community
around
graph
QL,
because
that
is
what
enables
its
power
and
also
to
talk
about
what
our
mission
is
as
Apollo
and
it's
to
bring
graph
QL
everywhere
to
enable
an
open-source
community
and
community
of
companies
all
across
the
world
who
can
use
graph
QL
to
better
their
needs,
to
make
things
more
Universal
and
to
collaborate
better,
and
even
though
we
just
started
with
Apollo
client.
We
have
something
like
170
different
repositories
around
graph
QL,
and
these
are
four
of
the
main
ones
to
get
started
a
client.
A
All
of
this
is
in
typescript
or
JavaScript
client,
a
server,
a
react,
integration
for
particular
users
of
react
that
we
have
others
as
well
and
tools
to
make
modifications
of
schemas
and
to
mock
schemas
and
to
work
with
your
API
contracts
and
unique
ways.
But
if
you
don't,
if
you're,
not
a
typescript
program
or
JavaScript
programmer
and
you
like,
Java
or
rust,
or
Kotlin
or
Lua,
there
is
a
huge
community
around
graph
QL
graph.
Ql
is
opinionated
about
one
thing
and
one
thing
only
and
that's
data.
A
It
is
how
to
talk
about
data
where
that's
where
that
data
is
stored.
What
languages
you
use
to
talk
about
that
data
when
you're,
consuming
it
or
fetching
it,
don't
don't
matter
as
long
as
you're
using
graph
QL
in
between,
and
we
also
work
on
having
some
of
those
community
building
some
community
resources
ourselves
to
how
people
get
started
and
to
learn
about
how
to
use
our
tools,
along
with
those
other
resources
that
I
posted
before
and
what
we're
building
is
the
graph
QL
platform.
A
You
can
see
at
each
step
at
each
edge.
You
traverse
along
that
graph,
how
long
that's
TV,
how
much
load
it's
putting
on
your
UI.
Sorry
on
your
server
code,
as
well
as
what
errors
you
might
encounter
along
the
way
and
dig
specifically
into
each
one
of
those
individual
fields
and
edges,
and
this
is
something
that
we
as
developers
have
had
to
rebuild
over
and
over
again.
A
But
the
next
thing
we
thought
about
was
integrations
taking
all
of
that
information
that
we
had
around
your
server
execution
and
bringing
it
wherever
you
are.
So
if
you
want
to
use
data
dog
for
your
metrics,
you're
gonna
use
pager
duty
for
your
alerts.
If
you
want
to
use
slack
for
your
collaboration,
all
this
information
should
be
there
to
help.
You
make
better
decisions
and
faster
decisions
around
your
workflow.
A
Today
we
have
this
whole
set
of
open
source
tools
and
we
work
a
lot
on
what
we
can
do
to
open
the
doors
of
graph
QL
and
the
doors
of
API
development
that
you
don't
need
to
redo
over
and
over
and
over
again,
but
I
think
an
important
thing
that
hasn't
yet
been
hasn't
yet
been
unlocked.
Though
it's
been
talked
about.
A
lot
is
having
graph
QL
is
a
place
for
collaboration
on
your
api's,
but
don't
take
it
from
me
like.
A
Let's
actually
talk
about
collaboration
here,
because
we're
out
of
github
conference
and
get
up
does
collaboration
really
really
well.
So
what
makes
github
so
successful
at
code
collaboration
and
that
collaboration
in
general
I
think
it's
a
few
key
things
and
I
want
to
learn
from
github
here
and
try
to
apply
those
learnings
back
to
graph
QL.
The
first
thing
is
centrality
the
idea
that
we
can
bridge
the
gap
between
your
code
and
your
software,
because
you
might
work
on
code
in
a
tie,
different
places.
A
You
might
work
in
different
local
IDE
s
with
different
build
processes
even
in
different
languages,
and
you
might
chip
your
software
to
different
places.
You
might
have
on-premises
solutions,
you
might
have.
You
know
a
whole
docker
fleet
that
you
run
on
your
own.
You
might
ship
it
to
the
cloud
using
kubernetes.
You
might
be
an
azure,
you
might
have
lambda
functions
whatever
it
might
be.
A
There
needs
to
be
something
to
bridge
the
gap
between
the
two
and
to
make
sure
that
when
you
communicate
with
the
other
people
on
your
team
working
on
this,
you
have
a
language
to
speak
and
that
language
is
github.
So
it's
central
to
those
two
themes-
you're
trying
to
get
from
code
to
software
and
github,
is
in
the
middle,
allowing
you
to
work
together
on
it.
So
I
think
that's
important.
A
You
want
a
place
to
have
all
of
your
code
and
all
of
your
software
in
one
place,
and
that
is
exactly
what
github
enables
by
having
this
great
system
around
different
repositories
and
people
and
teams
and
projects,
and
even
though
we
started
with
just
the
one
Apollo
project,
Apollo
client,
as
I
said
we're
now
at
173
different
repositories
all
across
the
Apollo
workspace.
So
it's
really
been
key
to
have
all
of
that
in
one
place,
so
we
can
build
up
our
community
around
it
and
all
work
together
more
effectively.
A
But
the
third
thing
is
languages.
You
need
a
language
to
communicate.
That's
important
right.
If
you
don't
have
a
way
to
talk
to
each
other,
about
what
you're
working
on
they're,
not
gonna,
get
anything
done,
and
github
is
built
support
for
tons
of
different
languages.
For
this
is
the
the
repo
that
I
specifically
work
on
and
we
work
in
a
lot
of
different
languages
and
get-up
supports
them
all.
There's
the
right
syntax
highlighting
the
right
understanding,
the
right
insights
about
security
analyses.
So
that's
thing
that
I
think
github
has
gotten
really
right.
A
Is
these
three
concepts,
centrality,
universality
and
language?
So,
let's
think
through
those
three
with
graph
QL.
So
the
first
is
centrality
right.
You
saw
this
slide
before
graph.
Ql
is
an
automatic
mapping
between
your
requirements
and
your
capabilities
or
in
our
terms,
your
client
code
and
your
server
code.
So
it's
central!
It's
right
there
in
the
middle
cool
check.
A
The
next
thing
is
universality.
Having
all
of
your
data
in
one
place,
we're
talking
about
collaborating
on
API
is
we're
talking
about
collaborating
on
data,
and
so
you
need
to
have
all
of
that
data
in
one
place
to
be
able
to
work
on
it,
and
so,
when
you're
talking
about
other
frameworks
like
rest,
you
might
have
that
data
scattered
across
multiple
different
endpoints
that
have
different
requirements
that
have
different
schemas
that
have
different
implementers
different
teams
working
on
then
with
different
styles.
A
But
the
craft
QL
you
just
have
one-
is
here
your
graph,
QL
endpoint
that
has
a
universal
way
of
talking
about
that
data
with
its
language,
so
cool
universality
feeling
good
so
far.
The
next
one
is
language,
and
language
is
really
easy,
because
graph
QL
the
L
stands
for
language.
We
have
a
language
out
of
the
box,
so
I
think
we
have
our
three.
A
In
today's
talks
and
yesterday's
talks
around
the
new
actions
feature
and
on
making
suggestions
which
I
think
are
really
pivotal
and
will
drive
the
future
of
being
able
to
collaborate
and
build
up
better
workflows
together
so
that
we
can
do
things
more
automatically
and
I
think
we
can
build
up
those
same
workflows
around
graph
QL.
Let's
look
at
my
idea
of
a
very
simplified
github
workflow,
so
you
start
off
and
you
ask
for
some
changes
like
I.
A
Don't
like
this
code,
I
want
new
code,
please
give
me
more
code
and
then
the
implementer
goes
ahead
and
says
that
you
have
a
conversation
like
well
actually,
I
think
that
that's
a
good
idea,
but
maybe
parts
X&Y
shouldn't
be
done
and
Parts
A,
B
and
C.
Should
you
go
on
and
you
have
a
conversation
around
their
requests
and
eventually
you
agree
on
what
you're
going
to
build.
You
go
ahead
and
you
start
building
it.
You
branch
off,
create
a
pull
request
and
you
have
that
same
conversation
around.
A
Did
this
actually
meet
the
needs
that
you
were
asking
for?
Can
you
work
with
it
and
then
you
go
through
that
checks
process
that
we
just
did
with
enabling
collaboration
in
the
first
place,
there's
an
approval
process,
there's
a
CI
and
C
D
workflows
before
you
actually
ship
that
software
to
its
own
destination.
A
So
let's
leverage
this
idea
of
the
github
workflow
for
graph
QL,
so
collaborating
on
graph
QL
the
whole
point.
So
let's
take
that
first
step,
collaborating
together
by
first
asking
for
a
change.
That's
the
first
step.
Well,
this
is
simple:
let's
just
ask
for
a
modification
of
the
API.
We
need
different
data,
and
this
isn't
just
about
the
API
we're
talking
about
graph
QL.
So,
let's
be
spits,
let's
be
specific.
A
We're
requesting
a
modification
to
the
graph
QL
schema
the
contract
that
says
these
are
the
capabilities
I
have
of
giving
you
data
so
that
you
can
get
it,
but
who
should
be
asking
for
that?
It's
at
the
end
of
the
day,
whomever
is
going
to
consume
that
data
and
do
something
with
it.
So
I
really
love
this.
A
The
other
day,
our
own
Chung,
who
was
dude
as
astute
listeners
and
viewers
out
the
crowd,
will
notice,
is
also
the
creator
of
the
NPM
charts
from
before
asked
me
or
asked
our
team
for
new
data
to
be
exposed
in
our
graph.
Ql
schema
and
I
really
loved
the
way
that
he
did.
It
I
think
this
is
like
a
de
facto
standard
for
graph
QL.
You
write
a
query
that
you
want
to
be
able
to
execute.
You
know
I
want
to
in
the
schema.
A
I
want
to
be
able
to
see
a
hash
and
a
created
at,
and
not
only
that.
I
also
want
to
understand
when
that
schema
was
last
changed
and
get
that
that
supplementary
information,
maybe
some
of
this
data
exists,
and
maybe
some
of
it
doesn't
and
then
also
providing
the
supplemental
materials
of
what
are
you
gonna
do
with
that
data?
Are
you
gonna
surface
that
to
the
end-user?
Why
do
you
need
it?
Do
you
actually
need
it?
A
Maybe
you
can
use
something
else
that
we
already
have
so
essentially
your
front-end
developer
says:
I,
have
query
and
asks
can
I
have
a
schema
and
it's
on
the
schema
implementers
and
those
who
expose
the
capabilities
to
provide
that
schema
and
to
work
together.
So
you
go
through
that
process
of
seeing
that
modification
that's
been
requested
and
working
together
to
figure
out
what
it
is
that
they
really
need,
and
then
you
can
actually
start
implementing
the
resolvers,
and
this
is
something
that
we
all
know.
We
know
implement
implementation,
how
to
collaborate
on
it.
A
Cuz,
that's
github,
so
you
go
ahead
and
you
start
implementing
the
same
way
that
you
collaborate
on
code
by
you
know
pointing
to
that
original
issue.
Saying,
ok
and
now
I'm
implementing
this.
This
schema
modification
here
is
how
I'm
doing
it.
You
work
on
the
code
and
whatever
language
you
might
choose,
we're
the
craft
queue
Island
with
pull
requests.
A
But
it's
literally
like
seven
lines
of
code
to
just
mock
out
a
whole
schema,
which
I
think
is
remarkable
and
a
huge
benefit
of
graph
QL,
because
it
unblocks
that
burden
of
waiting
on
your
back-end
developers
to
make
changes
to
the
API
so
that
you
can
start
writing
the
modifications
you
need
for
your
user
code
and
then
the
last
step
is
actually
testing.
Your
schema
changes
against
current
clients.
A
You
want
to
make
sure
that
the
changes
that
you're
making
they
were
really
good
for
that
one
person
who
asked
for
them-
and
hopefully
you
thought
about
the
rest
of
the
world,
but
let's
also
make
sure
that
they
work
for
everyone
else,
who's
using
your
API.
This
is
a
big
difference
between
graph,
QL
and
other
frameworks,
because
you
can
feel
much
safer,
modifying
your
API
because
you
know
exactly
how
it's
used.
A
You
have
a
that
specificity
where,
if
clients
want
to
understand,
want
to
get
some
data,
they
have
to
specifically
ask
for
it:
it's
not
just
given
to
them
in
giant
vomits
of
information.
So
you
can
see
how
your
current
clients
are
using
your
API,
and
this
is
something
that
we've
built
and
we've
been
working
with
internal
for
a
while
and
we're
really
happy
with
him.
A
The
reason
that
this
was
motivated
is
because
of
those
partners
that
we
mentioned
partners
at
huge
organizations
like
github
and
like
Airbnb,
who
have
lots
of
different
software
engineering
teams
and
lots
of
different
moving
parts.
We
want
a
universal
place
for
their
data
and
to
be
able
to
see
how
they're
modifying
their
schema
over
time
and
feeling
safe
about
doing
it.
A
So
you
can
make
changes
to
your
to
your
schema
and
change
types
and
fields
and
have
that
history
that
you
can
understand
what
changes
have
been
made
when
and
by
whom,
and
you
can
dig
into
a
specific
element
of
history
to
see
how
safe
it
was.
If
it's
not
a
warning,
maybe
no
one
is
using
it
yet,
but
it
is
in
fact
a
breaking
change
if
it's
a
failure,
maybe
you're
breaking
a
client,
that's
running
in
production
and
if
it's
a
notice,
maybe
it's
completely
innocuous.
A
You've
added
a
field,
for
instance,
and
one
thing
that
we
do
internally
and
that
I
really
love,
because
I'm
constantly
iterating
on
this
schema
is
building
it
directly
into
the
git
workflow
using
the
github
checks
API,
and
this
is
something
that
that
you
can
get
out-of-the-box
of.
You
are
using
a
graph
QL
schema
by
establishing
that
history
over
time.
You
can
then
register
it.
A
So,
what's
really
exciting
to
me
is
be
able
to
see
that
kind
of
come
together
within
our
own
data
graph
of
bringing
together
your
schema,
versioning
and
history
over
time
with
the
observability
that
you
can
have
into
how
your
graph
QL,
server
and
clients
are
working
in
production
so
being
able
to
annotate
each
history,
each
element
of
history
in
each
version
with
clients
that
you
might
be
breaking
or
queries
that
might
be
run
against.
It
is
really
exciting
to
me
and
I
think.
A
The
future
of
this
is
giving
having
more
of
a
tie
in
between
the
code
and
the
software
that
you're
writing
and
the
API
that
you're
developing
and
the
data
you're,
exposing
so
essentially
bringing
github
more
front
and
the
collaboration
that
you
already
have
built
into
how
you
work
on
code
into
how
you
work
on
schemas.
There
is
already
a
little
bit
of
that
there.
A
If
you
look
in
the
upper
right
here
around
having
commit
messages,
but
I
think
that
we
can
go
much
further
and
as
you're
making
schema
changes
to
see
exactly
where
the
schema
changes.
You're
making
come
from
what
lines
of
code
and
whatever
language
they
are
and
whatever
repo
they
are
made
by,
whichever
team
member
they
might
be
and
at
the
same
time
being
able
to
go
from
the
very
beginning
of
that
process.
A
When
you
want
to
suggest
a
change
and
write
a
query
that
you
can't
see
anymore
and
going
to
where
that
code
lives
in
whatever
repo
or
set
of
repos,
it
might
be
that
expose
that
API
and
so
now,
hopefully
I
will
do
a
short
demo
for
you
guys
if
I
can
get
out
of
here.
So
the
other
week.
I
was
like
I
wonder
what
would
happen
if
I
just
register
github
API
for
our
service
and,
as
you
know,
get
them
as
a
public
graph,
QL
API-
and
this
was
super
easy
with
graph
QL.
A
You
can
make
an
introspection
request
to
their
server
and
I
kind
of
forgot
about
this.
On
October
3rd
I
published
the
schema
as
it
was
as
it
was,
and
on
the
other
day,
I
guess
October
11th
yeah
six
days
ago,
I
published
a
new
version.
I
was
really
surprised
and
delighted
to
see
that
github
had
already
made
modifications
to
their
schema
in
those
past
eight
days
and
you're
able
to
see
the
actual
change
log
of
those
informations.
What
types
were
removed
or
added
or
changed
you'd
also
see
deprecations.
A
A
My
bad
okay
hold
on.
Thank
you
for
telling
me
it's
gonna,
make
it
much
harder
to
do
the
demo,
but
that's
okay,
so
I
was
really
excited
to
see
that
they
had
actually
made
modifications
to
their
scheme
on.
You
could
see
the
changelog
over
that
time
that
there
was.
You
know,
of
course,
I
don't
have
any
observability
into
the
metrics
of
how
people
are
using
graph.
Ql
schema,
but
I
am
able
to
see
that
there
was
one
failure.
A
So
the
other
day,
and
by
the
other
day,
I
actually
mean
a
few
minutes
ago,
I
made
an
introspection,
schema
against
github
and
downloaded
it
to
a
file
and
the
reason
I
did.
That
is
because
you
need
to
have
authentication
tokens
and
I.
Don't
really
want
to
show
you
guys
mine,
but
trust
that
in
intro
JSON,
not
old,
intro
JSON
is
github
x'
current
as
of
an
hour
ago,
graph
QL
schema
and
you
can
run
a
check
against
that
schema,
pointing
to
a
local
service,
in
this
case
I'm
pointing
that
service.
A
A
Okay
cool,
so
there
were
fields
added
and
they're,
just
notices,
cuz,
it's
not
breaking
anything.
So
we
should
feel
safe,
publishing
this
and
it
looks
like
two
things
were
added
now
you
can
do
a
pull
request
review
on
behalf
of
someone
else,
and
you
can
also
mark
a
pull
request.
Review
comment
as
outdated
cool.
These
are
awesome
features,
so
let's
go
ahead
and
change
that
check
command
to
hopefully
publish
if
I
remember
correctly
and.
A
Cool
we
have
a
new
tag
and
a
new
schema
and
let's
see
if
it
shows
up
yep
it's
right
there
and
as
you
we
see,
we
have
two
notices
that
these
two
fields
were
added
and
you
soon.
You
should
be
able
to
go
back
and
look
at
the
actual
commits
that
were
made
in
github.
If
you
have
that
flexibility,
of
course,
we
don't
here
because
I
was
not
the
one
who
made
those
changes
to
the
github
graph,
QL
API,
and
look
and
see
specifically
how
they
were
made
by
whom
and
for
what
reasons.
A
Now,
back
to
not
demo
so
from
here
on,
that
is,
that
is
what
I
wanted
to
try.
I
wanted
to
share
the
vision
that
I
see
for
collaborating
on
graph
QL,
what
is
already
out
there
and
what
you
can
do
with
it
and
whether
or
not
you're
using
graph
QL
right
now.
Hopefully,
you
understand-
and
you
see
the
same
value
that
I
see
and
using
graph
QL
to
work
more
effectively
on
our
data
layer
on
our
API
is
I'm
able
to
grow
them
and
expand
them
and
use
them
more
flexibly
and
we'd
love.
A
For
you
guys
to
connect
with
us.
We
we
would
love
to
collaborate
on
open
source.
You
can
go
to
the
Apollo
graph
QL
community.
In
github.
We
offer
support
and
training.
We
would
love
to
partner
with
you.
If
you
have
cool
ideas
around
projects,
you
should
definitely
join
our
Apollo
slack.
We
have
a
public
slack
that
you
can
use.
You
can
find
me
on
there
with
the
name
that
I'll
show
later
on
and
we're
also
hiring.
A
So
if
this
is
really
exciting
stuff
to
you-
and
you
want
to
work
on
the
future
of
graph
QL
check
out
our
careers
page
see
what's
interesting
to
you
or
message
me
directly.
This
is
my
information
here.
My
slack
is
also
science.
You
can
find
me
on
there
same
as
my
github
twitter
handle
is
underscore
science.
So
if
you
know
anyone
who
has
that
science
handle,
let
me
know
I'll
negotiate
and
feel
free
to
email.