►
From YouTube: GraphQL for Developers or Platform Team?
Description
While GraphQL is cool in providing the exact data of what client asks for, does GraphQL help front-end developers or backend developers? What about operators? What are the challenges in adopting GraphQL? In this hoot livestream, Keith Babo is joining Lin to discuss the overall GraphQL landscape, challenges in adopting GraphQL and some innovative solutions to tackle these challenges.
#graphql #mesh #operators
00:03 welcome + speakers intro
1:33 news for the week
3:20 General discussion on what is GraphQL
7:54 - network issue for 2 mins, sorry!
9:28 why GraphQL, resource constraint, over fetching and under fetching
16:27 Answer live qs: how GraphQL work internally? + demo
25:29 Part 2 of Demo - how data is resolved?
32:59 federation vs stitching
39:00 discussion around roles and personas for GraphQL + answer more live questions
48:45 wrap up
To learn more about us, please visit https://www.solo.io, we are hiring! https://www.solo.io/company/careers/
Questions? https://solo-io.slack.com
Code Samples: https://github.com/solo-io/hoot
Suggest a topic to cover here: https://github.com/solo-io/hoot/issues/
A
A
What
are
the
challenges
in
adopting
graphql
in
this
hood
live
stream?
I
am
so
excited.
Keith
bubble
is
joining
me
to
actually
teach
me
a
lot
of
things
about
graphql,
the
landscape
and
the
challenges
in
adopting
graphql,
and
also
some
of
the
innovative
solutions
out
there
to
tackle
these
challenges
so
keith.
Could
you
quickly
introduce
yourself.
B
Yeah,
hey
lynn,
thanks
very
much
for
having
me
so
my
name
is
keith
babo,
I'm
a
product
manager
here
at
solo,
I've
been
at
solo
since
november
of
2021.
I
guess
it's
been
a
fantastic
ride
here
before
that
I
worked
at
red
hat,
for
maybe
I
think
13
years
or
so
did
a
lot
of
things
in
managed
cloud
services,
integration,
technologies,
a
lot
of
api
management,
restful
apis,
really
really
excited
about
the
opportunity
that
graphql
creates
in
the
api
landscape.
So
happy
to
talk
to
you
about
it
here
today.
A
That's
awesome.
We
are
so
excited
to
have
you
kiss.
Well,
I
guess
you
are
hit
your
anniversary
with
solo
soon
in
the
next
few
months
yeah
I
know
I
just
had
mine
so
so
before
we
get
to
graphql.
I
like
to
quickly
cover
a
couple
of
news.
We
have,
if
you
don't
mind
so.
The
first
thing
I
want
I
do
want
to
share
is.
Last
week
we
spoke
with
uwa
psyllium
layer.
7
policy
was
istios,
so
we
have
the
steps
now,
if
you're
interested
to
try
what
I
demoed
last
week.
A
A
B
Yeah
so
like
graphql,
I
think
it's
best
at
baseline
graphql.
It's
not
this
like
complete
departure
from
how
we've
addressed
data
in
the
past.
Graphql
is
a
type
of
api,
so
we
know
about
grpc
and
rest
or
maybe
going
back
a
bit
further
like
soap-based
web
services.
We
generally,
these
are
programmatic
sort
of
interfaces
to
data
that
might
be
in
a
database
or
an
applications
domain
model
right.
B
What
you
do
is
you
probably
have
a
database,
and
then
you
get
a
resource
from
that
database
and
then,
when
a
client
queries
that
with
a
get
they
get
all
of
the
data
back
right
and
maybe
for
a
given.
You
know
maybe
there's
a
mobile
app
or
a
single
page
web
application.
Maybe
they
have
to
call
five
different
apis
and
get
all
this
data
back
and
then
put
that
together
and
pick
pieces
out
of
it
and
then
graphql.
A
Yeah,
it's
really
interesting.
You
know
why
play
with
graphql.
I've
been
actually
learning
graphql
myself.
I
kind
of
think
tell
me
if
this
is
the
right
way
to
think
about
it.
I
kind
of
think
graphql,
as
you
know,
like
mysql
commands
or
any
of
the
database
query
language,
but
somehow
made
it
available
through
http
cost.
So,
instead
of
I
need
to
go
to
the
database
client
calling
my
sql
command,
I
can
actually
going
through
calling
to
http
request
and
also
using
graphql
playground
to
play
with
my
data.
B
Yeah,
I
think
it's
it's
actually
it's
it's
very
close,
that's
a
great
good
way
to
start
from
it
and
that
you
have
a
dynamic
query
language
at
your
disposal.
Another
thing
that's
very
interesting
is
like
in
sql
you
can
have
a
described
command
that
basically
tells
you
about
the
tables
or
the
scheme
of
the
database.
That
you're.
B
Right
and
in
graphql
it's
a
requirement
by
the
specification
that
every
api
has
a
schema,
that's
defined
with
something
called
the
schema
definition,
language
or
sdl.
That
describes
that
api
endpoint,
and
this
is
a
huge
bonus
compared
to
what
like
soap
had
wisdol
right.
Rest
has
swagger
open
api,
but
none
of
those
are
required
right.
So
people,
you
know
how
they
formulate
and
structure
their
api
and
whether
they
publish
documentation
or
not.
B
A
B
Api,
the
client
just
navigates
the
graph,
so
they're
not
doing
joins
or
any
other
type
of
you
know,
correlation
or
foreign
key
relationships
at
the
front
side,
they're
just
looking
at
sort
of
a
linear
data
graph
and
they're
going
and
querying
whatever
they
want
from
it
in
database
terms,
you're,
probably
using
like
a
database,
virtualization
technology
or
some
other
view
layer.
That's
aggregating
that
on
the
back
end,
but
graphql
just
kind
of
takes
that
completely
out
of
the
picture
and
makes
it
easy
for
clients.
A
B
B
A
B
Right
on
there
also
well
it
just
could
be
that
the
audience
you
know
didn't
hear
it
so
I'll.
I
I'll
play
up
to
what
I
heard
before
you
dropped,
and
then
you
can.
Let
me
know
to
finish
it.
So
you
were
saying
we
talked
a
little
bit
about
what
graphql
is,
and
I
think
we
were
kind
of
leading
into
sort
of
the.
Why
of
graphql
like
you
know,
is
that
where
you're
going
with
the
question.
B
You
know
it
like
can't
take
in
like
a
5,
meg
payload,
especially
back
in
2012
right.
You
know,
like
we
were
still
more
more.
The
phones
were
a
little
bit
lower
powered,
maybe,
and
so,
when
you're
over
fetching
this
data
you're
just
like
flooding
the
memory
of
that
device,
and
it
makes
it
very
difficult
to
have
an
optimized
and
performant
app.
So
you
don't
want
to
over
fetch
you
when
you
call
you
just
want
the
data
you
asked
for
and
then
under
fetching.
B
The
correlator
of
this
is
just
as
bad,
because
that
means
that
you're
making
multiple
network
round
trips
right
so
aside
from
being
resource,
can
train
in
terms
of
memory.
We
know
phones
back
at
that
time
in
terms
of
network
speeds
were
not
amazing.
Even
today
you
know
in
more
remote
locales
where
there
might
not
be
great
service.
You
don't
want
to
be
fetching
a
ton
of
data
and
making
multiple
round
trips
to
the
server.
It
kills.
The
latency
there
just
kills
the
responsiveness
of
your
mobile
app
right.
B
So
facebook
hit
all
of
these
issues
and
they
came
up
internally
with
what
would
become
graphql,
which
is
putting
the
client
in
charge
of
the
data
they're
addressing
right
and
then,
ultimately,
I
think
around
2015
of
a
spec
was
put
out
in
the
open
or
sort
of
like
a
definition
of
that.
Ultimately,
that
became
the
graphql
foundation.
You
know
and
became
you
know
widely
deployed
sort
of.
You
know
specification
for
graphql
now.
B
The
second
part
that
was
the
first
question
sort
of
like
why
graphql
in
the
first
place-
and
that's
you
know,
everybody
feels
that
pain.
In
fact
all
front
end
developers
feel
that
pain.
If
I'm
creating
a
single
page
web
app
that
has
a
card
layout
of
various
items
in
a
store.
Let's
say
I
might
be
pulling
that
from
five
or
six
apis.
I
don't
keep
track
of
every
api.
I
have
to
talk
to
and
get
all
this
data
like.
B
B
Develop
this
graphql
api,
so
the
front
end
devs
can
actually
invoke
it
and
the
question
is
who's.
Doing
that
right
do
the
front
end
teams
now
assume
responsibility
for
back-end
api
infrastructure
do
existing
rest,
api
and
grpc
and
soap
based
you
know,
api
or
web
service
developers
now
start
doing
graphql
apis
are
the
platform
teams
responsible.
B
B
I
feel,
like
the
platform
teams,
actually
don't
realize
at
this
stage
how
beneficial
graphql
can
be
for
managing
infrastructure
right
from
a
security
resiliency
like
traffic
shaping
and
routing
standpoint,
there's
a
lot
of
really
powerful
platform
concepts.
You
can
apply
to
graphql
that
I
think
the
market
is
just
realizing
now
and
starting
to
to
embrace.
A
Yeah,
I'm
totally
with
you
on
that.
I
think
on
the
on
the
client
developer
side,
the
advantage
is
so
obvious
right.
I
just
had
a
network
issue
right.
What
would
be
even
nicer
than
I
just
pay
exactly
the
data
I
need
and
then
that's
the
data
transfer
through
my
network
right.
Assuming
nothing
is
free.
You
have
to
pay
for
it.
A
Then
you
always
want
to
pay
exactly
what
you
want
it
right
on
the
back
end
side,
you
know,
personally,
I
struggle
a
little
bit
myself
too,
as
I
was
learning
graphql,
because
I
find
that
you
know
it's
actually
pretty
hard.
To
kind
of.
You
know
put
the
data
that
you
have
and
then
make
it
a
graphql
server
and
make
it
available
so
that
your
client
developer
can
use
right
because
there's
a
terminology,
you
have
to
learn,
there's
a
real
java.
You
have
to
write
and
yeah.
A
So
so
totally,
I
think
there's
a
probably
some
confusing
in
that
place
and
also,
I
think,
there's
a
lot
of
tooling
out
there.
Just
follow
like
get
study
tutorial.
There's
apollo,
I
think,
there's
also
facebook.
Maybe
I
have
some
tutorial,
there's
also
library
for
different
graphql,
so
I
personally
find
a
little
bit
overwhelming.
B
Yeah
yeah
and
I
mean
there's
great
resources
out
there.
I
actually
think
the
graphql
foundation
have
done
an
amazing
job.
There's
the
graphql
spec,
which
is
pretty
hardcore.
I
mean
it's
actually
very
well
written
you
know
and
understandable,
but,
like
you,
don't
want
to
start
there
right,
like
that's
getting
really
into
the
nitty-gritty.
They've
actually
done
an
amazing
job,
just
with
some
high-level
docs
showing
examples
of
just
walking
through
the
value
proposition
of
graphql
and
the
you
know
top
level
concepts
there.
B
So
I
think
you
can
rely
on
resources
like
that
as
well,
and
then
vendors
that
are
in
the
graphql
space
all
have
examples
of
how
you're
using
their
frameworks
to
do
it
and,
as
you
mentioned,
that
could
involve
writing
code,
maybe
using
a
server
like
apollo,
for
example,
to
create
a
server
in
a
node-based
environment.
You
might
be
using
a
framework
in
like
go
or
ruby
or
java.
B
A
B
B
Yeah
this
is
an
excellent
question
and
it
hits
out
a
bunch
of
key
concepts
for
graphql
to
begin
with.
So
let's
start
from
the
client
perspective
and
then
our
we'll
work
our
way
all
the
way
to
the
data
source
and
so
to
establish
that
lineage.
Let's
assume
we
have
a
client
okay,
we
have
a
graphql
server
and
then
we
have
a
a
set
one
or
more
databases
behind
the
scenes.
Okay,
so
from
a
client
perspective,
it
reduces
database
calls
from
the
client,
because
the
client
is
only
making
one
call
to
the
graphql
server.
B
So
it's
always
one
single
call
and
you
get
the
result
there.
So
one
one
round
trip,
so
that's
definitely
saving
the
client
there.
On
the
back
end,
the
interaction
between
the
graphql
server
and
the
database
you're
always
going
to
need
at
least
one
call.
You
know
to
get
the
initial
data
or
to
insert
or
create
right
or
whatever,
but
but
the
real
advantage
with
graphql
is
it
can
optimize
that
traffic
in
a
way
that
clients
generally
wouldn't
have
this
level
of
sophistication?
B
So
a
very
common
example
is
caching
and
batching
caching
and
bad
batching.
Excuse
me,
that's
tough,
to
say,
back-to-back
server
layer
right
so
data
loader
as
an
example
is
a
very
popular
project
in
this
space.
But
there
are
other
implementations
as
well,
and
what
that
does
is
it
says:
hey
if
I've
already
fetched
some
data
from
an
upstream
data
source,
don't
call
that
again,
basically
or
if
I
know
I'm
going
to
make
several
calls
to
a
single
upstream
data
sources
batch
those
together
and
make
them
at
one
time
instead
of
a
bunch
of
individual
calls.
B
Yeah
yeah
yeah,
so
that
is
not
that's
actually
up
to
the
implementations
of
the
various
frameworks
and
and
graphql
servers
that
do
that,
I
would
say
by
convention
it's
very
popular
right
like
the
a
lot
of
the
aspects
of
ground
graphql,
it's
so
broadly
adopted
that
you
start
to
see
conventions
sort
of
develop
around
the
edges
of
the
spec.
Caching
is
a
great
example
of
that
data
loader
for
caching
and
batching.
The
resolver
tier,
like
client-side
caching,
there's
just
a
lot
of
standard
conventions
for
doing
that
in
the
graphql
community.
A
A
B
You're
able
to
see
my
screen-
that's
great!
Yes,
okay,
great!
So,
let's
go
ahead!
I'm
going
to
go
ahead
and
clear
this
out,
just
we
start
with.
So
what
I'm
looking
at
here
is
a
popular
open
source
framework,
javascript
client-side
framework
called
graphical,
and
what
graphical
allows
you
to
do
is
to
interact
as
a
client
with
a
graphql
api.
B
I'm
going
to
use
this
client
here
just
to
explain
a
little
bit
about
graphql
in
case
anybody
in
the
audience
is
unfamiliar
with
graphql,
it's
best
to
see
by
doing
right,
so
yeah
yeah.
So
let's
take
an
example
and
we'll
see
this
a
couple
times
I'll
probably
do
two
parts
of
this
of
this
demo,
but
I
just
want
to
focus
on
graphql
stuff
right
now.
B
So
what
I'm
going
to
do
is
a
very
common
use
case
is
taking
an
existing
rest
api
or
a
set
of
rest
apis
and
putting
graphql
in
front
of
that
okay.
So
in
this
case
I've
deployed
a
sample.
Api
called
tracks,
which
has
the
normal
crud
operations
you'd,
expect
inside
of
for
any
resource
and
rest,
so
create
like
get
post,
put,
delete
right
and
then
a
pretty
standard
resource
object
model
there
for
a
given
track.
It's
got
all
this.
B
B
So
let's
go
excuse
me.
So
let's
go
back
over
to
graphql
and,
first
and
foremost,
let's
look
at
the
first
on
the
right
hand,
side
here
we
can
see
the
documentation
explorer
and
what
this
is
showing
is
just
a
pretty
markup
version
of
a
graphql
schema.
As
we
said,
all
graphql
apis
must
have
a
schema
and
there's
a
great
tool
chain
built
around
that
to
actually
help
you
navigate
that
schema
to
understand
how
you're
going
to
invoke
a
graphql
operation.
B
Here
we
can
see
that
there
are
actually
two
route
types
defined.
One
is
a
query:
this
is
how
I
fetch
data
and
one
is
a
mutation,
and
this
is
how
I
mutate
data
so
like
creating
data
updating
data
deleting
data,
okay,
there's
a
third
type
called
subscription
as
well.
It's
less
commonly
used,
but
that's
sort
of
like
an
event
driven
long
pole.
Query
for,
for
you
know
basically
shorthand
description
of
what
it
is.
It
gets
a
bit
more
nuanced,
but
it's
sort
of
like
a
push
query.
Let's
call
it
that.
B
So
when
I
go
look
at
query.
For
example,
I
can
see
that
I
have
two
methods
here
and
these
you
can
naturally
map
these
to
a
rest.
Api
one
is,
I
have
get
all
tracks,
so
this
would
be
like
a
a
a
get
call
on
the
root
of
the
tracks
resource,
and
then
I
can
get
a
track
by
id,
which
would
I
would
normally
just
do
that
with
a
path
parameter.
That
includes
the
id
of
a
track,
but
here
we
can
see
a
first
class
representation
of
two
query:
fields:
get
tracks
and
get
track.
B
So
what
I'm
going
to
do
now
is
I'm
actually
going
to
close
that
up
and
I'm
going
to
go.
Look
at
our
little
explorer
here
and
again,
because
we
have
a
standard
schema.
We
can
build
a
bunch
of
useful
tooling
around
that
and
graphical
does
a
great
job
of
that.
So
if
I
get
all
the
tracks,
I
can
list
all
the
data
that's
available
to
me
and
again
I
don't
want
all
of
this
data,
so
I
might
just
want
you
know.
B
Let's
say
we
want
to
get
the
id
the
topic
and
the
let's
get
the
title:
okay
and
so
I'll
go
ahead
and
run
that
query
and
I
can
see
returned
here-
are
a
bunch
of
individual
tracks
with
just
the
data
I
requested
at
any
point.
If
I
want
to
add,
create
it
out,
I
can
run
it
again
and
I
see
that
data.
I
decided.
I
don't
need
it
right
again.
I
only
get
the
data.
B
B
A
Yeah
totally,
in
fact,
just
this
morning
I
was
playing
the
same
client
you
are
showing.
Certainly,
my
schema
was
very
simple,
like
hello
world,
but
the
ui
you
are
showing.
I
just
want
to
make
a
point,
even
though
you
have
glue
edge
in
there.
It's
nothing
related
to
like
it's.
Just
an
open
source
project
glue
edge
is
using,
which
I
got
it
running
on
my
machine.
You
know
without
any
of
the
glue
products,
which
is
very
nice
too.
B
Absolutely
and
that's
one
of
like
the
most
powerful
things
about
graphql,
is
that
there
are
so
many
graphql
clients
out
there
like.
There's
the
you
know:
graphql
sandbox
graphql
bin
apollo
studio,
studio,
altair
like
there
are
so
many
client
frameworks,
and
they
all
work
with
no
matter
how
you've
implemented
your
graphql
api.
They
all
work
because
of
the
strength
of
the
specification
and
the
portability
of
that
format,
of
the
sdl
to
work
with
all
client
tools.
B
B
As
you
mentioned,
you
know,
there's
a
vibrant
ecosystem,
there's
a
whole
bunch
of
different
ways
to
create
graphql
apis,
we're
just
going
to
show,
for
sake
of
example,
how
we
do
this
in
glue
and
then
you
know
you
can
apply
these
same
principles,
though
you
can
look
at
creating
these
in
other
languages
or
frameworks
as
well,
and
maybe
we'll
use
this
as
a
springboard
to
talk
about.
Maybe
some
of
the
unique
advantages
for
platform
teams
and
back-end
teams
that
that
you
might
want
to
look
for
so
right
now.
B
I
already
have
this
graphql
api,
I'm
going
to
go
ahead
and
tear
all
this
down.
So
let
me
come
back
over
here
and
delete
the
various
resources
around
this
okay,
great
and
then
I'm
gonna
go
ahead
and
first
I'm
going
to
so.
Let's
just
go
back
to
apis.
We
see
we
have
no
graphql
apis
anymore
and
if
I
come
into
my
set
of
services,
I
have
pet
store
deployed,
but
nothing
else
I'm
going
to
deploy
this
rest
example
that
has
the
tracks
api.
B
So
as
a
platform
team
or
a
back-end
team,
I
don't
need
to
write
any
code
here,
I'm
just
basically
a
app
dev
team
has
deployed
a
rest
api
and
we're
automatically
creating
graphql
apis
from
that.
So
if
I
come
back
into
our
ui
here,
we
can
see
that
we
have
the
full
schema
definition
with
get
tracks
and
get
track
and
all
the
various
mutations
and
the
type
definitions
all
available
to
me
just
as
a
native
graphql
api.
B
It
has
the
full
schema
that
we've
generated
for
it
and
everything,
but
to
get
to
your
specific
point
lynn.
So
how
does
this
all
map
up
and
when
I
called
get
tracks
before
like
how
did
that
map
to
my
rest
api?
So
in
our
case,
what
we
do
is
we
actually
just
have
a
reference
to
the
upstream
here,
which
is
the
name
of
the
upstream
in
our
environment,
which
is
default.
Rest
example
and
then
a
bit
of
configuration
that
gets
applied.
That
says
hey
for
that
rest
api.
B
That's
part
of
that
upstream,
what's
http
method
and
what
are
the
path?
What's
the
path
that
you
want
to
invoke,
and
with
that
information
we
call
the
upstream
rest
api
and
then
map
that
data
directly
onto
onto
the
schema
definition,
the
fields
and
the
schema
definition.
This
can
be
very
flexible.
This
could
declarative
syntax.
You
can
do
request
and
response
transformations
if
you're
looking
to
fit
data
or
change
data,
either
to
the
upstream
rest
api
or
back
in
the
response.
So
this
is
more.
A
Yeah
totally
because
I
was
trying
to
figure
out
how
to
write
code
for
something
I
was
trying
to
do
really
simple.
In
fact,
I
was
trying
to
display
like
a
couple
of
quotes
from
different
speaker.
It
sounds
something
simple,
but
I
was
not
very
familiar
with
node.js,
so
it
I
actually
haven't
figured
out
how
to
do
that.
So,
if
I
understand
you
correctly
keith,
let
me
replay
what
I
heard
from
you
right.
A
So
you
took
this
rest
example,
which
has
kubernetes
yaml
you
deploy
it
into
your
kubernetes
cluster
and
essentially
you
provide
a
graphql
schema.
That's
a
additional
you
have
to
provide,
and
inside
of
that
skimmer
you
somehow
kind
of
tell
glue
how
you
want
each
field
to
be
resolved
and
the
glue
kind
of
will
automatically
figure
that
out
for
you,
because
you
basically
said
for
this
particular
field.
Let's
say
message:
for
example,
this
is
the
rest
corresponding
rest
api
to
get
the
value
for
it.
B
B
B
And
wire
up
all
the
resolvers
okay.
Now
that's
really
useful
in
use
cases
where
you
just
want
to
take
an
existing
api
and
you
want
a
graphql
equivalent
right.
You
might
be
exposing
that
directly.
You
might
be
stitching
that
together
to
create
a
unified
graph
with
a
bunch
of
other
things
right,
but
it's
very
easy
to
do
that
auto
generation,
but
we
also
that
auto
generation
is
always
just
creating
kubernetes
custom
resources
that
have
the
two
things
that
you
mentioned:
a
schema
definition
and
the
resolver
configuration
right.
B
If
you
have
maybe
a
more
advanced
example
where
you're
doing
some,
you
know
transformations
manipulation
combining
multiple
upstream
apis,
you
don't
have
to
use
automatic
generation.
You
can
just
create
that
configuration
descriptor
yourself.
We
have
a
ui
that
does
it,
but
you
can
always
just
do
it
in
the
you
know
the
text
editor
of
your
choice,
and
that
gives
you
a
lot
more
control
on
how
you
create
that
graphql
api
and
the
shape
of
your
your
schema
definition.
A
Yeah
that
makes
sense
to
me
so
essentially
the
example
you
show
was
automatically.
I
assume
it's
automatically
discovery
of
the
rest.
Api
and
they'll
automatically
generate
that
schema
and
automatically
figure
out
the
resolver,
but
as
an
alternative
for
advanced
user,
they
may
not
want
everything
from
rest
to
be
converted
to
graphql
right.
Maybe
there
are
some
fields,
that's
legacy,
or
maybe
they
need
to
weave
multiple
services
rest
services
into
one
single
graph
that
they
need
to
kind
of.
Tell
us
how
they
want
to
do
that
together.
B
Exactly
and
we
have
another
example
that
we
can
share
afterwards,
I
think
in
the
notes
for
the
hoot
episode
but
like
we
took,
if
you
look
at
the
istio
book
info
example,
that's
a
pattern
widely
known
in
in
in
full
stack
development
circles
known
as
back
end
for
front
end
right.
So
you
have
multiple
rest
apis
that
exist
behind
the
scenes,
and
then
you
create
a
new
rest
api
just
for
a
specific
client.
B
So
maybe
it's
a
mobile
app
or
a
single
you
know
page
web
application
or
or
what
have
you
graphql
is
the
perfect
technology
for
implementing
bff,
because
you're
not
creating
a
specific,
specific
bff
api
for
every
client.
You
just
have
one
api
and
all
clients
can
consume
it
in
the
way
that
they
need
to
address
the
data.
So
what
you
were
saying,
the
more
advanced
use
case
there
would
be
exactly
that
type
of
pattern
with
bff
yeah,
where
I
have
a
single
graphql
api.
It's
talking
to
multiple
rest
or
grpc
upstreams.
A
B
B
Yeah,
so
let's
let
me
build
up
to
that,
so
there's,
and
actually
this
is
let's
enter
the
federation.
Stitching
point
is,
is
a
really
interesting
one
and
I
think
a
follow-on
question
is
more
about
change
management
and
what
controls
and
governance
controls
are
in
place
for
things
like
breaking
changes
that
might
impact,
maybe
a
federated
federated
graph.
So
let's
we'll
split
those
two
so
but
to
explain
these
terms
for
other
folks.
That
might
be
like
what
is
all
this.
B
Okay
and
then
that
bigger
thing
can
be
called
a
super
graph,
a
unified
graph.
It
could
be
called
a
federated
graph.
It
could
be
called
stitch
graph,
okay,
but
all
of
these
refer
to
the
same
thing,
which
is
they're
all
a
unified
graph
of
all
your
individual
sub
graphs
in
the
market.
There
are
two
prevalent
technologies
for
creating
that
unified
graph.
Okay,
one
is
called
apollo
federation,
which
big,
surprise
is
created
by
apollo
right
and
the
other
is
called
stitching,
which,
interestingly
enough,
was
also
created
by
apollo.
Originally.
B
They
decided
to
go
with
with
federation,
but
the
community,
the
guild
and
others
in
the
graphql
community
really
liked
stitching
still,
and
so
they
picked
it
up
and
evolved
it
and
created
a
great
support
in
the
community
for
stitching
as
well
from
my
standpoint,
the
real
difference
both
of
these
are
equally
capable
and
they
both
get
you
to
a
unified
graph.
They
ultimately
just
have
two
different
perspectives
from
the
standpoint
of
federation.
B
Every
graph
sub
graph
is
aware
of
the
unified
graph.
So
basically
you
have
this
very
sort
of
egalitarian
approach,
where
every
individual
graph
is
saying.
Okay,
this
is
the
super
graph
or
the
unified
graph,
I'm
integrating
with
here's
some
keys
and
other
directives
that
are
actually
linking
me
back
into
that
unified
graph,
whereas
with
stitching
it's
a
bit
more
of
a
compositional
model
where,
instead
of
everyone
owning
the
combined
graph,
maybe
you
have
a
dedicated
team
that
owns
the
composition
of
that
graph
and
they're,
creating
the
stitching
config,
that's
bringing
in
those
sub
graphs.
B
Now,
a
unique
advantage
with
that
approach
is
that
potentially
in
federation
model,
the
individual
subgraphs
are
not
viable
graphql
apis
on
their
own
they're,
actually
created
to
contribute
to
the
unified
graph,
whereas
in
stitching
generally
all
the
individual
sub
graphs
are
like
viable
standalone,
graphql
apis
and
they
get
combined
into
into
a
stitch
graph
right.
There's
lots
of
nuances,
but
in
broad
strokes
like
that's,
that's,
basically
how
I
look
at
it.
B
So
getting
back
to
the
question
is:
do
we
support
federation
or
existing
federation
of
graphql
apis,
and
the
answer
is
we
support
stitching
as
a
compositional
model
for
creating
that
unified
graph,
but
stitching
those
graphical
apis
can
be
a
federated
graph.
So
if
you
have
an
existing
federated
graph,
you
could
pull
that
directly
into
your
stitch,
because
that's
just
a
graphql
api.
At
the
end
of
the
day
right,
if
you
have
existing
graphql
apis
implemented
in
other
frameworks,
we
can
stitch
those
together
and
put
them
in
our
unified
graph
as
well.
B
So
we
have
not
elected
to
implement
apollo
federation
at
this
time
when
we
talk
to
customers
in
general,
they're,
very
happy
with
using
stitching,
but
if
we
see
a
lot
of
community
demand
there
there's
no
reason
why
we
couldn't
implement
federation
as
well.
So
I
hope
that
helps
answer
that
question.
There
was
another
element
around
discovery,
so
we
support
discovery
of
grpc
and
rest
apis.
We
don't
support
discovery
today
for
for
graphql
apis,
simply
because
you
create
a
resource
that
just
points
to
it
and
provides
a
schema.
B
So
it's
not
it's
like
a
very
easy
type
of
thing
to
incorporate
into
a
stitch
graph.
But
again,
if
we
get
feedback
that
that
would
be
super
useful,
that's
definitely
something
that
we
can
implement.
It
would
be
trivial,
pretty
trivial,
to
implement
the
change
management
aspect
of
this
automatic
schema
discovery
and
registry.
So
this
is
one
of
the
things
we
really
like
about
stitching.
B
Is
it
puts
you
in
control
of
referencing
the
upstreams
that
you're
incorporating
into
your
graph
the
subgraphs
that
you're
pulling
in
right?
So
you
can
label
and
sort
of
version
those.
However,
you
see
fit
and
use
that
to
drive
the
life
cycle
of
how
you
incorporate
newly
released
versions
of
those
subgraphs.
B
We
also
implement
support
and
we
actually
leverage
graphql
inspector,
which
is
another
great
guild
community
project
to
have
governance
controls
around
what's
allowed
for
changes
to
schemas.
One
of
the
biggest
concerns
here
with
a
unified
graph
is
that
a
sub
graph,
basically
busts
the
unified
graph
by
incorporating
a
breaking
change
right,
and
so
these
change
controls
allow
you
to
set
your
tolerance
threshold
for
whether
you'll
accept
a
breaking
change
in
the
first
place,
what
counts
as
a
breaking
change,
and
this
type
of
thing
so.
A
Yeah,
very
cool,
that's
really
clarifying
my
confusing
around
federation
and
stitching
so
great
explanation.
So
I
hope
that
answers
your
question
to
bonji.
Please
leave
us
a
comment
and
let
us
know
if
you
have
any
additional
questions
keys.
I
do
have
one
question
for
you,
as
you
were
speaking
the
user.
Who
does
the
stitching
right?
It's
do
you
think.
That's
like
a
platform
team
from
a
personal
perspective,.
B
My
guess
in
our
persona
definitions
like,
I
would
think,
that's
more
an
app
owner.
Maybe
you
know
sort
of
like
it
could
be
data
architect,
but
it
really
could
be
anything
right.
Like
a
platform
like
we
deal
with
a
lot
of
cloud
engineering
and
platform
engineering
teams
at
solo.
Basically-
and
you
know
the
almost
universally
in
those
teams-
they
want
to
take
the
state
of
their
platform,
check
it
into
git
and
then
use
that
to
roll
out
to
all
of
their
environments.
B
Basically,
and
that's
exactly
what
we
enable
so
absolutely
this
could
allow
responsibility
for
platform
teams
to
take
this
on.
I
think,
more
importantly,
it
sets
up
a
situation
that,
even
if
another
team
owns
it,
it's
a
resource
that
can
be
controlled
with
rbac
and
integrated
with
other
policy
resources
that
platform
teams
do
have
access
to.
So
when
you
start
looking
at
authentication
authorization
rate
limiting,
you
know
protections,
defense
and
depth,
and
this
kind
of
thing
the
way
that
we're
approaching
it
from
a
platform
standpoint
is
100
compatible
with
all
of
those
approaches.
A
B
Yeah
and
and
I'll
just
mention
you
know-
hopefully
this
has
been
clear
in
in
the
way
of
answering
the
questions,
but
I
just
want
to
make
stated
explicitly:
there's
not
a
right
or
wrong
way
to
do
this
right,
like
if
you're
writing
codes,
quick
graphical
ips,
that's
great
like.
If
that's
the
way
you
want
to
do
it.
If
you
want
to
use
declarative
config,
that's
great
too
one
of
the
really
nice
things
about
the
graphql
community.
Is
it's
so
inclusive,
it's
so
open
and
everyone's
participating.
B
You
know
and
contributing
what
we're
trying
to
do
is
just
make
it
a
lot
easier
for
teams
that
want
to
align
their
graphql
infrastructure
to
their
platform
architecture
or
make
that
as
easy
as
possible
right
and
in
our
customers.
We
definitely
see
cases
where
you
know
they
have
a
large
percentage
of
their
existing
graphql
apis
that
can
be
implemented
with
a
declarative
approach
and
there's
some
very
special
case
things
where
they
want
to
use
a
specific
framework
and
how
to
handle
it.
B
A
Yeah
makes
sense
we
just
got
by
the
way
we
got
a
thanks
from
banjo.
So
thank
you
for
answering
that
question.
We
got
another
question
also
from
you.
The
problem
with
federation
is
that
there's
a
need
for
central
gateway
and
all
subgraphs
have
to
be
up
and
running
or
the
gateway
would
not
work
and
doing
blue
green
deploy
is
not
possible.
B
This
is
such
an
insightful
question
and
it's
it's
interesting
because
we
were
just
discussing
this
a
couple
months
back,
as
we
add
support
in
glue
mesh
for
for
graphql
and
there's
a
couple
things
there.
That
we
hit
on
here.
One
is:
is
that
all
of
these
resolvers
and
resources
you're
talking
through
resolvers,
should
have
flexible
semantics
around
traffic
policies,
so
you
can
shape
and
redirect.
A
B
Traffic,
so
if
you're
rolling
out
a
change
to
a
rest
api
or
changing
some
of
your
resolver
logic,
you
can
test
that
you
might
want
to
initially.
You
know
basically
have
a
dark
launch
and
not
include
it,
for
anyone
then
use
specific
headers
and
just
route
specific
traffic
to
you
know,
and
then
you'll
maybe
get
an
aggregate
of
like
20
of
my
traffic,
I'm
bleeding
over.
B
So
it's
all
executing
against
the
route
tables
that
are
defined,
of
where
those
upstream
destinations
are
that
are
the
apis
right,
and
so
it's
all
like.
Ultimately,
all
of
this,
a
huge
percentage
of
our
implementation,
is
actually
not
in
the
control
plane,
but
an
envoy
itself
right,
so
we're
ever
using
envoy
whether
it's
in
a
gateway
scenario
for
north
south
traffic
or
east-west,
all
of
like
the
really
heavy
lifting
is
an
envoy
right.
Then
we
take
that
envoy
and
we
say
hey.
B
The
envoy
is
not
executing
at
the
edge
as
it
is
in
a
gateway
scenario,
but
it's
executing
a
client-side
car.
In
both
cases,
it's
just
a
dispatch.
Basically
you
get
a
single
graphql
request,
the
graphql
engine
that
we
have
in
the
proxy.
Basically
like
interprets
that
request,
validates
it
right
and
then
maps
it
to
resolvers.
That's
just
a
dispatch
mechanism
of
where
that
request,
flows
upstream
right.
So.
A
A
B
Yeah
I'll,
like
kind
of
give
like
just
to
reiterate
something
we
said
earlier,
it's
like,
I
would
definitely
start
with
a
graphql
foundation
and
like
and
and
just
the
high
level
docs
there
just
to
understand.
You
know
like
what
graphql
is
and
then
I
would
say
you
know,
based
on
the
individual
audience
members.
Are
you
an
app
developer
that
has
experience
with
javascript
or
your
go
developer,
ruby
or
like,
and
you
want
to
write
code
to
implement
graphql.
B
Okay,
then
that's
a
path,
and
you
can
go
to
that
framework
of
your
choice
and
they'll
have
great
getting
started
with
you
on
how
to
get
going
right.
If
you're,
a
platform
team,
a
cloud
engineering
team
or
even,
I
would
say,
a
front-end
team
that
doesn't
want
to
have
to
write
and
maintain
and
operate
a
graphql
api,
then
maybe
look
at
what
declarative
has
to
offer
and
in
fact,
maybe
do
both
and
compare
and
contrast
them
on
what
you
know
fits
best
for
your
needs.
So
we
have
some
great.
B
You
know
from
the
declarative
standpoint
and
and
doing
it
in
glue.
We
have
some
great
getting
started
guides
and
that
we
can
link
to
from
the
the
show
notes,
that'll
get
you
up
and
running
and
starting
to
play
around
with
this,
and
we
love
feedback.
So
you
know
on
slack
reach
out
to
us
and
and
ask
us
questions:
we'd
love
to
interact
with
our
community.
B
Might
be
a
great
way,
I'm
totally
sleeping
on
the
workshop.
But
yes,
we
have
a
fantastic
workshop,
so
you
don't
have
to
set
up
anything
locally.
It's
all
browser-based.
In
the
instruct
platform
we
run
those
regularly.
I
don't
know
when
the
next
one
is,
but
it's
on
our
events
calendar.
So
you
know
you
definitely
get
hands
on
those.
A
B
Only
thing
I'll
say
is:
if
you
haven't
used
graphql,
you
definitely
owe
it
to
yourself
to
give
it
a
shot.
You
know
it's,
we
see
it
soaring
in
popularity
like
they
have
like
like
monster.
Adoption
stats
and
like
the
javascript
community
of
like
98
of
developers,
are
aware,
like
crazy,
high
satisfaction
levels
every
year
they
do
the
api
landscape
graphql
continues
to
creep
up
and
creep
up,
which
is
a
very
mature
landscape.
B
When
you
think
about
you,
know
ftp
and
soap,
and
all
these
others,
like
you,
know,
interfaces
for
data
that
have
been
there
forever
decades
and
decades
and
decades
the
fact
that
graphql
has
grown
so
quickly.
It's
definitely
if
you're,
not
using
it.
Today,
it's
coming
to
an
environment
near
you,
you
know,
and
so
this
is
a
great
time
to
get
educated
on
it
and
understand
how
you're
going
to
deploy
successfully.
A
B
Yeah
so
right
now,
like
the
portal
that
we
have
today
is
just
for
rest
in
grpc,
and
we
actually
because
the
interfaces
for
graphql,
the
like
the
whole
api
registry
and
looking
at
the
type
tree
and
the
explorer
are
a
little
bit
unique
to
graphql
but
they're.
Not
so
unique,
and
so
what's
interesting.
Is
that
as
we're
adding
portal
support
and
like
we're
kind
of
this
is
a
little
bit
of
a
preview,
but
in
a
future
version
of
blue
gateway.
B
We're
updating
our
portal
and
you're
gonna
start
to
see
all
three
of
those
apis
occupy
the
same
level
right.
So
you
have
a
single
api
catalog
where
you
see
all
your
grpc
and
rest
and
graphql
apis,
and
then
you
go
to
the
appropriate
documentation
and
client
tooling
to
invoke
each
of
those.
So
the
answer
to
this
directly
is
no.
We
don't
add
this
in
portal
today,
but
the
next
version
of
portal
is
going
to
have
graphql
support
along
with
grpc
and
rest.
A
Awesome,
that's
great
thanks!
So
much
for
that
last
question.
You
know
we
had
fun
for
sure
answering
your
questions.
Let's
see
all
right
so
keys.
I
want
to
take
a
minute
to
thank
you.
You
know
I
feel,
like
I've
learned
a
lot
about
graphql
from
you.
You
know
how
you
know
the
landscape
works,
how
to
get
started.
You
know,
what's
the
difference
between
federation
to
stitching
why
you
know
we
go
down
with
stitching,
you
know
automatic
skimmer
generation
manual
generation.
A
B
A
Yeah,
I
really
appreciate
all
the
audience
tuning
in
and
you
know
ask
these
questions.
You
know
it
really
really
got
us
thinking
and
make
the
the
hood
so
much
fun.
So
it's
really
for
the
audience
that,
like
you
without
you,
you
know
there's
no
good,
so
yeah.
So
folks,
if
you
find
this
interesting,
please
give
us
a
thumbs
up
and
also
subscribe
to
our
channel.
So
you
don't
miss
any
of
our
future
good
episode.
Well,
I
you
know
talk
to
different
experts
on
different
topics.
So
thank
you
so
much
everyone
for
joining.