►
From YouTube: Magento GraphQL Community Meeting, 26 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
Guess
I
saw
the
agenda
for
today,
so
you'll
have
a
small
presentation
from
Vitaly
boy
about
extended,
store,
convict
coverage.
We
have
implementation
of
query
complexes
in
limiting
by
Yaroslav
here,
rendering
content
of
CMS
pages
and
retrieving
what
information
we,
as
across
fueled
by
ramen,
one
small
presentation
of
user
request.
We
has
a
graphic
from
me
and
graph
shows
he
must
what
checkout
by
Alex
a
large
from
magenta
yeah
I
guess
we
can
join
a
start
from
the
first
one.
This
vitaly
just
one
node
last
pull
request
from
vitaly,
also
basel
Redeemers.
B
C
C
C
C
Bye-Bye
bypasses
getting
values
from
scope,
config
and
returns
to
resolver,
which
this
data
going
to
be
Majid
and
return
back
to
graph
QL
framework,
let's
jump
into
dy
XML.
Here
we
have
this
list
of
configs
name,
which
becomes
the
keys
further
and
the
passes,
and
this
confuse
can
can
be
easily
extended
by
third
party
module,
UI,
XML
or
and
ex
common
craft
Cal's.
So
here
in
schema,
as
you
can
see,
we
have
the
skills
and
we
can
access
it
very
easily.
So
let's
make
a
test
I'm
sorry.
C
So
last
time
we
have
filled
from
store
interface,
and
this
is
this
fields
from
extended
data
provider.
So
let's
make
equality
for
I'm.
Sorry
I
forgot
to
mention
I,
have
here
two
two
stores,
its
Ukrainian
Ukraine
store
and
the
food
store
and
the
system
fix
should
be
definite
separately.
So,
let's
make
query
to
defaults
to
store.
C
C
C
D
D
C
D
Connect
Larry,
five
I
understand
correctly
so
store
code
in
URL
was
not
supported,
but
you
added
this
support.
Yes,
yeah,
that's
probably
not
excellent
want,
but
we
can
discuss
a
problem
later
in
in
code
review,
because
initially
the
idea
was
to
support
stores
which
we
have
headers,
because
we
want
to
have
like
single
end
point
for
all
graphical
queries
and
we
cannot
have
at
multiple
endpoints
and
that's
a
problem
now,
because
we
have
multiple
endpoints
if
you
have
multiple
stores.
So
we
need
to
take
a
look
like
why
store
is
not
passed.
D
D
D
F
Yeah,
just
have
one
note
so
literally
you
can
try
checking
the
controllers.
With
rascal
of
rock
you
module.
You
can
see
like
one
of
the
controller,
it's
like
an
intermediate
layer
between
the
framework
and
resolvers,
and
here
you
can
find
the
like
processing
of
the
headers
or
switching
in
the
store,
etc.
So
just
check
controllers
hidden,
rokkyo
module.
G
G
Some
of
them
are
acquired
in
CMS
magenta
model
and
another
one.
They
fired
in
zoom
magenta
model,
so
it
creates
implicit
coupling
between
the
store,
config
graph,
Keo
model
and
CMS
and
zien.
So
probably
it's
better
to
think
and
introduce
dedicated
graphical
models
for
this
proposed
just
to
not
create
president
and
when
we
run
necessary
to
expose
any
config
options
will
lead
to
editing
this,
because
it's
like
break
some
responsibility
principles,
because
this
model
should
provide
some
extension
point.
G
G
G
So
it's
it's
implicitly
assumed
as
those
modules
exist
and
enabled,
but
if
same
as
model
changes
or,
for
example,
introduced
new
one
config
path
which
will
hold
up,
for
example,
sidebar
will
need
to
edit
store
graphical
model,
which
is
not
not
really
correct,
but
this,
as
I
told,
is
pretty
minor
concerns.
So
just
just
to
want
to
highlight
this
concerning
and
invite
everyone
to
describe
this.
Probably
it's
not
so
important,
so
we.
B
F
Yeah,
hey
guys,
so
this
task
is
a
little
bit
tricky.
So,
like
I,
don't
have
a
final
solution,
it's
rather
point
for
discussions
and
for
further
improvements,
but
I
just
want
to
describe
the
idea.
So,
first
of
all,
why
do
we
need
to
to
limit
very
complexity
or
to
check
it
before
we
process
it
on
the
deeper
levels?
F
First
of
all,
in
some
occasions
we
can
have
really
heavyweight
queries
that
might
just
put
the
side
down,
because
the
single
query
might
result
in
hundreds
of
database
queries
that
might
be
with
a
heavyweight
for
store,
especially
if
you
have
a
big
amount
of
aeschylus
on
the
store.
So
the
main
idea
is
to
analyze
the
query
before
it's
processed
and
if
it
doesn't
match
the
rules,
just
show
an
error
or
a
message
that
you
need
to
modify
your
query
before.
F
It
will
be
accepted
by
example,
a
tie
and
graph
QL
or
the
bone
X
module
that
we
use
as
a
basis
for
graph
QL
image
on
top
already
contains
some
libraries,
some
like
services
for
checking
the
complexity,
and
that
trickiest
thing
in
this
task,
is
it's
really
hard
to
determine
the
rules
for
or
limiting
the
complexity
and
I
believe
that
we
here
it's
like
continuous
process,
and
we
do.
We
will
be
determining
this
complexity
over
the
time.
F
For
example,
we
don't
know
yet
the
final
complexity
of
our
of
our
queries,
for
example,
if
we
don't
want
to
have
a
full
product
information
in
the
order
items
or
so
and
I
believe
we
will
modify
this
proj
that
presented
today
in
the
future.
But
what
we
can
do
now
is
to
limit
that.
So
what
are
you
talking
about?
F
We
can
build
different
rules
for
particular
queries,
for
example,
if
we
don't
want
to
have
some
items
in
the
quote
request
that
we
can
build
a
separate
rule
for
that,
but
we
can
build
the
general
rule
that
will
analyze
the
complexity
and
analyze
the
query
death.
So
what
means
it's?
Basically,
it's
amount
of
fields,
total
amount
of
fields
in
the
query
and
the
depth
is
like
self-explanatory.
It's
how
many
subsequent
various
we
have
within
the
scope
of
the
main
query
and
for
now
I
have
implemented
the
separate
service
for
this
corpus.
F
F
So
it
has
only
one
entry
point
that
code
executes
and
it
is
quite
simple
for
now
it's
it's
checking
for
query,
death
and
I
said
very
def
like
54
now
and
query
complexity,
150
I'm,
just
I
was
just
testing
the
different
queries
and
checking
the
most
heavyweight
queries
and
that
Danny
III
just
started
from
these
values
and
I
believe
that
this
values
are
fair
for
for
start
and
we
might
change
them
in
the
future
and
for
like
to
not
hard
code.
These
values
I
put
it
in
by
I
XML
of
the
graph
key
on
module.
F
So
we
had
like
initial
implementation
of
these
fools,
but
it
was
a
little
bit
different
and
it
was
enabled
enabled
only
for
development
backside,
so
development
mode
I
mean
so
if
developer
mode
is
enabled
on
your
website,
this
rules
out
work
or
vice
versa.
I
I,
don't
remember
exactly
or
it's
just
work.
No,
it's
just
for
production
mode
yeah.
So
if
you
have
production
mode,
so
this
rules
work.
But
if
you
have
developer
mode
it
will.
This
rule
is
not
will
not
be
executed
and
I.
F
Believe
it's
not
a
good
approach
because,
for
example,
you
can
develop
a
store
in
developer
mode.
You
can
have
some
queries
and
the
query
is
just
fine:
they
they
are
working,
but
after
you
switching
to
the
production
mode
or
deploying
your
code
to
the
production
environment,
it
might
have
like
unexpected
behavior
because
complexity,
so
you
have
different
behavior
on
different,
like
deployment
mode,
so
I
believe
we
should
have.
We
should
have
these
rules
everywhere
and
yes,
so
the
main
idea
of
the
separate
class,
the
separate
service
or
model
for
limiting
the
query
complexity.
F
If
in
in
the
future,
we
don't
have
some
more
complex
logic
for
checking
some
particular
queries.
We
can
put
this
all
this
logic
here,
or
maybe
we
don't
need
some
different
services
for,
for
this
purpose
knows
and
let's
test
it.
So,
first
of
all
we
can
test.
The
query
depth
is
like
did
this
crazy
query?
You
can
see
here.
F
So
it's
like
recursive
query
and
if
we
don't
limit
varies
like
this
one,
it's
really
a
heavyweight
for
the
store
and
you
might
wait
for
15
or
more
seconds
until
you,
you
get
some
information
and
I
believe.
If
you
have
some
concurrent
calls.
The
similar
query
might
be
crazy
for
the
storage
zone
and,
as
you
can
see,
it
says
that
your
query
that
is
not
like
right
should
they're
less
than
15.
We
have
each
one
and
the
same
place.
F
And
let's
test-
and
you
can
see
that
sales
that
require
complexity
should
be
before
it's
bigger.
So
that's
the
main
idea
and
like
the
prototype,
and
we
stand
it
in
the
futures.
For
example,
some
give
some
customer
reports
and
issue
with
some
query:
that's
very
heavy
byte
for
store.
We
can
add
additional
rules
in
our
complexity
limiter
and
that's
the
only
if
you
have
any
questions,
but
you
know
thank
you.
Yeah.
D
Thank
you.
So
actually
we
already
had
very
depth
implemented.
It
was
I
believe
week
was
2:10
in
production
mode,
as
I
mentioned,
and
also
we
have
schema
introspection
disabled
in
production
mode,
and
it
was
I
believe
implemented
by
our
team,
because
this
is
like
best
practice
to
disable
introspection
on
production.
What
we
can
still
instigate
this
and
make
sure
that
the
decision
was
correct
and
for
very
limited.
It's
also
like
if
he
have,
if
you
have
it,
set
to
10,
for
example,
in
developer
mode
with
introspection.
D
It
was
basically
find
that
facing
this
query,
depth
constraints
and
he
wasn't
able
to
perform
introspection
and
probably
that's
why
query
limiting
was
disabled
on
production,
I'm,
sorry,
disabled
on
developer
mode,
but
it
was
enabled
in
production
and
equals
to
10.
So
we
can
probably
talk
about
this
and
I'm
not
sure
that
50
is
a
good
number,
because
it
seems
to
be
like
too
high.
F
Yeah
yeah.
Thank
you.
It's
it's
really
a
good
point
and
it's
as
I
said
it's
fun
for
discussions
and
I
thought
that
15
is
really
like
large
number.
But
after
checking
some
queries,
it's
possible,
but
yeah.
We
might
experiment
a
little
bit
with
that
and
as
for
the
English
function
and
the
previous
implementation,
I
have
moved
it
completely
to
the
new
query:
complexity,
limiter
class
and
introspection
as
still
disabled
in
the
production.
Ok,
so
you
just.
F
It
still
uses
the
same
logic
as
before,
but
I
changed
a
little
bit
values
for
depth
and
complexity,
and
then
we
can
move
like
so
what
what
was
implemented
previously
for
developer
mode,
everything
of
that
birth
disabled.
So
we
didn't
have
like
that
and
it'll
analyzes
or
complexity
checking
or
we
had.
We
also
had
introspection
disabled
in
production,
but
in
developer
mode
avidians
out
like
different
of
this
roles
and
as
I
said,
if
you're
we
can
experiment
with
that.
So
it's
like
just
a
starting
point:
yeah.
D
Yeah
I
think
it's
good
to
enable
query
depth
limiting
on
developer
mode,
but
we
probably
need
to
raise
value
from
10
to
a
little
bit
higher,
but
not
to
15
and
see
if
our
introspection
works
correctly
in
the
Waccamaw,
because,
like
previously
most
likely
depth
limiting
was
0
because
of
introspection
restrictions.
Yeah
wait.
F
A
C
Your
part,
thank
you,
hi
guys
and
just
a
small
update
from
my
side
this
week,
I'm
sure
my
screen
first
yeah
this
week.
We
decided
how
to
be
with
the
rendering
the
content
of
CMS
entities,
and
we
came
up
with
the
solution
where
we
gonna
use
such
filter
from
Regent
model,
and
this
approach
gonna
be
used
and
gonna
work,
both
on
community
version
of
Magento
and
almost
one
and
this
approach
approach,
also
taking
into
account
that
page
builder
can
be
enabled
okay,
because
a
page
builder
is
gonna,
extend
this
a
class.
C
That's
why
we
gonna
have
our
content
render
and
in
any
case,
if
we
go
this
way,
and
this
stop
was
already
implemented
and
yeah
I
believe
I
need
to
check
the
only
things.
The
one
thing
is:
Travis
feedback
and
yeah.
It's
ready
to
review
and
also
currently
I'm
working
on
the
quote
API
and
the
current
progress
is
that
I
involved
Alex
into
the
insertion
into
the
discussion
of
the
information
that
should
be
available.
The
first
interaction
for
this
task
and
yeah
after
we
discuss
this
stuff.
C
D
Thanks
to
Matt,
actually
I
have
one
one
questions
regarding
this
issue,
which
you're
currently
showing
was
it
in
ready
for
pickup
column
or
like
ready
to
start
:?
Oh,
it
was
in
new
column
because
looks
like
it's
not
really
grown.
Yet
when
do
you
know
like
when
you
pick
it
up,
did
you
pick
it
up
like
from
the
the
most
left
column
on
the
board,
Oh?
Actually.
B
A
B
Interesting
graph
QL
stuff
and
that
something
we
will
need
to
increment
and
yup
in
this
case,
I
took
any
final
subscription
sources,
idea
that,
while
building
there
some
tools
there's
a
graphical,
we
need
to
provide
the
user
experience.
So
you
need
to
provide,
in
my
account
section
and
I
thought
it
was
new
to
the
subscription
craft
Cole
Cole,
which
is
generally
quite
simple.
One
yeah
we
have
here.
B
The
subscription
resolver,
which
is
trying
to
get
is
a
new
set
of
subscription
based
on
the
customer
which
is
locked
in
so
you
cannot
get
it
by
a
dealer,
so
you
just
get
in
it.
If
you're
logged
in
you
will
receive
you.
If
the
customer
subscribe
to
you
Sarah
a
lot
yeah,
it
was
quite
simple:
Hema
herewith
returner
this,
if
subscribed
true
or
false,
so
it
will
be
boolean
and
yep,
as
example,
generally
to
try
it
yourself.
You
have
to
first
get
a
token
for
authorization
which
concerns
NK.
B
B
Usual
rest
IP,
so
just
after
receiving
the
token
and
paste
it
as
a
header
and
then
try
the
call
and
in
this
case
I'm
subscribed
and
if
I
will
wear
it
yep,
so
the
general
account
which
tested
and
if
I
will
remove
the
subscription
from
here
and
which
will
disappear
from
here.
Also,
you
are
quite
simple
and
I'll.
Let
the
tester
with
later
yeah.
That's
it
any
questions.
H
D
H
H
B
B
D
Okay,
so
actually
we
have
already
discussed
this
question
yesterday
on
architecture
consume
it
in
public
architecture
comes
from
me
and
what
I'm
pretty
sure
that
most
of
you
guys
haven't
attended
this
meeting,
so
I
will
just
cover
some
use.
Cases
and
decision
points
that
we
currently
discussing
regarding
checkout
flow
with
graph
kill,
and
we
are
going
to
publish
some
proposal.
D
Documents
soon
argue
like
in
several
days,
and
then
everybody
will
be
able
to
join
and
leave
comments
and
I,
but
for
now,
if
you
have
any
concerns
for
like
comments
regarding
this
early
list
of
decisions
like
you're
welcome
before
we
design
the
actual
schema,
because
this
will
like
all
these
decisions,
will
affect
the
schema
a
lot
Oh.
First
of
all,
we
are
going
to
have
like
separate
mutations
for
each
chakal
step
and
basically
we'll
be
able
to
create
empty
cards
at
items,
shipments,
I'm
at
method,
etc.
D
So-
and
this
is
already
reflected
in
current
issues
which
are
created
on
github,
then
second
points
that
we
are
going
to
have
uniform
interface
for
guest
and
customer.
So
you
not
have
to
do
it
like
in
Jordan,
currently
in
rest,
using
like
different
endpoints.
So
you
probably
remember
that
we
have
like
Milan
just
got
new
point,
and
here
the
difference
will
be
defined
and
decided
by
the
presence
or
absence
of
header,
authentication,
authorization,
header
and
otherwise.
Interface
should
be
uniform
and
who
you
as
well
say,
client
developer.
D
It
should
not
matter
I
work
in
with
guests
check
out
all
your
work
and
this
past
March
account
at
least
that's
the
idea
to
make
it
as
uniform
as
possible.
You'll
see,
maybe
we'll
have
some
use
cases
when
it's
not
possible,
but
so
now
this
is
our
main
direction
to
do
this,
then
we
have
some
complications
with
adding
products
to
cart,
and
the
main
complication
is
because
we
have
different
product
types
in
the
jungle
and
if
you
looked
at
our
products
and
point
in
graph
QL
products
query
a
graph
QL.
D
You
notice
that
we
have
interfaces
there
and
we
basically
have
multiple
implementations
for
product
interface,
and
this
allows
us
to
work
with
different
prototypes
graph.
Cal
has
limitation
that
or
input
teams
which
we
have
to
use
for,
say.
Adding
items
to
card
for
in
two
types
interfaces
are
not
supported
and
as
well.
You
cannot
use
polymorphism
for
product
product
information
when
you
add
in
product
to
call,
and
so
now
the
decision
is
noticed.
We
are
planning
to
design
schema
in
the
way
that
you
have
separate
mutations
for
different
product
types.
D
D
Another
point
is
that
probably
not
everybody
knows
that
you
can
combine
multiple
mutations
in
one
query,
so
you
should
be
able
to
request
adding
multiple
products
of
different
types
to
the
card.
In
one
query,
one
of
these
cases,
which
is
currently
present
in
Magento,
is
that
you
can
go
and
add
multiple
products
by
school
from
a
belief
customer
account
right.
Yes,.
E
D
From
customer
account,
you
can
do
that
and
if
product
doesn't
require
any
configuration
like
with
custom
options
or
unfavourable
options,
then
able
to
add
a
bunch
of
products
simultaneously.
So
this
is
case
will
be
supported.
Another
reason
for
heaven,
multiple
products
to
be
processed
at
the
same
time,
is
that,
basically,
you
will
be
able,
as
extension,
developer,
to
create
observers
or
plugins.
D
More
incrementation
for
your
extension
and
right
now
in
service
contracts.
We
have
an
issue
with
let's
say
our
positives:
that
we
don't
have
boiled
operations
for
persistence
like
product
update,
for
example,
products
create
so
for
those
operations
you
have
to
send
requests
like
one
by
one
and
extension
developers
also
create
plugins
and
observers
like
for
singular
input,
and
this
creates
performance
implications
so
in
in
design
of
us.
D
So
then
in
the
future
we
might
potentially
create,
will
important
your
single
mutation
to
allow
creation
order
in
one
code
it
is
not
currently
on
in
the
nearest
backlog
possible
to
do
it
in
the
future.
If
finito
and
the
last
point,
if
you
familiar
with
rust,
you
may
know
that
card
ID
is
not
hashed.
If
you
work
with
customer,
but
color
ID
is
hashed.
If
you
work
as
guest-
and
here
we
want
to
make
it
uniform
and
we
want
to
make
it
cashed
in
all
cases
yeah.
D
That's
a
card
query
to
get
in
for
own
specific
cards.
Client
is
trying
to
create
so
would
say.
If
he
has
already
created
empty
card,
he
has
card
cash
and
then
he
can
send
all
these
mutations
for
Aiden
items
and
awaken
cult,
and
he
might
do
this
synchronously
and
then
just
pull
card
query
to
get
information
about
the
card
that
he
has
just
created
and
alternative
way
is
just
to
subscribe
to
two
new
subscriptions
and
to
receive
notification
basically
about
credit
card
on
some
end
point
on
on
the
client
side.
D
But
this
is
an
open
question
for
now.
So
if
you
have
any
concerns
regarding
any
of
these
items,
please
let
me
know
as
soon
as
possible
before
we
detail
out
the
schema,
because
actually
I'm
going
to
work
on
details
for
the
schema
like
engineers
days
and
as
soon
as
it
is
done.
We
are
going
to
publish
it
to
our
architecture
github,
and
you
may
know
that
now
we
have
all.
Our
contextual
discussion
is
public,
and
yesterday
we
had
our
first
public
architectural
discussions
meeting
and
it's
going
to
be
like
big
bit.