►
From YouTube: Microprofile: GraphQL | JakartaOne Livestream 2021
Description
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://jakarta.ee/
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
Okay
and
we're
back
to
yeah.
This
is
the
last
studio,
jakarta
session,
with
with
content
with
content,
yeah.
A
Jakarta's
or
small,
rather
this
is
specification
content,
not
jakarta.
Specification
content,
yes,
and
in
this
talk
where
we
will
have
keto
man
here,
welcome
kido
and
you
will
be
talking
about
microprofile
graphql
and
I
I
think
many
of
the
listeners
are
wondering
what's
the
difference
between
graphql
and
rest,
and
I
think
you
will
address
that
in
your
talk
as
well,
so
go
ahead.
A
B
Thank
you
ivar
and
tanya.
I'm
going
to
talk
about
graphql
and
microprofile.
So
yes,
this
is
the
opening
part.
I
forgot
to
show
this.
I've
got
the
little
jakarta
image
there.
All
right.
Just
first
just
want
to
introduce
myself.
My
name
is
keto,
I'm
the
principal
consultant
at
virtua,
where
we
do
training,
consulting
and
mentoring
for
basically
full
stack,
but
full
stack,
meaning
you
know
front
end
can
be
javascript
and
angular
react.
B
Whatever
back-end
is
almost
always
java
in
our
world,
so
so
heavily
invested
in
the
whole
world
of
the
job
ecosystem
been
in
the
community
for
a
long
time.
I'm
a
java
champion,
I'm
a
google
developer
expert
in
web
technologies
and
I'm
the
co-host
of
the
stack
podcast.
So
if
you
like
podcasts,
you
should
check
that
out.
We
talk
about
jakarta
ee.
We
talk
about
job,
we
talked
about
front
end
development
as
well,
and
all
things
related
to
software
and
enterprise
development.
B
So
that's
that's
that's
my
overview.
I
am
not
a
member
of
microprofile
specifically,
but
I
have
worked
with
graphql
a
lot,
so
I've
become
very
interested
in
microprofile.
B
Well,
so
what
I'll
do
is
just
spend
a
couple
minutes
talking
about
graphql
in
general
and
then
I'll
talk
a
little
bit
about
the
microprofile
implementation
of
graphql.
B
B
It's
it's
completely
different
than
all
those
things
and
here's.
A
simple
example
on
the
left
here
is
a
query,
and
that
curry
is
saying,
give
me
all
give
me
all
all
the
heroes
and
give
me
the
name
property
of
all
the
heroes.
So
you
can
see
here
we're
basically
asking
for
the
data
and
we're
asking
for
the
properties
of
the
data,
but
we're
not
specifically,
you
know,
calling
it
endpoint
we're
saying:
here's
the
data,
here's
the
part
of
data
I
want,
and
that's
that's
the
basic
premise
behind
graphql.
B
So
the
main
thing
is
that
it
does
not
use
rest
now.
Of
course,
the
default
transport
is
http,
but
it
doesn't
have
to
be,
but
it
doesn't
use
rest,
it's
actually
created
by
facebook
and,
if
you
think
about
it,
this
makes
a
lot
of
sense,
because
it's
it's
really
great
for
representing
graphs
and,
of
course,
facebook
is
all
about
graphs
of
relationships.
So
it
was
started
back
in
2012.
B
It
was
open
source
in
2015
and
in
2017
the
graphql
foundation
we
started,
which
is
actually
part
of
the
linux
foundation.
So
it's
a
pretty
big
organization,
and
if
you
look
at
the
list
of
companies,
there
are
a
lot
so
everyone
from
github
to
lyft,
twitter,
etc,
to
use
it
and
of
course,
facebook
does
probably
the
largest
user
I
haven't
been
noticing.
B
There
and
if
you
think
about
it,
it's
actually
sort
of
different
than
rest
and
it
tries
to
solve
a
few
specific
issues.
So
one
of
the
main
things
that
the
client
decides
what
data
it
wants.
So,
instead
of
the
server
coming
up
with
an
endpoint
and
then
essentially
saying
okay,
this
is
my
endpoint.
Here
are
the
inputs
that
you
can
provide
here's
the
data.
I
provide
it's
more
like
saying.
B
The
client
is
requesting
the
data
and
it
tells
you
the
the
server
what
data
it
wants
and
then
the
server
decides
where
to
get
it,
and
so
it
sort
of
flips
the
apis
on
their
head
a
little
bit,
and
what
this
means
is
that
it's
actually
well
suited
for
bffs
or
back
ends
as
front
ends.
That's
one
of
the
areas,
you'll
see
it
where
you
have
several
different
microservices
or
dozens
who
knows,
and
you
basically
want
to
provide
a
unified
api,
that
the
front
end
can
access.
B
It's
not
the
only
way
that
you
don't
have
to
do
it.
That
way.
It's
just
a
good
example.
Another
main
difference
between
rest
and
graphql
is
that
graphql
uses
a
consolidated,
single,
dynamic
endpoint.
So,
as
opposed
to
you
writing
like
a
whole
bunch
of
different
endpoints,
you
basically
just
have
graphql
running
everyone
calls
that
endpoint
and
then
just
request
the
data
that
they
want.
Now
you
do
define
multiple
queries
or
mutations
for
that
data.
B
Another
very,
very
compelling
feature
mic
of
a
graphql
is
subscriptions,
and
this
is
the
idea
that
you
specify
the
data
that
you
want,
but
the
server
pushes
back
the
data
changes
all
right,
so
it
pushes
back
the
updates-
and
this
to
me
is
actually
probably
the
most
compelling
thing,
because
it's
not
something
that's
built
into
rust
and
it's
something
you
get
out
of
the
box
with
many
graphql
implementations
and
the
the
transport
is
is
not
baked
into
the
protocol.
B
However,
the
websocket
transport
is
the
most
popular,
but
you
could
use
any
transport
you
wanted.
You
could.
A
B
Like
mqtt,
if
you
were
dealing
with,
if
you
were
dealing
with
a
external
devices
internet
of
things,
sort
of
devices,
so
it's
quite
quite
powerful,
but
I
think
another
key
difference
is
that
it's
has
a
defined
data
format.
B
So
essentially,
you
have
a
schema
that
you've
defined
that
defines
the
contract
between
the
front
end
and
the
back
end,
and
it's
a
lot
more
granular
than
what
you
define
with
like
you
know,
a
swaggering
point
basically
there's
a
whole
language
for
finding
schemas,
that
is
typed
and
to
me
this
is
really
another
very
powerful
feature.
B
So
what
it's
trying
to
do
is
address
some
of
the
drawbacks
of
of
rest,
and
that
would
be
things
like
the
endpoint
decides
what
data
to
return.
So
a
common
problem
is,
you
know
you,
you
request,
like
all
of
the
person
objects
and
you
only
care
about
like
the
name
and
the
social
security
number
not
like.
You
could
display
that.
But,
let's
just
say
that's
the
case
and
the
the
back
end
returns.
B
The
entire
person
object
with
every
single
property,
because
whoever
wrote
that
back
in
did
not
did
not
assume
that
the
client
would
want
different
pieces
of
data
and
just
since
all
the
data
back
so
with
graphql,
since
the
client
can
specify
what
data
it
wants.
You
you
eliminate
the
the
you
eliminate
a
lot
of
wasted
data
essentially
being
sent
back
over
fetching
as
they
say,
data
can
be
split
among
several
calls
and
that's
something
that
can
happen
often
with
rest.
B
Where,
like
you
need
to
make
like
four
or
five
calls
to
get
the
data
you
want
and
rest
doesn't
define
their
data
format
right.
The
format
of
the
data
depends
completely
on
what
the
endpoint
decides
to
generate
and,
of
course,
for
the
rest,
there's
no
push
standard
as
well,
and
that's
something
that
the
graphql
subscriptions
helps
with
so
that's
sort
of
the
the
idea
of
graphql
and
what
what
people
like
about
it?
What
what
problems
it's
trying
to
solve?
B
I
want
to
do
a
very
quick
demo
of
what
graphql
looks
like,
and
this
is
specifically
with
graphql
our
microprofile
graphql,
so
I've
got
an
import
running
and
it
is
a
very
simple
person
endpoint
and
it's
using
graphql
and
you'll
notice.
I've
got
this
graphql
api
annotation
up
here.
This
is
a
normal
pojo,
I'm
using
cdi
to
inject
services.
This
is
actually
a
graphql.
I
mean
a
microprofile
application
entering
a
qarcus,
so
I'm
doing
my
normal
injection
of
of
dependencies
and
then.
B
A
query:
okay,
so
query
is
basically
just
returning
data
back,
and
this
is
just
normal
java.
The
graph
microprofile
graphql
handles
all
of
the
serialization
for
you
and
there's
also
a
mutation.
So
a
mutation
in
graphql
is
an
update.
So
basically
the
idea
here
is
that
we're
passing
in
a
person
and
then
we're
updating
it.
Okay,
so
just
by
adding
these
few
annotations,
I
get
the
ability
to
then
call
it.
B
B
A
graphql
client,
so
this
example
is
altera
graphql,
which
is
a
handy
little.
B
You
can
use
in
chrome,
but
you
can
also
use
graphite
12,
which
is
really
popular
and
so
on
the
left
here
you
see,
I've
got
a
query
so
here
I
have
query
people
and
you'll
note
here:
I'm
actually
getting
code
completion,
I'm
getting
this
because
macro
profile
graphql,
is
generating
a
schema
for
me
dynamically
and
sending
that
to
the
client,
and
so
I
get
co-completion
and
I
also
get
documentation
as
well
same
as
you
might
expect
with
swagger.
B
So
I
can
find
all
the
different
queries.
I
can
find
out
the
types
that
are
being
returned,
etc,
etc.
Okay
and
all
this
is
generated
dynamically,
basically
from
one
of
the
graphql
endpoints
that
microprofile
graphql
provides.
So
this
is
actually
look
up
here.
It's
graphql
schema.graphql.
B
B
B
It's
still,
it
is
json,
but
you
see,
I've
got
the
data
as
the
first
node
and
then
I've
got
whatever
data
I've
requested
coming
back
and
then,
of
course
I
could
easily
change
what
I
wanted
right.
So
let's
say
I
really
only
wanted
to
get
back
the
id
and
the
names.
I
could
then
do
that
and
then
I
get
this
data
back.
So
this.
B
Very
quick
example
I'll
send
you
I'll
show
you
a
link
of
the
example
I'm
using
at
the
end
of
the
presentation,
but
this
should
just
give
you
a
flavor
for
what
it's
like
and
how
it's
different
than
rest,
but
provides
some
capabilities
that
rest
does
not
provide.
B
B
All
right
so
just
a
few
words
about
my
profile,
graphql
in
general,
so
it
basically,
the
idea
is
for
to
allow
you
to
and
while
you're
building
a
market
profile,
application
to
very
easily
add
graphql
support.
It
does
all
of
the
basic
plumbing
for
you,
the
serialization,
the
implementation,
the
graphql,
endpoint,
etc,
etc.
B
So
1.0
came
out
in
february
2020
and
it
defines
the
server-side
apis
that
you
just
just
showed
you
and
also
supports
queries
which
again
are
retrievals
of
data
and
mutations
which
are
updates.
B
1.1
came
out
this
year
and
had
some
minor
changes,
nothing
that
really
affects
end
users
very
much
and
2.0
should
be
out
soon
and
that
will
work
with
micro
profile
five
and
that's
going
to
use
all
the
jakarta
ee
name
space
changes
so
that
a
whole
lot
of
material
change
and
functionality
there.
What
I
think
is
cool
is
that,
of
course,
there's
a
few
implementations,
so
there's
a
small
rise
sort
of
the
the
basic
library
that
a
lot
of
runtimes
use
so
quercus
uses
it
open
liberty,
wildfly.
B
So
of
course,
ibm.
Red
hat
is
the
one
sponsoring
that
project,
but
also
come
and
lose
support
as
well.
Yes,
I'm
out
of
time
all
right,
halidon
supports
it
as
well,
and
the
other
thing
I
want
to
say
is
that
2.1
is
in
in
the
works
now
and
so
has
a
client
api.
So
a
java
api
that
you
can
use
to
access
graphql
services.
It
has
supports
of
subscriptions
which
to
me
is
my
number
one
feature
request
and
all
those
are
actually
prototyped
in
the
small
rye
projects.
B
So
if
you
want
to
take
a
look
at
them,
you
can
there's
an
experimental
repo
where
you
can
take
a
look
at
it
and
play
with
it.
So
so
that's
pretty
much
it
here
are
some
links,
and
I
I
did
upload
these
to
the
share
drive
for
the
presentations,
but
there's
there's
a
link
for
graphql
the
overall
site
for
graphql
and
then
the
microprofile
graphical
spec
and
the
microprofile
graphical
examples
where
the
example
in
this
presentation
came
from
right.
That's
it.
A
Thank
you
very
much
kiddo.
I
don't
think
we
have
a
time
for
questions,
but.
A
No
no
worries,
but
if
there
are
any
questions,
please
feel
free
to
put
them
in
the
chat
in
in
crowdcast
and
keto
will
probably
go
in
there
and
answer
them.
Otherwise
we
will
send
them
to
him
and
he
will
answer
them
anyway.
So
thank
you
very
much
and
we're
ready
to
go
to
the
last
speaker
of
the
day
and
that
is
brugletsky
from
ibm
and
she's
going
to
talk
about
exploring
stateful
microservices
in
the
cloud-native
world.