►
Description
Unleash Declarative Data Access with GraphQL- Kevin Dorosh & Sai Ekbote, Solo.io
GraphQL is redefining the way that developers interact with APIs, putting application clients in control of the data they consume and placing new requirements on the platforms hosting these APIs. Understanding when to write code and when to let the platform do the work is a critical tradeoff to understand as you scale GraphQL adoption. In this talk, Kevin and Sai will share experience building GraphQL support directly into Envoy to support edge gateway and service mesh use cases. They will cover common deployment patterns, GraphQL-specific implications to security and policy controls, instrumenting existing mesh services (REST, gRPC, SOAP, Lambda) with GraphQL, and the benefits and tradeoffs between declarative and programmatic approaches to GraphQL composition. This will be a hands-on session with live demos and real talk, focused on patterns of adoption to easily implement GraphQL at scale. If you are a developer or platform engineer deploying GraphQL in your service mesh, this talk is for you!
A
So
a
little
bit
about
who
we
are,
we've
we're
solo.I
o.
You
might
have
attended
some
of
our
talks
earlier
today,
we're
a
small
startup
or
not
so
small
startup
anymore
in
cambridge,
that
was
started
in
2017
and
over
the
last
five
years
we've
learned
from
helping
many
customers
adopt
service
mesh,
among
them
numerous
fortune,
500
companies
and
two
of
the
five
top
telecoms
speaking
of
telecom
companies.
Now
that
you
know
who
we
are
kevin,
do
you
mind
introducing
us
to
the
audience.
B
Sure,
yes,
so
you,
the
audience
today
are
wayne
telecom,
a
telecom
bit
company
based
in
gotham
city
you're,
the
largest
provider
in
gotham
city,
and
require
highly
available
low
latency
communication
with
services
from
your
web
to
from
your
web
clients.
So
stick
with
us
as
we
lead
you
on
our
journey
to
spend
less
of
your
billions
on
cloud
infrastructure
and
wasted
developer
time
and
revolutionize.
Your
communication
stack
trust
me.
It's
going
to
be
fun.
B
So
where
do
we
start
stand
today?
We're
hammering
money
clean
and
simple?
So
we've
got
a
mobile
app.
Our
users
are
reporting
slow
loading
times.
Our
developer
teams
are
understaffed
and
front.
End
teams
are
experiencing
friction
working
with
back-end
teams.
Let's
take
a
look
at
a
couple:
potential
solutions.
B
So
just
a
concrete
example
here
this
is
going
to
be
our
pseudo,
our
rest
api,
a
sample
page
from
our
billing
application,
this
page
loads
in
all
the
phone
plans
for
the
current
user
that
they're
paying
for
in
order
to
get
adequate
information
for
this
planned
summary
page.
We
must
make
multiple
rest
api
calls
per
page.
B
A
lot
of
this
won't
be
new,
but
just
to
highlight
and
make
sure
we're
on
the
same
page.
One
of
the
problems
where
we're
seeing
low
slow
loading
times,
we
can
have
request
waterfalls,
and
so
the
problem
here
is
that
we
make
a
rest
api
call.
We
need
to
wait
for
that
response
on
the
client
before
we
remake
that
request
on
the
back
end.
B
Geographically,
our
origin
server
might
be
in
the
west
coast
and
on
the
right
coast
or
sorry,
the
eastern
hemisphere.
We
might
have
our
mobile
app,
and
so
you
know
it
takes
50
milliseconds
to
traverse
the
world.
We
take
the
response
and
we
do
it
again.
We've
just
doubled
how
long
it
takes
to
make
our
api
call.
B
B
We
can
solve
some
of
our
latency
issues
by
just
putting
an
intermediary
service
in
front
of
our
backend
microservices,
that's
responsible
for
aggregating
those
results,
and
so
we
send
one
single
request:
one
specified
for
each
client,
so
our
mobile
app
might
have
one
back-end
for
front-end
and
our
desktop
app
might
have
a
different
back
end
for
front
end.
Both
of
those
services
will
then
go
ahead
and
actually
make
requests
within
the
origin
servers
in
your
network
and
then
send
it
all
back.
B
Thus,
we
only
pay
the
cost
of
traversing
the
world
once
45
milliseconds,
rather
than
twice
just
for
a
more
complete
picture
here.
We,
you
know,
we
often
have
a
cdn
or
load
balancer.
Also
we're
trying
to
optimize
our
speed
here.
Cdn
a
little
about
is
going
to
help
us,
but
you
know
this
isn't
going
to
fix
everything.
We've
obviously
got
to
worry
about,
http
puts
and
posts
we
need
to
you
know.
If
you
have
any
mutation,
then
this
isn't
going
to
solve
the
problem
for
us.
A
A
So,
yes,
thank
you.
If
our
front
end
leverages
graphql,
it
only
has
to
create
one
graphql
query
to
get
all
the
data
it
needs,
and
hopefully
the
text
is
big
enough
for
you
to
read,
but
that's
one
single
graphql
query:
one
http
request
that
the
frontend's
going
to
make
to
a
graphql
server,
and
this
will
give
us
back
all
our
data
that
the
front
end
needs
in
one
response,
so
we
can
transform
our
entire
communication
stack
with,
within
the
back
end,
to
use
graphql
and
receive
two
major
benefits.
A
This
means
that
we
can
ask
for
exactly
what
data
we
want
from
the
graphql
back-end
and
get
back
exactly
what
we
asked
for
nothing
more,
nothing
less
and,
in
addition,
we
can
fetch
data
from
across
different
resources
from
a
single
query
and
have
all
that
data
sort
of
aggregated
by
the
graphql
server.
In
one
response,
this
gets
rid
of
obviously
the
problem
of
having
to
make
multiple
requests
for
one
single
piece
of
data,
and
second
or
I
guess
third
graphql
provides
first
class
support
for
a
typed
schema.
A
So,
in
our
case,
we
have
that
query
that
our
mobile
application
is
sending
to
our
graphql
server
on
the
right.
We
have
our
sorry
on
the
left.
We
have
our
graphql
query
and
on
the
right
we
have
the
graphql
type
schema
which
aligns
perfectly
to
the
query.
We're
sending
so
I'm
going
to
go
ahead
and
just
browse
through
the
query
here
and
you'll
see
that
every
part
of
the
query
aligns
with
a
specific
type
from
the
graphql
schema.
A
So,
what's
the
point
of
this
well,
the
graphql
schema
can
now
be
accessed
with
amazing
developer
tools
such
as
graphql
playground
here
and
developers
can
now
browse
the
schema
as
easily
as
browsing
the
internet.
You
can
ask
for
whatever
data
you
want
from
the
schema
and
you
can
get
it
via
a
great
ui
like
this
and
when
it
comes
to
just
making
it
into
your
application,
you
just
have
to
copy
and
paste
the
query
into
your
application
so
kevin.
Now
that
we've
seen
the
numerous
benefits
of
graphql,
where
do
we
stand
with
wayne
telecom.
B
Yeah
so
just
yeah,
we
great
graph
brief
graphql
intro
aside
now,
let's
just
zig
zoom
back
to
where
we
are
with
wayne
telecom.
You
know:
we've
implemented
a
graphql
server.
We
have
on
the
left
here,
a
sample
set
of
queries
and
on
the
right
we
have
a
sample,
resolver
and
so
resolvers
usually
defined.
You
know
in
code
and
here
we've
just
kind
of
hard
coded
it,
but
just
reminder
you
know
we
have
some
app
dev
teams
that
are
responsible
for
maintaining
these
resolvers,
these
backend
services.
B
These
service
owners
are
creating
those
resolvers.
A
platform
team
is
now
going
to
own
that
gateway
that
graphql
gateway,
but
our
front-end
devs
are
happy
and
productive.
You
know
our
front
end
is
snappy
it
loads
quickly.
You
know
their
developer.
Experience
is
improved.
You
know,
we've
removed
the
friction
of
working
between
back-end
and
front-end
teams
by
basically
doing
it
back
in
for
front
end
via
graphql,
so
front
end,
we're
definitely
happy
continuing
forward.
This
is
a
service
mesh
conference.
B
We
haven't
mentioned
the
word
service
mesh,
yet
service
mesh,
con
yeah,
so
we're
telecom
industry.
We
see
this
commonly
with
our
customers,
we're
very
heavily
regulated.
This
means
that
we
require
things
like
zero
trust
networking.
So
we'll
just
pick
the
de
facto
use
case
here
we
need
mtls
between
all
of
our
services.
B
So
now
this
is
our
current
wake.
Wayne
telecom
infrastructure-
we've
got
our.
You
know
single
cluster
view
kubernetes
cluster
with
istio
installed.
We
have
an
istio
ingress
gateway
where
our
traffic
enters
from
there.
We
forward
that
to
our
graphql
server,
which
is
then
our
bracket
for
front
end
and
talks
to
all
of
our
backend
services
as
required,
and
then
you
also
note
that,
for
example,
the
users
and
plan
service
might
talk
directly
and
that's
also
encrypted
via
mtls
via
istio.
B
So
now
I'd
like
to
take
a
second
and
zoom
in
on
those
first
two
aspects,
so
we've
got
the
the
ingress
gateway
onboard
proxy
for
istio,
and
then
we
have
our
graphql
server
so
and
then
we
talk
to
our
backend
microservices
and
so
again
this
is
the
layer
where
we
implement
certain
policies,
like
external
off
rate,
limiting
laugh.
Caching.
All
these
are
just
envoy
filters
act
on
the
filter
chain,
again
we're
just
securing
our
network
at
the
edge,
and
we
do
that
because
we
have
to
yeah.
B
Now,
just
reminding
everyone
it's
maybe
it's
already
apparent
to
some
of
you
here,
but
graphql
is
a
single
endpoint
behind
our
proxy
here,
and
so
it
means
that
we
need
to
be
identity,
aware
and
so
there's
a
couple
of
you
know
outcomes
here.
The
the
first
one
is
that
we
need
to
be
aware
of
things
like
authorization
right
like
if
we're
in
a
single
endpoint,
we
still
need
to
figure
out
who's
querying
that
endpoint
there's
two
two
different
ways
that
we
could
think
about
solving
this
kind
of
problem
on
the
left.
B
We
could
just
delegate
the
problem,
so
we
could
just
take
the
the
request
headers,
for
example,
like
an
authorization
header
and
just
pass
it
through
to
our
backend
service
and
let
our
backend
service
project.
If
we're
not
authorized,
you
know
that
works
in
many
cases,
but
not
all,
and
the
other
solution
is
to
go
ahead
and
code
it
into
our
server,
and
so
we
also
see
examples.
You
know
use
cases
where
customers
go
ahead
and
they
instrument
their
graphql
server
with
identity.
B
Aware
logic
like
this:
that's
enforcing
authentication
it
it
moves
beyond
just
platform
concerns
like
authentication,
though
you
could
also
have
to
worry
about
things
like
circuit,
breaking
and
failover,
and
some
of
those
things
specifically
circuit
breaking
failover.
We
really
kind
of
have
to
do
on
the
node
that
serves
graphql
right
like
if
we
want
to
actively
figure
out
which
endpoints
we
can
reach
from
where
we
live,
that
concern
can't
be
delegated
to
hypothetically
another
proxy
behind
graphql
unless
that
server
lives
co-located
on
that
node.
B
B
B
So
just
a
quick
checkpoint
of
where
we're
at
right
now
with
wayne's
telecom
we've
solved
a
bunch
of
problems
created
a
couple
as
well.
So
far,
we've
increased
front
end:
dev
efficiency,
we've
reduced
over
fetching,
we've
naturally
implemented
a
backend
for
front
end.
We've
got
istio
to
enforce
zero
trust.
Networking
and
we've
got,
of
course,
we've
gotten
rid
of
crime
in
gotham
city,
but
also
have
we.
We've
created
a
couple
more
problems.
You
know
our
platform
team
has
to
maintain
a
new
graphql
gateway.
B
A
So
yeah
we've
gone
ahead
and
solved
a
bunch
of
problems.
You
know
we've
made
our
front-end
developers
happy,
but
there's
a
bunch
of
other
problems.
You
know
the
joker
is
still
at
large
and,
most
importantly,
the
back
end
team
is
unhappy,
so
there
must
be
a
better
way
to
solve
for
our
backend
team
as
well
as
our
front
end
team.
A
So
this
is
our
current
architecture
and
we
see
that
the
proxy.
The
network
proxy
is
a
separate
deployment,
a
separate
pod,
then
our
graphql
server
and,
of
course
this
means
that
we
have
to
manage
two
different
deployments.
Different
teams
must
manage
different
pods,
but
what
if
we
went
ahead
and
merged
those
two?
A
You
might
have
seen
this
coming,
given
that
this
was
in
ediet's
slide
earlier,
but
now
we're
proposing
a
new
model.
Proxy
is
a
graphql
server,
so
essentially
we're
merging
the
responsibilities
of
the
platform
and
the
application
networking
team
into
a
single
component.
So
here's
a
quick
summary
of
the
benefits.
First,
it
completely
eliminates
the
developmental
and
operational
expense
of
maintaining
a
separate
application
deployment
for
your
graphql
server.
A
There's
no
additional
network
hop
between
the
proxy
and
the
graphql
server,
because
now
the
graphql
server
is
just
in
memory
in
the
proxy
and
the
graphql
capabilities
are
based
on
declarative
configuration,
which
you
now
use
to
manage.
Istio
envoy,
just
like
the
rest
of
your
cloud
native
infrastructure.
A
So
we
can
also
go
ahead
and
leverage
the
existing
capabilities
that
solo
has
provided
within
envoy,
so
there's
no
need
to
integrate
with
third-party
libraries
to
create
resolvers
or
graphql
specific
policies.
Now
we've
mentioned
these
policies
multiple
times:
waff
web
application,
firewall
caching,
external
auth
and
rate
limiting,
and
now
that's
all
built
into
your
proxy
with
graphql.
A
A
A
However,
now
that
we're
baking
the
graphql
server
into
the
proxy,
why
not
also
bake
this
logic
into
the
proxy
as
well?
This
discovery
logic
by
putting
a
sidecar
containing
this
discovery
and
translation
logic
next
to
each
service.
We're
able
to
transform
incoming
graphql
requests
to
the
request
that
each
application
understand
in
its
own
protocol
effectively
we've
now
converted
all
of
our
services
into
graphql
services
by
just
including
them
in
the
mesh.
A
So
we
can
see.
We
have
three
back
end
for
front
ends
here,
but
these
are
actually
virtual
back
end
for
front
ends.
They
live
within
the
proxy
on
different
routes,
so
they're,
just
one
deployment
still
only
one
thing
that
you
have
to
manage
and
each
of
these
can
request.
Different
services
make
graphql
requests
to
each
of
those
services
and
do
their
own
application
logic.
B
Yep,
so
not
only
you
know,
we've
is
this
more
resource
efficient,
but
it's
also
going
to
be
easier
for
us
to
use
as
a
maintainer
of
as
a
maintainer
of
our
graphql
platform
and
gateway
here
and
so
we've
got
pictured
here.
Is
some
istio
declarative
configuration
again
going
back
to
service
meshcon?
Well
envoy?
Is
you
know
the
service
mesh
proxy
for
for
istio?
B
We
get
to
leverage
the
fact
that
it's
built
in
istio
to
do
things
that
we
we
couldn't
do
before
and
so,
for
example,
completely
for
free
on
the
left
here,
you'll
see
a
typical
yaml.
This
game
will
itself
it's
not
particularly
interesting,
but
the
interesting
part
is
that
it's
the
circuit
breaking
config
that
you
might
have
already
applied
to
certain
destinations
in
your
cluster,
because
we've
built
a
graphql
server
in
envoy
and
c
plus
plus
on
the
filter
chain,
and
we
reuse
onvoice
cluster
routing
like
routing
implementation.
B
Then
we
get
the
circuit
breaking
knowledge
aware
for
free.
So
if
certain
clusters
are
already
unhealthy,
envoy's
already
aware
we're
already
rerouting
them,
no
user
configuration
or
intelligence
in
your
graphql
server
required
further.
We
can
extend
this
to
things
that
are
still
easier
than
they
used
to
be,
but
not
completely
free
on
the
right.
We
might
have
a
sample
authorization
policy,
you
can
apply.
You
know
authorization
to
certain
external
auth
on
certain
destinations
going
towards
the
back
end,
because
again
this
is
built
in
envoy.
B
We
could
build
an
internal
listener
to
ourselves,
and
then
we
could
rerun
that
that
authentication
logic
without
traversing
the
network
stack
without
going
down
and
out
all
in
user
space
and
just
forward
it
along.
We
can
do
that
more
effectively
or
quickly
than
we
could
before
with
a
separate,
separate
deployment.
B
Again.
So
just
back
to
our
original
solution,
we
have
our
old
programmatic
configuration
for
resolvers.
This
is
again
we're
instrumenting
platform
concerns
into
our
resolver
in
this
case
authentication,
but
it's
not
just
limited
to
authentication.
I'm
sure
some
of
you
have
written
graphql
resolvers
before
yourself.
B
If
you've
done
that,
you've
also
used
javascript
libraries,
I'm
sure,
like
data
loader
to
handle
batching
and
caching,
those
kinds
of
things
all
end
up
in
your
resolvers
and
make
them
perhaps
verbose
complex,
and
ideally
you
want
them
thin,
but
unnecessarily.
These
concerns
creep
in
like
to
compare
this
to
what
we
have
today.
What
we'd
like
to
propose
for
our
graphql
configuration
our
resolver
here
config
is
entirely
declarative,
so
you
can
see
on
the
bottom.
We
have
our
schema
definition.
I
hope
it's
big
enough.
B
You
have
the
your
graphql
query
and
then
the
information
behind
that
query
and
a
custom
directive
note
the
app
resolve
with
the
name
query
plans,
and
then
we
have
an
executable
schema
which
defines
how
to
actually
resolve
that
field.
So
we're
saying
we
have
a
query
to
get
plans
and
we
want
to.
If
we
want
to
resolve
it,
we
make
a
rest
request
with
that
header
with
that
path
to
that
destination.
B
It's
like
a
custom
string,
interpolation
language
that
we'd
come
up
with,
but
you
could
imagine
you
know
in
that.
Args,
for
example,
is
grabbing
from
the
graphql
arguments.
If
you're
familiar
with
running
the
graphql
resolver,
you
could
also
grab
from
the
parent
object
or
or
other
primitives
that
you're
used
to
seeing.
So
you
can
get
dynamic
information
at
runtime
as
part
of
your
graphql
resolution,
but
the
important
part
is
that
it's
declarative
and
it's
very
simple
and
we
haven't
instrumented
a
ton
of
platform
concerns
into
our
resolver
configuration.
B
So
now
I
would
just
go
ahead
and,
and
put
it
all
together
again
on
the
top
right
you'll
see
the
yaml
that
we
just
looked
at
this
yaml
could
have
been
generated
per
service
so
rather
than
being
defined
by
a
user.
We
can
discover
and
create
this
from
the
backend
service
that
fronted
it
from
the
wstl
or
the
open
api
or
the
swagger.
We
can
generate
this
using
logic
very
similar
to
the
graphql
mesh
and
provide
that
you
know
via
the
control
plane
seo
service
would
have
what
have
you
and
the
bottom.
B
If
there's
no
conflicting
types,
everything
just
works
on
the
first
pass
or
we
provide
some
kind
of
vml
type
merging
configuration,
but
you
can
create
like
an
api
gateway.
That's
like
a
superset
of
and
allows
you
to
make
queries
against
both
types
or
across
both
schemas
and
further
than
that,
we
can
also,
like
I
mentioned,
there's:
there's
data
loader
caching,
improvements,
that's
also
just
built
in
by
by
default,
because
we
can
make
intelligent
assumptions
on
the
yaml.
We
know
that
which
queries
will
return,
similar
responses
and
optimize
those
out
without
extra
user
interaction.
A
A
Thus,
our
microservice
thinks
about
the
data
that
it
wants,
rather
than
the
service
that
it
wants
it
from,
or
what
service
to
request
the
data
from
the
service
dependencies
are
now
documented
via
declarative
configuration
yaml
with
all
the
change
history
benefits.
If
you
were
to
use
git
ops
rather
than
coded
into
services
themselves,
so
we're
no
longer
writing
programmatic
resolvers
and
having
to
enforce
programmatic
policies
on
developers
instead
we're
enforcing
it
via
declarative
configuration
and
also
we
no
longer
have
to
scale
up
the
graphql
gateway
to
enable
more
mass
services
to
leverage
graphql.
A
So
just
going
to
overview
the
benefits
we've
seen
from
using
graphql
in
the
service
mesh.
The
biggest
selling
point
is
obviously
developer
efficiency,
particularly
in
the
request
to
reque
service
to
service
request
flow
by
merging
the
proxy
and
graphql
server
together,
as
well
as
including
graphql
in
your
sidecar.
For
your
pro
for
your
service
mesh
from
the
get-go,
there
are
less
deployments
to
manage
and
fewer
points
of
failure
in
your
graphql
system.
B
So
also
an
interest
of
time
to
demo
going
to
go
quickly,
but
this
chart
should
look
very
familiar
again.
We've
resolved
all
the
the
concerns
from
the
first
half
of
the
presentation.
We've,
certainly,
if
not
solved,
made
a
lot
easier.
The
concerns
that
we
had
created
by
automating
a
lot
of
the
required
processes
on
the
new
platform
and
back-end
teams
by
discovering
those
schemas
by
allowing
you
to
merge
them
together
with
a
stitch
schema
and
doing
most
of
that
automatically
almost
via
the
click
of
a
button.
B
C
A
A
Is
that
better,
a
little
bit
yeah
the
left
side
is
pretty
small,
isn't
it
oh
yeah,
perfect
yeah,
so
these
are
grpc
services
and
you're.
Gonna
have
to
trust
me
for
that.
Just
in
the
interest
of
time
we
have
four
minutes
left
and
we're
going
to
want
to
create
graphql
services
from
these
jrpg
services
without
even
touching
application
code.
So
how
are
we
going
to
do
that?
I'm
actually
going
to
open
up
canines
on
the
left
here
to
show
the
cluster.
B
A
A
A
Okay,
well,
there
there.
It
is
so
here's
a
query
that
we
can
issue
to
the
user
service,
which
gives
us
information
about
the
user,
and
we
can
see
that
we're
creating
a
graphql
query
which
gets
translated
into
a
grpc
call,
and
we
get
back
a
grp3
response
which
once
again
we're
translating
to
a
graphql
response,
and
this
none
of
none
of
the
application
developers
are
really
doing
this.
A
This
is
all
happening
in
the
graphql
gateway
and
we
can
also
do
the
same
thing
with
our
product
service,
where
we're
issuing
a
graphql
query,
getting
a
graphql
response,
and
once
again
I
want
to
emphasize
the
fact
that
we're
not
changing
any
application
code.
Here
we
are
doing
translation
in
the
gateway.
That's
translating
our
graphql
request
to
grpc
and
once
again
response
back
to
graphql.
A
So
now
we
want
to
stitch
these
two
services
together,
our
user
service
and
our
product
service.
You'll
notice
that
the
product
service
exposes
the
seller
field
with
a
username,
but
we
might
want
more
information
for
about
the
seller
like
their
first
name,
the
last
name,
what
country
they
live
in,
but
this
schema
doesn't
expose
that
if
it
did,
you
would
see
it
in
the
autocomplete.
A
So
instead,
we've
now
created
a
graphql
stitch,
schema
I'll,
try
and
zoom
in
a
little
more
there.
So
you
can
see
the
endpoint
is
a
little
bit
different,
essentially
we're
serving
a
different
endpoint,
we're
serving
a
stitched,
graphql
schema,
and
what
we
can
do
now
is.
We
can
actually
query
across
schemas
by
stitching
them
together,
and
so
we've
now
created
a
query
that
queries
the
products
service,
as
well
as
the
user
service,
and
something
really
interesting
that
we
can
do
here
is
now.
If
you
remember,
the
product
service
only
gave
us
information
about
the
username.
C
D
A
A
B
Yeah
we
send
like
a
graphql
query
or
mutation
and
it
just
to
be
spec
compliant,
and
so,
when
we're
working
at
the
graphql
level,
all
the
types
are
graphql
types.
The
request
that
you
send
is
a
graphql
query.
It
has
a
specific
shape
that
can
be
validated
and
that
just
gets
translated
via
resolver
into
how
you
resolve
each
field.
So
that's
really
part
of
the
graphql
spec.
If
I
understand
the
connect
question
correctly,.