►
From YouTube: Jakarta Tech Talk - GraphQL Distilled
Description
REST is all about endpoints that perform specific queries or operations. This works fine, but the client is limited by which queries have been exposed. What if the backend exposed the data, but the client could decide which subset of data it needed, and how to interact with that data? That’s the promise of GraphQL — simplify the back-end, give the client more power, and make it easier to evolve APIs.
When we take this approach, we also have more flexibility on the backend; we can use one or many different microservices together to provide a unified API. In this talk, we’ll explain what GraphQL is, how it works, and look at how easy it is to build GraphQL APIs using MicroProfile GraphQL.
Jakarta EE
Jakarta EE gives developers a comprehensive set of vendor-neutral, open specifications that are used for developing modern, cloud native Java applications from the ground up. With Jakarta EE, technology developers and consumers can be confident they have the best technologies for developing cloud native, mission-critical applications. And they can build on decades of Java developer expertise to move existing workloads to the cloud.
Learn more: https://bit.ly/3IPrxOq
Follow us on Twitter: https://twitter.com/home
Follow us on LinkedIn: https://www.linkedin.com/showcase/jakartaee/
Like us on Facebook: https://www.facebook.com/JakartaEE/
A
Hello,
everyone
and
welcome
to
another
jakarta
tech
talk.
My
name
is
serena
and
joining
us
today
is
keto
men
who
will
be
presenting
on
the
topic
of
graphql,
distilled
if
you
have
any
questions
for
quito
as
we
move
through
today's
presentation
feel
free
to
ask
it
in
the
chat
or
use
the
ask
a
questions.
Tab
before
we
get
started.
The
jakarta
ee,
10
release
tech
talk
is
happening.
On
june
28th
mark
the
celebration
of
the
community
driven
innovative
innovation,
release
of
jakarta
ee10
now
without
further
delay.
Kito
over
to
you.
B
Okay,
so
there's
my
intro,
my
my
my
ten-year-old
daughter
did
that
so
I
have
to
have
to
include
that.
So
let
me
change
to
the
right
screen
here
so
welcome
today,
we're
talking
about
graphql,
so
this
session
is
called
graphql,
distilled
for
java
developers
and
I'll
be
talking
about
what
graphql
is,
how
it
works
and
also
about
how
it's
implemented
specifically
in
market
profile,
but
also
java
in
general.
B
So
first,
let
me
talk
a
little
bit
about
myself,
so
my
name
is
keto,
I'm
the
principal
consultant
at
virtua,
where
we
do
training
consulting
mentoring,
et
cetera
on
basically
all
sorts
of
technologies,
mostly
worth
work
with
larger
companies
and
government,
but
also
startups,
sometimes
usually
working
on
backend
java
cloud
native
stuff,
but
also
front-end
as
well.
Angular,
react,
etc
also
web
components.
So
so
that's
that's
my
job.
That's
what
I
do
on
a
daily
basis
is
work
with
those
technologies.
B
Also,
you
know
we
do
mobile
et
cetera,
I'm
also
a
java
champion.
I
am
the
I've
worked
on
several
java
community
process:
expert
groups,
I'm
a
member
of
the
jakarta
ee,
guardian
leadership,
council
council
and
a
google
developer
expert
on
web
technologies,
and
I'm
also
the
co-host
of
the
stack
podcast
and
if
you
like,
podcasts,
I
encourage
you
to
check
it
out.
B
We
basically
focus
on
java
front
end
development,
just
enterprise
development
in
general,
and
also
best
practices,
all
sorts
of
fun
stuff
and
we've
had
lots
of
great
guests
lately
as
well,
and
we've
got
a
new
episode
coming
up
soon
with
holly
cummings,
who
actually
works
on
the
quarkus
team.
So
we've
got
lots
of
great
people
on
the
show
and
I
have
a
few
co-hosts
that
are
that
are
amazing.
B
So
if
you
like,
it
check
it
out
stackpodcast.com-
and
I
also
let's
see-
I
can't
even
read
my
other
point
here
on
the
screen.
But
here
we
go.
Let
me
hide
that
there
we
go
yeah.
I
speak
of
lots
of
conferences.
Okay,
that's
not
very
interesting,
all
right!
So
before
we
begin
I'd
like
to
hear
a
little
bit
about
the
people
on
the
in
the
session.
B
B
New
to
this,
but
experience
in
back
end:
okay,
excellent,
excellent,
okay,
yes,
and
this
I
do
different
versions
of
this
talk,
but
this
one
is
more
geared
towards
back
end,
so
I
think
this
will
work
out
well,
okay,
so
first
question
is
what
is
graph
up
graphql?
So
what
actually
is
it?
And
what
is
the
whole
point?
So
first
thing
I'll
point
out
is
what
it
looks
like
so
on
the
left.
B
Here
you
have
a
graphql
request
and
on
the
right
is
the
response
and
you'll
notice,
one
thing
here
initially,
which
is
that
in
the
request
you
specify
exactly
which
properties
you
want
back.
So
you
say
what
data
you
want
to
be
returned
from
the
back
end
and,
of
course
the
back
end
will
return
that
and
basically
we're
talking
about
a
completely
different
approach
to
client
server
communication,
meaning
that
we're
not
really
doing
rest
we're
not
doing
grpc
we're
not
doing
a
protobuf
we're
not
doing
soap
or
whistle.
B
B
So
obviously
not
rest
graphql
was
created
in
2012
by
facebook
and,
of
course
they
have
very
specific
needs,
especially
when
it
comes
to
transferring
information
about
users
and
basically
a
graph
right.
So
you
can
think
of
facebook
as
a
huge,
huge
social
graph,
so
it
was
open
source
in
2015
and
the
graphql
foundation
was
started
in
2017.
B
and
that
consists
of
lots
of
different
companies
and
it's
actually
been
adopted
by
a
large
range
of
companies
as
well.
This
is
a
partial
list.
Obviously,
but
you
see,
we've
got
lyft
twitter,
github,
paypal,
starbucks,
shopify,
yelp,
wayfair,
etc.
So
lots
of
big
companies
have
picked
it
up
over
the
years
and
I
should
mention
that
netflix
has
actually
started
using
it
as
well.
So
why
would
you
want
to
use
it?
B
Well?
The
first
first,
let's
look
at
the
benefits,
so
one
of
the
one
of
the
key
differences-
and
I
think
it
simplifies
the
client
usage-
is
that
there
is
a
single
consolidated,
dynamic
endpoint.
So
as
opposed
to
having,
like
you
know,
an
endpoint
for
each
particular
api
call
that
you've
built
you
basically
have
one
endpoint,
which
is
usually
slash
graphql.
B
B
Another
key
difference
is
that
with
graphql,
the
client
decides
what
data
it
wants
and
that
basically
means
that
you
can
cut
down
on
the
amount
of
traffic
being
sent
back
and
forth.
So
if
the
client
only
wants,
like
all
the
people
and
on
all
the
people
on
the
system,
but
only
ones
like
the
first
name
and
the
last
name,
it
can
ask
for
just
those
two
fields,
just
those
properties
and
not
worry
about
getting
a
whole
bunch
of
extraneous
data
that
it
doesn't
need.
So
that
means
that
you
know.
B
Let's
say
you
have
5000
records
coming
back.
If
you
can
specify
only
the
fields
you
want,
the
amount
of
data
being
sent
back
and
forth
is
going
to
be
a
lot
smaller,
and
because
of
that,
and
because
the
way
things
are
designed
with
graphql,
when
you
implement
it,
your
server
can
decide
where
to
get
the
data.
So
basically
the
client
and
the
graphql
implementation
have
a
defined
schema,
but
graphql
doesn't
care
about
where
the
data
comes
from.
It
has
nothing
to
do
with
that
same
way.
B
Rust
does
rest,
has
nothing
to
do
with
where
the
data
comes
from.
So
for
graphql
often
is
used
for
what
are
what
are
called
backends
for
front
ends.
So
basically,
let's
say
you
have
you
know
many
different
micro
services
running.
You
can
actually
consolidate
an
api
across
all
of
them.
That's
well
suited
for
the
the
client
that
you're
working
with-
and
that
gives
you
some
some
real
flexibility
and
we'll
talk
about
how
that's
enabled
on
some
server
products
as
well.
On
the
cloud
side.
B
Also
often,
data
is
split
up
among
several
calls,
so
you
may
have
a
very
well-defined
api
and
rest
and
several
different
calls
are
required
for,
like
the
client
to
get
back.
A
particular
set
of
data
also
rest
doesn't
give
you
a
specific
format.
You
know
you
can
send
whatever
you
want
back
and
forth
and
rest
it
can
be
json.
It
can
actually
not
be
json,
so
you
have
a
lot
of
flexibility,
but
because
of
that,
there's
nothing
really
keeping
you
from
sending.
You
know
strange
data
back.
B
So
you
will
see
here
there
is
a
little
client
here,
so
this
is
a
graphql
client
and
generally
left.
Graphql
client
is
going
to
be
very
similar
to
postman.
So
this
one.
Let
me
clear
this
out:
it's
called
altair
and
it
it's
pretty
good.
It's
not
stellar,
but
for
for
graphql
it
actually
isn't
a
lot
better
than
postman,
at
least
the
version
the
graphql
support
I
saw
in
postman.
B
So
so,
let's
start
out
with
a
very
simple
example.
I
will
look
not
at
that
one,
but
this
one
okay
and
altair
will
complain,
but
I
think
we'll
still
be
okay,
okay,
so
on.
Let
me
clear
this
out
on
the
left
here
we
have
a
very
simple
query
and
right
now,
I'm
actually
using
the
github
api
and
github
has
a
very
extensive
api
that
is
all
graphql
based,
which
is
nice.
B
Okay,
so
basically,
what
I'm
doing
here
is
I'm
looking
for
all
of
the
issues.
In
my
own
repository
there's
a
sample
app.
I
have
out
there
called
github
repo
lists
that,
basically
I
just
pulls
a
list
of
repos
and
displays
it
in
a
web
component,
but
for
our
purposes
we're
just
talking
to
github
and
getting
metadata
about
the
repo
right.
So
we
want
to
get
back
the
id,
the
name.
The
issues
total
count,
how
many
stargazers
there
are
and
the
primary
language.
So
if
we
run
this,
we
get
some
data
here.
B
Okay-
and
you
see
we
have
this
data
property,
which
is
usually
the
root,
that's
returned
and
then
all
the
data
coming
back
so
we've
got
the
repository.
We
asked
for
the
name,
the
issue
stargazer
accounts,
all
the
data
we
asked
for
and,
of
course
we
can
specify
the
data.
So
you
know
if
we
got
rid
of
name.
B
B
B
Okay,
so
this
is
pretty
similar
to
what
we
saw
before
right.
We've
got
a
simple
query
at
the
top
here
and
we're
looking
for
a
repository,
we're
getting
issues
from
a
repository
and
this
time
we're
looking
at
the
prime
faces
repository,
but
we've
got
something
a
little
different
here,
we're
looking.
We
actually
are
sending
in
a
filter
into
when
we
specify
what
issues
we
want
and
we're
getting
only
the
open
issues
and
we're
getting
the
first
50..
So
we
get
some
results
in
their
request
and
get
the
result
back
for
that.
B
Okay,
so
notice.
This
is
looking
a
little
bit
different
though
we've
got
the
repository
name
and
we've
got
issues
edges
and
then
the
node
and
the
title.
Okay,
so
we're
basically
getting
a
graph
representation
of
everything
here:
okay,
and
that
is
up
to
the
design
of
the
schema.
So
if
you
don't
want
to
use
edges
and
nodes
you
don't
have
to,
but
that
that's
how
their
api
is
designed.
B
B
B
And
this
is
a
similar
query,
but
you
notice
here
we're
basically
looking
for
issues
for
nodes
of
type
issue.
So
it's
the
same
idea,
but
because
we're
getting
back
nodes
we
need
to
again
specify
the
type
that
we
care
about.
So
we're
getting
issues
back
here:
okay
and
notice.
We've
got
the
whole
body
of
the
of
the
issue
as
well.
B
B
So
you
notice
this
is
very
similar
to
what
we've
seen
before,
but
there's
this
little
dollar
sign
query
thing
here:
okay,
so
this
is
basically
saying
we
are
supporting
a
variable
that
can
be
passed
into
this
particular
query:
okay
and
it's
a
type
string
and
it's
optional,
I'm
sorry!
It's
required!
Excuse
me,
because
if
we
get
rid
of
this
well
first
of
all,
this
is
what
the
variable
looks
like.
We've
got
query
and
circuit
breaker,
okay,
and
if
we
run
it,
we
will
get
the
results
back.
B
So
we're
getting
a
payload
back
or
I'm
sorry.
This
is
the
payload
that's
being
sent,
and
you
see
all
that
all
it's
basically
saying
is
you
know
this
is
the
value
we're
sticking
in
here.
We're
sticking
it
into
this
query
value
and
that's
going
to
be
inserted
into
our
query.
Okay,
so
that's
how
variables
work!
You
can
parameterize
any
query
that
you
want
that
way.
B
So
we've
seen
this
ability
to
specify
properties
based
on
the
type
right,
but
we
can
also
take
any
segment
here
and
actually
throw
it
into
a
fragment.
So
this
is
a
fragment
fragment.
That's
saying
oops:
where
is
it
fragment
repo
fields?
So
this
is
basically
saying
we're
creating
a
fragment
called
repo
fields,
and
we
can
insert
it
into
another
query,
so
this
down
here
is
doing
just
that,
so
it
looks
sort
of
like
the
spread
syntax
in
javascript.
B
Basically
we're
saying
we
want
to
use
a
particular
fragment
so
which
runs
pretty
much
the
way
you
would
expect.
We
get
all
of
the
nodes
back
that
are
of
type
repository.
Okay,
so
you
can
use
fragments
as
well,
and
there
are
also
directives.
So
what
directives
do
is
they
allow
you
to
basically
extend
the
graphql
language?
So
there's
only
two
directives
which
are
included,
there's
include,
which
is
just
a
conditional
and
there's
also
skip
okay.
B
B
You
can
see
that
I
no
longer
have
the
language
being
shown.
Okay,
so
that's
you
know
kind
of
a
useful
directive,
but
the
real
power
of
directives
is.
This
is
that
you
can
create
your
own
directive.
So,
if
you're
implementing
graphql
support
on
the
server
you
can
actually,
depending
on
the
libraries
that
you're
using
you
can
add
your
own
directives,
and
that
can
mean
all
sorts
of
things
so
you'll
find
also
that
some
cloud
services
that
use
graphql
have
their
own
directories
as
well,
so
so
think
of
directives.
B
A
B
See
mutations
so
those
are
called
mutations
in
graphql
and
basically
it's
like
you
would
expect
you
basically
call
or
you
call
a
mutation.
You
pass
in
input
parameters,
okay
and
then
you
get
back
data
and
you
specify
what
data
you
want
to
get
back.
So
usually
you
will
get
something
back.
That
represents
what
you,
what
the
operation
that
you
performed.
B
So
I'm
going
to
create
a
new
issue
in
my
github
repo
and
there
it
is,
and
I've
created
another
a
new
issue
here
called
keto
with
a
title
demo
in
the
body
demo.
Okay.
So
if
I
were
to
go
to
my
github
repo,
I
would
then
find
this
issue
created
because
I
just
did
it
programmatically.
So
so
you
can
create
as
many
mutations
as
you
want.
Just
like
you
can
with
queries,
but
usually
you
know
you
probably
will
have
a
lot
more
queries
than
you
would
have
mutations.
B
So
we
say
so
we
could
say
it's
a
filtering
mid
layer.
We
can
apply
over
data
source
back
end,
that's
a
that's
an
accurate
representation.
I
wouldn't
say
that's
all.
It
is,
but
that's
definitely
a
good
portion
of
what
you
can
do.
So
your
back
end,
you
might
actually
be
returning
all
you
know
a
huge
amount
of
data
but
graphql
the
graphql
layer
can
actually
filter
that
out
and
return
only
what
the
client
asks
for.
So
it
does
give
you
that
ability.
B
Fine,
because
when
you
you
almost
always
are
going
to
be
using
a
graphql
library
on
the
client
and
that
graphql
library
is
going
to
look
at
the
schema
on
this
file,
decide
what
it
can
do
and,
by
the
same
token,
the
server
library
that
you're
using
is
going
to
be
looking
at
the
schema
deciding
what
it
can
accept.
So
so,
usually
they
work
pretty
well
together.
B
And,
of
course,
the
client
can't
request
anything,
that's
not
defined
in
the
schema.
It
can't
make
any
calls
which
are
not
defined
there.
So
it's
very,
very
strict
in
that
way,
and
one
of
the
key
differences
is
that
with
graphql
the
schema
evolution
is
handled
through
deprecation.
So
there's
no
like
version
one
version,
two
version
three
like
there
is
in
the
rest:
there's
really
just
you
know
you
can
deprecate
different
parts
and
to
me
this
is
sort
of
good
and
bad.
B
So
it's
good
in
the
sense
that
it's
easier
to
manage
and
it
matches
pretty
well
what
the
way
we
handle
evolution
in
java,
but
on
the
flip
side,
unless
you
are
very
good
about
you,
know,
handling
those
deprecations
and
then
removing
them
and
making
sure
your
clients
are
aware.
You
can
end
up
with
a
lot
of
deprecated
parts
or
deprecated
queries
or
fields,
etc
that
your
clients
may
still
be
using.
So
so
it's
good
and
bad.
B
So
what
I
want
to
show
you
is
this,
so
this
is
actually
the
schema
for
github,
so
this
is
essentially
what
they
provide
so
and
you'll
notice.
It's
really
huge.
It
is
40
000,
so
they
have
a
very,
very
rich
schema
which
most
organizations
will
not
have
but
they've.
Also,
you
see
they
define
some
directives
as
well.
Okay,
so
they
won
for
preview,
one
for
possible
types.
B
So
every
single
graphql
schema
is
going
to
have
this
sort
of
top
level
element,
it's
not
at
the
top
of
the
page,
but
not
the
top
of
the
file.
But
it's
sort
of
the
entry
point
called
query
and
inside
of
it
you'll
put
all
the
queries
that
you
support
and
you
can
see.
This
is
how
you
do
comments
and
you
basically
can
define
your
own
types.
B
So
if
we
look
at
the
let's
see
if
we
look
at
repository
here,
okay,
this
was
the
repository
query.
We're
looking
at
you
can
specify
the
name
of
the
repository
and
the
owner
and
when
it
returns,
is
a
repository
object
which
looks
like
this
and
you
notice
that
it
is
looks
very
similar
to
you
know
a
lot
of
programming
languages
and
we
actually
can
implement
interfaces.
So
a
repository
is
a
node.
B
It's
a
package
owner
or
a
project
owner
repository
info,
it's
starable
and
it's
subscribable,
etc,
etc,
and
you
can
see
also
we've
got
properties,
assignable
users-
and
you
see
here
we
have
parameters
that
we
can
send
in.
So
whenever
we
request
the
assignable
users,
property
or
senate,
we
use
these
assignable
users
properties.
B
We
can
decide
what
we
want,
so
we
can
get
a
list
we
can
decide
before
or
after
so
this
allows
you
to
do
pagination
and
then
the
query
to
basically
query
against
that
list.
Okay
and
look
for
something
a
little
more
obvious.
So
there's
a
collaborators
right,
so
you
have
a
list
of
the
collaborators
the
affiliations
again,
you
can
do
pagination
and
for
kicks.
Let's
look
at
the
collaborator
affiliation
so
collaborated,
your
affiliation
is
an
enums.
This
is
another
type,
that's
supported
and
enums
look
like
they.
B
B
B
B
B
So
if
we
look
at
one
of
these
you'll
see
that
there's.
If
you
wanted
to
accept
a
topic
suggestion,
this
is
there's
an
input
object.
This
is
basically
what
I
was
talking
about
earlier
and
sent
in
the
sense
of
an
object,
that's
defined
for
accepting
query
parameters
so
or
mutation
parameters
in
this
case.
B
So
we
look
at
this
and
we
see
you
have
to
have
a
mutation
id
a
name
and
a
repository
id
okay
and
you
see
they've
got
basically
their
own
directive
here
saying
this
can
only
be
an
id
of
type
repository
for
the
concrete
type.
So
this
gives
you
an
idea
of
what
you
can
do
by
defining
a
very,
very
well
oiled
schema
that
works
well
for
clients
and
servers.
So
so
that's
that's
the
schema
here.
B
B
However,
if
you're
building
out
the
back
end
first
and
or
if
you
the
same
people,
are
building
front
end
and
back
end,
it's
really.
It
might
work
out
very
well
from
you.
The
key
thing
is
to
make
the
decision
up
front.
You
don't
want
to
be
making
it.
You
know
in
the
middle
middle
of
the
project
or
changing
your
mind,
that's
going
to
cause
a
lot
of
problems.
So
it's
more
upfront
decision.
B
Okay,
so
that
is
all
about
the
schemas.
So
let's
talk
about
subscriptions
so,
as
I
mentioned
before,
subscriptions
are
basically
the
ability
to
push
data
from
the
server
to
the
client
and
to
me
this
is
really
one
of
the
most
compelling
features
of
graphql.
It's
just
that
this
is
pretty
much
built
into
the
spec
as
long
as
you
have
a
as
long
as
you
have
libraries
on
the
front
and
the
back
and
then
support
it,
you're
good
to
go,
and
also
it's
transport
independent.
B
So
there's
no
rule
in
terms
of
the
specification
that
says
subscriptions
need
to
support.
You
know
one
protocol
over
the
other,
however
websocket
is
the
most
common,
so
you'll
find
websocket
is
pretty
much
universal
support
and
other
ones
it
really
depends,
but
I've
seen
you
know
mqtt
ones
for
iot
stuff.
I've
seen
I
think
I
may
have
even
seen
like
jms.
You
could
really
use
any
sort
of
messaging
layer
as
long
as
you
have
support
on
client
server.
B
So
I'll
show
you
a
quick
demo
of
this.
So
what
I've
got
running
here
is
actually
quercus
and
I've
got
a
if
you,
if
you're
not
familiar
with
quarkx.
It
is
a
micro
profile
and
jakarta
e
implementation
that
basically
is
optimized
for
microservices
from
red
hat,
and
I've
got
a
experimental
support
for
graphql
subscriptions
running
here
in
quercus
and
basically,
what
I'm
going
to
do
is
go
over
here
and
I've
got
this
page
running
and
you
see
I'm
just
going
to
hit
connect.
B
B
There
we
go
so
you
see,
we've
got
this
graphql
request
right
and
instead
of
https,
it's
ws,
because
it's
a
websocket
right
and
you
see
here
we're
just
pushing
all
the
requests
in
the
initial
query
is
just
like
you
would
expect.
It
looks
like
a
normal
graphql
query.
So
if
it
has
subscription
right
and
then
here
we're
pushing
the
data
back,
okay
and
all
that's
happening
here,
basically
from
a
from
a
client
perspective-
is
this:
this
actually
uses
this
example
uses
raw
javascript
and
raw
raw
web
sockets.
B
B
So
this
here's
the
query,
that's
being
set:
here's
a
new
web
socket
being
created
and
basically
we're
sending
this
request
here
and
then,
when
we
get
a
message
back,
we're
basically
just
updating
the
display
with
the
message
coming
back,
so
this
actually
doesn't
use
a
graphql
library.
So
this
actually
is
a
good
example
of
how
you
don't
actually
really
have
to
have
a
third
party
library,
if
you
don't
need
to,
but
obviously
the
libraries,
whether
they're
react
or
just
pure
javascript
or
some
other
framework.
B
B
All
right,
so,
let's
talk
about
implementations.
This
is
where
the
the
fun
part
is.
So
there
are
on
the
client
side,
lots
of
implementations.
Basically,
any
language
you
can
think
of.
There
is
a
implementation
out
there,
whether
you're,
using
javascript
or,
if
you're,
using
something
cool
cooler
like
elm
or
rust
or
whatever.
B
There
is
pretty
much
some
implementation.
You
can
use
you'll
find
a
lot
of
projects
we'll
use,
not
apollo
server,
but
they'll
use
the
apollo,
client
side
implementation,
but
there's
there's
tons
of
them
out
there.
So
it
really
just
matters.
You
know
what
what
framework
you're
using
and
what
you're
kind
of
interested
in
on
the
front
end,
but
I
will
say
apollo
is
probably
the
biggest
name
out
there
when
it
comes
to
javascript
both
on
client
and
server
for
for
graphql.
B
B
B
B
A
B
There
we
go
graphqljava.com,
okay,
very
pink,
so
graphql
java
is
a
low-level
api.
So
if
you're
interested
in
using
graphql,
it's
probably
not
the
best
place
to
start
unless
you're
going
to
get
really
really
into
it.
But
it's
the
low-level
api
that
almost
every
other
java
graphql
implementation
is
based.
On
top
of,
there
are
some
exceptions,
but
usually
that's
the
case.
B
B
B
First
I'll
look
at
the
subscription
example,
because
that's
what
I've
got
running
so
so
this
example:
it's
a
normal
normal
java,
app
nothing
special
going
on.
We've
got
an
endpoint.
We've
got
a
model
and
we've
got
a
service
class.
Okay
and
the
palm
is
pretty
straightforward.
Actually,
there's
a
parent
palm
here.
I
believe.
B
Okay,
so
the
parent
palm
basically
is
going
to
be
loading
carcass
dependencies.
You
know
not
a
whole
lot
special
going
on
here,
so
basically,
any
microprofile
implementation
will
do
so.
We've
got
in
here
a
person
endpoint.
Okay
and
again
this
is
the
subscription
implementation.
So
what
you
didn't
see
when
I
was
running
the
subscriptions
was
this:
this
is
output,
so
you
see
it's
still
pushing
out
data.
B
So
if
I
go
back
to
my
client
here,
you'll
see
it's
still
updating
233
here
we've
got
233,
234,
etcetera,
so
basically
the
micro
profile
graphql
implements
excuse
me
integrates
very
easily
with
the
way
any
micro
profile
application
will
be
written.
So
we've
got
this
person.
Endpoint
we've
got
this
graphql
annotation,
which
you'll
need.
B
There
are
some
queries
which
we'll
talk
about
in
a
minute
and
then
there
is
the
subscription
okay,
so
you've
got
subscription
annotation
and
again,
the
subscription
features
are
experimental
for
graphical
mark
from
microprofile
graphql.
Excuse
me
so
take
this
particular
implementation,
or
example
with
a
grain
of
salt.
But
this
is
generally
the
idea
in
the
way
it
would
work.
Pretty
much
in
any
any
any
implementation
you're
using,
so
you
basically
say
subscription
and
you
you
can
see
we're
returning
a
person
added
listener.
B
B
B
B
Does
basically
does
an
operation
every
two
seconds
here
using
this
multi-form
here
and
then
basically
for
each
item,
that's
created,
it
goes
and
creates
a
person
for
each
tic.
Excuse
me,
creates
a
person
and
then
pushes
them
out
essentially
so
so,
basically
we're
just
going
through
and
randomly
creating
different
objects
and
then
pushing
them
out.
B
Okay,
so
here
I
would
just
want
to
get
a
query
of
people
back
right,
so
I
do
this.
I
run
this
and
I
get
my
query.
People
and
what's
happened
with
with
a
microprofile
graphql.
Is
that
we're
essentially
doing
a
code
first,
it
does
not
support
schema
first,
so
it
dynamically
generates
a
schema.
Okay-
and
one
thing
I
forgot
to
show
earlier
was
that
anytime,
you
have
a
schema
which
is
pretty
much
all
the
time
you
get
free,
docs
so
see
here.
B
I
automatically
know
what
the
query,
what
I
can
query,
what
fields
I
can
query
and
then
you
can
see,
I
can
basically
go
through
the
entire
schema.
Okay,
obviously,
for
github
is
a
little
more
interesting,
but
you
basically
can
see
that
this
supports
a
person.
Query,
a
person's
surname,
the
random
number,
all
headers
people
etc.
Okay,
and
what
the
schema
also
allows
you
to
do.
If
you
have
any,
you
know
capable
query
tool,
you
get
code
completion
as
well,
so
let
me
get
rid
of
that.
B
A
B
B
So
if
you
look
at
the
actual
code,
this
is
the
person
graphql
api.
So
this
is
that
location
here,
where
again,
it's
normal
java
class
we're
using
the
graphql
api
annotation,
we're
injecting
our
services
and
we've
defined
some
queries.
We
can
use
the
normal
microprofile
metrics
on
them
as
well,
which
is
handy
because
that's
not
always
the
easiest
thing
to
do
with
graphql.
B
You
can
use
other
annotations
that
are
part
of
a
microprofile
archicad
e
as
well.
Okay,
and
so
this
is
the
get
people
endpoint
that
I
was
just
calling
and
you
notice
it's
just
returns.
It
just
has
a
query,
annotation
right
and
then
returns,
objects
and
graph,
and
the
implementation
automatically
serializes
serialize,
that,
for
you
and
one
of
the
things
you'll
notice,
is
that.
B
B
So
the
way
that
scores
are
sent
back
is
basically
with
another
query,
so
this
source
annotation
basically
says
that
the
scores
property,
the
source
of
it,
is
person.
So,
basically,
if
someone
requests
scores
on
people
on
a
person,
object
is
getting
back.
The
implementation
is
automatically
going
to
return
that
value
from
this
method
as
well.
So
this
allows
you
to
do
more
complicated
queries,
so
you'll
see
also
we've
got
all
the
scores
coming
back
here,
but
this
is
different
because
you're
actually
throwing
in
actually
I'm
sorry.
B
So
we've
also
got
a
mutation
that
we're
calling
as
well
so
I'm
going
to
create
a
new
person
called
keto,
great
name
and
after
I
do
that.
I
can
then
of
course
get
back
that
person.
So
this
is
id11
right.
So
then
I
can
get
back
that
one
person
back
and
what
you'll
see
here.
If
I've
got
four
scores,
I've
got
this
random
exception.
I've
thrown
in
just
for
fun
right.
B
So
let's
say
I
say
the
id
is
zero.
Okay,
I'm
going
to
get
back
an
exception,
so
you
see
here,
I'm
throwing
a
scores
unavailable
exception
right,
but
the
implementation
is
sending
back
this
generic
data
fetching
exception.
Okay
and
it's
happening
because
it's
sort
of
obfuscating
the
error
and
you
can
configure
a
micro
profile
graphql
to
us
return
the
real
exception.
If
you
want
to
you
notice,
also
that
down
here,
it's
returning
the
actual
data.
So
one
of
the
key
things
here
is
that
you
can
actually
return
partial
data
sets
with
graphql.
B
So
if
there's
an
error,
you'll
get
that
first,
but
you
can
also
return
data
back
so
that
that
helps
in
situations
where
you've
got.
You
know
multiple
data
sources
you're
talking
to
maybe
one
is
down
or
not
available.
You
can
still
return
the
data.
That's
available
back
to
the
client.
The
client
can
decide
if
it
wants
to
just
move
on
or
not,
or
you
know,
display
or
work
with
the
partial
data.
B
Okay,
all
right,
so
we've
got
a
question
here:
does
graphql
fetch
only
required
filter
data
from
db
or
against
entire
record
document
and
filters
before
sending
it
to
the
client
yeah
so
by
default?
Think
of
it
this
way,
graphql
doesn't
care.
Graphql
doesn't
really
care
what
you're
you
know
how
you're
getting
data
all
it
knows
is
that
when
it
gets
the
data
itself,
it's
only
going
to
it's
going
to
do
the
filtering
for
you,
okay.
B
So
in
this
example
you
see,
we've
got
the
we're
returning
the
entire
person
object
or
a
list
of
persons
right
now.
If
we
wanted
to,
we
could
get
a
better
handle
on
the
query,
get
more
and
more
metadata
about
what
the
occurring
is
and
return
only
certain
fields
from
the
database
generally.
That's
not
what
you
do,
though.
B
Generally,
you,
you
kind
of,
are
you
know
you
take
the
simple
approach
and
just
grab
the
data
and
then
let
graphql
do
the
filtering
for
you,
but
you
could,
if
you
wanted
to
be
a
little
smarter
about
it
and
usually
what
you'll
find
in
situations
like
that
is
that's
where
you
kind
of
need
to
go
down
to
the
the
actual
api
of
graphql.
So,
for
example,
down
here,
we've
got
the
ability
to
observe
parts
of
the
low
low
level
api.
B
B
Okay,
so
in
terms
of
the
demo,
I
think
that's
pretty
much
it.
You
can
see
it's
pretty
straightforward.
It's
like
you
know,
writing
a
rest
service.
Essentially
when
it
comes
to
the
the
implementation,
obviously
there's
more
stuff
you
can
do,
but
this
is
the
basic
idea.
Is
you
basically
just
write
methods
use
annotations
and
the
graphql
implementation
takes
care
of
more
of
the
work
of
parsing
the
query
and
passing
you,
the
right
data
and
all
that
kind
of
fun,
stuff.
B
Okay,
so
let's
move
on
there's
also,
if
you
are
in
spring
camp,
there's
a
spring
graphql
implementation
which
just
came
out
and
actually
well
1.0,
just
came
out
relatively
recently,
and
it's
very
full
featured
as
well
on
the
server
side
for
node.
Apollo
server
is
probably
going
to
be
your
your
most
popular
choice
and
there's
also
an
apollo
federation
feature
which
allows
you
to
basically
federate
multiple
graph
graphql
apis
together,
which
can
be
useful
in
larger
organizations.
B
B
Graphql
is
an
api
layer,
so
it
doesn't
care
about
the
database
at
all.
All
it
cares
about
is
the
ability
to
send
the
process,
queries
and
send
queries
back
and
forth.
So
so
graphql
is
database
data
agnostic,
whereas
jdbc
is
specifically
about
talking
to
relational
databases.
So
hopefully
that
helps.
B
All
right,
here's
another
question:
just
oh
wait!
Actually
we
already
answered
that
one.
So
someone
just
reposted
the
question
about
fetch
only
required
data,
and
my
answer
to
that
was
that
the
graphql
doesn't
care
what
data
you
request,
but
it
will
do
the
filtering
for
you.
So
if
you
turn
an
entire
object
or
entire
set
of
objects,
it
will
do
the
filtering
for
you
before
it
sends
it,
and
if
you
want
to
do
additional
filtering
before
you
return
data,
then
you've
got
to
do
that
yourself.
B
B
Swift,
et
cetera,
et
cetera,
so
lots
of
great
tools
out
there
and
a
lot
of
these
you
can
find
on
graphql.org.
So
it's
a
good
place
to
start
on
the
database
side.
You
can
imagine
that
any
graph
database
is
going
to
very
likely
provide
a
graphql
interface,
so
anything
any
database.
That's
usually
used
for
you
know
in
representing
graphs.
Almost
always
will
have
the
abilities
to
support
graphql
out
of
the
box,
and
I've
been
looking
at
neo4j,
which
has
some
great
stuff
in
there
for
supporting
graphql.
B
And,
as
you
can
imagine,
since
graphql
is
really
well
suited
for
being
a
back-end
for
front-end
for
being
essentially
a
an
api
that
consolidates
several
data
sources
that
it's
also
becoming
a
very
popular
choice
for
service
providers
for
for
cloud
providers.
So
so
aws
appsync
actually
does
this.
So
you
can
configure
a
graphql
api
that
talks
to
different
aws
data
sources,
including
dynamodb.
B
So
why
would
you
not
want
to
do
graphql
so
so
nothing's
perfect
right,
so
some
of
the
benefits
are
also
drawbacks
right.
You
know
you
can't
just
write
an
endpoint,
you
have
to
actually
do
the
schema
or
you
have
to
do
schema
first,
I
mean
sorry
code.
First,
where
you
write
the
code
first
and
then
generate
generates
the
schema
automatically.
B
B
Also,
I
have
no
specs
or
no
benchmarks
saying
graphql
is
slow
or
anything
like
that,
but
there
is
additional
overhead,
because
all
that
parsing
of
the
query
and
filtering
the
results,
that's
something
that
is
happening.
So
if
your
your
requirements,
don't
need
all
that
then
you're,
adding
additional
overhead
and
complexity
which
may
not
be
necessary.
B
B
So
that's
something
to
keep
in
mind
and
rest
is
simple,
easy
to
get
started,
it's
better
to
suited
for
read
only
or
low
data
api.
So
you
know
if
you
just
are
basically
sending
a
whole
bunch
of
post
requests
to
update
something,
there's
no
reason
to
use
graphql
a
graphqreal
is
really
well
suited
for
for
getting
a
lot
of
data
back
and
also
for
the
subscription
stuff
and
also,
if
you
don't
want
json
for
format-
and
you
want
to
use
someone
did
some
other
data
format.
A
A
Yes,
no,
we
definitely
do
so.
Thank
you
for
that
excellent
presentation.
Today,
keto
and
just
a
reminder
if
anyone
in
the
audience
does
have
any
final
questions,
there's
two
areas
where
you
can
post
them,
you
can
put
them
in
the
chat
section
or
you
can
post
it
in
the
ask
a
questions
tab,
while
I
wrap
up
so
again
just
wanted
to
highlight
the
next
jakarta
tech
talk
happens
on
june
28th
and
it's
the
jakarta
ee10
release
celebration,
so
you
can
register
for
that
session
using
the
link.
I
will
be
posting
shortly
in
the
chat.