►
From YouTube: GraphQL for Java Developers
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 back-end exposed the data, but the client could decide which subset of data it needed, or 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. In this talk, we’ll explain what GraphQL is, how it works, and look at a JavaScript client and a Java back-end.
A
Hello,
everyone
and
welcome
to
another
Jakarta
Tech
talk.
My
name
is
Serena
joining
us
today
is
Quito
man
who
will
be
presenting
on
the
topic
of
graphql
for
Java
developers.
If
you
have
any
questions
for
ketos,
you
move
through
today's
presentation
feel
free
to
ask
them
in
the
chat
or
in
the
ask
a
questions
tab
without
any
further
delay.
Keto
over
to
you.
C
B
So
hi,
my
name
is
keto
and
I'm
gonna
be
talking
today
about
a
graphql
and
we're
going
to
be
talking
about
it
from
sort
of
an
intro
perspective.
So
if
you're
a
graphqrell
expert,
this
may
not
be
a
video
for
you,
but
if
you've
worked
with
it
or
if
or
you're
familiar
with
it
or
you've
heard
about
it,
you
want
to
learn
more
about
it.
This
is
a
good
place
for
you
to
start.
C
B
A
B
So
it's
sort
of
a
full
stack,
a
team,
a
lot
of
cloud
stuff
as
well,
and
some
mobile
I'm,
a
Java
Champion
I
I
used
to
be
very
heavily
involved
in
the
Java
Community
process
in
some
of
the
specs
like
a
CDI
and
JSF
and
portlets,
and
now
that's
really
morphed
into
being
involved
with
Jakarta
ee
and
I'm,
a
member
of
the
Jakarta
ee
Guardians
and
a
Google
developer
expert
in
web
Technologies
alumni
that
I
just
ended
my
time
with
that
program
recently.
But
it's
a
great
program
I'm.
B
Also
the
co-host
of
a
podcast
called
the
stack
podcast,
which
me
and
a
three
other
awesome
hosts
Josh
Gino,
Daniel,
inaosa
and
Ian
labitz.
We
all
spend
time
talking
about
Java
Enterprise
development,
front-end
development,
angular,
back-end
stuff.
We
also
usually
have
great
guests
on
as
well,
so
we
have
a
lot
of
java
Champions
on
and
lots
of
other
people
in
the
community.
B
So
if
you
like
podcast
I,
encourage
you
to
check
that
one
out,
I
speak
a
lot
to
conferences
and
I'm,
also
also
working
on
a
new
product
called
speaker
tracks,
which
is
a
product
for
frequent
speakers
and
we
happen
to
be
using
graphql,
so
I'll
just
be
demoing
when
we
go
through
the
graphql
demo,
part
I'll
be
showing
some
speaker
track
stuff,
but
if
you're
a
frequent
speaker,
you
should
check
that
out.
So
that's
the
story.
There.
B
So
I
wanted
to
get
a
handle
from
the
audience
about
you
guys.
So
if
you
could
tell
me
put
in
the
chat
sort
of
if
you're
really
familiar
with
graphql
okay,
if
you
work
with
it
a
lot
or
if
you
you're
new
to
graphql
or
you're,
just
curious
about
it,
sort
of
what
you'd
like
to
get
out
of
this
session
today.
So
if
you
feel
that
in
the
chat
I
appreciate
it.
B
Okay
got
a
couple
responses.
Okay,
so
someone
says
they're
Jen
says
they
read
about
it.
They're
curious
Mark,
says
nudograph
well,
Alex
says
nudograph
well,
shurti,
says
Novus,
just
common
knowledge
and
Dennis
says
curious
about
graphql,
mostly
rest
in
grpc,
okay
cool
sounds
like
we
got,
got
a
good
mix
there
and
just
the
right
kind
of
audience
for
this.
So
okay,
so
what
exactly
is
graphql?
B
It
is
basically
an
alternative
way
to
do.
Client
server,
Communications
we've
been
doing
client
server
communication
for
years,
I,
remember
doing
it
in
the
early
days
with
Windows,
and
you
know
having
a
fat
client
talking
to
a
database
that
was
client
server
back
then,
but
you
know
now
there's
lots
of
different
approaches.
B
We've
tried
different
ones
over
the
years
and
rest
is,
of
course,
the
most
popular
one,
but
you
can
just
think
of
graphql
as
another
way
for
your
client
to
talk
to
your
server,
and
this
is
a
very
simple
example.
On
the
left
hand,
side
there
is
the
request,
so
the
client
is
basically
saying
I'm
a
hero
or
give
me
a
hero,
and
for
that
hero
just
give
me
one
name
property.
B
That's
all
I
want
back
I,
don't
want
any
other
data
now,
on
the
right
hand,
side
there
is
the
actual
data
coming
back
with
the
hero
element
and
then
also
the
name
property.
So
it's
giving
exactly
what
was
requested.
Give
me
the
hero,
give
me
the
name,
so
that's
basically
the
the
idea
of
graphql.
In
a
nutshell,
it's
basically
having
the
clients
request
what
it
wants
and
have
the
server
send
it
back
foreign.
B
B
So,
regardless
of
what
you
think
of
Facebook
in
general,
they
they
have
some
great
technology
and
graph
Growers
was
open
sourced
in
2015
and
in
2017
the
graphql
foundation
started,
and
the
graphical
foundation's
job
is
basically
to
store
graphql,
as,
as
you
know,
specification
and
different
implementations
and
all
that
kind
of
fun
stuff
and
it's
actually
used
by
lots
of
different
companies.
So
if
you
go
to
graphql.org
you'll
find
this
this
list
of
all
these
different
companies
and
a
lot
of
names
that
you
recognize
like
Lyft
Twitter.
B
B
So
there
are,
of
course,
some
benefits
and
one
of
the
one
of
the
benefits-
and
this
is
also
one
of
the
key
differences-
is
that
there's
a
single
Consolidated,
Dynamic
endpoint.
So
you
don't
have
to
like
remember
all
these
different
URLs
and
do
different
things
as
a
client,
and
you
don't
have
to
build
that
out
as
a
develop
as
a
server
developer.
B
There
is
this
idea
of
subscriptions,
which
is
really
one
of
the
best
features
of
graphql,
which
is
basically
the
idea.
The
ability
to
say,
hey,
I
am
interested
in
this
data
and
these
properties
of
this
data,
just
like
a
normal
graphical
query,
but
I
want
to
be
notified
when
that
data
changes.
So
basically
it's
a
push
protocol.
So
that's
a
nice
feature,
but
for
day-to-day
use,
one
of
the
key
benefits
is
that
it
has
a
defined
data
format.
B
So
all
graphql
requests
look
a
certain
way,
they're
in
a
certain
format
and
then
for
any
given
application.
You're
Building
you
basically
Define
define
the
schema
for
that
actual
application.
So,
as
opposed
to
arrest
where
you
sort
of
you
can
you
know
if
you're,
if
you're
disciplined,
you
can
build
out
stuff
using
an
open,
API
and
have
you
know
robust
apis
which
are
well
defined,
but
with
graphql
you
don't
have
that
choice
like
you
have
to
do
that.
B
You
have
to
have
a
type
schema
and
it
has
to
you
know,
be
integrated
into
your
back
end
and
your
front
end
has
to
use
it.
So
it's
a
little
more
rigid
in
that
respect,
whereas,
with
with
rest,
you
you
can
use
open
API,
but
you
don't
have
to.
You
could
just
write
an
arrest
endpoint,
so
it's
obviously
quicker
to
get
started
in
some
ways,
but
you
have
a
lot
more
rigor
when
it
comes
to
the
the
interface
between
the
client
and
the
server
for
graphql.
B
B
B
Is
you
end
up
either
creating
different
endpoints
that
have
different
subsets
of
data
or
parameterizing
it
so
that
you
can
return
different
amounts
of
data
depending
on
what
what
the
client
wants,
but
with
graphql
it's
a
little
nicer,
because
it's
sort
of
built
in
that
the
client
decide
what
decides
what
it
wants.
So
the
client
says:
Okay
I,
want
you
know
these
objects
back.
B
I
want
these
properties,
and
the
server's
job
is,
of
course,
is
decide
where
to
get
it,
but
it
doesn't
have
to
worry
about
creating
different
endpoints
or
different
parameters
in
order
to
filter
the
data.
That's
returned
that's
handled
by
the
graphql
engine
itself,
so
it's
one
of
the
nice
benefits
and
because
of
this,
it's
actually
well
suited
for
back
ends
for
front
ends
or
BFFs.
B
So
that's
the
idea
where,
basically,
you
have
a
special
API
which
is
designed
more
for
the
front
end,
and
then
you
may
have
several
different
back-end
services
that
basically
feed
into
that
API.
So
you'll
find
companies
that
have
like
a
graphql
API,
but
behind
it
there
have
dozens
of
microservices
or
you
know
even
more
than
that,
and
they
all
feed
into
the
to
the
graphql
API.
B
And,
of
course,
you
know
one
of
the
main
reasons
that
graphql
was
created
to
was
to
address
some
of
the
drawbacks
of
rest,
and
that's
some
of
the
things
I
mentioned
where
the
endpoint
decides
what
data
is
returned.
The
data
sometimes
requires
several
different
calls
to
get
the
data
back,
and
the
format
really
depends
on
what
the
server
you
know
is
actually
using
what
they
decide
to
use.
So
you
don't
have
any
particular
rules
about
what
the
format
is
and
that
kind
of
stuff,
so
you
know
usually
graph,
usually
with
rest.
B
You
return
Json,
but
you
don't
have
to.
You
can
still
use
rest
and
return
XML
right,
but
with
graphql,
it's
more
rigorous.
You
kind
of
have
to
return
graphql,
which
usually
is
returned
as
Json
so
and
of
course,
rest
doesn't
have
a
push
standard,
so
you
can
of
course
do
push
it
in
an
application
that
uses
a
rest,
but
there's
no
like
there's
no
standard
for
that
built
into
rest
itself.
B
B
B
So
it's
available
as
a
an
extension
like
this
or
also
as
an
electron
app,
but
you
can
also
use
other
tools
and
there's
also
one
I'll
show
you
later,
which
is
usually
embedded
inside
of
applications.
It's
a
little
react
app.
So
this
isn't
the
only
one
there's
other
options
as
well,
but
it
pays
usually
to
have
a
tool
that
has
specific
graphql
support,
foreign
okay.
So
what
I'm
going
to
show
here
get
rid
of
that?
This
is
a
very
simple
query.
B
And
this
is
basically
github's
graphql
API,
so
GitHub
has
a
very
extensive
graphql
API,
which
is
really
handy
for
obviously
query
and
GitHub,
but
also
for
dimmer
and
graphqls
features,
and
so
I'm
just
going
to
make
a
simple
request
here
and
look:
oh
I've
got
bad
credentials
and,
as
I
was
doing,
this
I
was
just
thinking.
You
know
didn't.
C
B
C
C
C
B
C
C
B
B
Okay,
no
questions.
Okay!
So
thank
you
for
bearing
with
me
all
right,
so
we
now
have
an
API
key,
so
we
can
actually
do
the
demo
and
what
you'll
see
here
is
I've
got.
This
query
probably
had
some
time
to
look
at
it
and
basically,
what
I'm
saying
is
I
want
all
of
the
issues
that
I
from
this
particular
repository
called
GitHub,
keto
list
or
GitHub.
Repo
list.
B
Excuse
me
and
I
want
to
get
back
only
the
IDE
name,
the
issues,
the
total
kind
of
issues,
the
stargazers
people,
the
number
of
people
who
started
the
primary
language
and
the
name
Etc.
That's
all
I
want
back.
So
this
is
when
I
get
back
on
on
the
right
hand
side
here
from
now,
if
I
didn't
want
all
this,
like,
let's
say:
I,
really
don't
care
about
the
issues
right
I
could
just
do
this
and
then
I
get
a
different
amount
of
data
back.
B
B
Is
this
is
one
of
those
days?
You
know
I
do
a
lot
of
presentations,
so
sometimes
everything
goes
perfectly.
Sometimes
it's
a
little
bit
Rocky,
but
Okay.
So
we
here
we're
getting
all
the
data
back.
We
get
to
pick
what
we
want,
and
this
is
the
basic
idea
with
graph
Grill.
So
you
can,
you
know,
decide
what
you
want
to
get
back
now.
B
B
B
So
this
is
basically
just
the
data
that
you're
seeing
on
the
right
hand,
side
I'm
on
the
left
hand
side.
So
so,
basically,
you
know
it's
pretty
straightforward
from
a
data
perspective,
you
don't
you
know
if
you're
working
with
a
graphql,
you
don't
have
to
use.
You
know
cool
graphql
apis
to
do
things
you
can
actually
just
use
ordinary
post
request
responses,
but
obviously
having
the
apis.
Having
libraries
makes
your
life
a
lot
easier,
but
this
is
basically
what's
going
on.
C
B
C
B
C
B
B
and
then
what
the
API
will
return
is
a
set
of
edges
and
then,
which
is
essentially
in
nodes
and
from
that
I
can
gather
whatever
properties
I
actually
need.
So
a
lot
of
apis
will
provide
this
sort
of
graph
based
API.
You
don't
have
to
do
it
this
way.
You
could
return
issue
objects
directly,
but
this
is
sort
of
a
generic
way
that
they
do
it
for
GitHub.
So
if
I
do
a
query
here,
let
me
again
change
my
header
over
here.
B
B
So
you
see,
we've
got
the
data
coming
back
here.
We've
got
a
repository,
the
name
of
the
repository
and
then
the
edges,
and
for
each
one
we
have
a
title
so
value
attribute
TV
Dragon
dropable
Etc.
So
these
are
all
the
different
issues
coming
back
from
the
Department
faces
repository
now,
of
course,
if
we
change
this,
we
would
get
different
values.
B
So
if
we
change
is
supposed,
we
would
get
a
different
value
back
right
and
then,
if
we
change
this
to
Foo,
what
would
happen
get
a
narrow
back,
so
graphql
actually
has
built-in
error
handling
and
you
can
see
what
it's
saying
here
is
that
you
know
on
line
five
column.
One
argument
States
on
input,
object
issues.
Filters
has
an
invalid
value
Foo.
We
expect
the
type
issue
State.
B
This
is
where
all
of
the
strong
typing
and
stuff
comes
in,
because
essentially
the
input
object
has
properties
and
it's
type
It's,
actually
an
enum
type
and
obviously,
if
you're
sitting
in
the
wrong
value
so-
and
this
error
handling
is
basically
what
the
graphical
engine
is
going
to
be
sending
back
by
default.
So
what's
nice
is
that
this
happens
before
it?
Actually
gets
to
your
code.
C
B
B
Essentially
it's
what
behind,
what's
behind
any
search
that
you
do
on
the
site,
sort
of
a
global
search
and
so
we're
doing
the
query
string
and
we're
telling
the
type
that
we
want
to
get
back
and
then
how
many
rows.
So
what
we
do
is
we
get
this
type
and
then
we
can
say
well.
If
the
type
is
repository,
we
want
these
fields,
we
could
get
back
a
different
type
and
if
that
were
the
case,
we
could
specify
those
fields
as
well.
B
C
B
Okay,
so
we
get
we're
so
doing
a
search
for
all
graphql
Java
repos
right
and
we
get
to
this
list
back.
We
have
graphql
Java,
graphql,
Java,
Kickstart
I'm,
a
graphql
code,
generator
Etc,
so
we're
getting
back
all
these
properties
and
again,
if
we
didn't
want
all
this
data,
we
could
just
specify
what
we
wanted.
Now,
if
we
did
something
else
like
say
type
issue,
let's
see
what
happens
now.
B
B
B
B
Parameterize
things
a
bit
so
you
see
here,
we've
got
we're,
have
a
query,
we're
calling
it
repos
and
then
we're
parameterizing
our
query
we're
sitting
in
a
string
and
this
string
is
essentially
a
variable
which
we
are
sending
in
here.
So
in
your
client-side
code,
whether
your
client
signing
code
is
in
Java
or
typescript
or
JavaScript
or
whatever
you
can
parametrize
a
particular
query
this
way
and
then,
in
the
actual
query
itself,
this
this
value
is
being
used.
So
we
want
this
to
be
circuit
breaker.
B
C
B
Like
I,
don't
know,
it
means
add
some
peanuts
for
a
snack
last
night.
That's
what
came
to
my
brain
so
see
see
what
what
repositories
are
in
amp
nuts,
that
so
of
course,
I'm
GitHub
many
repositories
called
peanuts
so
and
you
can
see
what
language
they're
in
etc,
etc.
So
so
there
we
go
so
that
that's
how
variables
work,
and
obviously
you
know,
when
you're
writing
code
to
make
graphql
queries.
It
helps
to
be
able
to
parameterize
things
for
yourself.
B
B
And
then
we'll
finally
get
rid
of
this
once
and
for
all
so
the
this
example
here
you
saw
this
earlier,
where
we
did
a
query
and
then
we
basically
said
okay,
if
it's
a
repository
do
this,
you
know
these
are
the
properties
we
want.
You
can
actually
pull
things
out
in
the
fragments.
This
is
sort
of
an
inline
fragment,
but
you
can
actually
do
it.
B
This
way
where
you
say
okay,
this
is
a
fragment
and
I
want
to
be
able
to
reuse
this
section
so
anytime
that
I
am
working
with
the
repository
I
want
to
grab
these
properties
and
then
what
you
can
do
is
reuse
it
this
way.
So
you
can
see
here.
We've
got
repo
fields
which
we
could
then
reuse
in
different
places.
So
so
this
should
look
pretty
much
with
a
credentials
problem.
B
B
B
Actually,
there's
a
couple
more
things,
so
one
other
thing
that
is
important
to
to
understand
are
directives.
So
directives
are
an
extension
point
to
graphql.
So
basically,
it's
just
a
way
to
do
different
things.
Over
and
above
what's
built
in
there's
a
couple
built-in
directives.
I
want
to
give
you
an
idea
about
how
it
works,
so
here
I
have
a
variable
that
I'm
using
called
shill
language
and
I'm
passing
that
in
and
then
what
I'm
doing
is.
C
B
B
Directive,
which
is
if
or
include
I,
should
say,
and
then
another
directive
is
Skip,
which
is
the
same
idea.
You
can
skip
a
section
based
on
some
condition,
so
there's
two
very
simple
directives,
but
what
you'll
find
is
the
different
graphql
implementations.
This
would
be
on
the
server
side.
We'll
have
different
different
directives
that
they
may
support.
You'll
also
find
that
in
situations
where
you're
using
a
graphql
service
I'm
going
to
talk
about
some
of
those
later,
they
may
have
different
directives
as
well.
So
it's
basically
just
an
extension
point.
B
B
So
this
is
a
mutation
and
a
mutation
looks
surprisingly
similar
to
a
query
right,
but
you'll
see
that
we
basically
are
usually
and
almost
in
most
cases
you
are
actually
you
know
sending
in
some
input
objects
because,
obviously
with
it
with
the
mutation
you're
sending
in
data,
you
want
to
persist.
So
you
want
to
need
to
be
able
to
send
that
data
in
and
you
send
it
in
with
an
input
object.
B
B
Okay
and
interestingly,
what
do
we
get
back
here?
What
we
get
back
is
a
this
data.
That's
requested
here.
So
when
you
do
a
mutation,
you
usually
do
get
the
object
back
that
you
create
and
from
there.
Of
course,
you
can
specify
what
what
properties
you
care
about.
Okay-
and,
of
course
I-
could
say,
I,
don't
care
about
these
properties
and
then
not
get
them
back,
but
it's
usually
it's
useful
to
get
the
object
back
that
you
created-
and
this
is
what
we're
seeing
here
is.
B
B
Sometimes
you'll
find
this
is
useful
for
additional
error
handling
things
like
this,
so
so
this
is
how
it
works,
and
what's
nice
is
that
you
can
actually
see
what
happened.
So
this
is
my
this.
Is
that
repo
that
ID,
that
I
put
in
here
this
is
a
demo
I
use
in
a
different
project,
a
different
talk
and
there's
my
issue
so
I
created
this
hello
from
Jakarta
Tech
talks
issue
and
there's
a
demo
there's
the
data?
Okay.
B
B
B
B
So,
unlike
rests
where,
usually
you
have,
like
you
know,
version
one
version,
two
of
the
endpoints
Etc,
the
graphic
value
we
handle
it
with
just
using
a
deprecation
flag
for
different
properties.
You
don't
want
to
support
anymore
and
of
course,
eventually
you
remove
them
and
I
think
that's
sort
of
a
good
thing
and
a
bad
thing.
It's
a
little
bit
easier
to
work
with,
but
then
again
it's
always
hard
to
get
people
to
remove
deprecated
code.
So.
B
C
B
Okay,
so
let's
look
at
it,
look
at
a
demo
of
a
schema
and
what
I've
got
here
is
the
graphql
schema
from
GitHub,
which
is
the
same
one.
We
just
looked
at
I'm
assuming
this
is
big
enough.
If
anyone
can't
see
this,
let
me
know
and
I'll
bump
up
the
size
a
little
bit
so
so
this
is
the
GitHub
schema
and
you
notice
it
is.
Let's
see.
B
B
So
first,
each
scheme
is
going
to
have
sort
of
a
top
level.
Query:
okay
and
that's
what
we
have
here
and
you
can
see:
we've
got
like
the
code
of
conduct.
We've
got
all
the
different
properties
you
might
expect
and
there's
also
this
documentation
here.
So
this
is
a
comment,
and
this
is
useful,
because
this
is
also
how
you
document
your
API
so
sort
of
like
with
open
API.
B
C
B
Actually
we're
looking
at
a
couple
things
we're
looking
at
search
and
actually
looking
at
repository.
So
so
this
is
the
repository
query
had
the
name
and
the
owner.
Okay,
and
this
returns
a
repository
object
and
the
types
are
pretty
similar
to
what
you
might
expect.
So
you
can
have
different
types
which
is
sort
of
like
an
interface,
and
then
you
can
also
Implement
things
which
are
actual
interfaces
so
so
sort
of
like
the
type
is
like
a
concrete
type
and
an
interface
is
something
you
can.
B
You
know
Implement
in
different
types,
but
the
main
difference
is
that
obviously
there's
no
other,
you
know
there's
no
other
properties
or
anything.
It's
just
the
types
that
are
in
here.
It's
just
essentially
saying
these
are
the
properties,
and
these
are
the
types
that
they
require.
So
repository
implements
node
package
package
owner
all
these
different
things.
Okay-
and
these
are
all
the
different
properties
that
it
can
have,
and
you
see,
there's
also
primitive
types
too.
So
Boolean
is
a
primitive
type.
Okay
is
the
Prototype.
C
B
B
B
B
B
B
B
So
we
saw
the
top
level
query
object,
there's
also
a
top
level
mutation,
which
is
the
same
sort
of
deal,
but
almost
every
mutation
is
going
to
take
an
input
object.
An
input
object
is
just
a
special
type
that
only
has
input
Fields
And.
If
you
look
at
this,
we'll
see
that
it
just
has
different
properties
that
you
specify.
So
when
you
add
a
comment,
you
need
to
specify
the
body
you
don't
have
to
specify
these
things
or
the
client
mutation
ID,
but
you
need
to
specify
the
subject
ID.
B
B
B
So
for
this
endpoint
I
didn't
click
on
this
before,
but
there's
this
little
docs
thing:
okay
and
if
I
refresh
this
will
give
me
documentation
for
all
the
GitHub
endpoints
or
the
GitHub
queries
and
mutations
I
should
say
so.
This
has
all
the
ones
where
we
just
looked
at
so
we
saw
query
and
we
saw
all
of
these-
and
you
see
these
are
the
comments
that
we
have
here
and
then,
of
course,
you
can
go
through
look
at
the
different
objects
just
like
we
did
before.
B
Okay,
so
because
we
have
that
defined
format,
we
can
then
write
tooling
to
make
our
lives
easier.
The
other
thing
that
we
get
from
the
schema
is
the
ability
to
do
co-completion
in
the
query.
So
I
didn't
show
this
before,
but
I
could
have
just
gone
like
this
and
discuss
it.
Try
and
find
what
property
to
throw
in
here.
B
B
Okay,
but
I
wanted
to
get
me
log
in
for
all
the
editors
and
so
having
the
schema
makes
it
really
easy
for
the
client.
You
know
for
your
free
to
generate
queries
and
also
really
easy
to
document.
What's
going
on
as
well,
which
is
nice,
okay,
so
I
made
that
change,
and
then,
when
I
and
when
I
get
back
are
additional
properties
as
well.
B
C
B
So,
there's
a
few
different
design
approaches
when
it
comes
to
building
out
schemas.
One
is
the
schema
first
approach,
which
is
basically
where
you
work
on
building
out
a
document
like
the
one
I
just
showed
you
and
you
build
it
out,
using
it
by
hand
with
some
good
tooling
and
and
then
from
that
you
can
generate
code.
B
You
can
generate
models
for
front
end
and
back-end
and
in
pretty
much
any
language
you
want,
but
of
course
with
Java
or
typescript
or
JavaScript
Etc
and
and
then
you
work
from
that,
and
that's
that
approach
is
really
good.
When
you
are
working
out
what
the
schema
is
with
like
two
different
teams,
so
you
can
basically
hammer
out
what
this
schema
is
like
and
put
an
even
in
a
different
repo
and
then
generate
code
from
that
and
that
works
out
really
well.
B
In
that
scenario,
another
common
scenario
is
code
first,
which
is
where
you
write
the
backend
code
and
the
backend
code
generates
the
schema
for
you
and
that's
often
what
you
see
in
a
lot
of
projects,
because
it's
a
little
bit
easier
to
get
started.
You
can
just
start
writing
code
and
generate
the
schema,
so
it's
a
little
bit
less
work.
B
You
still
may
end
up
generating
the
models
on
the
front
end
from
the
schema,
depending
on
how
you
do
things,
but
it's
it
gives
you
sort
of
a
more
code-oriented
approach
to
things.
The
main
idea
is
just
you
know,
decide
what
you're
doing
up
front
based
on
your
team
and
your
needs
and
sort
of
stick
with
it.
It's
going
to
be
hard
to
switch
later
on.
The
other
thing
is
that
a
lot
of
tools?
Don't
support,
schema
first.
B
Okay,
so
another
piece
are
subscriptions
subscriptions
subscriptions,
let
you
push
data
from
it
from
a
client
to
the
server
and
what's
nice
about
them,
is
that
they're
transport,
independent,
meaning
that
you
know
the
the
the
way
you
write
the
client
server
doesn't
depend
on
how
they
actually
interact
on
over
the
wire.
So
websocket
is
the
most
common
protocol,
but
there
are
other
ones:
there's
lots
of
different
messaging
protocols,
there's
even
in
mqtt,
which
is
popular
for
iot.
B
So
so
it's
nice
because
you
can
kind
of
build.
You
build
your
application
and
then
you
know
pick
the
the
transport
mechanism
that
work
that
works
best
and,
of
course,
the
caveat
there
is
that
websocket
is
almost
universally
supported,
whereas
the
other
ones
are
less
common.
So
obviously,
if
you,
if
you
need
a
particular
transport
that
may
again
impact
the
library
that
you
use.
B
B
B
Okay,
so
implementations
I'm
going
to
do
a
really
really
quick
demo.
Just
so
you
see
some
actual
code
and
what
I
will
tell
you
is
that
there's
pretty
much
Universal
support
for
for
graphql
on
the
client
side.
Apollo
is
the
most
popular
client
Library
I'm
apologize
company.
That
is
basically
the
graphql
company.
B
So
they've
got
a
really
powerful
graphql
client
sort
of
a
react
first
client,
but
they
do
have
support
for
other
Technologies
as
well.
Apollo
elements
is
what
I
like
it's
it's
web
components
for
angular
for
graphql,
but
and
you
can
use
it
with
any
Library.
You
want,
but
obviously
web
components
work
best
and
there's
lots
of
other
ones.
On
the
server
side
there
for
Java
world
there's
graphql
Java
tools
which
is
sort
of
a
lower
level
Library,
which
you
can
integrate
in
any
server-side
application.
B
You
know
using
rest
or
servlets
or
whatever,
and
so
it's
sort
of
it's
a
handy
tool.
It's
really
good
for
doing
schema
first,
support,
which
is
nice,
there's
also
dgs
framework,
which
is
a
powerful
framework
from
Netflix
and
it's
more
of
a
spring
boot
oriented
framework,
but
that's
available
as
well.
B
Mr
micro
profile
graphql
and
that
one
supports
Federation
I,
will
say,
there's
macro
profile
graphql,
which
is
what
I'll
be
looking
at
today,
and
that
is
basically
just
an
implementation
of
graphql
that
works
on
top
of
jakarti,
EE
and
macro
profile,
using
on
top
of
Jakarta
rest
well,
not
really
Jakarta
rest,
but
on
top
of
all
the
other
micro
profile,
stuff,
CDI
Etc.
So
so
that's
a
nice
choice
spring
also
has
graphql
support
as
well.
B
So
this
is
a
relatively
new
project,
but
it
does
give
you
graphical
support
in
Spring
and
on
the
JavaScript
side,
as
I
mentioned,
there's
lots
of
different
choices,
lots
of
different
libraries.
So
so
you
can
do
a
really
really
quick
demo.
Any
amount
of
time
we
have
left
so
I
have
spun
up.
I've
got
a
little
application
here,
so
we've
got
the
speaker
tracks
Apple,
working
on
it.
It's
built
using
graphql
and
quarkris
on
the
back
end.
B
C
B
So
I'm
going
to
send
this
query
to
get
the
profile,
and
here
is
that
profile
back
and
on
our
hand,
side.
You
see
the
speaker
profile
object,
the
ID,
the
bio,
the
sessions,
all
the
stuff,
that's
being
displayed
there.
Okay,
it's
all!
This
is
right
here
and
basically,
the
way
it
works
is
inside
of
my
little
carcass
app
here.
B
B
B
So
you
can
basically
use
hibernate
in
a
reactive
manner
and
then
we
have
a
query.
So
this
is
our
query.
This
is
the
description
that
will
be
displayed
in
the
schema.
Okay,
and
this
is
getting
the
speaker
profile
and
then
this
is
the
ID
that's
returned
or
that's
needs
to
be
sent
in
we're
returning
a
uni
which
is
a
an
object.
That's
returned
by
the
hibernate
reactive
API,
it's
supported
by
the
quarky
supplementation
of
micro
profile
graphql,
but
we
could
just
return
a
normal
speaker
profile
here.
B
It
would
work
just
fine,
it
would
just
be
blocking
I'm,
not
seeing
the
difference
so
and
then
we
returned
fine.
This
fine
is
just
a
helper
method
that
basically
does
a
database
call
to
find
something
by
ID,
so
very
straightforward
there
and
what's
Happening
Here
is
there's
also
other
methods
here.
So
there's
the
getspeaker
profile
right,
which
returns
speaker
profile
instance,
but
also
we
have
the
speaker,
object
itself,
the
headshot
all
these
other
properties,
and
these
can
actually
be
handled
by
different
methods.
B
B
B
So
this
is
a
very,
very
simple
example
where
you
basically
just
use
the
right
micro
profile,
graphical,
annotations
and
magically.
You
have
a
query
now.
What
we
can
also
do
is
look
at
the
results
here.
So
one
of
the
nice
things
about
Quark
is
there's
this
little
little
Dev
mode
here.
Right
so
we
can
look
at
the
quarkus
dev
mode
and
then
it
actually
has
the
ability
here
to
look
at
the
graphql
schema.
C
C
B
So
that's
the
schema
and
I
also
mentioned
a
lot
of
there's
also
other
options
for
interacting
with
your
API.
So
this
is
the
graphco
UI,
which
is
built.
I
forgot
the
name
of
the
the
project,
but
there's
there's
a
little
react
app,
which
is
really
easy
to
just
put
into
any
graphql
server,
and
this
is
it
so
you
can
also
look
at
stuff
this
way
so
and
it
has
those
same
sort
of
features
as
Altair,
it's
not
quite
as
powerful,
but
this
will
actually
do
things
like
this.
B
B
Okay.
So
again,
this
gives
me
each
session
coming
back
and,
as
you
might
imagine,
there's
again
a
documentation
as
well.
Okay,
so
we
can
look
at
the
root
query.
We
can
get
back
to
people
profile,
get
back
in
session
Etc
so
and
all
this
is
generated
by
code,
because
micro
profile
graphql
Works
code.
First,
there
is
no
schema
first
approach
for
it
right
now.
So
that's
basically
the
idea
there's
also
the
ability
to
write
mutations
as
well.
B
B
A
B
Then,
on
the
client
side,
basically
it's
this
is
typescript.
This
is
the
method
that
loads
the
profile
and
then,
if
you
look
in
here,
there's
a
super
class.
If
you're
not
familiar
with
typescript,
it
looks
sort
of
like
JavaScript
and
Java
combined,
but
essentially
What's
Happening
Here
is
we
are
making
a
call
to.
B
B
There's
a
query
for
a
particular
speaker:
ID
that
query
calls
this
controller
and
the
controller
is
actually
a
it's
a
reactive
controller
from
the
Apollo
graphql
elements
project.
So
it's
basically
graphql
wrapper
on
top
of
custom
elements.
So
it's
basically
an
easy
way
for
us
to
make
graphical
queries,
so
we're
doing
execute
query
we're
passing
in
a
variable.
We
talked
about
variables
before
and
then
we
get
this
data
back
and
you
notice
we
actually
are
returning
the
type
so
because
we
specified
up
here.
B
Where
were
we
that
we
wanted?
This
profile
is
of
the
type
that
we
want,
and
here
we're
specifying
this
type
speaker
profile
we're
actually
getting
a
typed
object
back,
so
we're
making
graphical
graphql
query,
but
getting
the
typed
object
back.
We've
actually
generated
models
from
the
schema
returned
by
the
back
end
on
typescript,
so
this
is
from
the
hibernate
entity.
You
basically
end
up
with
something
like
this
generated
using
typescript
generator.
B
C
C
B
Okay,
so
I've
talked
about
how
great
graphql
is,
and
so
the
question
would
be
well.
Why
would
you
not
use
it?
Well,
you
know
nothing's
perfect,
you
may
not
want
all
the
additional
overhead.
That's
involved.
You
man
I,
want
the
type
schemas
having
to
find
a
contract,
all
that
kind
of
fun
stuff.
So
it
really
depends
on
how
complicated
your
system
is.
B
B
B
B
So
there
is.
These
are
I'll
we'll
put
in
the
the
notes,
a
link,
but
these
are
different
places.
You
can
look
at
to
learn
more
there's
a
graphql
site.
This
article
on
schema
first
approach
is
pretty
handy
to
get
an
idea
about
the
pros
and
cons
and
then
there's
some
other
links
to
some
of
the
other
things.
B
B
B
A
Okay,
perfect
so
yeah.
That
was
the
only
question
that
we
had
there
as
I
just
wanted
to
say.
Thank
you
so
much
for
the
excellent
presentation
today
and
if
we
are
looking
to
book
some
more
Jakarta
Tech
talks
at
the
end
of
the
year,
so
please
feel
free
to
fill
out
the
form
that
I'm
going
to
link
in
the
chat
if
you
are
interested
to
participating
in
hosting
a
webinar
with
us.
Thank
you
again
so
much
Quito
and
everyone
have
yourself
a
wonderful
day.