►
From YouTube: Magento GraphQL Demo, 15 Feb, 2018
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
C
A
We're
missing
we're
actually
missing
one
who
is
our
tech
writer?
His
name
is
Kevin
Harper.
You
guys
will
can
see
his
work
on
on
the
dev
Doc's
web
portal.
So
let
me
do
I'm
gonna.
Do
a
quick
intro
before
we
dive
into
the
actual
demo
of
kind
of
where
we
stand
and
do
a
little
intro
of
graph
QL.
You
guys
that
are
joining
us
today.
I'm
sure
have
probably
deep
knowledge
of
what
graph
G
all
is,
but
just
in
case
there's
somebody
on
the
call
who
maybe
is
new
to
this
technology.
A
I
don't
want
to
give
you
a
quick
intro
to
what
it
is
and
why
we
are
interested
in
this
technology
here
at
Magento
just
for
their
future
reference,
as
you
guys
have
questions
today.
I
probably
would
like
to
handle
that
via
the
chat
of
the
zoom
conference.
Client,
so
I
just
pasted
your
questions
and
they
will
try
to
answer
everything.
We
do
have
a
lot
to
show
today.
A
So
if
we
can't
get
to
something,
we
can
continue
the
conversation
on
slack
or
or
elsewhere,
but
we'll
get
to
the
feedback
channels
as
well,
so
I'll
jump
right
into
it.
What
is
graph
QL
graph
QL
is
a
query
language
that
was
developed
by
Facebook
back
in
the
day.
It
was
used
internally
for
awhile
before
they
decided
to
open
it
up
to
the
public.
It's
been
growing
quite
a
bit
and
getting
a
ton
of
adoption.
It
can
be
thought
of
as
an
alternative
to
rest
and
other
have
web
services.
A
It's
a
very
convenient
technology
to
improve
developer
experience
for
those
that
do
a
lot
of
work
on
the
front
end
and,
and
the
main
benefit
is
that
you're
able
to
define
the
structure
of
the
data
that
you
want
and
you
get
that
data
and
only
that
data
back
from
from
the
server
so
request
data
equals
the
response
data.
Like
you
see
in
this
quick
example
here,
the
technical
benefits
are
quite
a
lot.
These
are
some
of
the
main
ones.
Typically,
you
can
accomplish
more
in
one
API
call
to
graph
QL
than
you
can,
for
example.
A
In
comparison
with
rest,
the
developer
gets
exactly
and
only
the
data
that
they
need.
So
you
don't
have
you
save
kind
of
on
the
overhead
of
the
payload
going
over
the
network
traffic?
So
normally
it's
a
bit
snappier
than
than
rest.
Well,
there
are
a
couple
other
advantages
of
built
in
features
like
documentation
and
deprecation,
so
because
everything
is
strongly
typed
and
everything
you
want
is
part
of
a
schema
knowing
that,
ahead
of
time
kind
of
brings
you
those
benefits
of
documentation
and
things.
A
Things
like
where
you
can
validate
the
syntax
of
a
query
before
you
even
sending
it
to
the
server
can
be
validated
on
client,
etc
and
introspection.
Of
course,
while
you're
writing
the
query,
you
know
what
what
is
available,
what
you
can,
what
you
can
write.
It
has
a
nice
autocomplete
feature
and
a
lot
of
graphical
tools.
There's
been
a
proliferation
of
just
tooling
in
general,
around
graph
QL.
A
Lately
that
helped
the
developers
do
their
work
faster
and
more
efficiently,
so
I
want
to
do
a
kind
of
an
overview
of
where
our
current
project
is
currently
at
our
task.
We
set
out
to
create
a
storefront
API
in
graph
QL,
so
this
is
any
any
kind
of
admin
actions
or
interactions
are
out
of
scope.
For
now,
it's
not
to
say
that
we
can't
tackle
those
later,
but
this
is
this.
A
Is
where
we
started,
we
kind
of
wanted
to
build
a
foundation
on
which
developers
can
build
front-end
experiences,
so
we
started
with
products
we
built
out
support
for
all
product
types,
plus
the
ability
to
search
sort
and
filter
and
we'll
demo
a
lot
of
this
later
on
in
the
session.
We
also
build
kind
of
a
basic
customer
authentication
mechanisms.
A
Here
we
are
starting
to
work
on
beginnings
of
query
API,
which
is
kind
of
a
it's:
a
lightweight
and
flexible
data
retrieval
layer
to
in
an
effort
to
kind
of
increase
performance
of
our
graph
QL
queries,
and
then
the
API
coverage
itself
is
meant
to
be
expanded
later.
So
again
we
started
with
products
and
we
wanted
to
see.
If
we
can,
you
know
do
things
like
render
product
details
page
or
a
category
page
very
product,
focused
experiences,
and
then
we
can
later
expand
the
API
coverage
to
start
rendering
things.
A
Like
my
account
page,
you
know
parts
of
checkout
and
order
order,
placement
flows,
etc
and
well.
We
certainly
have
intentions
of
doing
that
as
far
as
the
code
quality
as
it
stands
today,
where
the
team
is
very
much
still
in
development,
but
we
felt
like
the
qualities
is
coming
together
enough
to
where
we
can
start
exposing
this
publicly,
and
you
know
we
want
to
have
developers
start
playing
around
with
this
and
providing
feedback
we
want
to.
A
We
want
to
leave
ourselves
enough
runway
to
kind
of
be
able
to
react
to
whatever
feedback
we
receive
from
you
guys,
so
that
we
can
obviously
build
a
better
product
together
as
far
as
resources
with
some
Doc's
currently
already
published
up
Tom
the
first
kind
of
iteration
of
what
we've
built.
So
this
is
meant
to
be
expanded
as
well,
and
we
have
a
like
I
said
tech
writer
that'll
be
working
on
that
as
far
as
feedback
we're
like
I,
said
for
today's
session.
A
You
guys
can
use
the
chat
feature
and
we'll
try
to
capture
those
and
answer
them
on
the
call.
If
not,
we
are
active
on
slack.
If
you
guys
are
not
familiar,
there
is
a
community
engineering
slack
channel.
The
all
of
us
in
the
roof
are
where,
where
we're
all
present
there
and
that's
Magento
comm
with
two
M's
Eng,
that's
like
that
comm
and
our
channel
is
graph.
Ql
I
think
would
pay
attention
to
things
like
PWA
channel
as
well,
because
these
are
all
kind
of
interrelated
right.
A
C
C
So
I'm
going
to
give
you
quick
overview
of
overall
architectural
architecture
and
where
a
graph
kills
place
is
in
all
the
big
guys
and
the
document
I
am
sure
and
it
will
be
accepted
soon
and
if
you
have
any
desire,
you
can
go
and
comment
on
this
document
before
we
accept
it.
I
mean
we're
specifically
making
some
time
for
getting
feedback
from
from
the
community.
I
will
paste
a
link
to
this
document
in
the
channel.
C
A
C
Yeah,
where
I
move
it?
Okay,
yes,
so
basically,
we
have
two
types
of
integrations.
Mainly
admin
panel
integrations
it's
this
box
and
storefront
integrations.
So
the
eventual
graph
here
is
supposed
to
replace
all
rest
guys
for
storefront
integrations
and
rest
and
soul
are
still
going
to
solve
admin
panel
integrations.
C
Then
you
can
see
that
rest
and
soul
are
talking
to
service
contracts
and
sometimes
two
models
directly.
If
you
don't
have
service
contract
coverage
now
and
we're
on
Keo
is
going
to
talk
to
clarify
which
has
been
built
right
now,
and
the
service
contracts
in
case
of
some
persistence
operations
like
mutations.
Basically,
if
you
add
in
something
to
cart
or
modified
customer
account
from
cell
phone,
so
those
who
go
through
service
contracts,
but
all
queries
should
go
to
query
type
and
then
you
can
see
the
under
query
guy.
C
We
are
going
to
have
just
our
normal
high
storage,
our
primary
data,
and
we
also
try
to
route
as
many
queries
as
possible
to
our
indexes
to
make
requests
faster,
and
here
you
can
see
that
storefront
is
supposed
to
talk
to
grant
hill,
it's
possible
that
it
will
be
via
Ajax
calls,
or
we
even
planning
to
expose
PHP
interface
for
making
graphical
queries.
So,
let's
say
from
your
blog,
you
will
be
able
to
my
graph
QL
query
and
I'm
going
to
also
point
out
couple
high
level
requirements
where
technical
requirements
for
our
graphical
implementation.
C
So,
first
of
all,
we
are
going
to
support
unlimited
nesting
and
we
should
be
able
to
request
any
related
entities.
So,
for
example,
you
can
get
like
order
than
order
items
and
products
related
to
order
items
and
related
products
to
those
products.
So
basically
you
should
be
able
to
request
anything.
C
You
want
in
one
query:
huge
filtration
must
be
done
by
my
suppo
and
it
should
not
be
done
on
application
layer
as
it
is
done
now
for
service
contracts,
when
we
fetch
the
whole
data
for
the
object,
and
then
we
filter
out
with
a
couple
fields
in
return
to
third-party
customizations.
You
have
to
be
done
in
for
both
service
contracts
and
graft
help,
because,
as
you
can
see
here,
we
don't
have
like
shared
point.
So
we
get
the
different
implementations
on
this
side
and
on
this
side.
So
obviously
you
have
to
have
different
customizations.
C
C
Folder
of
your
queries
will
return
200
HTTP
status
code,
and
the
only
exception
is.
If
there
is
some
issue
with
schema
generation,
then
you
may
see
a
hundred
and
we
are
going
to
pass
store
code
via
headers
and
another
point
that
I
would
like
to
mention
is
about
libraries
that
we
are
using
to
build
on
top
of,
and
actually
this
is
Robo
next
vertical
PHP
library
and
according
to
our
investigation,
this
is
the
most
production-ready
library
illustrates
production
ready
yet
actually,
because
it
is
version,
is
0.9,
if
not
mistaken.
C
Actually,
it's
0.11
at
the
moment,
but
still
this
is
the
most
solid
version
that
we
have
written
for
PHP
and
also
it
is
implementation
of
the
same
library
which
exists
for
JavaScript
and
for
other
languages,
and
the
only
drawback
of
this
library,
I
believe,
is
that
it
has
poor
documentation
and
moments.
But
we
are
trying
to
mitigate
this
by.
C
B
Okay,
I
will
be
talking
about
the
let's
see
what
am
I
talking
about
the
schema
and
how
to
declare
it.
How
we
are
using
resolvers
I'll
show
you
the
products
query
that
we
are
using
and
also
how
we
handle
attribute
exceptions.
So,
first
off
with
the
schema
we
have,
as
you
can
see
here,
a
products
query
customer
query:
custom
attribute
metadata,
which
is
essentially
getting
front-end
types
from
the
backend
attributes
via
their
attribute
codes
and
entity
type
combinations.
B
Currently,
so
in
it
we
have
five
arguments
which
gives
you
pagination,
filtering
and
search
as
well
as
sort
input
and
I
will
show
you
how
we
go
about
declaring
that
so
inside
of
the
graph
QL
XML,
which
is
what
we
are
introducing
and
for
this
product
is
initially,
we
have
just
the
top
level
output
type,
which
is
query
and,
as
you
can
see,
that
is
always
what
you
will
be.
Your
entry
point
for
any
given
graph.
B
Kale
query:
on
our
end
point
and
on
this
query
we
will
add
the
difference,
sub
queries
and
in
this
case
this
is
products
which
is
has
a
type
of
products
and,
as
you
can
see,
we
declare
our
arguments
here
and
we
have
documentation
that
isn't
currently
being
shown
on
this
page.
But
soon,
we'll
have
a
just
actual
description
here
where
it
says
no
description.
We
have
not
completed
that
functionality.
Yet,
though,
and
as
you
can
see,
we
just
have
lots
of
declarations.
B
Basically,
we
have
your
what
you
would
expect
to
see
with
minimal
price,
maximum
price
and
regular
price,
and
each
of
these
has
adjustments
and
amounts,
and
a
really
good
thing
you
would
want
from
prices,
and
so
this
is
just
an
interface,
and
with
that
interface
you
have
to
declare
a
concrete
type
and
so
a
concrete
type.
The
most
basic
one
you
can
have
is
simple
product
and,
as
you
can
see,
we
also
declared
two
other
interfaces
that
simple
product
implements,
which
physical
product
interface
simply
gives
you,
the.
B
Simply
gives
you
weight
as
a
field,
and
so,
as
you
can
see,
we
add
these
interface
fields
automatically
by
simply
saying
on
the
XML
node
that
declares
simple
product
by
simply
saying
implements,
and
then
we
say
which
interfaces
it
implements
from
here
yeah.
We
are
sorry.
We
also
have
the
customizable
product
interface,
which
this
interface
gives
you
all
of
your
product
options
that
you
could
possibly
want,
and
we
also
implement
strict
typing
for
it.
B
Instead
of
having
just
generic
JSON
objects
with
all
fields,
so
with
customizable
field
option,
for
instance,
you
have
a
customizable
field
value
as
your
value,
which
has
very
specific
things
for
it,
and
all
the
other
ones
also
contain
type
specific
information,
rather
than
being
a
generic
object
that
contains
all
fields
for
all
of
them,
and
so
essentially
we
do
all
the
merging
automatically
for
these
type
declarations,
and
if
you
were
to
do
it
wrong,
it
would
be.
There
would
be
helpful
error
handling.
B
That
would
give
you
reasons
why
it's
not
generating
the
schema
correctly
and
we
hope
to
also
improve
that
in
a
future
just
to
make
it
more
robust.
But
as
you
can
see
here,
this
is
just
an
introspection
query
which
gives
you
access
to
your
graphical
endpoints
schema
and
you
can
get
all
sorts
of
information
about
your
type
system
here,
including
getting
it
about
the
top-level
query
and
so
on
and
so
forth.
B
G
B
Okay,
these
things
down
here
that
I
have
are
actually
named,
fragments
which
are
useful
if
you
want
to
separate
different
fields
for
different
types
from
your
main
query,
to
make
it
a
little
bit
cleaner.
So,
as
you
can
see,
I
have
things
like
bundle
fields
which
are
specific
to
bundle
product
and
all
the
custom
own
I
have
customizable
options,
I
showed
you
earlier
and
so
on
and
so
forth,
and
it
keeps
my
query
a
lot
cleaner,
which
allows
me
to
read
it
much
easier
and
I
can
know
like
okay,
these
are
configurable.
B
B
And
it
will
take
a
second,
and
so,
as
you
can
see
here,
we
have
a
variety
of
information
that
I
requested,
including
all
the
media
gallery:
entry
entry
information,
including
the
file,
the
type.
What
kind
of
content
you
can
expect,
and
media
or
information,
also
has
video
content
inside
of
it
too
oops.
B
B
And
see
exactly
what
that
items
field
contains,
and
so,
as
you
can
see,
we
have
quantity
and
position.
So
this
I'd.
This
particular
item
doesn't
have
any
quantity,
but
it
is
position
zero.
So
it
should
go
first
and
the
product
listing
and
we
also
have
a
field
called
product
that
gives
us
all
the
product
fields
that
we
could
expect
from
the
product
interface
and
once
again,
normally
before
and
rest,
you
would
have
to
query
all
the
children
products
separately
from
the
main
product
search
and
now
we
are
able
to
just
grab
it
all
in
one.
B
Go
and
same
goes
for
to
figure
more
products
which
I
can
just
show
you
the
fragment
that
it
uses
for
your
product
links.
We
get
all
in
one
go
same
with
bundle
which
has
items
with
a
SKU
for
each
item
and
all
the
options
associated
with
that
as
well
as
the
product
downloadable
gives
you
all
of
your
expected
downloadable
information
on
top
of
the
product
information
that
you
get
from
the
rest,
employment
and,
let's
see
what
else
it
has
attacker
pass.
A
B
I'll
start
with
attributes,
so
for
attributes,
as
you
can
see,
any
attribute
you
would
expect
from
a
product
are
all
available
on
the
base
as
a
base
field,
and
so
formerly
we
would
do
custom
attributes
and
extension
attributes
inside
of
their
own
containers
and
a
rest
call
and
all
avy
attributes
actually
I'm,
not
sure.
With
a
bee
in
a
container
arrest.
You.
B
Area
B,
specifically,
okay,
so
yeah,
so
all
of
our
attributes
used
to
be
in
different
containers
on
a
rest
call
and
it
would
be
up
to
the
client
to
go
through
and
iterate
through
all
those
we'll
figure
out
how
they
fit.
But
now
we
have
our
own
implementation
of
this.
Where,
specifically
for
our
product
in
point,
we
have
explicitly
declared
all
extension,
attributes
and
eav
attributes
where
for
the
custom
attributes,
we
actually
have
our
own
attribute
reader.
B
So
the
reader
that
takes
in
this
config
information
and
resolves
it
to
a
schema
also
uses
this
attribute
reader
which
for
products
specifically
in
catalog,
and
it
goes
in
and
dynamically
grabs
all
custom
attributes
that
might
be
associated
to
a
catalog
product.
And
so
you
can
see
here.
These
are
actually
all
custom
attributes,
including
color,
and
this
Erin
recommends,
which
is
claiming,
and
all
of
these
are
all
custom
attributes
specifically
and
they
get
automatic.
Basically,
when
the
schema
is
generated.
B
But
as
I
was
saying
earlier,
though,
extension
attributes
are
not
automatically
generated
and
they
must
be
in
our
implementation.
They
are
declared
explicitly
and
the
graphical
that
XML
so,
for
instance,
for
configurable
products.
Obviously
your
configurable
product
links
and
options
are
normally
extension
attributes
and
we
have
explicitly
declared
those
here.
However,
that
is
not
to
say
that
you
couldn't
write
your
own
reader
that
will
go
and
custom
or
in
creating
automate,
create
automation
to
grab
all
of
the
extension
attributes.
B
B
B
Okay,
so
let's
say
I
were
to
remove
entity
type
which
it
is
required
for
the
custom
attribute
metadata
endpoint.
So
now
we
have
a
very
specific
message:
saying
missing:
entity
type
of
the
input
attribute
code
skew
and
we
have
a
category
that
allows
you
to
bucket
the
message
and
handle
it
on
the
front-end.
B
It
will
give
you
a
masked
error,
which
will
just
be
internal
server
error
well
on
production
mode.
Now,
if
you
were
good
to
go
into
developer
mode,
though
you
would
get
a
stack
trace
as
well
as
for
if
it
is
a
localized
exception,
you
also
get
a
specific
debug
message
field
that
will
give
you
the
full
exception
message
and
yeah.
That's.
C
B
A
C
All
these
declarations
which
we
have
in
Tokyo
this
is
how
we
expect
start
front
applications
to
work
with
specific
entities
and
we
are
designing
those
independently
from
existing
rest
and
trying
to
optimize
it
for
certain
applications.
So,
basically,
you
should
not
expect
any
correlation
between
gravity
all
types
and
existing
data
entered
like
service
contract
that
they
did
two
phases
which
is
used
in
the
rest.
A
Cool
and
then
the
second
question
from
Matthew
was
around
the
testing
and
what
kinds
of
attributes
would
test
with
so
I
guess.
Part
of
your
question
is:
are
you
testing
with
large
attribute
sets
and
that
I'm
it
I'm
interpreting
that
to
me
and
just
scale-wise,
and
we
we
will
ensure
the
test
with
just
huge
attribute
sets,
because
we
know
those
are
in
the
wild
and
will
that's
that
gets
more
performance
and
I.
Think
the
second
half
for
your
question.
A
G
A
A
A
B
Yeah
I
will
show
you
now
a
resolver,
so
we
declare
our
resolvers
inside
of
the
graph
killed
on
xml,
where
the
field
is
declared.
So
now
you
wouldn't
declare
it
on
the
type
you
would
actually
declare
on
the
field,
and
so
our
resolver
for
products
is
this
class
right
here
and
it
implements
a
specific
interface
that
our
live,
our
library
that
we're
using
to
create
the
graph
QL
server
will
basically
call
a
callback
that
will
then
invoke
this
resolve
function
and
do
any
sort
of
data
fetching
and
arguments,
processing
and
transformation
of
the
data.
B
B
We
also
have
something
called
type
resolvers
which
take
the
interfaces
that
you
are
requesting
and
using
the
data
that's
returned
by
the
resolver.
They
will
determine
what
kind
of
concrete
type
should
be
passed
back
to
the
response
and
in
this
case,
I'm
trying
to
find
it
there.
It
is
so.
Here's
our
product
interface,
type
of
type
resolver
and,
as
you
can
see,
it
goes
in
and
checks
the
type
ID
in
our
data
and
if
it's
simple,
it'll
turn
a
simple
product,
if
it's
virtual
or
return
virtual
product,
this
will
be
more
configurable
in
the
future.
D
Ok,
so
I'm
going
to
be
demonstrating,
the
customer
part
and
I
will
share
my
screen.
This
requires
a
authentication
from
the
customer
part
and
we
have
a
payload
that
looks
like
this.
So
we
have.
We
have
demonstrated
products.
We
have
the
customer
part
which
has
a
schema
like
like
this,
so
you
would
be
able
to
for
the
front-end
purposes.
You
can
query
your
own
customer
right.
D
You
cannot
query
other
customers,
because
this
is
into
the
four
front
end
and
there
is
no
admin
super
user
that
can
query
other
customers,
so
you
can
have
access
to
all
your
information,
as
you
will
see
it
right
now
on
on
the
front
end,
plus
there
we
we
trimmed
out
some
secure,
fills
that
identify
your
token
or
stuff
like
that.
That
won't
be
exposed
to
the
front
and
also
your
addresses
and
which
one
is
intended
for
billing
or
shipping
or
and
so
forth,
all
right.
D
So
so
far,
this
identification
works
in
two
ways
same
as
the
Web
API
part.
The
rest,
of
course
the
rest
will
support
more,
but
we
actually
support
your
session
and
token
right.
So
what
is
what
is
session?
Let's
say
I'm
gonna
front-end
right
now,
so
I'm
logged
in
with
my
customer
I
will
be
able
to
actually
query
my
my
own
customer
without
providing
a
token
at
all.
D
D
D
As
you
as
you
see,
we
moved
a
lot
of
fields
around
and
we
will
continue
to
do
so,
so
you
guys
can
have
better
API
to
consider
and
have
all
the
data
at
the
fingertips
without
doing
a
lot
of
queries
or
as
graphical
as
more
fields
to
to
to
be
able
to
minimize
the
number
of
I/o
operations
that
you
do
for
rendering
front-end.
Ok,
so,
let's
say:
I
will
log
out
from
from
my
user
right
and
I
will
try
to
actually
query
the
same.
Customer
I
won't
be
able
to
and
I
will
getting.
D
I
will
be
getting
a
message
from
graph
qo,
which
is
the
user
message,
is
not
a
debug
message
that
okay
well
there's
something
going
on
and
I
don't
have
enough
authorization
now
the
way
you
can
pass
a
token
and
I
know
if
you're
familiar
with
if
you're
familiar
with
with
postman
and
I
have
a
postman
the
same
as
a
tab.
You
can
request
through
API
a
a
customer
token.
Alright,
so
you
use
this
endpoint,
you
create
your
token,
you
get
it
back
through
post
and
yet
then
he
has
this.
D
You
have
this
hash
tag
or
whatever
key
this
is,
and
you
can
use
it
in
in
the
headers,
something
like
that
as
an
authorization
bearer-
and
you
put
this
token
here.
Okay,
you
can,
you
can
use
postman,
but
it
becomes
kind
of
ugly
because
the
the
raw
payload
looks
like
this
and
it
becomes
very
unusable
for
for
a
developer
that
just
wants
to
use
this
software
right.
D
Unfortunately,
the
tab
graphical
does
not
support
on
overriding
of
any
headers.
So
far
it
has
like
query
variables
and
you
can
probably
see
if
you,
if
you
do
an
inspection
like
what
what
is
the
payload
given
right.
So
here
in
the
network,
you
can
see
here
well,
this
will
be
the
payload
I
will
copy
it
and
I
will
out
of
the
headers
and
but
we
we
found
a
application
that
is
compiled
for
Mac
or
Windows.
That
can
can
actually
support
all
this
stuff
and
it's
graphical,
but
as
an
app
regardless
from
from
from
chrome.
D
So
you
have
a
nice
interface
here,
similar
to
the
tab
one,
but
you
can
actually
edit
Heather's
right.
So
I'll
put
this
authorization
bearer.
I
would
query
my
own
consumer
without
having
the
session
right.
This
is
useful,
for
maybe
testing
was
useful
for
for
manual.
Testing
is
useful
for
not
having
a
session
right
and,
if
I,
if
I
get
it
wrong
right,
let's
say
I
added
this
and
I
put
the
wrong
bearer.
I
shouldn't
be
having
access
to
to
my
own
customer
right
and,
as
you
see
he
on
customer
there
there.
D
No,
there
are
no
arguments
right.
You
cannot
query
another
customers
ID
right,
and
this
is
intended
to
be
this
way.
Okay,
so
this
is.
This
is
the
part
where
we
demonstrated
the
customer
will
proceed
to
store,
but
what
store
specific
queries
are
is
that
okay,
well
I
will
have
a
product
here
and
in
my
Magento
installation
will
have.
D
We
will
have
this
product
which
has
been
assigned
to
two
stores,
so
I
created
my
second
store
and
I
have
one
name
here,
so
you
have
specific
values
for
for
this
stores.
Some
of
them
are
story
view.
Some
of
them
are
for
website
intended
and
so
forth.
So
I
just
have
jaws
level
back
like
this
name
and
and
the
second
one
I
just
have
another,
and
this
goes
for
I,
don't
know
anything
that
can
be
scoped
for
for
store
right
right,
so
I
I
will
edit
my
headers
and
we
added
the
store.
Second
right.
D
If
you
don't
specify
this
store,
it
will
actually
take
default,
one
so
I'm
expecting
the
payload
to
actually
come
with
the
second
name
that
was
intended
for
for
this
right.
I
think
you
got
a
question
there,
so
if
I,
if
I
put-
and
this
is
store
cause,
this
is
not
IDs
or
anything
right.
If
I
put
here,
the
default
I
would
get
I
didn't
save
it.
D
All
right,
so
the
next.
The
next
thing
that
I
will
demonstrate
is
actually
pricing.
We
we
modified
the
the
pricing
structure
as
it
was
in
the
API,
and
it
would
look
something
like
this
in
the
API,
you
would
have
a
float
price,
which
is
the
catalog
price
for
this
purpose.
We
we
joined
the
rendering
API
with
with
the
catalog
API.
Where
is
it
intended
for
for
rendering
purposes,
and
in
this
case
you
will
just
have
like
minimal
price,
maximum
price
and
regular
price
now
for
simple
products.
D
Then
the
actual
price
from
the
catalog
to
show
up-
and
we
can-
we
can
see
it
here
now
it
gets
more
complicated
where
you
have,
let's
say
a
bundled
product
or
configurable,
and
for
bundle,
player
and
configurable.
You
can
see
more
usages
like
okay,
well,
I
will
have
a
minimal
price
here.
I'll
have
a
maximum
price,
which
is
like
the
difference
between
the
minimum
configuration
and
maximum
configuration
you
can
have,
and
you
can
also
have
a
regular
price.
D
D
We
have
let's
say
this
test
for
customer
and
this
test
for
customer.
Its
usage
is
actually
quite
simple.
It's
similar
to
the
Web
API,
so
you
just
set
your
header
and
you
get
you
set
your
payload
alright
and
you
can
actually
get
a
response
and
then
you
you
do
your
assertions
very
similar
to
the
Web.
Api
is
actually
more
simple
because
way.
Api
has
soap
has
rest.
You
can
configure
more
stuff
in
this
header
map
and
this
more
car
but
I
think
for
this
purpose.
D
It
will
be
actually
far
more
simpler
and
we
did
provide
some
tests
for
all
the
payloads
that
you
seen
so
far
or
for
the
we
like
to
call
endpoints
but
they're,
actually
fields
that
have
some
arguments.
Okay,
so
the
last
thing
that
I'm
going
to
demo
is
the
Euro
resolver
that
happened.
This
is
a
feedback
that
we
received
from
our
pw
18.
That
is
doing
some
framework
that
will
make
usage
of
this.
D
A
D
D
He
will
still
resolve
to
the
actual
the
actual
entity,
and
if
we
look
at
the
database
like
how
how
renames
work
it
doesn't
matter.
If
you
query
an
old
URL
that
doesn't
exist
anymore
resolves
to
to
something
that's
current,
it
will
still
work
in
just
one
query:
you
don't
have
to
follow
the
chain
and
it's
it's
very
easy
to
use.
D
C
And
discussion
actually
in
comments
now
I'd
like
to
comment
on
a
couple
more
items.
I
respondent
would
like
to
mention
why
it
is
not
good
idea
to
auto-generate
graph,
kill,
endpoints
or
graphical
queries
based
on
service
contracts,
and
the
main
reason
is
because
we
will
lose
performance
benefits
in
this
case
in
case.
C
If
you
want
to
fetch
only
couple
fills,
he
will
still
be
fetching
the
whole
entity
using
service
contracts,
and
then
you
will
be
just
filtering
out
a
couple
fuels
on
application
well,
and
there
was
also
question
about
aggregating
results
from
third
party
systems
into
our
graphical
response
and
do
that
two
options.
One
option
is
already
mentioned
using
polar
client.
C
If
it's
ok
for
you,
if
it
fits
your
needs
and
second
option,
if
you
can
declare
custom
field
on
your
entity,
you
can
write
custom
resolver,
which
will
just
pull
data
from
any
sort
party
service
unit,
and
then
it
can
be
reused
from
back-end
as
well
like.
You
will
be
able
to
use
this
as
a
service
in
your
PHP
application,
not
just
from
JavaScript
client.
G
A
Thank
you
anything
else.
He
is
one
bringing
up
around
the
discussion.
What's
taking
place,
no
okay!
So
there's
one
last
thing
that
I
wanted
to
point
out,
which
is
the
documentation:
that's
been
written
already,
if
you
guys
could
just
go
to
deaf
dogs,
Magento,
there's
a
little
banner
here
that
points
out
that
we've
got
some
pre-release
docs
on
graph
QL.
So
if
you
open
that
up,
Kevin's
done
a
good
job
of
writing
some
content
here.
That
goes
over
a
lot
of
the
a
lot
of
the
themes
and
concepts
that
were
shown
here
today.
A
I
won't
I
won't
go
into
every
topic
here,
but
just
know
just
know
that
this
is
this.
Is
here
and
then
the
last
thing
that
I
wanted
to
point
out
was
that
all
of
this
is
already
in
the
to
three
public
branch
right
on
github.
So
if
you
guys
want
to
get
hands-on
and
actually
go
see
what
the
code
looks
like
your
feel
free
to
check
that
out
and
use
that
as
a
reference
for
for
conversations
again.
This
is
what
was
shown
here
today
is
just
a
carrot
state.
A
We
would
love
to
get
ideas
and
feedback
from
from
the
community
so
that
we
can
improve
our
product
before
the
release.
We
still
got
some
time
to
kind
of
be
able
to
react
and
with
that
that
I
want
plans
as
well
like
I,
said.
Core
API
is
probably
the
main
thing
that
that
we've
been
working
on.
It's
that's
between
now
and
release,
but
we
would
love
to
incorporate
any
meaningful
feedback
that
that
you
guys
suggest
to
us
so
again
encourage
you
to
come
talk
to
us
on
the
slack
Channel.
F
A
Here
and
it'll,
be
the
graph
QL
channel
would
love
to
come,
have
a
conversation
going.
It
was
good
good
discussion,
good
questions
from
you
guys,
so
we're
excited
to
get
this
out
and
get
this
get
this
further
improved
with
that.
This
concludes
our
demo
thanks
for
attending
thanks
for
everybody's
time
today,
it
was
good
to
me
everybody
until
next
time.
Thank.