►
From YouTube: GraphQL and Headless CMS CrafterCMS
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
A
A
These
are
the
kinds
of
questions
that
we
hear
from
folks
that
are
new
to
graphql
and
it
can
be
used
in
all
of
those
ways,
but
it's
not
what
graphql
is
but
graphql
is,
is
a
specification
for
data
retrieval
and
data
mutation
that
was
started
by
a
company
called
meta
and
that
they
later
contributed
to
the
open
source.
Community
graphql
is
now
maintained
and
managed
by
the
Linux
Foundation.
In
this
specification
there
are
two
parts.
A
The
first
part
is
a
schema
in
which
we
have
a
strongly
typed
data,
dictionary
of
objects,
the
object's
properties
and
the
relationships
between
those
objects,
and
the
second
component,
along
with
that
schema,
is
a
query
language
definition.
So,
with
a
strongly
typed
schema
and
a
query
language,
we
can
now
interrogate
systems
by
asking
them
to
return
their
structure
to
us,
as
well
as
the
data
in
those
structures.
Well,
isn't
that
just
what
SQL
and
nosql
provide
that's
kind
of
an
obvious
question?
A
Well,
the
difference
here
is
that
graphql
is
implementation
agnostic,
so
any
kind
of
server
can
implement
the
graphql
specification
and
present
itself
as
a
graphql
server
and
then
map
onto
that
back-end
technology,
whereas
SQL
and
nosql
databases
tend
to
be
very
implementation,
specific
by
contrast
with
graphql,
it's
not
a
about
the
store.
Instead,
it's
about
the
graphql
implementation,
which
is
required
to
expose
both
the
schema
and
map
the
query
language
onto
the
backend
system,
and
it's
the
fact
that
graphql
requires
both
of
these.
That
is
key
to
illustrate
this
further.
Let's
take
a
look.
A
At
this
example,
we've
got
a
client
making
a
single
graphql
request
to
the
graphql
server.
The
graphql
server
then
interprets
that
single
graphql
query
into
backend
system
queries,
and
in
this
case
three
back-end
system
queries.
So
it's
the
fact
that
graphql
is
by
its
design,
both
client
and
back
end
agnostic
and,
at
the
same
time,
still
a
standard.
That
is
the
key
difference
between
it
and
standards
like
SQL.
A
This
positions,
the
graphical
query,
language,
to
be
one
query:
language
to
rule
them
all
and
on
top
of
its
query,
capabilities,
graphql
comes
with
some
special
powers
and
of
these
one
of
the
most
powerful
is
its
ability
to
support
what
we
would
call
Api
gateways,
federations
or
sub
graphs
because
of
its
graph
oriented
nature
and
discoverability
support.
You
can
layer
one
graph
upon
another
graph
and
then
combine
those
subgraphs
into
a
single
graph.
A
This
is
a
potent
capability,
because
then
you
can
have
many
graphql
implementations
that
are
all
exposed
as
one
integrated
API
look
at
our
example.
Here
we
can
see
that
there's
an
individual
graphql
graph
for
products,
content,
users
and
inventory.
Each
of
these
is
a
facade
of
the
implementation
technology
for
the
specific
system.
A
More
importantly,
we
can
see
that
we
have
several
clients
at
the
top
web,
apps,
mobile,
apps
and
so
on,
and
each
of
these
are
able
to
access
all
of
this
data
through
a
single
API
endpoint
in
order
to
retrieve
and
operate
on
the
integrated
whole.
How
awesome
is
that
another
kind
of
superpower
is
that
you
don't
have
the
problem
of
over
fetching
that
you
have
with
rest
based
systems.
A
This
is
why
people
often
talk
about
graphql
as
an
alternative
to
rest
apis
in
graphql,
you
use
a
single
HTTP
request
to
send
a
query
across
potentially
many
resources
and
ask
for
only
specific
data
elements
of
each
resource
that
you
want
back.
By
contrast
in
rest,
you
send
a
request
for
each
resource
and
get
back
a
standard
or
fixed
response
with
a
superset
of
data.
Then
the
data
that
you
need.
This
is
a
very
inefficient
and
arguably
less
secure
way
to
request
data
than
graphql
provides.
A
You
make
more
calls
and
transport
more
data
than
you
are
likely
to
need,
and
we
know
when
it
comes
to
Performance
and
security.
Less
is
more,
and
this
is
what
you
see
in
the
example
here.
On
the
left,
we
have
an
example
of
a
client
making
multiple
rest,
API
requests
and
getting
back
fixed
responses
and
on
the
right
we
have
a
single
graphql
request
being
sent,
and
it's
getting
back
just
the
data.
It
asks
for
and
no
more
with
graphql.
A
We
also
have
some
control
over
the
shape
of
the
response,
and
now
when
I
say
the
word
shape,
that's
a
technical
term
shape
means
the
structure
of
the
response,
including
the
names
of
the
data
elements.
This
can
be
very
important
because
it
provides
the
consumer
with
the
flexibility
it
needs
to
handle
changes
over
time.
Renames
and
removal
of
fields
are
easier
to
deal
with,
and
it's
even
possible
in
some
cases
to
mimic
responses
of
Legacy
systems
that
you
might
be
replacing.
A
Anyone
that
has
been
around
API
development
for
any
amount
of
time
knows
that
you
have
to
version
apis,
because
consumers
become
dependent
on
the
calling
and
response
interfaces.
If
we
change
those
interfaces,
then
our
consumers
are
broken
and,
as
a
result,
we
must
make
a
new
version
of
each
API
when
we
change
it.
These
can
be
kind
of
a
pain
to
manage
and
their
technical
debt.
Graphql
doesn't
have
this
issue
since
graphql's.
Calling
and
response
interface
is
a
query
language
consumers
describe
what
they
want
and
how
they
want
the
response
to
look
when
it
returns.
A
This
means
there's
no
change
to
this
calling
Convention
as
the
backend
system
mutates.
Thus,
there's
no
need
to
version
apis.
This
is
a
big
deal
because
it
simplifies
what
we
need
to
manage
and
it
lowers
technical
debt.
Graphql
also
has
an
awesome
ecosystem.
Everything
from
developer
tools
like
Ides
to
framework,
plugins
and
Lang
language
bindings
are
included
in
this
ecosystem
because
it's
a
spec
it's
easy
to
integrate
with
and
create
tools
for
it
and
because
graphql
is
so
widely
applicable.
There's
a
tremendous
incentive
to
do
so.
A
This
leads
to
a
lot
of
adoption
and
a
virtuous
cycle
with
respect
to
the
community,
the
ecosystem
and
adoption
just
to
make
sure
all
of
this
is
concrete.
Let's
take
a
look
at
an
example
of
a
graphql
query
and
a
response.
So,
on
the
left
hand
side
of
the
query.
We
can
see
that
we're
asking
for
a
social
post,
specifically
we're
asking
for
the
title
and
the
comments
of
the
post,
along
with
the
comments
author
there's
a
couple
more
things
to
note
here.
A
The
first
is
that
we're
asking
for
what
we
need
in
order
to
satisfy
our
use
case,
and
only
that
we
don't
need
every
data
element
of
the
post,
so
we
don't
ask
about
it.
The
second
point
of
interest
is
that
we
can
see
for
each
comment
that
the
kind
of
author
we
can
receive
back
for
each
comment
can
be
different
and,
and
we
can
see
that
the
query
itself
has
a
mechanism
for
dealing
with
those
different
kinds
of
objects
and
returning
them
in
a
similar
fashion
to
the
calling
client
on
the
right
hand
side.
A
A
Graphql,
like
any
technology,
has
some
gotchas
and
areas
to
watch,
but,
generally
speaking,
it's
very
compelling
at
crafter
CMS,
we're
very
excited
about
graphql
and
I
want
to
talk
a
little
bit
about
why
we
think
graphql
is
so
important
for
headless
CMS
platforms
like
crafter
CMS
and
here's.
The
big
one.
Graphql
is
technology
agnostic
on
both
the
front
and
back
end,
and
it
already
has
a
large
amount
of
adoption
tool,
support
and
integration
across
a
wide
range
of
programming,
languages,
development,
Frameworks
and
platforms.
A
Graphql
is
really
the
first
opportunity
in
the
content
management
space
to
have
a
widely
adopted,
widely
understood,
widely
applicable
common
API,
so-called
standard
apis
in
the
content
management
space
like
iecm,
jcr
and
cmis
have
generally
failed
and
I
think
it's
for
two
main
reasons.
The
first
is
that
they
were
too
often
technology
specific
and
the
second
and
more
important
reason
is
that,
in
a
way
they
were
two
content
management,
specific
and
Niche-
all
which
leads
to
adoption
issues.
A
A
Remember
this
kind
of
flexibility
helps
us
avoid
vendor
lock-in
and
it
helps
us
deal
with
use
cases
that
would
otherwise
require
API
versioning,
which,
as
we
discussed,
is
technical
debt,
and
the
last
thing
that
I'll
point
out
here
is
the
support
for
API
gateways.
Federations
and
sub
graphs
is
a
really
big
deal
in
the
content
management
space.
Marrying
content
to
business
objects
is
a
major
and
very
common
use
case
in
the
content
management
space
products
live
in
product
information
management
systems,
marketing
content
lives
in
content,
Management
systems,
but
the
object
that
our
applications
want
back.
A
A
Now,
let's
talk
specifically
about
graphql
with
crafter
CMS,
and
for
those
of
you
who
don't
know
crafter,
let
me
give
you
a
quick
overview.
Crafter
CMS
is
an
open
source.
Headless
CMS,
unlike
the
other
thousands
of
CMS
platforms
out
there,
crafter
is
built
on
top
of
git.
Git
gives
crafter
CMS
its
own
set
of
superpowers.
Our
git-based
versioning
is
like
a
time
machine.
A
We
can
reproduce
any
moment
at
any
time
to
support
Advanced
editorial
use
cases
like
rollbacks
or
Audits,
and
we
can
support
working
in
teams
based
on
branches
for
use
cases
like
redesigns
or
the
segregation
of
sensitive
content
and
the
team.
That's
working
around
that
sensitive
content
from
the
larger
team,
and
these
are
very
difficult
problems
to
solve,
otherwise
also
leveraging
git-based
workflow
mechanics
crafter
CMS
fits
directly
into
your
devops
process,
making
it
easy
to
move
content
and
code
between
environments.
A
This
tight
integration
of
devops
with
the
content
process
is
called
Dev
content
Ops
and,
unlike
a
handful
of
other
git-based
cms's
out
there,
which
are
generally
intended
for
static
sites,
crafter
CMS
is
designed
to
manage
Dynamic
and
personalized
content
for
any
channel
to
support
this
content.
Authors
need
great
authoring
tools
and
crafter.
Cms
has
a
very
robust
and
easy
to
use,
set
of
in-context
editing
and
drag
and
drop
content,
authoring
tools
for
Content
authors
and,
of
course,
crafter
CMS
supports
a
variety
of
API
endpoints,
one
of
which
is
graphql.
A
We
benefit
from
graphql
in
all
of
the
ways
that
we've
discussed.
In
addition
to
those
there
are
a
few
crafter
CMS
specific
things
about
our
graphql
implementation.
That
I'd
like
to
point
out,
and
the
first
is
that
our
graphql
implementation
is
completely
native
and
very
fast.
Graphql
is
an
afterthought
for
many
CMS
platforms
and
it
has
been
bolted
onto
their
existing
apis
with
the
bolt-on
approach.
One
graphql
query
may
turn
into
a
large
number
of
actual
CMS
queries.
Crafter
CMS
takes
the
opposite
approach
to
this.
A
We
see
graphql
as
strategic,
so
we've
made
graphql
native
to
our
system
and,
to
the
extent
possible.
One
graphql
query
is
one
CMS
query
within
crafter
CMS.
Another
thing
that
we
do
is
automatically
generate
your
graphql
schema
for
you,
so
you
don't
have
to
when
you
define
content
objects
in
crafter
CMS.
We
automatically
configure
your
graphql
schema
for
you
saving
you
time
and
effort,
and
lastly,
we
provide
programmatic
extension
points
for
you
within
our
graphql
server,
so
you
can
Define
your
own
schema
elements
and
Fetchers
from
our
last
point.
A
You
know
that
we're
all
about
low
code
support,
we
don't
want
you
to
have
to
program
or
do
more
work
than
you
need
to,
but
we
know
that
we
can't
think
of
everything.
So
we've
given
you
the
extension
points
that
you
need
so
you'll
always
have
the
flexibility
to
handle
any
kind
of
integration
scenario
that
you
face.
Okay,
let
me
sum
this
up
by
saying
that,
while
no
technology
is
a
silver
bullet,
graphql
is
a
powerful
and
important
technology
that
has
a
large
and
growing
base
of
adoption.
A
We
feel
that
it's
a
fundamental
technology
for
the
CMS
space
at
crafter
CMS,
we're
committed
not
only
to
having
and
supporting
a
graphql
server
we're
committed
to
having
one
of
the
best,
if
not
the
best
implementations
for
headless
CMS
out
there
in
the
open
source
space
and
with
that
I'd
like
to.
Thank
you
very
much
for
your
time.
I
hope
you
learned
something
about
graphql
and
about
crafter
CMS.