►
From YouTube: Introducing GraphQL for Gloo Edge and Gloo Mesh
Description
For more great content, visit https://solocon.io
SoloCon 2022:
Introducing GraphQL for Gloo Edge and Gloo Mesh
Speakers:
Sai Ekbote
Software Engineer, Solo.io
Keith Babo
Product Manager, Solo.io
Session Abstract:
GraphQL is a powerful new query language for APIs that is transforming how modern applications are developed and architected. A key benefit of GraphQL is the ability for clients to leverage a single API endpoint to access data in any shape they need, unlocking massive performance and efficiency gains for front end applications. While most of the excitement with GraphQL focuses on the front end, the benefits to a well-architected back end GraphQL infrastructure are just as important. In this talk, Sai and Keith will introduce the new GraphQL support coming to Gloo Edge and Gloo Mesh. The talk will highlight the benefits that native Envoy GraphQL support and a declarative approach to GraphQL provides to developers and platform engineering teams, along with a feature overview and roadmap.
Track: Community and Open Source
A
A
B
B
B
B
B
Well,
this
is
where
graphql
comes
in.
The
benefits
of
graphql
are
twofold:
graphql
apis
return,
exactly
what
we
need
and
nothing
more
and
the
graphql
server
can
fetch
data
from
across
different
resources.
Given
a
single
client
query,
so,
even
if
an
object's
data
model
is
distributed
across
multiple
microservices,
the
graphql
api
can
present
the
object
to
the
client
as
unified
api.
B
Let's
take
a
look
at
this
in
action
once
again,
we're
going
to
use
the
yelp
api,
but
this
time
we're
going
to
query
the
singular
graphql
endpoint
that
yelp
provides
graphql's
queries
are
extremely
customizable,
and
here
we
show
that
the
server
provides
us
only
the
data
that
we
asked
for
here.
We
query
for
any
businesses
that
might
be
named
solo
and
we're
just
asking
for
the
business
name.
For
now,
the
server
responds
with
potential
businesses
with
names
that
we
might
be
looking
for.
Now.
Let's
say
we
want
the
phone
numbers
to
these
businesses.
B
B
If
the
graphql
server
were
not
here,
the
client
itself
would
have
to
issue
the
location
request,
but
graphql
saves
the
mobile
client.
The
round
trip
graphql
also
provides
some
other
wonderful
functionality,
such
as
aliases,
so
that
we
can
name
the
data
whatever
we
want
in
this
case
we're
naming
the
query
solo
query,
which
is
also
really
useful
in
the
case
where
we
want
to
issue
multiple
of
the
same
queries
in
this
case.
We're
issuing
a
business
search
for
any
businesses
named
solo,
as
well
as
a
software
search
for
any
business's
name.
B
Now
you
may
want
now
you
may
be
wondering
how
do
we
construct
these
queries?
Is
there
any
way
of
knowing
what
the
data
model
is
like?
For
example,
rest
apis
can
be
defined
using
the
open
api
spec,
but
there's
no
consistency
across
all
rest
apis.
So
how
does
graphql
solve
this?
Well,
graphql
is
typed.
B
It
provides
first
class
support
for
api
specifications
through
its
type
schema.
So
what
does
this
look
like
for
graphql
developers
and
consumers?
Well,
graphql
has
its
own
simple
language
for
easily
defining
object,
data
models
and
relations.
For
example,
every
single
field
in
a
query
is
defined
in
the
schema.
B
B
B
B
A
A
So
the
first
one
is
the
easiest
and
and
is
really
appropriate
for
starting
out
when
you
have
maybe
your
first
step
with
graphql,
you
have
an
existing
rest
api
and
even
a
single
rest.
Api
as
psy
was
mentioning,
can
have
a
ton
of
data
that
your
front
end
doesn't
need.
So
as
a
first
step,
you
can
put
a
graphql
server
in
front
of
that
have
a
graphql
api
and
only
and
let
the
client
and
the
front
end
determine
what
data
they
want
to
consume.
A
Once
I've
done
that
the
next
step,
and
as
likely
when
I'm
scaling
graphql
within
teams
in
my
own
organization,
is,
I
start
to
see
a
lot
more
graphql
apis.
In
other
words,
there
are
bits
of
the
graph
across
the
various
teams
in
my
organization,
and
so
the
next
step
is
actually
to
federate
those
sub
graphs
into
a
unified
graph
and
that
federation
there's
a
number
of
technologies
that
can
enable
that
there's
apollo
federation,
but
there's
also
schema
stitching
as
examples.
A
Now
this
is
starting
to
get
pretty
advanced
and
pretty
mature
when
it
comes
to
graphql
adoption,
but
there's
one
pattern
left
and
that
pattern
is
when
you
start
to
think
about
how
you're
scaling
graphql
and
a
unified
graph
across
all
of
your
deployment
environments.
So
that's
on
premises,
that's
private
cloud
across
the
cloud
providers
and
even
looking
at
partner
and
sas
apis
all
of
these
data
sources,
collectively
contributing
to
your
unified
graph
that
you're
presenting
to
clients.
A
A
So
one
other
thing
we
want
to
talk
about
in
terms
of
what
we
see
with
customers
is
those
are
the
adoption
patterns
for
graphql.
But
what
about
the
network
topologies
and
the
traffic
patterns?
And
so
there's
really
two
principal
patterns
that
we
see
and
once
you
see
them,
it
won't
be
particularly
surprising.
The
first
is
north
south
right,
so
we're
standing
up
a
graphql
server
that
graphql
server
is
talking
to
one
or
more
upstream
apis.
A
Likewise,
we
also
see
the
case
where,
potentially
in
a
mesh
environment,
you
have
an
east-west
traffic
direction.
So
in
that
scenario,
the
graphql
server
and
the
api
are
deployed
as
independent
deployments
in
the
mesh
and
of
course
they
talk
through
side
cars.
So
any
any
conversation
between
the
graphql
server
to
resolve
data
in
the
rest,
api
is
going
through
the
server
sidecar
and
then
back
up
through
the
product
sidecar,
whether
you
deploy
one
or
both
of
these
mechanisms.
A
A
And
the
reason
for
that
is
a
graphql
server
is
only
half
of
the
complete
picture
for
exposing
graphql
apis
in
a
secure,
reliable
and
scalable
way.
So
what
we
see
on
the
left
of
this
picture
is
what
the
graphql
server
provides
today,
which
is
all
of
the
awesome
benefits
psi
was
describing
earlier
in
the
presentation,
but
on
the
right
are
all
of
our
existing
application.
A
Networking
policies
that
we
must
have
for
any
api,
that
is
exposing
business
data
or
valuable
customer
data
outside
of
our
network
boundaries,
so
things
like
rate,
limiting
and
authentication
authorization
and
web
application
firewall
rules,
data
loss
prevention.
Caching,
all
of
these
controls
that
we
implement
in
the
proxy
layer
today
need
to
be
combined
with
the
graphql
capabilities
in
the
server.
A
So
when
we
see
this
environment,
our
customers
and
discuss
with
them
their
concerns
and
considerations
for
deploying
graphql,
we
start
to
think
what's
a
fundamental
way
that
we
can
help
and
assist
our
customers
in
adopting
graphql
and
one
of
the
primary
ways
that
we
can
help
is
by
treating
graphql
as
a
layer,
eight
protocol
that
is
understood
directly
in
envoy,
and
so
what
we've
done
to
achieve
that
is.
We've
implemented
a
graphql
filter
in
envoy
that
performs
as
a
full
graphql
server,
no
need
for
a
separate,
graphql
server
deployment.
A
A
The
first
is
a
drastically
simplified
deployment
architecture.
We
talk.
I
can't
tell
you
how
many
times
we
talk
to
customers
that
begin
to
struggle,
even
in
the
tens
when
they
get
to
graphql
apis
and
individual
graphical
endpoints,
when
they're
standing
up
tens
forget
hundreds
and
thousands,
even
at
tens
of
graphql
server
deployments
and
starting
to
deal
with
the
sprawl
of
managing
those
additional
deployments
right.
How
do
you
keep
them
up
to
date
and
enforce
consistent
policies?
A
All
these
concerns
would
come
with
a
separate
deployment
for
the
graphql
server,
so
what
we've
done
is
we've
eliminated
that
entirely
no
need
for
a
separate,
graphql
server
deployment.
You
can
just
use
the
proxy
that
you've
already
got
deployed
today
for
graphql,
a
corollary
to
that
is
that,
because
we've
dropped
the
extra
graphql
server,
we've
eliminated
a
network
hop.
So
not
only
are
you
not
dealing
with
that
extra
network
hop
but
because
the
graphql
filter
is
implemented,
natively
in
envoy
and
c
plus
plus
get
blazing
fast
performance
of
the
data
plane.
A
Another
benefit
of
this
being
an
envoy
is
all
the
other
features
our
customers
are
using
today.
It's
a
mentor
for
rate
limiting
and
security
and
all
the
other
great
filters
we
have
implemented.
You
can
do
that
in
the
proxy
and
implement
that
policy
consistently
across
your
graphql
endpoints
and
apis
in
your
organization.
A
If
you're
doing
this
in
code,
you
rely
on
every
application
team
binding
to
libraries
and
configuring
those
in
a
way
that's
consistent
across
the
graphql
landscape
in
your
org,
which
is
prone
to
failure.
We
can
do
this
in
a
single
place
in
the
proxy
today
and
we
can
automate
that
so
it's
super
super
powerful.
A
If
you're
selling
standing
up
a
simple
monolithic,
graphql
api
proxy
is
already
there,
it's
super
lightweight
super
easy
to
get
started
yet
that
simple
architecture
scales
all
the
way
to
composite
apis
through
federated
apis,
with
stitching
all
the
way
to
hybrid
multi-cloud
and
multi-cluster
environments,
where
we
have
a
unified
control
plane
in
the
mesh
that
spans
all
of
the
environments.
So
a
single
solution.
B
B
B
B
This
means
that
your
graphql
platform
teams
can
now
receive
all
the
benefits
of
a
gitoff's
workflow,
including
configuration
change,
reviews,
history
and
changelog
tracking,
as
well
as
an
easy
way
to
revert
back
to
a
previous
git
commit
in
the
event
that
is
about
that.
A
bug
is
introduced
into
the
system
for
more
information
on
get
ops,
make
sure
to
also
check
out
the
weworks
talk
about
get
ops
with
glue
edge.
B
Blue
graphql
also
makes
it
especially
easy
for
customers
to
migrate
from
existing
apis
over
to
graphql
apis
without
ever
touching
a
line
of
application
code.
We
call
this
schema
discovery
in
auto
generation.
Let's
say
you
have
a
grpc
soap
and
rest
api
microservice
running
in
your
kubernetes
cluster
glue
can
discover
these
api
specifications
and
definitions
and
translate
them
directly
into
graphql,
schemas
and
resolvers.
B
So
now
your
clients
can
issue
graphql
queries
to
the
graphql
server
and
the
server
will
handle
a
handle
translating
these
queries
into
their
respective
api
protocols,
as
well
as
translating
the
responses
back
into
the
graphql
response.
Json
response
that
the
client
expects
you
can
check
out
a
live
demo
of
this
working
during
our
hands-on
with
graphql
workshop
led
by
admin
keith.
B
Here
we
have
a
gateway
deployment
where
our
proxy
is
processing
and
routing
graphql
traffic
from
a
mobile
client
to
various
applications,
notice
that
these
applications
haven't
been
touched
or
modified,
modified
and
still
serve
grpc
soap
and
rest
traffic.
But
the
mobile
client
sees
graphql
responses
because
of
the
graphql
translation
that
happens
in
our
proxy
layer.
In
addition,
we
can
also
take
advantage
of
existing
layer,
7
functionalities
such
as
external
auth,
server
to
authenticate
requests,
as
well
as
our
rate
limiter.
B
B
So
now
that
we
have
a
graphql
server
in
the
network
proxy,
we
can
improve
this
model
further
by
moving
to
a
service
mess
architecture.
If
you
have
a
glue,
mesh
and
istio
deployed
to
a
cluster
already,
then
your
service
mesh
sidecar
proxies
turn
into
their
own
graphql
servers.
The
glue
mesh
gateway
is
then
able
to
expose
a
gateway,
graphql
schema,
which
is
an
aggregation
of
all
the
services
graphql
schemas,
so
that
the
mobile
client
is
able
to
access
the
services.
B
So
why
not
make
our
model
a
little
more
sophisticated?
Here
we
have
a
multi-cluster
deployment
of
istio
and
glue
mesh,
and
this
is
where
glue
mesh
really
starts
to
come
alive.
The
glue
mesh
management
plane
is
able
to
manage
all
the
gateways
across
kubernetes
clusters
and
keep
clusters
configuration
synchronized
across
permission
spaces
such
as
security
user
clusters
and
public
cloud.
B
B
For
example,
the
payments
team
can
grant
access
to
the
accounts
team
for
a
subset
of
their
graphql
services
or
part
of
the
graphql
schema,
essentially
graphql
and
glue
mesh
allow
for
more
sophisticated
level.
8
routing
and
configuration
management
to
allow
your
applications
teams
to
develop
faster
without
having
to
worry
about
the
underlying
infrastructure
and
configuration
management.
A
All
right,
I'm
excited
now,
so
that
was
great.
Let's
talk
about
what's
next,
so
first,
we're
really
really
excited
to
announce
the
beta
release
of
glue
graphql,
with
the
glue
edge
1.11
beta
you'll
see
a
blog
announcement
with
all
the
details
around
how
to
register
for
the
beta
and
get
access
to
the
bits,
but
just
we
really
wanted
to
focus
quickly
on
what
are
the
capabilities
that
you'll
be
able
to
get
a
hands-on
with
here
when
you
get
that
beta
build.
A
As
I
mentioned,
we've
got
the
envoy
filter
and
the
language
support
he
covered
support
for
rest
and
grpc
resolvers
that
really
nice
declarative
api.
That's
just
minimal
level
of
config
to
get
graphql
apis
wired
up
and
ready
to
consume,
for
your
front-end
teams,
really
helpful
productivity
tools
like
discovery
and
auto
generation
of
graphql
apis
from
open
api,
upstreams
core
metrics
for
graphql,
really
nice.
A
Caching,
in
the
resolver
tier
to
eliminate,
like
refetching
data
in
the
course
of
executing
a
query,
eliminates
n
plus
one
sort
of
query
issues
for
your
upstreams
minimizes,
the
load
on
those
upstream
data
sources,
the
ui
that
we
saw,
which
is
really
great,
which
also
includes
schema
registry
capabilities.
So
when
you're
looking
to
browse
the
catalog,
the
graph
for
your
organization,
you
can
see
all
the
individual
schemas
that
are
comprised
and
available
within
your
organization
and
then
finally
wiring
into
the
other
application
networking
policies.
A
So
that's
what's
in
the
beta
when
we're
looking
at
what's
coming
next
well,
the
next
step.
The
immediate
next
step
is
getting
this
to
ga,
which
will
happen
in
the
111
release
of
blue
edge
in
that
release,
is
some
of
the
stuff
we're
working
on
right
now
that
will
show
up
actually
in
a
refresh
of
the
beta
as
well,
but
things
like
schema
stitching.
That's
I
mentioned
also
two
exciting
additions
to
our
caching
support.
A
So
I
mentioned
resolver
caching,
but
also
the
ability
to
cache
and
via
persistent
queries
and
and
cache
controls,
cdn
compatible
responses.
So
what
that
means
is
that
I
can
issue
cache
directives
or
specify
those
within
the
configuration
and
then
also
provide
a
htv
get
or
cdn
compatible,
persisted
query
that
my
clients
can
execute
so
the
very
first
time
they
execute.
A
It
will
go
into
the
upstream
data
sources
and
then,
when
on
the
response
path
that
can
get
cached
in
the
cdn
and
then
further
requests
within
the
cache
controls
will
actually
go
to
that
cdn,
so
really
helping
to
lighten
the
load
on
your
on
your
infrastructure
and
then
also
the
ability
to
integrate,
with
the
caching
support
coming
in
111
to
support
caching
directly
in
envoy
itself.
So
response
caching
for
graphql
and
other
api
types
directly
inside
blueedge.
A
A
After
that
111
ga
release
of
graphql
capability.
Very
next
step
is
to
bring
this
capability
to
mesh.
So
we're
already
implemented
in
an
envoy,
and
we
just
need
to
do
a
few
things
with
mesh
to
really
fine
tune
and
provide
the
best
experience
for
integrating
with
things
like
the
v2
api
and
mesh
and
the
concepts
like
workspaces
that
sci
discussed
earlier.
A
We're
also
looking
at
integrating
with
our
developer
portal.
So
you
can
have
a
really
nice
self-service
kind
of
view,
documentation,
interactive,
query,
browser
and
explorer
sign
up
for
api
keys
and
stuff
for
graphql
apis.
We
feel
like
we
can,
based
on
our
existing
developer
portal,
can
have
a
market
leading
solution
there
for
for
graphql
enriching
our
tracing
information
with
graphql
span,
so
in
the
resolver
tier
and
query
execution
phases,
adding
those
spans.
A
Looking
at
additional
resolvers
like
custom
resolvers
made
in
wasm,
we
the
soap
looking
at
lambda
and
database
resolvers
a
lot
of
other
great
ideas
in
talking
to
customers
of
other
resolver
types
they
want
to
have,
and
last
but
not
least,
continued
feedback
from
customers.
We've
had
great
experience
with
customers
so
far
working
with
their
use
cases
and
requirements
to
build
out
this
capability
and
we're
looking
forward
to
continuing
to
do
that.