►
From YouTube: Connecting the Dots: Kong for GraphQL Endpoints
Description
GraphQL is a popular alternative to REST for front-end applications as it offers flexibility and developer-friendly tooling. In this Kong Summit 2019 talk, Rakuten Software Engineer, Julien Bataille will look into the differences between REST and GraphQL, how GraphQL API Management presents a new set of challenges, and finally, how we can address those challenges by leveraging Kong extensibility.
Learn more about Kong: https://konghq.com/
A
Thank
you
Robert
good
afternoon,
everyone
as
Rob
interests
me
I'm,
Jenna,
Battier,
a
walk
attraction
I'm
a
software
engineer,
so
I
walk
in
the
team
where
we
provide
common
as
a
service
to
the
rest
of
our
group
companies.
Our
API
management
platform
is
addressing
a
lot
of
use
case
from
different
businesses.
A
Earlier
this
year
we
are
talking
on
to
one
of
our
biggest
team
here
in
the
US,
and
we
bring
up
a
very
interesting
use
case.
They
have
a
lot
of
AP
is
and
we
are
migrating
to
graph
QL.
So
we
had
a
question
for
us
is
like
how
Cong
can
help
them
manage
insecure
graph,
QL
api's.
So
today
what
I'd
like
to
do
is
actually
present
the
result
of
our
overall
walk
our
investigation
into
this
topic,
and
to
do
that
first
I
will
briefly
talk
about
what
is
graph
QL.
A
This
is
not
a
talk
about
graph
QL,
but
I
think
it's
useful
for
further
context
to
to
make
a
quick
introduction
and
then
I
really
want
to
highlight
the
differences
between
rest
and
graph
QL
and
how
it's
impacting
the
way
we
implement.
Api
management
policies
and
finally,
I
will
show
you
two
Kong
plugins
we
implemented
and
maybe
at
the
end,
if
we
have
time,
I
would
make
live
the
amount
of
one
of
those
plugins,
but
first
a
very
quick
word
about
graph
QL.
A
So
it's
a
very
popular
alternative
to
rest,
especially
for
front-end
applications,
so
web
or
mobile,
and
since
it
was
open
source
by
Facebook
in
2015,
adoption
has
been
really
strong.
It's
a
very
popular
for
developers
and
no
days
you
can
find
both
server
and
client
implementations
for
almost
every
stack
and
one
thing
one
really
a
particular
is
very
specific
to
graph
QL
is
that
the
client
defines
the
structure
of
the
data
required
and
the
server
will
return
exactly
that
and
nothing
else.
A
It's
doing
much
more
than
that,
but
I
think
I
want
to
insist
on
this
point,
because
it's
really
relevant
to
today's
topic
of
API
management
to
explain
the
overfitting
and
underfitting
problem.
I
want
to
use
what
I
hope
is
a
familiar
use
case
for
this
audience
is
the
Kong
admin
API?
How
many
of
you
are
using
the
Kong
and
min
API?
Please
raise
your
hand,
yes,
perfect.
A
Ok,
so
you
know
what
I'm
talking
about
this
screenshot
here
is
from
the
conga
open
source
blood,
but
he's
using
the
Kong
admin
API
to
display
the
configuration
of
your
cluster.
So,
let's
say
I
want
to
display
this
UI
to
the
end
user,
with
a
list
of
services
configured
on
my
cluster
and
the
modification
I
made
is
I
want
to
display
the
plugins
configured
on
each
services,
the
list
of
plugins.
A
Let's
see
how
I
would
do
this
with
REST
API
calls.
First
I
will
need
to
call
the
services
endpoint.
It
would
return
the
list
of
services
and
from
this
response
from
the
server
we
get
the
host
name,
the
name
of
the
services,
the
creation
time,
and
you
can
tell
that
it's
also
returning
a
lot
of
fields
that
I'm
not
actually
using
in
this
UI.
A
This
is
over
fetching.
The
server
returns
a
lot
of
data,
but
actually
I
don't
need
for
this
application,
not
only
that,
but
actually
from
this
first
response,
I'm
missing
the
list
of
plugins,
so
I
need
to
use
the
ID
of
each
service
as
an
input
parameter
to
make
additional
rest
calls
to
a
different
rest
API.
In
order
to
display
all
the
data
I
need
for
this
UI,
so
this
is
a.
This
is
an
example
of
under
fetching.
A
I
need
to
make
multiple
round
trips
to
the
server
to
display
a
simple
page
like
this,
and
this
is
a
very
simple
use
case.
But
if
you
think
about
what
might
describe
my
describe
today
with
Expedia
application,
you
can
tell
that
it's
begin
becoming
very
complex
when
you
have
a
hotel
description,
reviews,
user
information.
A
So
now,
let's
compare
this
to
how
we
would
display
the
same
UI
using
graph
killer.
So
first
on
a
client
side,
I
would
build
this
query.
I
would
specify
that
I
want
a
list
of
services
and
for
this
list
of
services,
only
one
the
name
host
creation,
time
and
plugins
list
on
the
plugins
entity.
I
just
want
the
name
and
nothing
else.
A
I
would
put
this
query
inside
the
HTTP
POST
request
body
and
the
server
will
return
that
so
I
would
get
all
the
fields
I
need
in
a
single
road
trip
to
the
server
and
I.
Don't
get
extra
data
and
I
don't
need
for
my
application,
so
I
think
from
this
example.
You
can
also
already
notice
a
few
differences
between
rest
and
graph
QL
that
will
have
an
impact
about
how
we
implement
API
management
policies.
A
A
So.
Finally,
as
we
just
saw
in
a
previous
example,
a
single
graph
QL
request
can
replace
multiple
rest
Qwest.
So
how
do
we
implement
a
thing
like
rate
limiting
in
this
case?
Does
it
even
make
sense
to
have
a
number
of
coal
per
hour
or
per
minute,
this
kind
of
limit
in
a
graphical,
API,
so
I
hope
at
this
point
you
will
agree
that
to
manage
graph
here
on
points.
A
A
The
second
one
is
actually
it
was
addressed
this
morning
in
the
keynote.
It's
query
cost
analysis.
So
this
is
where
we
want
to
measure
the
cost
of
a
query
by
counting
the
number
of
entities
required
by
the
client.
So
this
example
here
is
actually
from
github
graph
QL
API.
The
client
is
requesting
50
repositories
from
an
account
and
from
each
repository
the
first
10
is
used
for
a
total
of
550
nodes.
So
this
is
how
github
implements
rate
limiting
for
a
graph
QL
API
is
instead
of
setting
a
limit
of
requests
per
hour.
A
A
A
final
example
of
this
characteristic
is
if
we
can
compare
two
different
graph,
QL
queries
and
we
can
say
that
two
slightly
different
queries
are
functionally
equivalent.
We
can
implement
what
I
call
query
whitelisting,
where
we
would
only
allow
some
queries
in
production,
so
doesn't
make
sense
for
an
API
like
github,
because
we
have
this
open
API
to
any
client.
But
if
it's
your
own
API
for
your
own
clients,
you
probably
don't
want
to
enable
the
flexibility
of
graft
in
production,
because
you
know
already
what
your
clients
are
using.
A
So
you
could
adjust
for
every
release
of
your
app.
You
could
just
white
list
all
the
possible
queries
that
your
client
is
sending
I
will
develop
this
example
in
just
a
moment,
but
first
I
want
to
mention
that
all
those
policies
are
actually
already
available
in
libraries
for
different
implementations
of
graph
QL.
Those
are
language,
specific
solutions,
so
it
means
you
need
to
modify
or
reconfigure
your
graphical
server
to
enable
it-
and
this
is
where
I
believe
Kong
brings
a
better
alternative,
as
assignment
as
for
REST
API
is
like
we
we
are
used
to
do.
A
So
to
validate
this
approach
in
Rakuten
in
the
past
few
month
we
developed
two
open
source
plugins,
so
you
can
go
to
github
and
look
at
the
source
code.
You
can
test
it
on
your
own
cluster.
The
first
one
is
actually
implementing
the
nesting
limit.
I
mentioned
earlier,
so
you
can
set
a
very
simple
parameter,
one
two,
three
ten
and
it
will
block
any
queries
with
a
nesting
higher
than
the
limit
you
set.
So
this
way
you
upstream
Silva
will
never
receive
this
kind
of
illegal
queries.
A
It's
a
very
simple
plugin
and
what
the
reason
we
implemented
it
is.
We
wanted
to
validate
that.
We
can
pass
a
graph,
QL
query
inside
the
conk
plug-in
and
execute
some
simple
business
logic
on
it.
The
song,
the
second
one,
is
a
much
more
complex
is
the
operation
whitelist,
and
this
is
a
one
I'd
like
to
demo.
Today,
a
quick
word
about
the
requirements
we
had
from
our
internal
team
about
operation
whitelist.
The
first
is:
we
wanted
to
support,
queries
and
mutations
and
those
queries
and
mutations.
A
If
they
are
not
part
of
a
whitelist,
they
will
be
simply
blocked
by
the
conga
gate
away.
It
means
your
your
upstream
will
never
have
to
process
it,
and
also
an
important
requirement
is
that
if
we
have
two
slightly
different
operations,
if
they
are
functionally
functionally
equivalent,
it
should
be
represented
in
the
white
list
as
the
same
entity.
So
this
is
why,
in
the
pipeline
I'm
describing
here
in
this
diagram,
after
after
passing
the
query,
we
are
generating
a
signature,
and
this
is
the
signature
hash,
but
we
are
checking
against
a
whitelist.
A
It
would
be
much
easier
when
I
show
of
a
demo
to
understand
why
it
means,
but
something
I
want
to
highlight
is
that,
of
course,
we
use
a
plug-in
development
kit
to
implement
those
plugins
and
two
very
important
features
that
were.
It
was
really
useful
to
implement
to
implement
those
plugins
was
the
fact
that
we
can
store
and
cache
custom
entities,
and
the
second
one
is
that
we
can
extend
the
congressman
API.
It
was
very
useful
to
manage
the
whitelist
to
add
new
operations
to
remove
to
update.
A
Let
me
switch
to
a
demo
now
and
to
demo.
I
will
not
use
a
postman.
I
will
actually
use
the
conga
dashboard,
but
please
keep
in
mind
that
everything
I'm
showing
here,
of
course,
you
can
operate
with
API.
It's
calm,
guys
just
a
nicer
way,
I
believe
to
demo
so
honest,
our
service
activated
graph,
key
operation,
whitelist
plugin
and
the
way
to
manage
the
whitelist
in
this
implementation
is
actually
on
the
consumer
level.
Let's
save
and
read
up
in
the
list
of
credentials.
I
have
all
my
basic
API
keys.
A
All
the
credentials
you
used
to
use
with
Kong
I
have
a
new
type.
The
operation
whitelist,
and
here
you
can
see.
I
have
a
name
of
the
operation.
Hush
and
I
can
add
new
operation
delete.
So
let
me
let
me
show
you
this
I
have
already
one
operation
whitelisted,
and
this
is
a
query
to
get
the
hero,
the
name
of
your
hero
in
Star
Wars.
A
A
So
I
need
to
put
the
name
and
copy/paste
value
so
now,
I
have
a
new
entry
in
my
whitelist,
and
now
this
operation
is
valid,
so
here
inside
this
way
at
least
I
can
show
some
details.
So
it's
very
useful
to
see
the
original
operation
to
remember
what
you.
Actually,
why
kissed
it
and
you
can
see
the
operation
signature
I
mentioned
earlier.
A
So
in
this
very
simple
example,
the
only
difference
you
can
notice
between
the
original
operation
and
signature
is
actually
the
query
name
disappeared,
because
of
course
you
should
be
able
to
name
the
query
whatever
you
want
and
it
still
works,
and
we
also
reorder
of
the
fields
because
it
doesn't
matter
like.
What's
the
other
field,
you
should
be
able
to
to
pray
like
this
and
the
audios
change.
This
is
functionally
equivalent.
It's
a
very
simple
example:
let's
take
an
example,
which
is
a
bit
more
complex.
A
Let
me
send
this
one
directly
to
the
server
without
without
using
the
gateway.
So
if,
if
you're
not
familiar
with
graph
QL,
this
one
is
actually
comparing
two
heroes
from
different
episodes.
So
I
have
a
left
comparison
with
a
hero
from
New
Hope
and
the
right
comparison.
Hero
from
Jedi
and
I'm
using
a
fragment
fragment
is
a
way
not
to
repeat
a
graph
or
graph
QL
operations
it
make
it
available.
So
you
can
see
like
this
part,
is
actually
repeated
here
and
here
so,
let's
add
this
one.
A
A
So
I
have
it
here:
let's
just
check
out
it
walks
yeah
it
works.
So
in
this
case
you
will
see
that
original
operations
totally
different
from
the
signature.
So
what
we
did
is
actually
we
replace
the
fragment
by
its
definition,
and
you
can
see
that
the
parameters
here
are
not
in
the
signature.
It
means
that
actually
I
can
replace
this
one
by
I
can't
remember
the
names
of
episodes,
okay,
Empire
and
so
I
get
the
response
with
a
different
parameter
and
my
query.
A
So
this
is
this
idea
that
in
graph
you
have
a
lot
of
flexibility.
You
have
a
lot
of
ways.
You
can
format
your
query
and
actually
very
different
queries
can
be
functionally
completely
equivalent
on
the
back
end.
So
this
is
why
the
whole
person
white
list
is
not
as
simple
as
just
verifying
what
is
coming
in
and
we
are
using
this
signature
mechanism.
A
When
we
talk
to
the
team
requesting
with
this
feature,
they
were
actually
stuck
with
an
existing
system
that
has
not
so
much
flexibility
and
was
very
easy
for
us
to
implement
exactly
what
they
wanted,
and
it
was
really
thanks
to
relieve
a
PDK
feature,
especially
when
something
might
appear
complicate.
You
should
look
into
admin,
API
extensions,
it's
really
useful,
just
a
few
words
about
credits
and
reference.
If
you
want
to
learn
more
about
this,
you
should
really
look
into
Apollo
blog.
We
have
a
great
article
to
describe
many
kinds
of
policies
you
can
implement.
A
B
A
A
C
A
Thank
you
very
much
for
this
question.
Actually,
I
can
show
you
why
it
works
because
the
self-documenting
it's
actually
a
very
specific
type
of
query,
which
is
called
an
introspection
query
and
by
default
the
plug-in
is
letting
all
the
introspection
query
go
through,
but
I
think
I
implemented,
or
maybe
I
didn't
finish,
but
it
could
be
a
parameter
of
a
plug-in
also
to
to
enable
it
or
disable
it.