►
From YouTube: Magento GraphQL Community Meeting, 24 May 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
Hello,
everybody,
let's
get
started
thanks
for
joining
this
morning.
This
is
our
first
real
community
graph,
QL
grooming
meeting
and
we'll
start
by
introducing
ourselves.
My
name
is
Misha
Kotov
I
am
a
product
manager
for
the
graph
QL
track
and
with
me
here,
I've
got
Alex
Parrish.
He
is
the
architect
on
our
technical
team
responsible
for
the
graph
QL
project
here
I
see,
we've
got
got
some
other
internal
folks
on
the
call
as
well.
I
won't
make
them
introduce
themselves
this
this
time
in
the
interest
of
time.
So
let's
I
think
we've
got
everybody.
A
Let's,
let's
get
started
here
so
I
wanted
to
probably
start
with
kind
of
framing
this
meeting
and
and
what
it's
for
right.
This
is
a
grooming
meeting
and
just
so
kind
of
everyone's
on
the
same
page,
what
we
are
what
we
intend
to
do
in
these
meetings.
We
want
to
hold
them
regularly
and
every
week.
So
far,
probably
at
this
time,
unless
we
get,
you
know,
involvement
from
other
other
groups
for
whom
this
time
doesn't
work.
A
A
We
kind
of
took
a
first
pass
through
the
issues
and
wrote
them
down
kind
of
from
the
intension
perspective,
but
obviously
a
lot
of
the
work
can
benefit
from
further
kind
of
discussion
and
further
documentation,
and
that's
what
we
were
hoping
to
do
with
with
the
community
folks
and
so
to
start
off
with
I
think
this
is.
This
is
a
good
place
to
start,
if
you
guys
don't
have
the
CRL
bookmark
I
would
encourage
you
to
do
so.
A
I'm
gonna
paste
it
in
the
chat
here-
and
this
is
our
project
page
and
you'll-
see
I'm
on
the
I'm
on
the
wiki
tab
of
the
graphic
you'll
project.
Here
we've
got
an
overview
and
kind
of
describing
and
framing
again
the
intent
of
the
project.
So
this
is
this:
is
graph
QL
you'll,
see
on
this
page
a
quick
overview
and
I'll
go
through
the
space,
just
to
make
sure
that,
where
everything
is
clear,
I've
got
a
tab
here
linking
to
our
current
roadmap
and
on
the
very
from
a
very
high-level
perspective
we've
got.
A
You
know
in
our
internal
team
had
been
working
for
months
on
an
initial
implementation.
If
you
will-
and
this
is
very
roughly
what
we
got
done
right-
we've
got
an
initial
implementation
for
products
for
categories
for
customer,
as
well
as
a
kind
of
an
in
point
for
URL
resolution
kind
of
a
future
use,
and
what
we're
looking
to
do
in
the
future
is
basically
build
upon
this
foundation.
A
This
framework
that
we've
that
we've
implemented
currently
and
some
highlights
of
where
we're
looking
to
go,
include
mutations
to
support
some
very
basic
e-commerce
flows
like
checkout
payments,
shipping
handling
and
being
able
to
render
my
account
and
then
also
increase
coverage
for
entities
that
already
exists
like
products
and
categories
as
well
as
obviously
coverage
for
experiences,
lekha
or
dimension
check
out
my
account,
etc.
We're
looking
to
implement
some
improvements
in
the
graphic
Ewell
framework
and
then
also
there's
some
performance
related
things
there
for
contact
information
you're
on
the
meeting,
so
you
obviously
made
it.
A
A
B
A
One
thing
that
I'll
mention
is
we
use
this
add-on
called
Zen
hub
and
you'll
see
an
extra
tab
that
I
have
up
here.
You
can
get
a
Chrome
extension
I
think
that
I'm
guessing
they
have
extensions
for
other
browsers
as
well,
but
it
helps
it
basically
kind
of
provides
a
layer
of
additional
functionality
on
top
of
github
issues.
It
allows
us
to
view
issues
as
boards
and
and
kind
of
facilitates
an
agile
workflow.
Then
I'll
show
you
guys
in
a
second.
A
So
for
now,
let's
look
at
what
the
roadmap
page
looks
like
like
I
mentioned,
we've
got,
we
considered
phase
one
to
be
complete,
and
this
goes
into
a
little
bit
more
detail
of
what
we
accomplished
in
in
that
phase.
That
was
done
internally
before
starting
out
with
phase
two,
which
is
what
we're
looking
to
kick
off
here
today.
So
for
phase
one
you
can
see
under
products
I'll
go
over
this
quickly.
Obviously
this
is
a
query
that
can
be
used
to
fetch
data
about
products
for
use
on
on
building
things
on
the
front
end
right.
A
So
the
things
that
we
support
are
all
product
types.
We
support
filtering
based
on
certain
attributes,
like
you
see,
listed
here
and
standard
operators
that
you
guys
are
probably
all
familiar
with.
We
support
search,
and
this
is
kind
of
full
text
search
capability.
We
support
sorting
and
pagination
for
results
to
come
back.
We
support
scopes
for
multi,
store
views
and
that's
handled
through
HTTP
headers.
We've
got
support
for
eav
attributes
and
automatic
generation
of
those
as
part
of
the
schema,
and
we
support
extension
attributes.
A
A
A
This
is
to
build
out
things
like
category
experiences,
navigation,
retcons,
etc.
It
can
benefit
from
improvements,
but
we
do
have
a
basic
implementation
in
place.
We
also
have
support
for
the
customer
entity,
and
this
just
means
in
the
scope
of
graph
QL,
because
it's
an
API
designed
for
storefront
information.
Only
this,
basically,
you
can
fetch
attributes
about
the
currently
logged
in
customer
and
that
if
education
is
based
on
the
session
token.
A
Lastly,
we
have
a
query
for
URL
resolution,
and
this
is
basically
just
an
endpoint
where
you
can
you
can
that
takes
URLs,
and
then
it
spits
out
kind
of
basically
a
canonical
ID
version
of
of
the
URL,
it's
kind
of
like
a
permalink.
If
you
will
to
identify
the
resource
and
the
tech
of
the
resource
that
it
is
alright
on
to
phase
two.
A
So
we've
been
hard
at
work,
trying
to
generate
an
initial
backlog
of
items
that
we
then
we
envision
ourselves
working
on
right
and
what
you
see
here
is
kind
of
a
quick
screenshot
of
a
mind
map
that
we
created
and
I
have
a
link
here
as
well.
So
I'll
show
you
what
that
what
that
looks
like
this
is
basically
a
tool
that
represents
kind
of
a
hierarchical
view
of
how
we
think
of
our
graph
QL
phase
to
approach
and
I'll
zoom
it.
So
you
guys
can
see.
A
Every
one
of
those
tracks
is
kind
of
broken
down
into
further
issues,
so
in
case
of
performance,
for
example,
you
see
these
yellow
items
that
we've
marked
here
our
document
as
its
epics
in
the
backlog,
and
then
each
epoch
is
broken
down
into
actually
further
kind
of
individual
issues.
Here,
the
link
to
this
mind,
map,
like
I
said,
is
on
github.
You
guys
can
open
this.
You
should
be
able
to
follow
links,
etc.
A
We
see
ourselves
working
on
as
well
internally
and
those
are
marked
with
a
little
lock
sign
though
I
feel
like
everything
is,
you
know,
nothing
is
set
in
stone
and
things
are
kind
of
fluid.
So
if
there's
interest
in
some
of
these
things,
we're
we're
definitely
down
through
to
collaborate
and
discuss
and
and
enable
our
community
to
work
on
things
that
they
want
to
work
on,
did
I
miss
anything.
A
B
A
Yeah,
so
we
definitely
want
to
dive
into
most
of
these,
or
at
least
do
a
quick
overview
of
what's
in
the
backlog
before
I.
Do
that
I
do
want
to
show
you
guys
the
probably
design
hub
board
where
we've
got
these
issues
documented
and
actually
you
can.
You
can
enter
the
items
themselves
from
from
the
mind
map,
like
I,
said,
if
everything
is
kind
of
linked
back
and
forth,
so
you
can
kind
of
jump
between
issues.
A
Let
me
let
me
finish
going
through
this
page
and
we'll
we'll
start
on
the
issues
list.
So,
like
I
said
we
grouped
this
phase
of
work
on
graph,
QL
and
several
different
tracks.
One
track
is
performance.
You
can
see
kind
of
the
major
items
that
fall
under
each
one
of
these
and
these
guys
are
going
to
be
epics
like
already
mentioned
so
under
performance,
we've
got
caching
work,
we've
got
persistence,
layer
work
then
for
coverage
coverage
is
actually
probably
the
the
biggest
item
here
and
there's
there's
a
lot
of
work
to
do.
A
There's
things
like
enabling
checkout
experience
right,
which
includes
mutations
and
payments
and
tripping
and
all
kinds
of
things.
So
that's
quite
large,
we've
got
enabling
building
out
my
account
experience
and
if
you
you
guys
know
in
my
account,
you
have
all
kinds
of
different
functionality
available
and
so
we'll
need
to
build
out
graphical
coverage
to
enable
developers
to
build
those
things
out.
There's
additional
coverage
for
products,
additional
coverage
for
category
and
then
also
CMS
on
the
framework
track.
A
We've
got
extensibility
we've
got
improvements
to
the
existing
framework
and
we've
got
support
for
mutations,
which
will
be
necessary
to
build
out
a
lot
of
these
experiences
and
the
last
track
we've
got
is
security
for
now.
Security
has
only
one
item
there,
which
is
query
complexity
limiting-
and
this
is
kind
of
a
obviously
a
limitation
to
reduce
vulnerability
for
a
store.
C
C
A
The
question:
why
do
we
want
to
provide
coverage
yeah
yeah,
so
so
you're
right?
The
check
out
today
is
based
on
largely
arrest,
api's
and
an
AJAX.
This
would
just
pro,
we've
had
third
parties
express
interest
in
being
able
to
do
so
via
graph
QL
as
well-
and
you
know
this-
the
graph
QL
is
intended
to
cover
all
of
the
api's
that
are
needed
for
to
render
storefront.
A
This
is
just
kind
of
architectural
direction
that
we're
headed
in,
we
think
it'll,
be
you
know
an
iteration
of
api's
that'll
make
you
know
the
experience
better
and
faster.
You
know
this.
This
is
one
of
the
main
things
that
we
want
to
work
on
pretty
pretty
high
in
our
priority
list.
I
think,
but
I
see
how
you
know.
There's
there
is
an
alternative
and
rest
will
be
just
an
alternative
way
to
implement
that
experience.
For
now,.
A
So
I
want
to
the
next
thing
I
wanted
to
do
is
show
you
guys
this,
the
Zen
hub
board
like
I
mentioned
so
when
I
this
is.
This
is
again
enabled
by
the
chrome
add-on.
You
can
see
it
I've
got
a
little
bluesy
over
here
in
the
corner,
so
this
is.
This
is
what
the
swim
lanes
look
like
right.
Here's,
the
very
leftmost
Lane,
it's
just
a
backlog
of
new
issues.
A
It
says
basically
most
of
these
will
need
a
little
bit
of
grooming,
meaning
you
know
adding
of
details
of
technical
approach,
kind
of
business
use
cases
level
like
another
level
of
detail.
Just
so
everybody
is
on
the
same
page.
The
next
Lane
is
backlog.
These
are
issues
that
we
consider
our
it's
it's
more
or
less
known.
What
what
we
need
to
do,
and
so
these
are
issues
that
community
can
pick
from
and
pick
up
as
long
as
you
know,
you
don't
pick
one
that's
already
in
progress.
A
If
you
pick
one
up,
please
label
it
as
such
and
move
it
to
the
lane
if
necessary.
Next
Lane
is
investigation.
This
is
just
things
that
are
kind
of
in
progress,
but
are
either
require
a
spike
or
just
some
additional
work
to
figure
out
how
to
how
to
approach
an
issue
you
guys
can
see.
We've
got
a
couple
issues
already
in
progress,
which
were
very
grateful
for
her
community
to
helping
for
helping
us
out,
review,
QA
and
then
merging
in
progress.
A
A
If
you
don't
have
the
Zen
hub
add-on
for
now,
like
I
said
this,
is
it
makes
a
working
and
get
home
very
convenient
as
far
as
kind
of
this
agile
approach
to
software
development?
All
these
issues
that
are
on
this
board
are
created
as
issues
in
in
the
backlog
so
you'll
see.
You
know
this
is
just
another
view
of
the
same
kind
of
work.
A
So
all
the
epics
and
all
these
stories
are
created
in
here-
you'll-
see
there's
three
pages
here
currently
with
different
types
of
labels
that
we've
created,
epics,
America's,
epics
and
then
kind
of
the
functional
area
that
they
fall
into.
If
a
story
is
not
marked
as
an
epic,
it's
just
a
story.
We
went
through
and
kind
of
took
a
first
pass
at
sizing
for
these
things
and
you'll
see
a
few
of
these
are
marked
as
a
good
first
issue.
These
are
generally
tend
to
be.
A
A
So
you'll
see
this
one
is
broken
down
into
a
couple
different
areas:
we've
got
issues
for
handling
payments,
handling,
shipping
will
then
check
out
and
then
cart
operations
deserves
kind
of
its
own
epic,
because
there's
a
there's
a
bunch
of
things
in
here
we
try
to
make
the
stories
granular.
So,
that's
you
know
they're,
not
super
time-consuming
for
for
anybody
to
pick
up
so
that
it's
you
know,
kind
of
smaller,
more
digestible,
more
manageable
chunks.
So
within
cart
operations
you
can
see
we
categorize
these
into
queries
and
mutations
queries
are
basically
just
fetching.
A
Data
and
mutations
are
the
create,
update
and
delete
operations
so
for
queries.
We've
got
fetching
shopping
shopping
cards
for
registered
guests,
I'm,
sorry
registered,
choppers
and
then
guest
shoppers,
because
those
are
implementation.
Details
are
a
little
bit
different
there
for
mutations.
We've
got
managing
gift
cards
on
cards,
we've
got
the
placing
of
the
order.
We've
got
manage
the
shipping
and
billing
addresses
on
the
card.
We've
got
managing
coupons
and
then
managing
the
cart
items
the
products
within
the
cart
themselves.
A
Moving
on
here
to
the
next
epic.
This
is
my
account
and
a
lot
of
these
stories.
The
intention
here
is
to
provide
enough
API
coverage
for
so
that
a
developer
could
technically
build
out
the
front-end,
for
my
account
experience.
So
similarly,
we've
got
this
grouped
into
queries
and
mutations
for
queries.
We've
got
fetching
my
orders
to
be
able
to
render
than
my
orders
tab
of
my
account.
So
this
is
just
all
previous
order,
history
for
a
customer
and
relevant
data.
We've
got
my
downloadable
products.
A
My
wish
lists
gift
registry,
my
invitations
fetching
newsletter
subscriptions
product
reviews,
reward
points,
billing
agreements,
store
credits
and
then
stored
payment
methods,
as
well
so
for
mutations.
We've
got
kind
of
analogous
issues
here
that,
for
some
of
these
experiences
are
required
not
only
reading
data
but
also
modifying
data,
so
things
like
managing
the
address
book
managing
your
newsletter
subscription
preferences,
changing
account
information,
like
name
and
email,
address,
etc.
Changing
passwords
for
customers
managing
a
wishlist
managing
the
stored
payment
methods
which
for
now
I
think
out
of
the
box.
A
We
just
allow,
depending
on
what
your
payment
method
you
have,
but
for
for
things
like
Braintree,
we
have
just
deleting
cards
for
now
and
let's
see
managing
a
gift
cards,
those
functions
for
things
like
checking
the
status
and
the
balance
for
gift
cards
alright.
So
that
was
my
account.
The
next
epic
that
we've
got
here
is
enhanced
coverage
for
four
products
within
catalog,
so
we've
got
a
kind
of
a
bucket
of
items
here
that
have
to
do
with
pricing.
A
Here's
an
item
for
itemized
we
tax
and
then
we've
got
a
few
bugs
listed
here,
some
of
which
are
limiting
list
of
filterable
product
fields
and
then
hiding
attributes.
Product
attributes
that
are
not
intended
to
be
shown
on
storefronts
I
think
actually
be
or
need
feedback
about,
at
least
at
least
some
of
these
things,
and
then
for
for
additional
coverage.
Here,
we've
got
returning
a
full
canonical
product
URL
within
the
product
object.
We've
got
returning
the
available
sort
options
for
product
listings,
returning
product
stock
data
and
then
returning
resized
image
paths
for
products.
A
Moving
on
here,
we've
got
some
issues
that
have
to
do
with
the
URL
result.
Resolving
so
we've
got
an
issue
to
fix
the
query:
to
support
relative
paths.
We've
got
support
for
absolute
paths
as
well
and
then
just
a
simple
rename
operation,
because
of
basically
a
mistake
that
we
made
and
naming
it
originally
by
the
way
as
I
go
through
these
issues.
You
know
this
is
this:
is
the
initial
backlog
that
we
came
up
with?
A
That's
not
to
say
that
you
know
the
community
or
you
guys
couldn't
add
more
issues
that
that
belong
on
the
backlog.
So,
if
you,
you
know,
if
you
think's,
if
you
think
of
things
or
improvements
for
graphical
they're
not
listed
in
here,
I
feel
free
to
create
an
issue
in
the
backlog,
and
then
we
can,
you
know
we'll
be
able
to
kind
of
categorize
it
and
put
it
put
a
Mac
mind,
map
and
and
just
add
to
the
backlog
for
for
work.
Community.
A
A
Cool
yeah,
those
two
exactly
those
two
you're
already
done
all
right.
So
moving
on
to
the
category
coverage
here,
this
has
to
do
with
working
with
the
category
entity,
so
we've
got
stories
for
adding
filtering
capabilities
to
categories
which
got
a
story
for
adding
category
children
depth
parameter.
This
is
this
would
be
something
that
allows
you
to
control
kind
of
to
which
depth
you're,
trying
to
fetch
children
for
a
certain
category.
A
Let's
see
include
products
in
the
category
query.
This
is
something
that
doesn't
show
up
today,
but
this
item
was
actually
already
in
progress
as
well,
and
then
adding
breadcrumb
support
for
categories
has
to
do
with
being
able
to
fetch
information
about
your
categories.
Parents
or
ancestors
MS
degree
up
through
the
route.
A
Okay
and
the
next
epoch
has
to
do
with
CMS
coverage
here.
So
this
is
being
able
to
work
with
our
entities
within
our
CMS
system,
and
some
of
these
have
implications
to
both
the
original
CMS
system,
as
well
as
the
new
page
builder
functionality.
So
we've
got
CMS
page
coverage,
block
coverage
and
then
making
some
modifications
to
the
existing
product
fields
to
enable
basically
WYSIWYG
slash
page
builder
content,
so
some
of
these
fields
will
become
complex
objects
instead
of
what
the
way
that
they're
currently
rendered.
A
C
While
you
are
mentioning
page
builder,
how
do
this
issue
relate
to
possible
mature
commerce
features,
as
page
filler
will
not
be
in
a
community,
so
at
least
this
is
one
that
overlaps
to
commerce
features
but
I'm.
Also
thinking
about
staging
capabilities
of
Magento
Connors,
oh
the
said
overlap.
If
the
craft
cruella
coverage
you
want,
you
yeah,
see
art
rest
by
the
by
the
community.
Sure.
A
Sure,
no
that's
a
good
question.
We
to
be
honest.
We
still
have
to
kind
of
figure
that
out
and
figure
out
logistics
of
how
to
work
with.
You
know,
implement
this
work
for
open
source
versus
implementing
it
for
Magento
commerce.
You
know
we're
just
starting
out,
so
we
we
won't
have
all
the
answers
here,
but
I
do
know
that
you
know
for
four
modules
that
are
commerce
only
you'll
have
a
corresponding
module,
corresponding
graph
QL
module
that
provides
that
will
provide.
You
know,
graphical
functionality
for
that
module.
A
C
C
But
page
cache
has
two
options:
caching,
on
a
PHP
side
which
is
not
recommended
for
production
and
cashing
in
varnish.
However,
craft
URL
will
be
always
a
post
request
which
by
default,
is
not
catchable
in
varnish.
So
there
are
options
in
one
issue
to
actually
provide
caching
based
on
the
body,
but.
B
C
Think
varnish
would
make
a
lot
of
sense
because,
if
you
imagine
so
today,
you
are
caching,
let's
say
a
category
page
which
has
all
the
products.
If
you
now
take
out
when
we
think
about
PWA
a
fronting
or
something
like
that,
if
you
remove
the
caching
of
the
page,
every
visitor
would
hit
the
back
end
just
to
retrieve
the
ordinary
products
that
are
viewed
on
the
on
the
default
category
page
right.
And
so,
if
you
don't
cache
that,
then
everyone
will
hit
the
back
end
which
which
just
make
everything
impossible
to
handle.
C
So
caching,
on
the
edge
like
varnish,
would
make
a
lot
of
sense
to
deliver
the
same
kind
of
results
over
and
over
again
for
every
visitor
and
speed
on
up
things.
So
we
would
need
something
that
behaves
in
the
same
kind
of
way,
and
maybe
we
can
also
create
a
spike
here,
just
to
figure
out
what
what
kind
of
tools
and
requirements
we
would
have
to
allow
cashing
and
varnish.
It
is
possible,
but
it
will
require
some
additional
configuration
here.
C
B
Oh,
no,
these
tasks
are
created
and
they're
ready
for
grooming,
so
you
don't
have
all
the
details,
but
they
they
are
ready
for
investigation.
At
least
this
like
identifies
areas
that
you
want
to
improve
and
again
we
all
look
at
the
board,
maybe
like
after
looking
at
this
mind
map-
and
we
will
see
like
what
issue
somehow
is
clear
and
and
question
is
one
of
those
issues
which
require
investigation.
A
All
right
cool
thanks,
excellent
all
right,
so
that
was
some
discussion
on
the
on
this
caching
epoch.
In
you
know
we
can,
we
can
add
details
as
we
go
like
we
said
you
know.
A
lot
of
these
will
require
more
investigation
and
discussion
in
which,
which
we're
happy
to
do,
and
it
will
we'll
add
those
details
to
to
the
story
as
we
go
so
to
continue
going
through
the
article
mindmap
here.
The
other
side
of
performance
that
we
have
written
down
is
the
persistence
layer.
A
Persistence
layer
is
effectively
a
kind
of
flexible
and
performance
data
retrieval
layer
which
we've
got.
We
attempted
to
implement
this
for
the
initial
release
of
graph
QL,
but
we
didn't
quite
get
there.
We
ran
out
of
runway,
so
there's
there's
remnants
of
that
word
still
in
the
code,
so
some
of
these
things
need
to
be
basically
filled
out
and
some
of
them
potentially
need
to
be
refactored
from
from
the
original
effort.
So
this
we
don't
consider
it
probably
as
an
issue
that
we
get
picked
up
right
away,
but
maybe
further
down
the
line.
A
If
we,
if
we
get
some,
if
we
work
up
some
expertise
and
some
critical
mass
with
the
community,
we
might
we
might
be
able
to
tackle
this,
but
we
we
imagine
this
will
be
kind
of
a
bigger,
bigger
amount
of
work.
Okay.
So,
let's
move
on
to
the
framework
track
here
for
framework
we've
got
at
the
top
is
an
epoch
for
extensibility.
So
this
is
just
thinking
through
and
working
on
how
we
can
improve
graphical
extensibility
in
general.
B
So
it
would
be
like
really
nice
to
avoid
her
dependencies
from
third-party
developers
code
on
the
warnings
because,
like
for
core
it
small,
was
like
easy
to
change
the
dependencies
in
the
future,
but
like
we
cannot
dictate
it
for
such
partisan
because
of
backward
compatibility
we
will
live.
You
may
not
be
able
to
do
it
in
action
shape.
You
don't
do
it
now.
A
Yeah,
okay,
so
good
good
detail
there.
Moving
on
to
framework.
The
next
item
we've
got
here
is
mutations,
so
this
is
just
being
able
to
create
update,
delete
entities
or
information
about
those
entities
via
graph
QL.
So
the
couple
stories
that
I've
got
there
for
now,
it's
just
one
is
for
prototype
or
a
POC
to
see
how
it
might
work
in
our
current
framework
and
then
the
actual
full-fledged
implementation
of
that
functionality,
and
the
last
epoch
we've
got
here
is
framework
improvements.
A
Let's
see,
we've
got
some
ideas
on
partial
automation,
of
how
the
Doc's
are
generated.
We've
got
alphabetizing
schema
fields,
just
so
it's
easier
to
find
what
you're,
looking
for
at
a
glance
and
I
believe
that
one
is
also
in
progress
currently
and
then
some
some
basically
filling
out
documentation
that
we
have
for
a
test
framework
and
we've
got
some
documentation
online
currently
about
our
Web
API,
functional
tests,
etc.
A
A
There's
there's
some
things
that
we
want
to
do
internally
to
make
sure
that
there's
you
know
we're
doing
due
diligence
with
our
internal
internal
resources
and
we
want
to
have
an
audit
to
have
them.
You
know,
go
through
and
and
just
just
see
if
they
can,
you
don't
find
any
any
glaring
vulnerabilities
or
anything
like
that.
So
this
is
just
kind
of
for
transparency
and
visibility.
We've
got
this
item
on
here,
but
it's
a
mainly
intended
for
it
for
our
internal
team
and
then
implementing
this
query.
A
Complexity
limiting
this
is
this
is
an
item
that's
more
fit
for
kind
to
be
worked
on
by
someone
someone
in
community-
and
this
is
obviously
to
the
intent
here-
is
to
limit
someone
issuing
extremely
complex
queries
that
can,
you
know,
potentially
bring
down
a
server
or
something
like
that.
So
we
want
to
definitely
avoid
that.
A
A
Cool
alright,
so
I'll
take
that
as
a
no
and
we
as
a
next
step
kind
of
want
to
probably
go
back
to
the
our
agile
board.
Here
and,
like
I,
said,
we
kind
of
organized
this
into
items
that
need
more
discussion
or
may
potentially
investigation
and
as
far
as
the
items
that
are
in
the
backlog
column,
those
are
more
ready
to
pick
up
more
more
detailed
out
and
spelled
out
as
far
as
what
what
the
issue
you
holds
so
do.
B
B
A
Absolutely
so,
let's,
let's
do
that!
We're
gonna,
like
Alex
just
said
we
want
to
go
through
this
list
of
issues
that
are
more
or
less
ready
and
then
we'll
see
if
you
know
any
of
them
warrant
kind
of
further
discussion
with
you
guys.
So
the
first
thing
we've
got
listed
here
is
a
query
to
fetch
a
guest
Rappard
card
data,
so
intent
is
to
fetch
shopping
card
data
via
graph
QL.
So
you
can
build
out
the
you
know,
things
like
card
mini
card
on
the
storefront,
etc.
A
B
B
Also
feel
free
to
comment
on
like
sizing
of
the
issues,
because
we
did
it
like
some
issues
require
grooming
and
it's
not
completely
clear
like
what
is
the
sizing,
and
here
like
what
is
small
is
probably
something
that
can
be
done
in
one
day
and
medium
is
something
that
can
be
done
like
in
couple
days,
networks
three
days
and
also
it
accounts
for
complexity,
sometimes
and
large
issues.
We
should
probably
require,
like
at
least
of
week,
of
implementation
for
underwater
yeah.
A
As
as
much
a
developer,
I
want
access
to
the
parents
and
ancestors
of
the
category
object,
so
that
I
can
build
breadcrumbs
on
the
product
page
with
the
one
graph
QL
request.
So
there's
there's
a
couple
things
here.
Currently
the
category
does
does
provide
access
to
a
field
and
I
forget
what
it's
called.
It's
basically
path
to
route,
but
it
just
provides
IDs
of
of
those
parents
on
on
the
way
to
the
category
category
route
number.
But
the
idea
here
is
to
kind
of
provide
fold
it
in,
like
full
hydrated
objects
of
those
parents.
A
If,
if
the
client
decides
to
query
those
objects,
and
so
if
I,
basically,
if
I
fetch
your
category
category
by
ideas
should
be
able
to
as
one
of
the
data
fields
have
access
to
the
parents
and
information
on
on
on
that
object,
and
then
its
parents,
it's
etc
it.
It
can
probably
be
just
implemented
as
a
flat
list
of
categories.
So
apparently
I'm
parents
can
just
be
an
array
of
those
category
objects
because
we
do
have
a
field
that
accounts
for
the
level
of
depth
of
each
category.
So
you
can
use
that
to
figure
out.
A
Okay,
I'll
take
that
as
no
questions
on
this
one.
Let's
see
the
next.
One
also
has
to
do
with
categories,
so
this
has
to
do
with
I
want
to
control
the
depth
of
the
returned
children
for
the
requests
of
categories,
so
that
my
queries
can
be
more
performant,
so
this
has
to
do
with
by
default.
Currently,
when
you
fetch
a
category
I
think
we
return
all
children,
regardless
of
how
deeply
they're
nested
within
the
currently
fetched
category.
A
So
this
is
a
parameter
basically
intended
to
give
client
control
over
how
deeply
do
they
want
to
fetch
those
children?
So
an
example,
is
you
know
if
you
provide
a
depth
parameter
of
one?
This
will
only
fetch
the
immediate
children
of
the
category
and
two
will
fetch
media
children
and
their
children,
and
then
again
you
can
you
can
go
as
deep
as
as
you'd
like
and
again.
The
default
currently
is
zero,
but
the
intention
here
is
to
be
able
to
control
that
number.
A
Any
questions
on
this
one.
You
no
make
sense
cool.
Thank
you
all
right.
Next
one
has
to
do
with
products
and
stock
information,
so
we
had
actually
a
lot
of
internal
conversations
about
how
much
how
much
data
needs
to
be
retrieved
for
stock
or
if
exact
numbers
need
to
be
retrieved
for
stock.
But
basically
this
one
has
to
do
with
certain
configurations
that
are
available
out
of
the
box
as
far
as
stock
goes
so
Magento
allows
you
to
display
products
on
storefronts
that
are
out
of
stock
right,
there's,
basically
setting
it
says.
A
A
If
that
setting
is
enabled,
and
then
there
is
another
configuration
or
feature,
if
you
will
of
Magento,
that
defines
the
threshold
of
of
stock
for
products
and
then
if
product
falls
below
that
threshold,
then
it
will
be
displayed
as
only
X
amount
left
or
you
know.
If
you
want
to
customize
it
you
can.
A
Alright,
golden
silence:
let's
see
a
return
product
stock,
so
the
next
one
we've
got
here
is
some
documentation
on
test
framework.
This
is
you
know,
I
need
as
a
developer.
I
need
complete
documentation
of
grab,
kill,
test
frameworks
that
can
learn
it
and
I
can
use
it
in
my
development.
Here's
a
link
to
basically
analogous
documentation
for
our
Web
API
functional
tests
framework.
B
Graph,
your
testing
framework
is
not
complete
a
new
framework.
It
is
just
extension
of
the
decisions
about
the
framework.
So
if
you
use
a
bit
of
a
framework
for
rest
test
or
so
testing
in
the
past,
then
it's
pretty
easy
for
you
to
write
drug
tests
as
well.
We
just
have
a
way
to
to
basically
make
requests
informative
graph
kill.
B
You
just
have
a
stream
as
regular
graphical
requests
like
like
you
would
do
in
graphical,
for
example,
and
response
is
automatically
parsed
and
you
have
access
to
response
as
an
array,
so
you
can
assert
on
response
field,
so
I'm
not
sure
like
it
will
be
a
completely
separate
documentation.
Most
likely
it
will
be
just
an
extension
of
a
distant
page,
but
this
can
be
discussed
with
our
documentation.
A
Ok,
moving
on
here,
let's
see
URL
resolver
again
for
background.
The
earl
resolver
is
a
thing
that
accepts
a
kind
of
canonical
SEO
friendly
urls
and
it
returns
a
a
short
I,
debased,
URL
kind
of
I.
We
don't
want
to
call
a
canonical
anymore,
because
that's
it's!
It's
kind
of
that
word
is
reserved
to
something
else,
but
basically
it
returns
currently
a
relative
URL,
and
so
it's
the
way
that
works
today
is
just
a
misnomer.
C
A
Yeah
exactly
so
that
you
know
what
is
what
is
returned
today
is
not
technically
canonical.
Canonical
is
normally
referred
to
as,
like
the
SEO
friendly,
URL
right,
it'll
it'll
be
it'll,
have
the
name
of
the
product
HTML
or
something
along
those
lines,
but
to
have
it
return
a
canonical
URL
would
be
would
be
something
that
would
be
something
that
this
end
point
doesn't
provide
today.
So
that
would
be.
If
that's
something
that
would
be
helpful,
then
it
would
be
kind
of
a
separate
improvement
on
on
the
screen.
Yeah.
B
So
we
just
want
to
make
sure
in
this
sense,
como
estas,
that
we
do
not
block
someone
to
introduce
this
canonical
URL
later,
which
is
actually
canonical
URL.
This
look
like
looks
like
it
was
just
named
properly
and
by
the
way
we
can
already
accepted
community
pool
request
for
like
real
CEO
friendly,
canonical
URL
for
products,
so
you
can
request
it
for
products
records
right.
C
B
B
C
C
C
B
A
Yeah,
that
makes
sense.
We
don't
have
that.
That's
something
it's
not
currently
in
the
backlog,
but
that
we,
we
certainly
can
can
add
that
yeah
the
the
problem
is
today.
Magento
doesn't
support
a
canonical
URL.
That
includes
the
category
in
that
URL
right
like
correct,
multiple
categories,
and
we
are,
we
don't
have
a
notion
of
like
main
category,
which
is
the
main
reason
for
not
being
able
to
do
that.
Specific
thing,
right
and
I
know
there's
extensions
in
the
marketplace
that
actually
handle
that,
but
the
implications
of
building
URLs
with
and
without
categories.
A
It's
just
something
that
I
think
we
need
to
kind
of
think
through
in
the
different
ways
that
you
can.
You
know
you
can
fetch
products
today.
So
that's
a
that's
a
good
note
and
we'll
yeah
we'll
take
that
into
consideration.
Thanks
cool
all
right.
Thank
you.
Moving
on
here,
we've
got
the
next
item.
Here
is
a
prototype
for
creating
mutations,
so
this
is
again
just
a
way
for
to
do
create,
update
delete
operations
via
graph,
qaul
and
that'll,
be
you
know
built
on
top
of
so
this
is.
B
A
A
A
B
A
B
By
sorry,
if
I
mispronounced-
it's
probably
speaking-
and
this
was
initially
developed
on
contribution
day
in
Poland,
but
speaking
of
like
continued
development
after
contribution
day-
and
he
also
addressed
all
comments
that
we
had
and
eventually
we
were
able
to
merge
this
pull
request.
So
thanks
yeah.
A
B
Yeah,
so
this
was
also
contributed.
Actually,
it
was
independent
contribution
and
we
just
had
communication
in
github
and
again
thank
you
Peter
to
contributor
for
addressing
all
comments
and
again
we
have
back
and
forth
and
eventually
we
managed
it
so,
and
this
was
actually
the
first
pull
request
that
she
washed
yes,.
A
B
B
A
B
A
A
Excellent
all
right
we're
out
of
time.
We
will
post
the
recording
for
everyone
to
see,
probably
in
our
slack
channel
and
also
on
on
the
wiki.
We
really
appreciate
you
guys
joining
and
we
will
continue
same
time
next
week
if
that
still
works
for
you
guys.
But
let
us
know
if,
if
that
that
doesn't
work
for
some
reason
where
we
can
look
to
reschedule
necessary
and.