►
Description
Presented by Brooks Swinnerton, GitHub.
In this talk, Brooks Swinnerton will discuss why GitHub made the decision to create a public GraphQL API and the things that they’ve learned along the way with respect to authorization, API design, and tooling. The interesting challenges of a public GraphQL API aren’t limited to your codebase; we will also discuss some of the ways that GitHub is working to introduce the new world of GraphQL to its users and integrators, as well as how we plan to support and grow the API for years to come.
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
All
right,
hi
everyone,
my
name-
is
Brooks
I
am
an
ecosystem
engineer
here
at
github,
where
I
work
on
our
api's
and
web
hooks,
and
today
I'd
like
to
talk
about
launching
get
hubs
graph,
QL
API,
but
before
I
dive
into
get
into
the
graph
QL
API,
how
it
works,
and
ultimately,
our
decision
to
use
it.
I'd
like
to
start
with
the
story
of
the
github
API.
Now
github.com
is
almost
a
decade
old.
A
Now,
shortly
after
the
launch
of
the
website,
the
first
API
endpoint
was
added
to
the
application
and
it
unsurprisingly
allowed
you
to
fit
data
about
commits
in
a
variety
of
different
response
formats.
One
of
those
response
formats
was
JSON
the
same
one
that
we
use
today,
XML,
which
was
very
popular
at
the
time
and
even
a
response
format
called
yamo,
which
was
a
fun
fact
that
I
learned
in
researching
this
talk.
A
Now,
after
about
a
year,
API
v2
was
released
and
this
gave
github
the
chance
to
evolve
the
API,
based
on
the
lessons
learned
in
the
first
iteration.
Now
this
is
sort
of
the
natural
progression
of
REST.
Api
is
in
general,
API
designers
version
them
as
they
learn
more
about
the
way
that
people
use
them
and
has
they
gained
a
better
understanding
of
how
to
best
model
their
data
in
April
of
2011
API
v3
was
released,
and
this
was
a
pretty
significant
change.
A
We
had
dropped
support
for
XML
and
yeah
Milland
standardized
on
this
JSON
response
format.
Now,
for
all
intents
and
purposes,
this
is
the
same
API
that
we
use
today
almost
six
years
later.
The
only
difference
is
that,
over
the
course
of
those
last
six
years,
we've
added
more
to
the
REST
API,
as
new
features
are
released.
A
Now
I'd
like
to
take
a
quick
detour
to
discuss
the
way
that
REST
API
is
work
to
better
understand
our
thought
process
when
we
were
designing
the
next
version
when
interacting
with
a
REST
API,
there
are
a
few
different
components
to
your
request.
The
first
is
an
HTTP
verb
and
it
specifies
the
operation
that
we'd
like
to
take
against
the
API.
The
second
is
an
endpoint,
and
it's
an
identifier
that
allows
us
to
specify
which
part
of
the
API
that
we'd
like
to
interact
with
when
we
make
a
request
to
this
endpoint.
A
A
But
we
don't
always
think
of
these
resources
in
isolation
commonly
you
see,
attributes
that
refer
to
associated
resources,
to
make
it
easier
to
view
tzer's
for
users
of
the
API
to
get
all
the
information
that
they
need
in
a
single
request.
In
this
example,
you
can
see
that
we've
added
counts
of
repositories
and
gist's,
as
they
relate
to
the
currently
authenticated
user.
A
A
So
in
order
to
help
fetch
those
associated
resources,
hypermedia
was
introduced
to
the
api.
The
v3
API
in
August
of
2011
hypermedia
is
a
machine
readable
link
to
another
place
in
the
API
about
information
related
to
the
resource
at
hand.
Here
you
can
see
a
URL
that
will
tell
you
more
about
the
repositories
for
the
currently
authenticated
user.
In
this
case,
it's
myself,
and
if
we
make
a
request
to
that
endpoint,
we
get
back
a
response.
That's
now
describing
a
different
set
of
resources
in
this
case.
A
It's
that
list
of
repositories
and
again
you
can
see
that
there
are
attributes
describing
this
new
resource
and
even
more
hypermedia
pointing
to
another
resource,
and
if
we
make
another
request
to
that
endpoint,
we
get
another
response
of
keys
and
values
that
are
now
describing
the
issues
of
each
of
the
repositories
that
belong
to
that
currently
authenticated
user.
We
can
use
hypermedia
as
a
way
to
navigate
the
data
graph
of
an
API.
A
If
you
imagine
that
we
have
a
desktop
application,
you
can
see
that
it
takes
numerous
different
requests
to
get
all
of
the
information
that
we
may
need.
One
request
to
the
the
currently
off
for
the
currently
authenticated
user,
another
request
to
fetch
all
the
repositories
and
then
for
each
of
those
repositories
fetch
a
list
of
all
those
issues.
A
So
to
tell
you
a
little
bit
more
about
graph
QL,
it's
a
data,
query
language
for
your
api's,
so
think
of
it
as
sequel,
which
is
the
lowest
common
denominator
between
technologies
like
my
sequel,
Microsoft,
sequel,
Postgres
and
so
on,
and
think
of
it
less
as
neo4j.
If
that's
something
you've
heard
of
which
is
an
entire
graph
database
in
its
own
right.
A
So
graph
QL
is
a
query
language
specification
and
it's
been
implemented
in
a
variety
of
different
languages
like
Ruby,
JavaScript,
Scala,
Python
and
the
language
was
originally
created
by
Facebook
to
help
with
the
data
access
needs
of
their
mobile
clients.
Dan
Schafer,
one
of
the
co-creators
of
graph
QL,
came
to
universe
last
year
to
talk
about
their
story.
A
This
is
the
hello
world
of
graph
QL
right
off.
The
bat
you'll
notice
that
it
bears
some
resemblance
to
JSON.
It
almost
looks
like
JSON,
but
without
any
of
the
corresponding
values,
and
that's
very
much
on
purpose
and
we'll
see
why
in
a
few,
so
there
are
a
few
different
components
to
a
graph
QL
query.
The
first
shown
here
is
viewer,
which
represents
an
object
that
has
more
information
that
it
can
return.
The
object
in
this
case
is
the
currently
authenticated
user,
which
is
similar
to
that
slash
user
endpoint.
A
That
would
saw
earlier
so
for
the
currently
authenticated
user
we'd
like
to
fetch
their
name
and
email.
We
call
these
fields
and
they're
a
selection
set
of
the
object.
When
we
execute
a
query
against
the
graph
QL
server,
we
get
a
response
that
looks
like
this
now
you'll
notice,
that
the
query
has
defined
the
shape
of
the
response
and
that's
an
important
part
to
graph
QL.
If
we
wanted
to
send
a
request
to
a
graph
QL
server,
it
might
look
something
like
this.
A
A
A
So
few
features
of
the
query
language
that
I
like
to
really
dig
into
the
first
is
that
graph
QL
is
typed
and
the
type
system
is
a
product
of
the
application
code
that
graph
QL
sits.
On
top
of
when
we
look
at
that
hello
world
example
behind
the
scenes,
there's
actually
something
that
we
call
a
schema
and
it's
this
fimA
that
graph
QL
is
capable
of
querying.
It
might
look
something
like
this
for
this
particular
query.
A
Now,
I
should
point
out
that
the
schema
is
pretty
much
imaginary
and
behind
the
scenes,
it's
something
that
we
as
users
of
the
API
really
don't
have
to
worry
about,
but
it
is
useful
for
understanding
how
graph
QL
works
under
the
hood.
We
call
this
notation
on
the
right
hand,
side,
IDL
and
it's
a
way
of
describing
the
schema.
If
we
break
down
the
query
on
the
Left
line-by-line,
you
can
see
that
each
part
has
a
corresponding
entry
in
the
schema.
A
The
viewer
field
lives
at
the
queries
route
I'm,
seeing
that
on
the
top
right-hand
side
of
the
screen,
and
it
returns
a
user
object,
type,
remember
objects
and
graph
QL
have
warned
that
you
can
ask
of
them.
The
user
type
implements
two
fields,
name
and
email,
both
of
which
return
what
we
call
a
scalar
value,
just
a
string.
A
We
start
with
the
user
field
in
the
queries
route
and
that
user
field
takes
an
argument
named
login,
which
must
be
a
string
and
that's
something
that
the
schema
mandates
what's
cool
about
graph
QL
is
that
it's
capable
of
validating
queries
before
it
does
any
sort
of
heavy
lifting,
and
that's
the
power
of
the
graph
QL
type
system
user
passes
in
anything
other
than
a
string
or
fur
login.
It
can
return
a
helpful
error
message
and
say
that
it
was
expecting
something
else.
A
So,
similarly,
to
the
last
example,
the
user
field
returns
a
user
object
type
and
that
object
type
implements
both
name
and
bio,
which
are
string.
So
what
if
we
wanted
to
fetch
a
list
of
objects?
This
query
will
return
a
list
of
all
the
open-source
licenses
on
github
their
name,
their
nickname
and
their
URL.
A
A
Here
we
can
see
that
the
licenses
field
returns,
that
collection
of
license
objects
and
a
license.
Object
is
composed
of
a
name,
a
nickname
and
a
URL.
We're
name
and
URL
are
guaranteed
to
always
be
present,
but
we
may
not
always
have
a
nickname
another
feature
of
graph.
Ql
are
aliases.
Let's
say
that
we
wanted
to
fetch
to
users
by
their
login
Chris
and
myself.
If
we
were
to
execute
that
query,
we
would
expect
to
get
a
response
that
looks
like
this,
because
the
shape
of
the
query
defines
the
shape
of
the
response.
A
We'd
end
up
having
a
key
conflict
which
isn't
quite
legal
JSON
aliases
can
be
used
to
assign
a
different
name
to
a
pappa
graph.
Ql
query:
if
we
execute
this
query,
we'd
end
up
with
something
like
this,
where
instead
we
have
user
we're.
Instead
of
having
user
for
the
keys,
we
have
our
aliases,
Chris
and
Brooks
next
up
or
fragments.
You
can
imagine
that
over
time,
queries
might
grow
to
be
large,
unwieldy
and
repetitive,
fragments
are
a
powerful
tool
to
reuse
different
pieces
of
schema.
A
If
we
take
a
deeper
look
from
our
previous
example,
we
can
see
that
there's
some
duplication,
their
name
and
bio,
are
used
in
both
of
these
user
lookups.
We
can
use
a
fragment
to
deduplicate
what
we
want
for
each
user,
fragments
use
this
dot,
dot,
dot,
notation
followed
by
their
name,
and
that's
how
you
reference
one.
The
fragment
itself
is
defined
at
the
bottom
of
the
query.
Where
we've
named
it
user
info
we've
specified
that
it
will
always
be
called
on
a
user,
and
for
that
user
we
would
always
like
its
name
and
its
bio.
A
Now,
in
some
cases,
you
may
dynamically
change
pieces
of
the
query
variables.
Give
you
the
option
to
do
so.
You'll
notice
that,
in
all
of
my
previous
examples,
I've
started
every
query
off
with
an
open,
curly,
brace
but
actually
there's
an
implicit
keyword.
There
called
query,
and
it's
something
it's
it
specifies
that
we're
trying
to
gather
information
from
the
API.
Both
this
query
keyword
and
that
open,
curly
brace
are
totally
valid
graph,
QL
syntax
now,
like
fields,
the
query
keyword
can
take
arguments.
A
The
arguments
that
it
accepts
are
the
variable
names
and
their
respective
types
that
we
intend
to
use
throughout
the
rest
of
the
query.
We
just
have
to
remember
to
send
along
the
contents
of
those
variables
to
the
server
when
we
execute
our
request.
It
might
look
something
like
that
now,
when
we
make
that
request,
we
get
back
response.
That
looks
just
like
what
we
would
normally
expect,
where
the
query
has
defined,
that
shape
of
the
response.
A
Now,
as
I
alluded
to
before
graph
QL
servers
aren't
just
capable
of
querying
data,
you
can
also
modify
data
with
what
we
call
mutations.
In
this
example,
I'm
looking
to
create
a
new
project
board
for
one
of
my
repositories,
we
can
use
the
mutation
named,
create
project
to
do
so
create
project
is
an
action.
A
All
right
and
the
last
major
component
that
I
like
to
cover
is
relay
relay,
is
an
extension
to
the
graph
QL
specification
that
gives
us
more
flexibility
when
paginating
over
collections
about
Jax.
It
adds
the
graph
to
graph
QL,
because
really,
we
think
about
our
and
graphs,
not
necessarily
resources
with
well-defined
boundaries,
so
relay
gives
us
a
few
things.
First,
it
can
tell
us
metadata
about
the
collections
of
objects
that
we're
referring
to.
In
this
example,
we
can
determine
the
total
number
of
repositories
that
the
currently
authenticated
user
has
access
to.
A
A
A
Nodes,
on
the
other
hand,
are
the
respective
repositories
that
are
on
the
edge
of
each
of
those
edges
that
belong
to
the
viewer.
So
off
of
each
of
those
edges
lives
that
single
node
a
repository
and
for
each
of
those
repositories
belonging
to
the
currently
authenticated
user,
ID
like
to
fetch
their
name.
If
we
execute
that
query,
we
get
back
response
that
looks
like
this,
where
I
have
a
collection
of
edges
for
each
of
the
repositories
that
belongs
to
me.
But
how
would
we
go
about
getting
the
next
two
repository
belong
to
me?
A
The
last
major
component
of
relay
is
cursors.
Cursors
refer
to
the
position
in
a
collection
in
which
an
edge
may
reside.
So
if
we
take
the
last
cursor
from
our
BOTS,
we
can
pass
that
in
to
that
same
query,
to
get
the
next
two
repositories
after
NYC
restaurant
greats
and
launch
bar
github.
Something
like
this,
which
would
give
us
this
response,
which
is
the
next
two
repositories
that
I
own
so
another
feature
of
graph
QL.
A
A
Now,
if
I
browse
through
that
documentation,
I
can
go
back
to
the
query
route
to
determine
what
top-level
queries
are
available
to
me
here.
I
can
see
that
there's
a
top-level
licences,
collection
and
the
license
object
implements
a
variety
of
different
fields.
There.
Let's
say
that
I
wanted
to
fetch
the
name
and
the
description
of
every
open-source
license.
That's
on
github
now,
once
executed,
I'll
get
back
an
array
of
these
licenses
with
the
fields
that
I
had
requested.
The
name
and
the
description.
A
But
let's
try
something
that
uses
relay.
Let's
say
that
I
wanted
to
query
a
particular
user
as
I
start
to
type
out
with
at
the
top-level
user
fields.
Graphical
knows
that
every
login
I
choose
to
funked
and
for
that
user
I'd
like
to
fetch
the
total
number
of
repositories
that
that
user
has
now.
In
addition
to
fetching
the
total
number
of
repositories,
I'd
like
to
also
determine
the
size
represent
or
ease
use,
you
I
can
use
the
total
disk
usage
field
to
do
so.
A
So
let's
take
it
one
step
further:
let's
fetch
the
name
and
the
name
of
each
of
those
repositories.
In
order
to
do
so,
we'll
need
to
fetch
the
repository
edges
and
off
of
each
of
those
edges,
the
node
and
from
there
we
can
fetch
that
repositories
name
just
like
that.
So
these
are
all
the
repositories
that
defunked
has
access
to.
A
But,
as
I
mentioned
earlier,
we
can
use
aliases
as
a
way
to
change
the
way
that
we
named
something
in
the
response.
I
find
edges
and
nodes
a
little
be
easier
to
comprehend
if
I
rename
the
node
the
singular
version
of
the
collection
that
I'm
referring
to
so
in
this
case,
it
would
just
be
called
the
repository
now
in
the
response.
A
I
can
see
that
I'm
iterating
over
a
series
of
repositories
and
then
I
have
a
single
repository
each
time
instead
of
the
word
node
now,
one
of
the
biggest
strengths
to
graph
QL
is
its
ability
to
fetch
a
variety
of
different
types
without
having
to
make
a
number
of
different
requests.
Let's
say
that
we
want
to
fetch
each
of
the
issues
off
of
each
of
the
repositories
that
belong
to
that
defunct
user.
Here,
I'm
fetching
the
last
10
issues
of
those
repositories
and
for
each
of
those
issues.
A
A
I'm,
a
really
slow
typer,
so
you
may
have
noticed
with
graph
QL
or
graphical.
Rather,
we
were
able
to
nest
multiple
different
resources
into
a
single
query.
So
if
you
think
back
to
our
earlier
desktop
application,
where
we
had
to
make
numerous
requests
to
get
all
the
information
that
we
needed
now,
that
application
can
make
a
single
request
to
the
graph
QL
endpoint.
A
So
going
back
to
the
question
that
we
were
asking
ourselves
when
we
started
work
on
the
next
version
of
our
API,
we
realized
that
graph
QL
was
standing
out
as
a
great
contender
to
offer
a
better
developer
experience
to
our
users.
So
in
early
2016
we
started
work
on
what
would
ultimately
become
the
next
version
of
our
API.
That
journey
started
on
March
20th
2016.
A
A
If
this
is
what
we
can
do
in
a
matter
a
few
weeks,
what
could
we
do
with
it
over
the
course
of
a
year
shortly
after
the
proof-of-concept
was
complete,
a
new
team
was
created
to
focus
on
taking
that
proof
of
concept
and
see
how
far
that
we
could
really
take
graph
QL
in
our
code
base.
After
eight
months
of
hard
work,
we
released
the
graph
QL
API
in
early
access
at
github
universe
last
year,
and
this
was
an
opportunity
for
us
to
get
feedback
from
our
users
on
this
new
API
it
github.
Satellite.
A
This
year
we
launched
the
production
version
of
our
graph,
QL
API
API
v4,
and
if
you
fast-forward
to
today
we're
executing
over
200
million
graph
QL
queries
every
day.
One
of
the
first
hurdles
that
we
had
to
overcome
was
how
to
effectively
rate
limit
in
graph
QL
and
the
REST
API
as
an
authenticated
user.
You're
granted
5,000
requests
an
hour.
Now
there
are
a
few
abuse
limits
in
place
as
well
to
help
protect
the
system
and
ensure
that
you're
using
the
right
tools
for
the
job.
Now.
A
The
reason
that
we
have
rate
limits
in
place
does
not
deter
users
from
fetching
too
much
data,
it's
to
make
sure
that
they're
doing
so
a
form
in
an
efficient
way
that
experience
of
other
users.
So
when
we
started
to
explore
what
rate
limiting
could
look
like
and
graph,
we
had
hit
a
snag.
A
single
request
to
the
graph
QL
endpoint
has
the
potential
to
return,
far
more
data
and
be
much
more
taxing
on
our
systems.
So
we
ended
up
with
a
two-part
solution.
A
Is
that
you
can
only
receive
a
maximum
of
500
thousand
nodes
at
a
time
for
a
single
query,
after
that,
you
need
to
paginate
over
your
collection
using
those
cursors
that
we
saw
in
relay,
and
the
second
is
a
scoring
system.
That's
based
loosely
on
the
number
of
collections
that
you're
fetching
and
how
they
relate
to
our
underlying
data
access
infrastructure.
A
When
executing
a
query,
you
can
ask
for
the
rate
limit
statistics
when
they're
currently
available
on
the
bottom
there,
and
if
you
pass
the
argument,
I
run
with
a
value
of
true
you
get
back
only
what
that
query
has
the
potential
to
return
in
terms
of
node
count.
This
is
one
of
the
only
parts
of
our
graph
QL
schema,
where
the
shape
of
the
query
doesn't
necessarily
I'd
showcase
the
shots,
and
you
can
do
the
same
sort
of
dry
run
execution
to
determine
what
the
query
would
cost
against
your
allowance
without
actually
affecting
it.
A
For
that
new
feature,
once
the
UI
is
complete,
the
engineering
team
releases
it
to
others
that
get
up
in
a
process
that
we
call
staff
shipping
once
that
feature
goes
through
a
final
set
of
iterations
based
on
that
feedback.
It
goes
to
production,
but
till
the
weeks
after
it's
been
launched
that
work
on
the
corresponding
REST
API
would.
A
A
It
allows
us
to
exchange
a
query
for
Ruby
objects
so
that
we
can
Co
locate
them
inside
of
our
views,
and
this
is
something
this
is
a
pattern
that
you
may
be
familiar
with.
If
you've
heard
of
react,
it
looks
something
like
this,
where
we
can
execute
our
query
in
our
controller
and
then
in
our
view
is
we
can
inject
that
response.
We
assess
them
as
a
series
of
Ruby
objects.
This
just
goes
to
show
that
we
are
our
own
consumers
of
the
graph
QL
API.
A
The
only
difference
is
that,
instead
of
us
using
that
slash
graph,
ul
endpoint
we're
using
this
Jim
to
help
get
the
responses
back
in
Ruby.
This
is
just
one
of
the
ways
modifying
the
github
application
to
API.
First
now,
another
part
of
those
two
hundred
million
queries
a
day
that
we
execute.
Interestingly
enough
comes
from
the
REST
API,
because
all
new
features
start
with
graph
QL.
That
means
that,
in
order
for
us
to
create
a
REST
API
for
these
new
features
to
the
hood,
we
actually
need
to
execute
a
graph
QL
query.
A
A
So
the
way
that
scientist
works
is
that
it
executes
s--,
two
code
paths
at
once:
a
control
and
a
candidate,
but
only
the
control
is
ever
actually
returned
to
the
end
user.
In
this
example,
let's
say
that
we
were
trying
to
back
the
slash
user
endpoint
with
a
graph
QL
query.
The
control
in
this
case
would
be
on
the
top.
It's
the
legacy
code
that
we
know
has
always
worked.
The
candidate
would
be
this
new
graph,
QL
query
whose
response
we
take
and
we
make
it
look
and
feel
like
a
rest
resource.
A
Once
scientist
is
executed
both
of
these
code
paths
that
allows
us
to
compare
both
of
them
for
accuracy
now.
In
some
cases,
there
might
be
mismatches
between
the
control
candidate
and
that's
an
opportunity
for
us
to
figure
out
what
might
be
causing
it.
Scientists
can
also
compare
the
speed
at
which
the
control
and
the
candidate
executes
and
that's
been
a
powerful
tool
for
us
to
figure
out
what
needs
to
be
optimized
first,
and
there
are
been
a
few
tools
that
we've
helped
build
to
onboard
users
into
this
world
of
graph
QL.
A
One
of
my
garlic
colleagues
guarantee
rick
ian
built
a
tool
called
graph
QL
Talk
Docs,
which
powers
one
of
the
the
pages
on
the
developer.
Docket
up
comm
website
this
tool,
utilizes
the
power
of
graph
QL
introspection
to
display
documentation
in
a
clean
and
elegant
way
for
users
to
view
now.
The
cool
part
is
that
this
all
happens
automatically.
We
don't
have
to
write
any
extra
documentation
outside
of
what's
inside
of
our
schema
when
we
craft
it.
A
Last
week
we
shipped
an
automated
change
log,
which
automatically
updates
a
page
on
developer
github.com,
with
all
of
the
additions
and
modifications
been
making
to
the
graph
QL
schema.
Last
year
at
github
universe,
we
launched
a
community
website
that
we
use
as
a
platform
for
discussing
bugs
feature,
requests
and
new
ideas
for
the
graph
QL
API.
A
You
can
see
that
a
platform
github
community,
so
what's
next
for
the
graph
QL
API,
one
of
the
biggest
things
on
our
roadmap
is
gaining
confidence
in
the
coverage
of
the
graph
QL
schema,
and
that
means
that
making
sure
that
you
have
everything
that
you
need
in
order
to
make
applications
and
integrations
using
graph
QL.
We
know
that
the
graph
QL
API
isn't
fully
there
yet
and
it's
going
to
take
us
a
little
bit
of
time
to
get
there.
A
One
of
the
next
major
components
of
our
roadmap
is
a
github
apps
integration.
One
of
the
best
parts
of
graph
QL
is
that
it
gives
you
finer
grained
access
to
the
data
that
you
need,
but
that
doesn't
drive
super
well
with
the
resource
based
Java
scopes
that
we
currently
require.
Github
apps
will
give
us
the
opportunity
to
better
align
fine-grained
authorization
with
fine
grained
data
access.
If
you'd
like
more
information
on
graph
QL,
you
can
check
out
our
documentation
on
developer,
get
up
com
or
you
can
check
out
the
entire
specification
at
graph.
A
Ql
org
I
also
encourage
you
to
check
out
the
platform
github
community
website.
If
you
have
any
ideas
or
feature
requests
that
you'd
like
to
share
for
the
graph
QL
API
and
finally
I'd
like
to
thank
all
the
people
that
helped
get
graph
QL
to
where
it
is
at
github.
Today
there
are
countless
Engineers
members
of
our
support
team,
our
quality
team
and
our
documentation
teams
who
help
shape
to
this
project
and
work
with
us.