►
From YouTube: Magento GraphQL Community Meeting, 21 Jun 2018
Description
GraphQL Community Project Wiki: https://github.com/magento/graphql-ce/wiki
Mind Map: https://www.mindmeister.com/1094880388?t=a5LVAQ71Vq
Backlog (with Zenhub): https://github.com/magento/graphql-ce#boards?repos=128075669&showPRs=false
Backlog (without Zenhub): https://github.com/magento/graphql-ce/issues
Zenhub Chrome Add-on: https://chrome.google.com/webstore/detail/zenhub-for-github/ogcgkffhplmphkaahpmffcafajaocjbd
A
B
B
So
let's
say
if
you
have
category
which
is
marked
as
anchor
and
it
has
subcategories
which
contain
products
before
they
fix
those
products
were
not
visible
when
query
and
core
category-
and
this
is
not
how
it
currently
behaves
and
cold
front
and
obviously
had
to
be
fixed
so
right
now,
if
you
have
color
key
of
categories
on
their
anchor
and
you
query
all
products
from
an
core
category,
you
will
get
basically
all
those
products
and
there
were
two
issues
reported
independently.
So
this
is
one
of
them,
which
is
mr.
B
B
And
also
right
now
we
have
three
pool
requests
from
community
members
in
progress.
We
are
working
on
finalizing
them
and
getting
ready
to
merge.
So
basically
so
now
we
are
waiting
for
some
changes
to
be
made
in
dose,
pool
requests
and
as
soon
as
there
like
any
comments
or
second
comments
are
addressed,
will
be
glad
to
merge.
Those
requests.
A
Excellent
yeah,
thanks
for
thanks
for
doing
that.
Okay
and
the
next
thing
that
I
was
going
to
make
a
mention
of,
is
that
we,
we
did
not
receive
any
new
issues
in
the
past
week.
So
let's
take
that
as
a
good
sign,
because
most
of
the
issues
that
have
been
getting
reported
or
have
been
bugs,
so
maybe
we
ran
out
of
those.
A
But
so
the
next
thing
that
I
wanted
to
do
during
this
week
is
go
through
some
of
the
issues
that
we've
got
in
our
backlog
in
the
column
called
for
grooming
and
just
quickly
talk
through
a
few
of
them
in
an
effort
to
kind
of
move
them
to
ready
to
start
column,
and
so
the
the
group
of
items
that
I
think
we
should
go
through
today
came
from
our
CMS
content
team
and
I
wanted
to.
We've
got
a
few
of
them
written
down.
A
A
Has
to
do
with,
like
I
said,
building
at
the
graph
QL
API,
so
that
you
can
query
and
manage
CMS
pages
CMS
page
entities
so
as
a
magenta
developer,
I'd
like
to
query
CMS,
page
content
using
graphical
API,
so
that
I
can
build
basic
ecommerce
store
fronts
using
only
graph
q1
right.
So
the
the
main
use
case
here
is
the
developer
query
or
using
graph
key
with
the
query,
CMS
page
content
and
getting
back
all
the
necessary
data
that
they
need
to
the
pages
on
the
storefront
or
in
third-party
apps.
A
The
way
that
it's
written
currently
is
for
only
querying
this
data,
but
there's
nothing
to
prevent
us
from
being
able
to
manipulate
and
manage
it
as
well.
So
do
things
like
creating
and
updates
and
deletes
as
well
so
in
acceptance
criteria.
What
we've
got
so
far
is
that
obviously
only
pages
that
are
enabled
currently
should
be
returned
by
the
API
pages
disabled.
It
shouldn't
be
visible
on
storefronts,
so
there's
that
distinction
then
store
view.
Context
is
fast,
just
like
it's
built
to
today.
A
A
Staging
versions
of
the
page
cannot
be
queried
has
to
do
with
those
staging
and
preview
functionality.
Obviously
only
content.
That's
currently
live
can
be
returned
by
the
graph
QL
API,
because
that's
the
that's
all
the
storefront
has
the
ability
to
view
and
render
right
and
next
what
I
have
is
a
list
of
fields.
This
again
is
kind
of
a
draft.
A
A
A
A
So
I'm
gonna
close
this
guy
and
move
it
in
here
and
then
I
want
to
talk
through
the
second
related
feature
here,
which
is
very
similar
except
so
still
and
CMS
entity,
but
now
this
time,
instead
of
it
being
a
CMS
page,
it's
a
CMS
block
which
reads
as
a
magenta
developer.
I
want
to
query:
SIMEX
CMS
block
content
using
graph
QAPI,
so
that
I
can
build
basic
ecommerce
store
fronts
using
only
graph
tol
for
efficiency.
A
So
again,
the
same
type
of
deal
here
it's
written
for
querying-
and
this
is
where
I
think
we'll
start
with
this
entity,
but
later
on,
we'll
definitely
want
to
build
out
capabilities
to
manage
them
in
terms
of
creating
updating
and
deleting
as
well.
The
use
case
is
very
similar,
a
developer.
You
can
query
graph
QL
for
CMS
blocks
right
and
get
back
all
they
need
to
render
those
blocks
on
the
storefront
or
in
third-party
apps.
A
So
very
kind
of
analogous
to
the
previous
story.
Only
enabled
blocks
should
be
returned
by
the
API,
the
store
view
context
should
be
respected
in
terms
of
what's
returned
versus,
not
staging
versions
cannot
be
queried
again.
Only
only
the
live
data
would
be
returned
by
the
API
and
then,
as
far
as
the
object
itself,
for
the
fields
that
it
that
its
Cavs
has
on
it.
It's
kind
of
a
simpler
object
and
that
Venom
pages
and
has
much
fewer
field
elements,
but
things
that
should
be
returned.
C
C
C
A
C
C
A
C
A
So
these,
both
of
these
by
the
way,
should
be
compatible
with
kind
of
the
old
or
older
legacy.
Now
CMS
CMS
system
and
the
newer
page
builder
kind
of
entities
and
concepts,
so
we
need
to.
We
need
to
take
into
account
both
of
those
ok.
This
CMS
coverage
here
is
an
epoch,
so
that's
more
of
a
container
story
for
everything
else.
I,
don't
think
I
made
another
one
for
for
CM
a--
for
other
CMS
entities.
Unless
I
just
don't
see
it
here,
but
that's
that's
all
I
was
kind
of
planning
on
going
through
today.
A
We
are
now
up
to
almost
20
stories
and
or
bugs
call
them
work
items
that
already
they're
in
they're,
ready
to
start
column.
So
these
should
be
able
to
be
picked
up
and
worked
on
by
anyone
who
volunteers
and
then
we've
got
50
issues
that
still
need
to
be
groomed
out
so
we'll
gradually
go
through
these
and
move
them
into
ready
to
start,
as
we
kind
of
talk
through
them
and
add
details
to
to
these
stories
and
books.
I
guess
some
of
these
are
epics
as
well,
so
the
actual
number
is
lower.
A
All
righty,
we
will
end
with
this
next
week.
It's
unclear.
We
may
be
skipping
next
week's
meeting
because
we
have
people
out
of
town,
but
we
will
let
you
know
in
the
slack
Channel
so
come
join
us
there
and
we
will
let
you
know
thanks
everyone
for
joining
we'll
see
you
guys
in
one
week
or
two
weeks,
thanks.