►
From YouTube: Hands on with GraphQL
Description
SoloCon 2022:
Hands on with GraphQL
Speakers:
Keith Babo
Product Manager, Solo.io
Sai Ekbote
Software Engineer, Solo.io
Session Abstract:
Roll up your sleeves and prepare to dive into the end-to-end developer experience for GraphQL with Gloo Edge. Sai and Keith will walk through a set of common use cases for GraphQL APIs with a live demonstration implementing them with GraphQL support in Gloo. You will leave this talk with the knowledge you need to build GraphQL APIs with the platform along with an understanding of all the key GraphQL features we have to offer.
Track:
Community and Open Source
A
B
Hey
I'm
keith
babo,
I'm
a
product
manager
here
at
solo.I.
Oh
so,
as
I
mentioned,
exciting
talk
we're
going
to
get
super
hands-on
in
today's
session,
we'll
kick
it
off
skye's,
going
to
cover
how
we
integrate
with
upstream
discovery
and
function,
discovery
services
in
glue
edge
to
automatically
generate
graphql
apis.
B
Then
psy's
going
to
talk
about
as
you
scale
graphql.
You
start
to
have
many
graphql
apis
and
you
want
to
create
a
unified
graph.
How
you
can
use
stitching
to
actually
create
that
federated
graph,
then
we're
going
to
show
the
graphql
ui
there's
a
couple
of
cool
demos
mixed
in
there
and
then
we'll
just
talk
about
the
next
steps
and
how
you
can
get
hands-on
with
this
yourself.
B
B
The
talk
that
sign
cyanide
gave,
which
on
introducing
graphql
talks
about
background
of
graphql
and
what
solo's
position
is
and
what
we're
doing
there
then
kevin
and
adam
get
into
the
details
of
securing
graphql
and
some
of
the
like
the
really
deep
level
plumbing
really
cool,
talk
there
and
then
there's
a
workshop.
So
all
those
things
are
great
ways
to
get
up
to
speed
and
how
you
can
get
hands-on.
In
addition
to
watching
this
talk
so
that
that
out
of
the
way
psy,
you
want
to
talk
about
schema
discovery.
A
Sure
yeah
sounds
good
keith
thanks
for
that
excellent
intro.
I
did
want
to
mention
that
this
will
be
more
of
a
200
level
course.
The
introduction
to
graphql
in
glow
edge
and
glue
mesh
talk
that
we
gave
earlier
so
con.
It
was
more
of
a
100
level,
color,
so
you're
if
you're
not
familiar
with
a
lot
of
the
graphql
concepts.
I'd
highly
recommend
watching
that
first
and
then
coming
to
this
talk,
so
one
of
the
main
tenets
of
graphql
is
the
fact
that
it's
a
strongly
typed
api
protocol.
A
It's
a
way
of
being
able
to
communicate
with
your
upstreams
or
multiple
upstreams
at
once,
while
knowing
exactly
what
data
you're
going
to
be
sending
and
what
sort
of
responses
you're
going
to
be
receiving
back.
So
how
do
we
exactly
generate
those
graphical
schemas,
those
graphical
types
from
our
existing
upstreams
without
touching
application
code?
A
Because
as
an
organization
you
may
have
you
know,
rest
up
streams
or
rest
services,
grpc
services,
soap,
services
that
exist
in
your
cluster
that
you
know
might
be
legacy,
might
not
have
been
touched
in
many
years
that
you
want
to
modernize
to
graphql.
But
you
you
know,
you
don't
want
to
touch
the
application
code.
Well,
we've
introduced
a
way
called
graphql
schema
discovery
to
basically
modernize
your
applications
to
graphql
without
without
touching
your
application
code
and
just
doing
this
at
an
infrastructure
layer
or
an
api
layer.
A
A
Well,
your
pet
service
currently
exposes
an
open
api
spec.
What
is
an
op
open
api
spec,
it's
kind
of
like
a
type
definition
for
the
api.
It
exposes
what
end
points
exist
in
that
service
and
what
types
those
endpoints
exist
expect,
as
well
as
what
responses
they
give
back
and
generally
that's
exposed
as
a
big
json
such
as
this,
that
has
a
list
of
paths
and
the
inputs
and
outputs
those
paths.
A
A
The
open
api
spec
also
provides
us
the
parameters
that
the
endpoint
expects.
So
we
can
convert
those
parameters
to
the
parameters
that
the
graphql
field
expects.
So
for
this
example,
we
have
the
pet
id
parameter
in
the
open
api
spec,
and
we
convert
that
to
the
id
input
argument
in
the
graphql,
and
you
can
see
that
the
graphql
output
type
is
a
pet
output
type.
But
how
do
we
know
exactly
what
that
pet
type
consists
of?
Well,
the
open,
epi
spec
also
provides
that
information
in
the
schema
section.
A
So
when
we,
when
we
go
down
even
further
in
the
open
api
spec,
we
see
that
there's
a
schema
section
and
the
pet
type
is
enumerated
out
here
with
all
of
its
specific
properties
that
the
upstream
is
going
to
serve
back
to
you.
So
you
have
the
id
category
name
and
status
of
the
pet,
and
so
we
can
it's
almost
a
one-to-one
correlation
between
open
api,
spec
types
and
graphql
types.
A
A
In
this
case,
we
have
messages
which
are
essentially
going
to
translate
directly
into
graphql
types,
and
we
also
have
services
which
state
the
actual
remote
procedure
calls
that
you
can
make
on
that
grpc
service.
So
we
are
going
to
generate
graphql,
query
types
or
graphql
query
fields
from
the
protobuf
services.
A
So
there's
a
one-to-one
correlation
here
as
well,
where
we
create
a
get
book
field
in
graphql
from
the
getbook
method
in
the
book
service
proto
in
the
protobot,
and
we
can
also
translate
the
inputs
and
the
outputs
of
the
book
service
or
the
get
book
method.
Two
graphql
types,
because
those
are
also
enumerated
in
the
protobuf
definition.
A
So
now
that
we've
gone
and
converted
individual
services
to
graphql
apis,
I
want
to
zoom
out
a
little
bit,
and
I
want
to
emphasize
the
fact
that
this
is
a
layer
above
our
application
code
and
so
application
developers
don't
have
to
worry
about
making
any
switch
to
the
graphql
spec
or
implementing
a
graphql
server
within
their
application.
They
just
have
to
worry
about
maintaining
their
service
definitions
and
graphql.
Discovery
will
take
care
of
the
rest.
A
So
now
that
we've
gone
over
what
graphql
discovery
does
or
the
schema
auto
generation
does
at
a
high
level,
we
can
make
things
more
concrete
by
talking
about
how
we
can
actually
enable
schema
discovery
today
on
our
services
or
upstream
so
glue
supports
two
modes
of
discovery.
The
first,
which
is
allow
list
when
using
allow
list
mode.
We
turn
on
discovery
for
specific
services
manually
by
labeling
those
services
with
this
function.
Discovery
enabled
label
so
essentially,
what's
happening
in
your
cluster.
A
The
grpc
definition
in
this
case
and
turn
it
into
a
graphql
schema
and,
secondly,
we
allow
for
block
list
mode
which
creates
graphql
schemas
for
all
supported
services
unless
explicitly
disabled,
which
we
can
do
with
this
function,
discovery
disabled
label,
so
in
this
case
we've
gone
and
labeled
our
payment
service
with
that
disabled
label
and
graphql
schema
discovery
will
explicitly
ignore
that
service
while
discovering
the
rest
of
our
services
in
our
cluster.
So
this
just
supports
two
different
sort
of
workflows
for
enabling
schema
discovery
for
our
services
in
our
cluster.
Currently.
A
B
Awesome
thanks
ai
all
right,
so
psy
just
did
a
great
job
of
describing
how
integrating
with
upstream
discovery
can
automatically
generate
graphql
api.
So
that's
taking
what
we
might
call
a
resource,
first
approach
for
every
upstream
resource
or
api
that
I
want
to
generate
or
that
I
want
to
have
graphql
for
I'm
generating
a
graphql
api
from
that.
B
Another
mode
of
operation
is
to
go
in
the
other
direction
and
to
start
with
the
schema
first
and
when
we
start
with
the
schema
first,
we're
designing
a
schema.
Maybe
what
the
front
end
data
model
needs
in
mind,
but
then
how
do
I
connect
it?
This
isn't
discovered
and
automatically
generated
from
anymore.
I
still
need
to
connect
the
schema
definition
to
my
upstream
apis
that
are
going
to
serve
that
data
and
that
exists
via
a
piece
of
functionality
called
resolvers.
B
So
on
the
left
here
I
have
a
schema
definition:
that's
going
to
satisfy
maybe
a
home
page
for
a
bookstore
where
I
have
a
card
layout
where
I'm
going
to
serve
various
products
with
details
and
that
data
comes
from
many
upstream
data
sources.
So
it's
not
a
single
upstream
data
source.
I'm
fetching
it
from,
but
multiple
and
they're
sort
of
related,
there's
foreign
key
relationships
between
them.
B
How
that
works
when
we
actually
look
at
configuration,
is
really
two
parts
to
it.
The
first
is
that
when
I
need
to
supply
data
inside
of
my
graphql
schema
whether
that's
at
the
top
here
in
the
query
definition.
So
that's
the
entry
point
for
all
clients
that
are
invoking
graphql
operations
or
I
need
to
overall
override
specific
fields
and
the
data
handling
for
specific
fields.
B
First,
the
request
portion,
so
we
receive
a
graphql
operation
so
we'll
receive
like.
Let's
say
a
query
and
then
that
query
is
going
to
be
serviced
by
one
or
more
upstream
apis
and
the
request
portion
of
the
resolver
config
controls.
When
I
request
data
from
that
upstream
api,
how
am
I
formatting
that
request
that
http
request?
So
that's
one
portion,
the
next
portion
is
the
response.
So
I've
invoked
that
upstream
api.
B
So
let's
look
at
each
of
these
in
turn.
So
when
we
look
at
the
request
configuration
right
at
the
top,
we
have
the
headers
section
and
there's
two
required
aspects
there.
One
is
the
method.
This
just
tells
us
the
http
method
that
you
want
to
invoke
whether
that's
post
put
get
delete
patch,
whatever
you
want
to
use
there
in
your
upstream
api
and
then
also
the
path
element.
So
basically,
this
could
be
a
root
path.
It
could
be
api
v2
or
whatever
the
path
is
of
that
upstream
api,
then.
B
Finally,
we
support
any
number
of
key
value
user
defined
headers
here,
and
these
headers
could
be
statically
a
static
definition.
Like
you
see
here,
myheader123
we
can
pull
data
out
of
the
graphql
request
itself
and
seat
seated
there
we
can
dynamically
pull
data
from
the
headers
of
the
graphql
request,
so
a
very
flexible
capability.
Here,
that's
going
to
allow
you
to
give
your
upstream
rest
apis
the
data
that
they
need.
B
Finally,
rounding
out
the
other
options
here:
query
parameters,
so
this
is
the
bit
that
goes
after
the
question
mark
in
your
url.
You
can
specify
any
number
of
key
value
pairs
here
again.
These
can
be
substituted
variables,
based
on
the
context
of
the
graphql
request
and
then
finally,
the
body,
the
body
is
really
only
useful
when
you're
doing
when
you're
passing
a
body
of
data
in
the
request,
so
like
a
post
or
a
put
or
a
patch
for,
gets
and
deletes
you,
you
really
won't
use
the
body
field.
B
Now
that
we've
talked
about
the
request,
let's
talk
about
the
response,
so
in
the
response
there's
two
key
fields:
the
first
is
result
root,
and
what
does
that
mean?
That
means
that
I
could
be
invoking
a
upstream
rest
api
that
just
barfs
a
ton
of
data
back
at
me
right
like-
and
I
only
need
a
very
small
subset
of
that-
and
this
data
could
be
very
hierarchical
in
nature.
Result
root
allows
me
to
narrow
down
that
response
data
to
a
specific
object
or
field
that
I'm
going
to
map
into
my
graphql
schema.
B
Setters
is
sort
of
a
corollary
capability
there
that
allows
for
transformation
of
that
data
you're
getting
back
into
the
graphql
schema.
So
if
you
have
a
field
name
in
your
schema
that
doesn't
match
the
response
data,
you
can
use
setters
to
rectify
that
and
to
map
that
data.
We
also
have
a
very
powerful
expression,
language
or
transformation
language
that
can
be
used
to
manipulate
that
data
like
to
concatenate
fields
or
select
out
data
within
resp
return
data
to
set
that
as
part
of
the
graphql
response
and
then
finally,
upstream
refs
again.
B
B
So
we
see
that
there's
an
at
resolve
there
and
it's
returning
a
product
all
right-
and
here
is
the
actual
definition
of
that
configuration.
So
we
know
it's
a
get
and
we
know
that
it's
going
up
against
this
default
product,
page
upstream
api,
and
it's
passing
this
path.
There's
no
other
configuration
here
because
we're
actually
able
to
take
that
response
data
and
automatically
map
it
into
the
the
product
data
type
here
in
our
graphql
schema,
because
all
of
these
fields
match
and
the
nature
of
the
data
just
fits
perfectly
on
its
own.
B
But
there's
a
lot
of
other
fields
that
aren't
satisfied
by
this
request.
There's
other
rest
apis
that
we
need
to
invoke.
So
how
do
we
handle
those
and
that's
with
more
resolvers?
So
here
we
can
see
for
the
author
page.
We
need
to
go
to
the
details,
api
and
we
can
see
here
a
substitution
variable.
That's
actually
we've
already
fetched
the
product
details
and
the
product
id.
I
can
use
that
data
in
other
resolvers
as
sort
of
a
foreign
key
to
correlate
that
data
and
grab
related
data
all
within
one
graphql
api
call.
B
If
we
look
at
reviews,
this
is
a
list
that
comes
back
and
again
we
see
some
of
the
automated
data
mapping,
that's
already
happening
for
you
requiring
an
upstream
risk
api,
it's
giving
us
a
sort
of
nested
list,
we're
pulling
out
a
list
inside
of
that
and
then
we're
automatically.
The
graphql
runtime
is
automatically
creating
that
list
and
populating
it
into
the
graphql
schema,
because
the
reviewer
and
text
fields
automatically
match
the
response
data.
B
In
other
cases,
I'm
getting
a
list
back
here
in
ratings,
but
for
the
ratings
api,
it's
giving
me
a
stringified
map.
So
now
I
get
to
exercise
some
of
that
cool
transformation
logic
to
go
into
that
string,
that's
getting
returned
and
create
basically
store
a
key
and
value
and
parse
that
into
the
reviewer
and
num
stars
field,
so
really
flexible
transformation
language
there,
all
right
psy!
That's
all
I've
got
in
terms
of
getting
into
the
depths
of
result,
and
we
didn't
even
touch
all
of
it.
B
A
We,
you
don't
want
to
expose,
you
know
50
or
500
different
graphql
endpoints.
You
only
want
to
expose
one
maximum,
a
couple
of
graphql
endpoints,
because
otherwise
we're
kind
of
it
defeats
the
purpose
of
one
of
graphql's
main
benefits,
which
is
that
you
can
fetch
data
across
different
resources
from
a
single
query.
A
So
from
a
single
graphql
operation,
you
can
essentially
stitch
together,
multiple
graphql
sources
or
upstreams
without
having
to
do
any
like
special
chaining
logic
on
the
client
side,
all
that's
sort
of
handled
by
the
graphql
server.
So
what
exactly?
How
exactly
do
we
do
that?
And
how
do
we
accomplish
this
sort
of
schema,
stitching
or
graphql
service
stitch?
A
A
A
A
Similarly,
for
the
product
service,
we
issue
a
query
for
a
product
and
we
issue
for
some
product
with
an
id
of
125
and
we
get
back
the
name
of
the
product,
narnia
great
book
and
the
seller,
who
happens
to
be
18.
now.
Let's
say
we
want
to
get
the
full
name
of
the
this
seller,
this
user,
a
heath
well,
the
product
service,
won't
be
able
to
tell
us
that,
in
fact,
if
we
were
to
go
ahead
and
run
that
query
on
the
product
service,
we'd
get
back
null
or
an
error
from
the
product
service.
A
A
So
we
can
give
glue
some
hints
saying:
okay,
I
have
the
user
type
here
and
if
you
give
us
this
key
of
username,
we
can
run
a
query
on
the
user
service
to
get
back
all
the
full
user
information
from
the
user
service,
including
the
full
name,
and
similarly
with
the
product
service.
We
can
do
the
same
thing.
If
you
give
us
a
product
with
a
certain
id,
we
get
all
the
product
information
you
might
want
from
the
product
service,
for
example
the
product
name
or
the
seller.
A
A
So,
given
the
type
merging
configuration
that
we
had
in
the
previous
slides,
we
can
now
create
a
gateway,
schema
or
a
gateway
api.
That's
essentially
a
gateway
into
our
three
services
running
in
our
cluster,
so
this
gateway
schema
encompasses
all
those
three
services,
partial
types
to
create
sort
of
these
super
types
that
essentially
stitch
all
those
sub
schemas
together.
A
So
what
does
this
mean?
We
can
now
run
a
query
against
this
gateway
schema
that
includes
information
and
ask
for
information
from
each
of
our
services,
while
only
creating
one
query
from
the
client
and
to
really
highlight
this,
I'm
going
ahead
going
to
go
ahead
and
add
some
color
to
this
query
to
show
exactly
which
of
these
services
each
part
of
the
query
is
coming
from,
so
we
can
see.
A
A
A
A
So
we
see
all
these
methods
that
the
jrpc
pet
store
provides
and
this
lines
up
pretty
well
with
exactly
the
pet
store
proto
that
this
grpc
service
uses.
So
all
the
service
definitions
are
right
here
and
those
are
the
exact
same
ones
that
the
grpc
service
gave
us
right
here.
So
now,
let's
turn
these
services
into
graphql
services.
A
Normally
this
would
be
a
pretty
big
undertaking
involving
an
entire
team,
modernizing
the
application
by
implementing
a
graphql
server
in
whatever
language
those
applications
are
written
as
well
as
writing.
Resolvers
for
each
of
the
graphql
fields,
however,
glue
edge,
makes
this
process
super
easy,
using
schema
discovery,
as
I
talked
about
earlier
in
this
talk,
so
let's
go
ahead
and
enable
schema
discovery
for
these
services
by
labeling.
A
These
services
with
this
function,
discovery
enabled
label
and
similarly
we're
going
to
do
this
for
the
pet
store
grpc
service
and
as
we
label
these
services
you're
going
to
start
to
see
that
discovery
is
going
to
discover
the
service
definitions,
the
grpc
protobufs
and
the
rest
open
rest,
open
api,
spec
definitions
and
convert
those
definitions
into
graphql
schemas.
So
now
we
can
actually
see
these
graphql
schema
crds
in
our
kind
cluster,
and
we
can
go
ahead
and
browse
these
schemas
by
looking
at
the
resource
definitions
themselves.
A
So
we
have
this
graphql
query
type,
which,
and
each
of
these
service
methods
correspond
to
a
query
field
as
well
as
the
type
definitions
from
the
protobuf
correspond
to
input
and
output
types
in
the
actual
schema
definition.
Let's
so
now
we're
going
to
create
a
virtual
service
to
route
traffic
to
our
graphql,
schemas
or
backends.
A
A
Each
of
these
routes,
routes,
traffic
to
a
different
graphql
backend,
one
routes
to
the
rest,
backend
and
the
other
routes,
the
grpc
backend.
And
if
we
go
ahead
and
apply
this
graphql
virtual
service,
let
that
configure
itself.
We
can
now
use
the
graphql
playground
to
actually
query
these
running
graphql
services.
A
But
I
want
to
remind
you
that
we
haven't
touched
a
line
of
application
code,
so
what's
happening
here
is
that
we
are
converting
these
queries
into
actual
rest
request,
sending
it
to
the
rest
up
stream
and
the
pep
stop
stream
is
going
to
give
us
back
a
json
response
which
would
then
we're
going
to
process
and
filter
so
that
we
get
back
the
data
that
we
actually
want.
So,
for
example,
we're
only
going
to
get
the
data
that
we
asked
for
for
each
of
our
queries.
A
So
now
we're
going
to
do
the
same
thing
for
our
grpc
backend,
we're
going
to
issue
a
query.
This
find
pep
id
query
which
comes
from
the
protobuf
definition
right
here
and
issue
that
against
our
grpc
backend,
and
we
can
go
ahead
and
query
the
your
pc
back
in
the
same
as
we
did
with
our
other
sources.
A
A
In
fact,
it
doesn't
even
exist
in
the
grpc
schema,
and
that's
only
because
this
was
discovered
from
the
grpc
server,
so
it
obviously
knows
nothing
about
the
rest
service.
This
is
where
schema
stitching
comes
in,
so
what
we're
going
to
do
is
create
a
gateway,
graphql
service
or
great
gateway,
graphql
schema,
which
is
going
to
stitch
these
two
sub
schemas
together
and
allow
us
to
query
both
these
sub
schemas
from
one
single
query.
So
all
we've
done
is
referenced.
A
So
now
that
we've
created
this
gateway,
graphql
schema,
we
also
have
to
hook
it
up
to
a
virtual
service.
So
let's
do
that
right
here
comment
this
and
now
we
have
this
graphql
gateway
route
which
uses
the
gateway,
graphql
schema
and
let's
go
ahead
and
apply
this
change
to
the
graphql
virtual
service,
and
once
we
create
that
gateway,
graphql
schema
we're
going
to
see
that
glue
automatically
generates
the
graphql
schema.
A
The
super
schema
that's
going
to
include
both
the
grpc
pet
store
and
the
rest
pet
store,
graphql
schemas
in
it,
and
we're
going
to
copy
that
graphql
schema.
You
can
see
that
all
the
types
from
the
rest
service,
as
well
as
the
grpc
service,
are
in
this
query
type.
So
now,
let's
query
this
gateway
schema
and
see
this
in
action.
A
So
right
now
we
have
a
query
here
which
does
the
get
pep
id
from
the
rest
service,
as
well
as
the
find
pep
id
from
the
grpc
service,
and
these
two
queries
are
running
independent
of
each
other
in
the
back
end
and
querying
each
of
their
respective
services
and
then
glue
is
bringing
back
the
responses
and
stitching
them
together
into
one
coherent
response
for
the
for
the
client.
So
your
client
doesn't
have
to
worry
about
making
a
request
requested
one
service
and
then
making
a
request
to
another
service.
B
That
was
an
awesome
demo
side
really
really
impressive
to
see
that
come
all
come
together,
all
right.
So
now,
let's
switch
gears
here
and
we've
been
doing
a
lot.
You
know
looking
at
config
raw
configuration
seeing
a
lot
of
stuff
from
the
command
line,
there's
a
whole
other
angle
to
our
graphql
support,
which
is
what
we've
added
to
the
edge
ui.
B
So
what
better
way
since
this
is
a
hands-on
talk
and
we've
seen
enough
slides
for
today,
I
think
I'm
going
to
go
right
into
another
demo,
where
we
see
the
graphql
ui
in
action
all
right
here
we
are
in
the
edge
ui,
which
you
may
already
be
familiar
with.
One
thing
you
probably
haven't
seen
is
this
new
nav
item
here
for
apis
in
the
top
menu.
When
I
click
on
that,
I
get
a
list
of
all
the
graphql
apis.
B
I've
deployed
this
functions
very
much
like
an
api
registry
or
schema
registry
for
graphql,
and
that
now
I
can
go
and
as
a
consumer
of
these
apis,
I
can
go
click
on,
for
example,
the
pet
store
graphql
api
that
sai
was
discussing
earlier,
which
is
automatically
generated.
I
can
come
in
and
see
all
the
queries
that
are
available
on
this
api,
all
the
various
types.
So
if
I
want
to
look
at
like
the
pet
type,
for
example,
I
can
see
the
fields
available
on
a
pet
type
and
even
the
mutations
are
listed
here
as
well.
B
I
also
have
details
on
the
upstreams
that
I'm
integrating
with
so
I
can
click
on
the
pet
store
and
get
details
on
that
upstream
api
that
graphql
is
sitting
in
front
of.
But
the
main
thing
I
wanted
to
show
from
a
hands-on
perspective
in
this
ui
is
the
ability
to
actually
create
new
graphql
apis
as
well.
So
let's
follow
that
workflow.
B
So
I'll
click
on
create
api
and
then
we'll
call
this
one.
My
book
info-
and
this
is
going
to
be
based
off
the
book
info
example
that
we
looked
at
earlier,
go
ahead
and
select
the
schema
definition,
so
I'm
not
supplying
any
other
configuration
other
than
the
original
schema
definition
that
I
want
to
use
so
I'll
say,
create
api,
and
if
we
go
and
look
at
the
underlying
config,
I
can
see
that
there's
a
crd
here.
B
So
let's
go
ahead
and
get
started
with
the
top
level.
Query:
the
entry
point
for
our
graphql
api,
which
is
products
for
home
I'll,
go
ahead
and
define
a
resolver
here.
I
want
to
specify
this
is
a
rest
api
type.
I
could
also
choose
grpc
if
I
had
that
available
and
then
I'll
get
a
list
of
rest
apis
in
my
environment,
in
this
case
we're
going
to
go
and
click
on
product
page,
which
is
the
upstream
for
the
top
level
details
I
want,
and
now
I
get
prompted
for
the
resolver
config,
which
is
pretty
straightforward.
B
B
Next
thing
I'm
going
to
do
is,
if
you
remember
some
of
the
details
in
my
graph
were
satisfied
by
one
api,
but
they're
actually
like
four
different
apis
that
I
wanted
to
mash
together,
for
this
particular
graphql
schema,
and
so
I'm
going
to
do
is
navigate
down
into
product
and
there's
some
individual
fields.
Here
I
need
to
define
specific
resolvers,
for
so
like
authors,
pager
or
author
pages
in
year
are
all
from
the
details
api.
So
let's
go
ahead
and
define
those
as
well
again.
B
Only
other
thing
I
want
to
specify
here
is:
I
want
to
narrow
this
down
just
to
the
author
field
and
we're
good
to
go,
and
I'm
going
to
repeat
this
pattern.
So
I've
just
copied
that
config
here
for
pages
very
similar
thing,
we're
going
to
get
that
from
the
details,
api
and
we'll
go
ahead
and
just
update
that
and
then
finally,
for
year
same
thing
go
into
the
details,
api
and
we'll
specify
year
all
right
last
field
I
want
to
get
in
this
before
we
actually
show
it
live
in
action
is
a
review
field.
B
B
We
can
see
here
that
the
up
streams
I'm
talking
to
have
automatically
populated
on
this
page-
and
the
next
thing
I
want
to
do
is
make
sure
I'm
enabling
introspection
for
this
api.
So
let's
go
right
back
up
and
we
can
see
that
that's
disabled
by
default,
so
I'll
go
ahead
and
enable
that
now,
what
does
that?
Do?
That
provides
a
really
useful
feature
here.
B
If
I
want
to
come
in
as
a
developer
or
even
we
were
seeing
before
the
catalog
use
case,
where
someone
else
has
created
a
graphql
api,
I'm
just
looking
at
the
documentation
or
maybe
I
want
to
try
it
out.
So
I'm
going
to
come
over
here
to
the
explorer
page
and
we
can
see
that
I've
got
a
live,
interactive
explorer
that's
available.
B
All
of
the
documentation
from
my
schema
definition
is
available
here,
so
I
can
see
that
I'll
list
it.
If
I
need
details
in
the
various
fields
and
we
also
have
the
ability-
let's
call
this
a
books
query,
and
we
can
see
that
I
have
autocomplete
for
the
various
fields.
So
that's
the
query.
I
want
products
for
home
and
let's
go
ahead
and
pull
the
title:
the
author
number
of
pages
and
year
and
now
I
can
run
this
query
and
I
get
that
data
live
back
to
me.
B
So
this
is
really
exciting,
not
just
from
the
standpoint
of
traditional
api
registry
and
schema
registry
use
cases,
but
also
as
a
development
tool.
So
your
dev
teams
can
get
up
and
running
quickly,
purely
through
the
ui,
creating
new
graphql
apis
based
on
the
upstream
rest
and
grpc
apis.
You've
already
deployed.
A
B
In
addition
to
that,
we're
super
happy
to
announce
the
beta
of
glue
graphql
here
at
solocon.
So
this
is
part
of
the
glue
edge,
111
release
stream
and
the
beta
is
now
available
for
everybody
to
get
hands
on.
We
won't
go
into
all
the
features.
There
was
another
talk
that
talked
about
all
these
features,
but
you
can
see
here
there's
a
lot
of
great
stuff
in
the
beta
to
get
a
hands-on
with.