►
From YouTube: Magento Architectural Discussion -- September, 11, 2019
Description
- Versioning in GraphQL
- Single mutation for adding products to cart + wishlist
- Reduce q-ty of error reports created in var/report
- Code style for GraphQL schema
- Graphql product filters
https://github.com/magento/architecture/issues/265
B
A
Of
the
cases
which
are
coverage,
removal
of
existing
fields
gradually
varied
application
addition
of
new
fields
to
existing
types.
It's
also
not
breaking
change,
because
customer
request,
specific
set
of
fields
and
it
doesn't
affect
the
customary
to
new
field
appears
in
the
schema.
However,
there
are
some
cases
when
it
is
difficult
to
make
it
resinous,
and
some
of
those
cases
are.
Let's
say
we
have
products
query
and
it
accepts
some
arguments,
and
then
we
decided
to
completely
redesign
set
of
arguments
for
products
field
by
product
query.
A
This
can
cause
a
problem,
this
name
and
so
it's
possible
to
solve
it
in
backward
compatible
way.
If
we
introduced
completely
new
query
instead
of
the
old
ones.
However,
it
gives
us
headache
business
name
and
we
always
don't
want
to
name
something
inappropriately,
just
because
we
need
to
find
another
alternative
name.
So
if
we
have
products-
and
we
introduce
another
beautiful
products,
just
with
different
arguments,
it
would
probably
make
sense
to
keep
products
name
in
as
previously
and
as.
A
Has
nothing
to
do
yes,
so
it
will
probably
be
some
products,
but
it
will
be
some
ugly
name
which
will
be
just
confusing
because
you
do
have
products.
You
will
have
some
some
other
kind
of
products
and
and
other
kinds
of
products.
Now
it
will
be
confusion
and
suggestion
is
to
introduce
agreement
that
we
can
use
suffixes
like
we
can
use
to
tell
you
one
or
the
two
so
I
suggest
to
start
from
with
two,
because
they
currently
will
have
some
real
one.
A
A
Alternative
solutions
which
were
considered
were
introduced
version
in
on
endpoint
level,
which
is
again
extremely
weird
for
graph
here,
because
usually
he
was
supposed
to
have
single
schema
you're
supposed
to
integrate
with
single
API
and
Poland
and
then
just
create
whatever
you
need
from
the
client
application,
and
there
was
one
more
suggestion
to
introduce
versioning
on
the
level
of
modules,
I
believe
and
it
would
be
tied
to
module
origin.
But
to
me
it
seems
also
complicated
and
I'm
sure
if.
A
A
Additionally,
after
some
time
we
can
go
back
to
original
name.
So
let's
say
a
couple
years
past
we
already
removed
products.
We
have
just
products
three
two
in
the
schema.
It
might
look
weird
as
well,
because
he
will
have
this
product
3
2,
but
not
product,
so
we
may
consider
going
back
to
products
after
sometimes
it's
another,
assuming
nobody
is
using
the
old
one.
Yeah.
D
A
In
source
applications,
you
can
do
that
when
you
control
application,
you
know
exactly
what
queries
are
made
to
your
application
in
case
of
graph.
Do
you
have
knowledge
of
both
queries?
I
used
oil
fields
are
actually
requested,
and
that
will
work.
However,
in
case
of
Magento,
it
is
about
format.
We
have
no
wave
on
what
clients
actually,
but
that's
just
extra
extra
optional.
A
C
A
E
E
C
F
A
Clients
and
now,
when
we
start
having
some
clients,
they
find
use
cases
which
just
don't
work
for
them
and
we
have
to
change.
But
this
old
should
have
real
clients.
I,
don't
think
we
will
have
any
like
major
changes
in
advice
anymore,
and
this
is
what
happened
in
our
rest,
so
we
had
version
incapabilities
design,
but
we
never
use
them
because
we
help
clients
basic
from
day.
One
I
would
say
at
least
like
in.
E
The
most
important
thing
is
collecting
input.
It
will
consist
of
school
quantity,
foreign,
school
selected
options
and
answers,
or
the
most
interesting
are
selected
interruptions
that
it's
described
in
the
document,
so,
for
example,
for
simple
products,
I
want
to
add
blue
cup,
with
my
special,
like
personal
personalized
cup,
to
the
shopping
cart,
how
the
mutation
would
look
like
I
will
add
school
its
cup.
When
did
you
selected
options?
E
E
24Option
ID
its
color
and
42.
It's
optional
value
ad,
it's
blue!
So
this
is
the
approach
higher
how
all
of
these
selected,
my
user
options
will
be
encoded
and
sent
in
this
request,
a
little
bit
different,
we'll
be
with
answered
options,
but
somebody
if
I
want
to
personalize
this
cup
that
some
I
don't
know.
That's
my
croissant
car.
E
So
the
same
approach
this
this
is
my
custom
options,
and
this
is
their
ID,
ID
and
value
whoa
most
will
be.
He
base64-encoded
one
important
thing
that
it's
not
like
client-side
work.
This
value
should
be
present
on
front-end,
which
means
that
products
require
needs
to
return
this
data
about
possible
options
that
are
available
for
this
specific
product.
E
If
we
go,
for
example,
at
virtual
product
called
the
same,
let's
say
that
we
want
to
add
personalized
membership
with
the
expression
data
cards,
so
we
will
have
the
same.
This
is
just
and
configurable
ID
and
value
the
same
approach
like
was
for
Cordy
column
and
what
options
you
know:
the
same
gift
cards,
its
entrance
options
with
amount.
E
E
This
is
specific
case
because
of
specific
magenta
behavior
right
now.
So,
if
a
bunch
of
products
is
headed
to
Cutler
options,
they
should
be
identical
all
the
for
all
children,
because,
right
now
we
don't
have
an
option
from
like
front
end
to
add
bundle,
products,
bundle,
child
products
with
different
options.
All
of
them
should
have
the
same
set
the
identical
set
of
options.
E
A
Just
like
to
clarify,
basically,
the
problem
is
that
you
have
to
assign
option
to
parent,
not
children,
and
there
is
no
way
in
current
structure.
If
you
don't
introduce
completely
new
mutation,
there
is
no
way
to
assign
any
options
to,
because
you
have
only
reference
to
a
parent
school
in
each
item
and
that's
why
compromise
was
not
to
complicate
ap
I.
A
Have
this
like
suboptimal
implementation
for
this
very
narrow
use
case
when
you
have
fixed
price
bundle,
product
with
custom
options,
and
if
you
have
dynamically
priced
bundle
product,
there
is
no
way
to
set
custom
options,
so
it's
only
for
very
specific
use
case.
We
have.
This
is
basically
the
most
dramatic
part
of
this
proposal.
Right
now,.
E
Probably
that's.
That's
it
about
this
proposal
mate.
In
order
to
achieve
all
of
this,
few
important
steps
need
to
be
implemented
is
that
we
need
to
give
front-end
information
about
these
selected
and
rental
options.
We
need
to
return
this
data
in
products,
query
and
then
front-end
will
be
able
to
get
this
data
and
send
it
to
ins
in
the
article
mutation
and.
E
B
B
D
Okay,
one
thing
this
proposal
is
doing:
is
it
separates
options
from
merchant
defined
options
from
via
input
options,
so
for
for
this
proposal
existed
to
two
big
families,
one
big
family.
This
is
a
family
of
options
which
merchant
gets
to
specify
an
admin
like
dropdowns,
multi,
selects,
checkbox,
everything
and
other
family
is
this
option
which
we
are
expecting
to
receive
from
from
an
from
a
buyer.
D
So
with
this
proposal
you
have
a
two
different
arguments:
one
is
entrant
options,
other
one
is
just
options.
So
if
you
want
to
specify
image,
you
have
to
put
this
image
into
entered
options
in
a
format
which
is
pretty
compatible
to
format
as
we
are
using
right
now.
This
is
a
graph
key
all
for
the
same
operations.
A
D
We
would
like
to
have
a
unique
way
to
identify
an
option
in
our
system
in
future
in
perfect
world.
Ideally,
we
will
use
kind
of
your
ad,
but
right
now
to
keep
the
solution
paper
compatible.
We
are
going
to
encode
the
information
about
option
type
option,
may
optionally
option
value
ad
and
yeah,
but
by
the
way
we
are
going
to
hide
this
from
from
a
developer.
So.
D
D
F
F
F
D
No,
actually,
you
don't
read
this
information,
because
for
f2
card
is
only
things
that
you
should
care
about.
This
merchant
selection,
as
eating
I
mentioned
yet
exist
the
difference
between
images
you
want
to
upload
to
print
them
on
page
and
the
options
that
you
can
choose
from
select
or
drop
or
checkboxes,
but
inside
of
this
family.
Actually
there
are
no
need
to
expose
such
information.
It's
not
to
say
that
that's
its
merchants
so
like
this
is
kebab.
Is
this
set
of
particular
options
by
the
way
you
know
these
different
prototypes?
I
D
D
G
D
D
F
F
F
So
one
of
the
reason
is
that
they
don't
just
don't
watch
what's
going
on
in
the
report
folder.
So
this
time
they
those
reports
accumulate.
Another
reason
can
be
is
if
there
is
a
critical
problem
happening
in
some
commonly
used
paths
and
with
many
requests.
Those
reports
can
accumulate
pretty
quickly.
So
that's
the
problem
and
there
are
a
couple
solutions
to
that
that
is
proposed.
So
we
discussed
this
last
time.
F
I
think
one
of
the
solutions
is
to
generate
the
cash
flow
for
each
such
exception
for
each
tower
and
create
report
file
based
on
this
cash,
meaning.
The
name
of
the
file
is
some
discussion
and
in
in
that
way,
log
only
only
unique,
unique
errors
so
like.
If
there
will
be
several
errors,
several
sign
errors
happening,
they
will
not
be
creating.
They
will
not
lead
to
creation
of
several
files.
The
Bokashi
is
based
on
request,
URI
and
screen
name
and
exception
exception,
Trace,
exception
message.
F
H
A
F
D
F
E
F
F
J
I
F
F
G
F
F
F
F
I
would
say
that
first
recommendation
would
be
to
monitor
it
and
make
sure
that
it
doesn't
happen.
So
I
would
not
optimized
flow
for
this
case,
because
this
is
an
exceptional
case,
and
this
just
shouldn't
happen,
and
the
problem
is
I,
think
actually
I,
don't
know
what
my
sequel,
my
sequel
lights,
but
still
you
need
some
kind
of
configuration
for
that.
F
H
D
G
D
G
Please
read
this
document
careful
and
I
found
answer
on
your
question.
There
are
two
different
problem.
One
of
size
of
files
is
why
we
don't
write
it
in
one
files
and
another
is
already
of
right
exception
in
the
exception
block
file.
So
if
you
need
just
exceptionally,
you
can
read
exception.
What
and
on
our
platform,
you
already
configured
it
to
break
right
to
some
amount
and
send
even
irritated.
G
C
F
So
Khan
style
guidelines
for
graph
GL.
There
are
some
non
written
agreements
about
code
style
in
graphical
schemas,
so
I
just
wanted
to
write
them
down.
Original
I
just
created
a
task,
but
there
is
already
some
discussion,
so
I
thought
that
we
can
talk
about
it
here
on
the
meeting
and
based
on
that,
we
can
create
a
document
for
the
dots
there
later
so
now.
The
agreements
that
we
have
is
the
first
one.
We
should
use
quantity
instead
of
qti,
so
just
to
not
shorten
names.
F
Then
you
should
use
camel
case
for
queries
and
mutations.
It's
fields
in
graph
QL.
Then
again,
we
should
use
camel
case
for
arguments
as
well.
Right
now
looks
like
we
have
both
camelcase
and
snake
case
for
arguments.
So
I
guess.
The
proposal
is
to
stick
really.
Okay,
as
we'll
have
a
test.
It
will
help
us
then
opportunities
for
Phibes
and
snake
case
for
fields.
F
C
It's
correct:
it's
not
convenient
and
that's
an
understatement,
because
anything,
that's
inconvenient
for
the
front-end
incurs
the
payload
pit
or
some
sort
of
performance
problems.
So
we
don't
want
to
download
a
library
just
to
convert
those
snake
case
representations
and
the
counties
and
also,
why
are
we
even
being
inconsistent
in
the
first
place
right?
Everything
else
is
camel
case.
Why
are
the
fields
snake
case
right
just
doesn't
make
sense.
C
K
D
By
mistake,
so,
fortunately
we
can
I
change
this.
It's
like
a
compatible
manner
to
duplicate
all
existing
fields
introduced,
and
you
want
all
these
new
fields
go
with.
You,
you'll
be
supported,
oh,
and
this
is
pretty
straightforward
because
we
was
only
we
have
we
have
to
be.
We
just
have
to
rub.
Our
resolver
see
is
the
kind
of
you
know,
mapper,
which
will
transform
a
new
camel
case.
I
have
to
ask
my
case
and.
D
This
is
another
question,
I
would
say
because
eav
this
is
okay,
Eevee
attributes.
This
is
right
now
this
is
a
schema,
but
this
is
something
which
is
specified
by
immersion,
so
I
I
believe
that
it
potentially
can
be
a
part
of
exception.
Yeah.
Definitely
I
I
would
prefer
to
have
everything
in
camo
camp
camel
case,
but
became
disguises
separately,
but.
A
C
A
C
A
A
F
I
So,
based
on
the
new
lead
navigation
changes,
what
we
are
going
to
do
is
the
baby
Ivana
filter
products.
They
are
going
to
dynamically,
generate
all
the
Vav
attributes
on
the
schema
so,
and,
and
also
along
with
a
particular
change
application
which
is
going
to
return.
What
are
the
possible
attributes
that
can
be
filtered
on
based
on
a
given
search?
So
the
thing
is,
the
problem
that
that
could
be
problem
is
approach
which
could
which
could
be
like
that.
I
If
that
is
any
changes,
if
they
are
you
here,
we
are
fitness
being
added,
then
the
scheme
needs
to
be
refreshed.
That
is
one
and
the
way
the
currently
the
clients
have
to
bar
various
attributes
used
to
be
some
of
the
applications
they
need
to
map
each
of
the
attribute
code
with
the
custom
added
metadata
putting
under.
I
So
these
are
the
problems,
so
the
idea
was
to
make
this
little
more
generic,
so
instead
of
dynamically
generating
this
attribute
of
the
schema
based
on
so
the
clients
can
know
what
are
the
attributes
that
can
be
based
on
this
particular
aggregation
itself,
and
then
they
can
use
those
attributes
to
filter
it.
So
the
difference.
So
the
current
query
is
going
to
be
like
this,
which
is
found
in
products
filter
and
each
of
the
attributes
which
is
currently
from
to
derive
from
the
schema
this
one.
You
proposed
it.
K
A
I
A
I
I
Right
and
so
how
will
the
clients
know
if
any
hey
we
attribute
is
being
added
so
based
on
this
current
approach?
So
whenever
a
pneumatic
we're
just
being
added,
they
need
to
clean
their
cache
of
the
custom,
attribute
particular
query.
So
how
will
the
clients
know
that,
if
any
way
at
if
it
is
being
added
on
seven.
I
I
A
F
A
F
I
Also
one
other
community
member
image
and
the
issue
like
so
because
some
stores
generally
have
like
hundreds
of
attributes
and
having
more
number
of
addresses
the
schema,
so
even
the
adjusting
to
go
with
a
collection,
kind
of
approach,
which
is
similar
kind
of
an
approach
rather
than
like
a
flooding.
The
schema
with
all
the
set
of
attributes
Eiling
is
an
attic
type.
It
can
accommodate
all
the
site
abuse.
What
are
the
type
it
belongs
to.
A
Okay
and
that's
something
that
we're
discussing
some
other
okay,
so
I
mean
if
you,
if
you're,
really
interested,
you
can
probably
invite
you
into
those
discussions,
but
I
would
probably
not
merge
this
now
because
it
doesn't
solve
issue
make
it
solve
it
in
one
specific
place.
But
at
the
same
time
it
doesn't
help
much
because
motions
to
come
to
clear
that
Pollak
publication
customer.
A
A
If
you
catch
something
on
one
side,
I
mean
so
it's
your
problem,
you,
but
you
can
detail,
you
probably
have
to
wear
them
to
detail,
inspires
and
then
the
page
is
clear.
If
you
like
on
server-side
cash,
then
make
a
way
to
clear
brush
cash
from
so
very
safe.
It's
varnish.
We
can
tax
and
we
can
do
that.
But
if
you
put
that
me.
I
Yes,
so
you
know
think
it
might
break
their
quota
for
a
prank.
So
let's
say
when
viewing
the
application,
when
a
new
attitude
is
being
at.
It's
gonna
come
up
on
the
client
side,
but
then
you
either
get
is,
since
they
are
going
to
be
cashing
this
customer,
whether
it
our
query,
so
this
is
not
going
to
be
a
new
market,
is
still
not
be
available
on
the
cached
version,
so
that
will
be
some
inconsistencies
so.
A
Body
method,
they
will
release
that
show
irritations,
response,
I
suppose.
Hence
the
response:
how
can
we
call
this
feel
my
fingers
hold
all
the
code
aggregations
now,
so
in
response
to
products
we
give
possible
applications
and
in
scope
on
those
applications.
We
can
that's
yeah.
That
might
make
sense.