►
From YouTube: Magento GraphQL Community Meeting, 27 September 2018
Description
Agenda:
1) General updates about Pull Requests processing, current issues (@vnayda)
2) Status of "Schema for adding shipping/billing addresses to cart" prototype (@Yaroslav Rogoza @Vitalii Boiko)
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
So,
first
of
all,
by
the
way,
our
status,
we
published
it
our
status
each
week
on
our
tableau,
so
we
became
more
transparent
and
but
it
can't
read
our
status
and
we
are
going
to
do
this
each
week.
So,
let's
start
from
our
blockers
and
issues
Julianne's
this
week,
we
not
just
request,
is
small
image
and
if
you
remember,
I
talked
about
that.
This
pool
request
contains
some
changes
in
benchmark.
During
rush
this
request
online.
A
We
had
a
few
issues
related
to
our
performance
view,
but
all
of
these
issues
were
resolved
it,
and
this
pull
request
already,
did
not
mind
it's
important
for
us,
because,
if
you
put
a
quest
was
blocked
at
with
this
functionality
and
this
pull
request
market
a
special
challenge
because
it
was
important
for
us
next,
our
issue.
Our
blockers
was
about
18,
simple,
proper
to
cart.
Now
we
finished
additionality
and
started
to
this
request
nurturing
progress.
A
A
We
had
meeting
these
guys
from
engineering
team
and
we
decide
to
include
our
architectural
repository
in
our
points,
perverse
programs,
our
points,
if
you
don't,
we
have
absolutely
absolutely
open
architecture
repository
and
now
anybody
would
not
only
contribute
some
port
but
also
share
his
ideas
and
he
takes
changes.
And
yes,
of
course,
for
all
of
this
request.
A
If
you
provide
some
additional
points,
point
contribution
points,
but
we
still
need
to
think
about
how
many
points,
because,
for
example,
if
it
is
big,
polar
quest
with
some
big
changes
with
some
character
changes,
it
should
be
appreciated
in
more
points.
So
now
we
have
only
one
open
question:
it's
about
count
of
points
of
how
much
points
we
need
to
provide
for
this
pull
request,
but
I
think
your
slow
ass
get
about
this
possibility
was
tweaked
and
I
think
we
will
start
this
program
from
from
next
week.
A
And
finally,
interesting
discussions:
at
last
week,
Alex
Parrish
created
proposal
for
a
deanship
in
building
address
to
shorten
part
and
slow
pupusa
and
Vitaly
Boyko
started
work
on
these
questions.
This
prototype
at
hackathon
and
three
also
marcus's
pull
requests
as
complex,
because
it
read
with
some
example
for
another
task.
It's
done
base
way,
so
we
are
slow
is
in.
You
will
share
more
information
about
this.
B
So
as
well
as
I
said
during
the
last
week,
we
worked
on
the
code
functionality,
particularly
on
adding
shipping
address
billing
address
and
settings
shipping
methods
on
the
code.
Also,
we
have
provided
a
prototype
for
getting
available
shipping
methods
on
current
shopping
cart,
so
we
still
working
on
the
prototypes,
but
it's
like
it's
only
the
beginning
and
during
providing
these
prototypes.
We
also
introduced
like
a
basic
concept
of
the
schema
for
working
with
these
actions.
B
Actually,
this
concept
has
been
developed
earlier,
but
we
we
have
just
improved
it.
I
added
some
some
new
points
and
remove
the
old
one
so
yeah
and
we
met
one
difficulty
implementing
the
logic.
For
quote,
it's
a
possibility
to
use
single
address
like
checkout
or
multi
multi
ship
and
check
out,
and
the
main
problem
is,
if
you
look
at
this
scheme
on.
B
The
main
idea
of
this
schema
is
to
have
a
transparent
Andrew
points
for
working
with
multi
shipping
and
with
single
shipping
cases,
but
actually
we
still
not
sure
the
best
way
to
implement
it,
because,
as
you
can
see,
if
we
we
will
make
it
transparent
on
this
level
and
if
we'll
use
multi
shipping
for
handling
all
addresses
no
matter,
we
have
one
address
for
both
or
multiple
addresses.
It's
not
like
active
way,
because
the
multi
shipment
functionality
is
very
complex
and
it
it
doesn't
make
sense
to
use
it
for
the
single
shipping.
B
So
this
English
in
case
because
in
most
cases
we'll
have
the
single
shipping
and
yeah.
That's
the
point
for
discussion
about
the
best
way
to
implement
it.
So
the
ideas
or
the
ideas
where
we
can
leave
it
as
it
is
so
we
can
use,
for
example,
on
this
query
we
can
use,
we
can
set
shipping
addresses
on
card,
so
it
will
be
the
single
or
the
single
entry
point,
and
if
we
provide
just
one
address,
we
will
like
detect
int
or
detect
it
on
the
resolver
level,
and
then
we
will
decide
what
to
use.
B
If
we
have
only
one
address,
we
will
use
a
single
shipping
flow
and
if
we
have
multiple
addresses,
we
will
use
the
multiple,
a
multi
second
functionality,
but
yeah
that's
the
one
case:
it's
not
like
very
transparent,
but
we
at
least
will
have
this
schema
more
or
less
optimized.
The
second
way
is
to
provide
two
different
types
of
entry
points.
Separate
group
for
single
shipping
and
separate
group
promote
multi
shipping,
and
in
that
way
we
will
have
more
entry
points,
but
we
will
not
have
a
lot
of
complex
logic
in
our
results.
B
C
Cool
yeah
I
agree.
We
here
internally
talked
about
similar
possibilities:
I
I,
don't
I,
don't
exactly
remember
if
we
100%
settled
on
one,
but
we
we
talked
about
similar
options
having
either
different
entry
points
with
simpler
logic
or
just
you
know,
use
use
one
common,
one
and
then
kind
of
under
the
covers
have
more
complicated
logic.
That
routes
either
a
simple
way
or
the
multi
shipping
logic.
C
So
if
maybe,
if
schema
works
out
to
a
to
a
common
set
of
fields,
maybe
one
a
two
point
makes
sense
but
I,
just
since
you
guys
are
actively
working
on
this.
Let's
have
a
maybe
a
one-off
meeting
to
to
discuss,
and
then
you
know,
whoever
whoever
is
interested
can
can
participate.
I'll,
probably
organize
it
through
slack.
If
that's
okay,
all
right,
you
guys
think
it
makes
sense
to
have
an
one-off
on
the
subject.
Yeah.
B
C
Great,
let
me
yeah,
let
me
take
the
action
item
of
scheduling
it
I
know
so
Alex.
Our
architect
here
is
out
this
week,
so
I'll
probably
schedule
for
really
next
week,
so
we
can
get
together
and
talk
us
through
but
yeah.
This
is.
This
is
great.
Maybe
maybe
one
more
question
I
have
about
this.
You
guys
said
that
you
made
certain
changes
to
the
schema
I.
Were
you
guys
using
the
schema
suggested
they
were
proposed
by
Alex
as
the
base
yeah
yeah.
B
C
B
One
more
change
we
have
provided
we
add
that
card
a
ID
to
the
input,
because
we
have
all
mutations
all
operations
related
to
the
code,
to
the
shopping,
cart
with
cart,
ID,
for
example,
I
didn't
coupons
or
products
or
whatever.
So
we
have
probably
have
added
the
cart
ID
here
as
well,
here
and
everywhere
for
the
input
yeah.
C
Yeah
now
that
that
makes
sense,
okay
and
the
changes
that
you
guys
are
proposing
are
you?
Are
you
guys
making
comments
on
that,
be
like
the
the
proposed
scheme
on
by
Alex
Orion?
Do
you
do
you?
Have
your
own
car
I
just
want
to
make
sure
that
we
have
all
the
feedback
kind
of
in
one
place,
yeah
yeah?
Actually
we.
B
C
Yeah
I
think
so
so
you
guys
can
either
do
that
or
or
leave
comments,
but
I
understand
in
the
interest
of
I,
guess,
rewards
and
other
things
that
you
you
can
you
can
do
it
via
pull
request.
So
if
you,
if
you
guys
want
to
do
that
this
week,
maybe
that's
we
can
also
discuss
that
on
the
on
the
call
early
next
week,
so
that
we
can
kind
of
quickly
consolidate
into
it
come
to
a
decision.
Okay,
great!
Thank
you!
Cool
yeah,
thanks
for
thanks
for
working
on
this
today.
Also.
A
We
had
one
question
about
parameter
of
cart:
do
we
need
to
retune
Curtis
output?
She
said
hard
recipe.
For
that
mistake.
Do
we
need
to
return
hard
object
if
he
said
said
billion
I.
A
C
Think
it
was
done
out
of
assumptions
that
that
would
be
like
if,
if
we
always
return
cart,
whenever
we
make
modifications
to
it,
it
becomes
easier
on
the
on
the
client
to
deal
with
it.
But
I.
You
know,
that's
I,
guess
that's
a
that's
a
point
up
for
discussion.
I
think
it
was
done
intentionally
but
based
on
just
certain
assumptions.
If
we
have
reasons
to
change
it,
let's,
let's
discuss
those
as
well
yeah.
B
I
I
can
clarify
the
question
so
oh
yeah,
for
example,
it's
not
correct.
It
was
hard
as
well.
It's
just
temporary
change
so,
for
example,
we
eat.
According
to
this
schema,
we
need
to
return
card
after
setting
a
shipping
method
on
on
this
shopping
cart.
But
in
some
cases
we
have
only
a
address
ID,
for
example,
and
coat
ID,
and
we
can
set
the
shipping
method
without
getting
the
address
information.
But
if
we
check
the
card
object
here,
we
need
to
return
addresses
in
this
case
all
this
data.
B
B
Id
yeah
that's
possible.
We
can
create
a
separate
like
helper
or
something
for
this
purpose,
but
I'm
not
sure
from
the
performance
perspective.
If
we
need
to
get
the
address
data
so
on,
if
we
only
need
ID
for
our
resolver,
so
it
will
be
much
slower
in
this
case,
so
we
need
to
set
something,
and
then
we
need
to
get
data
from
the
database
to
return
what
we
don't
work
with
this
data
directly.
So
that's
like
not
very
clear,
yeah.
C
No
I
see
I
see
what
you're
saying
it's
a
good
point.
I
know
when
we
looked
at
current
version
of
check
out.
Sometimes
they
in
certain
flows
I
forget
now
what
they
are,
but
even
even
when
you
provide
you
know
hande
that
comes
we
provided
address
IDs.
It
still
went
and
sent
all
of
the
fields
anyway
in
some
of
the
flows,
so
it
was
probably
not
ideally
optimized,
and
but
you
don't
here
here
in
graph
tool,
we
can
do
you
know
this
is
this.
This
is
not
necessarily
grounded
in
any
sort
of
current
implementation.
C
A
So
generally,
I
will
prepare
some
agenda
for
grooming
because
looks
like
we
have
a
three
questions
and
we
will
makes
a
meeting
next
week.
Maybe
it
makes
sense
to
report
this
meeting
holes
yeah,
agreed
so
and
final
update
from
my
side.
We
we
had
one
two,
three
four
phone:
you
pull
request
created
during
this
week
and
I
am
going
to
review
of
this
pull
request,
but
I
have
only
one
advice.
If
you
see
that
you
have
read
view
static
so
on,
please
don't
eat
the
waiting
for
review.