►
From YouTube: Magento GraphQL Community Meeting, 12 July 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
Hi
guys
kinda
here,
yes,
okay,
so
in
scope
of
this
mutation,
auto-type
I
wasn't
able
to
create
test
module
with
graph
key.
Oh
my
baby
I
functional
test,
and
you
can
see
that
in
scheme.
You
are
now
recall,
in
addition
to
query,
which
was
enable
to
loosely
not
have
mutation,
and
here
we
have
just
placeholder
for
now,
which
is
part
of
graphical
module
and
the
reason
is
we
cannot
have
type
mutation
without
any
fields
and
that's
why
we
have
this
placeholder
of
now,
unless
we
have
at
least
one
mutation
implemented
and
also
on
my
instance.
B
So,
basically,
here
you
can
see
syntax
for
mutation
like
you
have
to
call
like
mutation,
then
this
is
specific
field
for
mutation
and
arguments
as
usual,
in
request
in
query
and
then
again,
fields
so
and
type
hinting
and
everything
works
like
as
usual,
so
you
can
see
that
it
works,
and
when
you
execute
this
query,
you
get
response
same
way
as
you
do
in
query,
and
the
difference
actually
is
probably
semantics
was
on
implementation
level.
There
is
no
difference
if
you
implement
in
query
support
or
you
implement
in
mutation
and
on
schema.
B
B
B
So
you
can
see
that
resolver
is
identical
and
I
introduced
mutation
item
just
to
make
sure
that
new
types
are
correct
brought
it
correctly,
even
if
they
declared
just
for
mutation
for
query
so
and
the
resolver
as
I
said
it's
just
regular
as
over
I
didn't
even
change
it
from
query.
We
can
check
this
one,
so
not
nothing
special
here.
B
An
extension
also
works,
so
I
tested
extension
from
different
module,
extreme
extension,
and
there
is
no,
so
you
can.
You
can
notice
that
mutation
item
contains
in
in
disk
images
two
fields,
but
on
my
instance,
it
contains
like
three
fuels.
In
addition
to
those
two
fields
it
contains
integer
with
fuel
and
that
into
the
integer
list
field
is
provided
by
another
module.
C
B
B
B
E
B
B
Operation
modify
some
state
so
in
this
test
module
it
doesn't
matter,
but
I
mean
in
reality,
you're
supposed
to
modify
stricken,
probably
return
result
like
for
card,
for
example,
if
you
add
in
new
item
to
card
you
will
just
modify
card
status
of
Scott
state
here
and
we'll
return.
The
whole
card
object
in
response,
like
whatever
is
the
closet
of
oncology,
but
it
should
be
possible
to
get
full
part
object
as
a
result
of
mutation.
So.
B
B
Fields
and
then
you
can
resolve
us
for
some
specific
tools
like
prices
or
like
categories
or
something
that
like
not
complex
fields.
But
basic
data
is
on
single
resolve
and
when
we
implement
persistence
layer,
it
will
be
again
resolved,
like
most
of
the
fields
will
be
resolved
by
managers
over
by
the
Norton
graph,
kill,
query
directly
to
sequel,
query
and
the
rest
of
the
fields
like
some
complex
relations
will
be
resolved
by
customers
over
and
same
information.
F
B
B
It
should
be
somewhat
humans,
cuz
I'm
saying
so.
This
is
I
suppose
maybe
I
cannot
show
you
this
one.
It's
not
part
of
the
agenda,
but
still
we
are
working
on
a
proposal
for
cards
schema
and
you
are
welcome
to
participate
and
leave
your
feedback
in
this
task.
So
we
are
not
implementing
here,
but
we
are
on
the
stage
of
cumin
and
you
can
see
like,
for
example,
how
they're
proposing
to
add
card
items
to
the
cart.
B
So
you
will
have
like
cult
ID
and
then
you
will
have
items
and
again,
all
all
all
the
correlations
here
are
identical
to.
How
would
you
do
this
in
query,
so
you
have
some
graphical
type.
You
should
be
player
somewhere
in
schema
and
say
card
item
and
then
in
the
references
like
the
custom
options
to
configurable
cetera.
So
all
data
for
mutation
like
to
do
it
in
rest,
in
post
body,
for
example,
put
body.
A
A
G
Hey
guys
I
just
want
to
clarify
one
point
suggest
for
people
who
are
not
familiar
with
mutations,
so
why
do
you
need
mutations
at
all?
So
if
we
use,
for
example,
REST
API,
we
are
doing
like
fetching
the
data.
We
are
get
requests.
So
if
the
API
is
well
designed,
you
will
never
write
the
data
using
get
requests.
We
use
post
route
delete
requests
for
this
purpose,
so
we
have
separated
there
the
data
reading
and
data
writing
by
the
request
type
and
within
the
scope
graph
QL.
G
We
have
query
for
reading
the
data
and
we
have
added
mutation
for
writing
the
data
all
for
changing
some
some
state
on
the
server
side.
So
that's
why
we
need
mutations
in
general,
so
this
is
a
task
that
requires
creating
and
you
I
can't
report
or
function
for
creating
an
empty
card,
and
the
main
like
precondition
here
is
if
the
customer
is
logged
in,
he
should
be
three
of
the
shopmen
card
ID
after
its
created
and
if
it's
a
guest,
the
current
ID
issue
patched.
So
it's
a
standard
agenda
functionality.
G
We
can
use
interfaces
for
this
purpose
and
the
work
is
still
in
progress,
but
I'll
show
you
the
results,
so
we
already
have
that
mutation
route
here,
so
we
can
call
it
now
and
we
can
use
create
energy
card.
It's
already
there
so
currently,
I'm
performing
the
separation
as
a
guest
and
I
have
the
hash
it
card
idea
as
a
response,
and
we
can
test
the
same
with
the
luggage.
English
user,
so
write
some
magic
here.
G
And
try
once
again
so
as
a
bloody
thing.
Customer
I
have
the
card
created
it's
and
they
got
six.
So
when
we
check
their
quotes
table
I
will
see
that
there
is
one
new
record
it's
for
gas
card,
so
it's
been
regenerated
every
time
when
guests
request
new
shopping
cart
and
as
for
the
logged
in
user,
we
have
a
shopping
cart
with
entity,
ID,
six
which
was
created
previously,
so
it
ought
not
be
recreated
once
again.
G
F
B
So
we
have
an
etic
basically
and
as
part
of
that
epoch
we're
going
to
do
a
typical
95
and
then
it
should
be
possible
to
add
items
at
the
scholarship
in
mass
exponent,
nice
words
and
obviously,
with
modified
items
and
fiber
disappear.
We
should
have
community
to
do
preparations
for
all
of
these
12
steps.
A
C
C
We
have
a
multiple
meeting
there
and
we
came
to
the
point
that
we
started
to
develop
the
venue,
any
a
team
for
that
and
this
team
that
is
kind
of
fronting,
which
will
be
connected
to
manage
enter.
We
had
the
graph
quick
at
least
expects
it
to
be
really
proud
graph
QL,
but
Jeff
is
not
a
full
coverage
of
API,
so
the
rest
is
still
possible.
So
we
we
didn't,
come
to
the
point
yet
when
we
need
arrest.
C
But
we
already
come
to
the
point
when
the
craft
cured
is
not
fully
like
creative
for
the
usage
for
EBA,
even
the
building,
some
simple
stuff
working
currently
on
home
page,
for
example,
and
the
biggest
topic
which
is
about
when
we
already
discussed
it
with
magenta,
guys
that
the
configuration
values
of
the
system
or
as
we
build
in
the
front
end.
We
expect
that
the
customer
is
ready
to
that.
C
You
haven't
functionality
to
continue
to
configure
his
front
end
and
a
lot
of
those
failures
has
taught
in
magenta
modular
configuration
and
yeah
to
build
a
font,
and
we
need
those
vendors
and
emerging
tourists
out
of
box.
We
have
the
basic
store
configuration
which
we
can
get
with
usual
REST
API.
That's
like
media
class
base,
URL
currency,
like
language
I,
guess
yeah
kind
of
this
that
something
this
has
the
rest,
but
we
be
happy
to
have
it
on
graft.
C
We're
also
done,
and
in
addition
to
that,
we
need
some
other
attributes
for
Magento
bacon,
which
is
not
covered
even
by
the
rest
api
for
this
kind
of
almost
Lyon
design
elements.
Some
of
the
configuration
various
like
which
H
is
a
homepage,
how
to
recruit,
to
display
the
prices
on
the
front
end
and
some
standard.
C
C
C
C
B
A
H
H
D
Yeah
thanks
guys
for
all
the
work
it's
looking
great,
the
progress
is,
is
really
good
which,
which
is
making
us
excited,
I,
think
we're
really
getting
some
critical
mass
on
this
project
and
I
think
it's
gonna
really
bring
a
lot
of
value
to
Magento,
and
so,
like
I
was
saying
kind
of
last
time.
I
think
our
current
focus
is
gonna
remain
on.
You
know,
check
out
in
card
for
now.
D
To
kind
of
be
able
to
integrate
with
other
with
other
systems
and
accomplish
more
functionality,
including
for
for
Twi
and
I,
was
important
for
them
as
well,
so
we're
gonna
be
working
in
lockstep
with
with
that
project
as
well,
so
we
are
gonna,
be
making
sure
that
backlog
is
getting
groomed
gradually.
It's
where
we're
gonna
be
working
on
that,
so
that
you
guys
are
able
to
pick
up
more
stories
and
more
more
different
features
of
graph,
QL
and
we'll
all
together
move
this
project
forward.
B
Then
I
would
also
like
to
encourage
everybody
to
join
this
current
item
specification
discussion
and
if
you
have
any
feedback,
please
leave
your
comments,
and
this
is
like
right
time
because
we
had
this
custom
schema
folk
art
with
several
groups
right
now,
like
several
independent
groups
and
any
feedback
is
welcome
and
basically
you
can.
You
can
probably
add
some
value
to
do.
D
This
yeah
that's
exactly
right.
This
is
this
is
one
of
the
crucial
points
of
of
decisions.
So,
if
anyone
has
experience
specifically
in
you
know,
cart
at
checkout
and
kind
of
orders-
and
you
know
like,
like
I
said
before
arrest
is
kind
of
our
starting
point,
but
we
certainly
want
to
make
improvements
on
things
that
we
can
get
right
with
that
implementation.
So
this
is
this
is
our
chance
and
we
could
really
you
don't
use
some
expertise
and
some
feedback
on
on
the
cart
schema.
B
And
also
I
would
like
to
mention
that
you
should
not
look
at
rest
when
you're
looking
at
schema
or
graph
Keo.
You
can
basically
do
whatever
you
want.
It
should
not
be
related
to
vision,
implementation
and
we
just
need
to
provide
the
best
interface
possible
for
cart
operations,
and
then
we
will
take
how
to
implement
those
resolvers
and
imitation,
but
basically
the
interface
should
be
our
highest
priority,
like
would
interface,
which
is
convenient
for
developers
when
generated.