►
From YouTube: Magento Architectural Discussion -- August, 14, 2019
Description
- RoutableInterface proposal for PWA to route all URLs
- Enforce product SKU uniqueness at the database layer
Meeting minutes - https://github.com/magento/architecture/issues/227
A
B
The
graph
QL
API
currently
supports
something
called
URL
resolver
and
that's
a
specific
query
that
was
made
based
on
a
request
by
the
PWA
team,
to
have
something
available
for
us
to
request
the
to
send
a
URL
key
as
an
argument
to
a
graph
to
L
query
and
then
receive
the
entity
type
of
the
page,
the
identity
of
the
page
within
that
table,
and
then
potentially
some
later
properties
could
be
added
to
the
schema
there.
So
that
was
implemented
for
us
quickly,
so
that
we
could
begin
respecting
business
user
managed
to
storefront
routes.
B
B
Gradual
query
that
runs
whenever
you
navigate
to
a
new
page
when
I
perform
that
navigation.
All
that
the
client
side
app
was
aware
of
was
that
I
attempted
to
navigate
to
the
URL
veniat
tops
the
location
that
is
represented
by
the
URL
veniat
ops,
that's
maintained
in
the
in
the
category
entities
and
then
handled
in
the
routing
table
and
the
SEO
redirects
under
under
Magento
architecture,
but
there's
no
way
in
the
client-side
application
to
maintain
a
full
mapping
of
every
single
URL
to
every
single
entity,
and
since
the
PWA
is
fully
api
driven
at
runtime.
B
B
What's
the
corresponding
type
and
IDR
for
the
URL
veniat,
ops,
HTML
and
the
URL
resolver
query
responds
with
a
special
string
that
belongs
to
an
enum
which
is
extensible
by
various
Magento
modules.
The
catalog
module
adds
the
string
category
to
the
enum,
for
instance,
and
the
ID
represents
the
unique
I
guess
primary
key
within
the
the
the
identity
table
for
these
entities.
B
So
when
we
receive
category
and
and
then
19
that
gives
the
PWA
enough
information
to
proceed
with
fetching,
not
just
the
actual
entity
for
the
category
itself,
but
also
to
fetch
a
particular
named
additional
piece
of
code
in
this
case
root
component
category,
which
you
can
see
here,
which
then
fetches
in
this
the
sorry.
The
logic
that
is
specific
to
displaying
at
this
category
page
in
its
pagination
and
this
way
the
progressive
web
app
makes
sure
that
it's
only
fetching
what
it
needs
to
display.
B
So
this
connecting
enumeration
seems
like
it's
unnecessary,
because
graph
QL
already
provides
a
means
for
introspection
into
the
type
of
something.
So
this
proposes
a
type
called
route,
which
is
an
interface
and
any
entity
which
can
be
displayed
as
a
page
would
implement
that
interface.
If
it
already
implements
another
interface,
then
it
would
use
the
multiple
implementation
feature
of
graph
QL
to
implement
that
and
then
implementing
that
interface
would
by
itself
signify.
B
So,
for
instance,
if
the
root
query
that
returns
items
of
this
type
received
a
product
URL,
we
could
request
the
type
name
which
is
built
in
to
the
graph
QL
specification,
and
it
would
return
the
concrete
type
which
implements
product
interface
in
this
case,
and
that
should
be
enough
for
us
to
go
through
our
projects
and
identify
if
there
is
a
particular
component
that
can
do
that.
So,
for
instance,
right
now,
the
structure
of
our
project
requires
that
any
given
return
value
from
the
URL
resolver
be
supported
by
a
particular
component.
B
B
Another
advantage
to
this
is
that,
with
the
route
type
that
is
actually
a
particular
trait
or
interface
of
a
real
data
type,
we
no
longer
have
to
place
one
query
to
get
the
type
of
the
entity
in
question,
which
already
indicates
that
the
system
that
was
about
the
entity,
we
don't
have
to
place
two
queries
to
get
the
entity
metadata
and
then
the
data
itself.
Instead,
we
can
have
a
sequence
of
concrete
type
clauses
so
that
when
we
fetch
a
route,
we
already
know
for
various
different
content
types.
What's
additional
properties
we
need.
B
But
the
idea
is
that,
for
instance,
you
could
use
it
as
a
simple
tagging
scheme
or
flagging
scheme
so
that
an
extension
developer
or
theme
developer
could
replace
the
theme
variant
drop-down
for
a
given
entity
with
the
drop-down
that
supports
some
iteration
of
these
things.
So
then,
when
we
request,
for
instance,
the
product
foo,
it
returns
a
display
metadata,
a
value
of
featured
that
would
allow
us,
in
our
root
component
dispatch
to
actually
route
different
individual
entities
to
different
route
component
of
limitations.
You
can
see
right
now.
B
The
component
category
is
actually
called
root
component
category
default.
This
doesn't
specify
default.
But
since
these
directives
can
take
arbitrary
additional
properties,
then
you
could
have
two
competing
or
two
complementary
implementations
of
a
product
page
and
then
in
the
entity
itself.
Using
the
display
metadata
string
value,
the
back-end
could
store.
B
Eav,
like
properties
to
indicating
given
product,
has
a
different
treatment
like
a
dark
mode
or
feature
of
your
microsite.
So
this
also
enables
a
simple
place
to
store
routing
data
instead
of
having
to
replicate
the
logic
for
routing
across
our
middle
tier
frontier,
at
our
back
tier,
so
in
both
supporting
graph
QL
as
an
actual
underlying
schema
for
the
site
map
in
allowing
for
a
simple
place
to
store
extensibility
data
and
in
supporting
fewer
calls
to
get
the
same
information.
B
I
think
this
is
a
big
advantage
over
URL
resolver,
and
it
also
is
part
of
a
concept
that
we
are
supporting
more
and
more
on
the
PWA
team,
which
is
to
sort
of
store
as
much
about
the
extension
system
that
is
supported
or
the
exhorting
the
the
extension
state
that
the
store
is
in
what
modules
are
turned
on.
What
custom
pages
exists
to
display
that
in
the
graph,
QL
schema
as
much
as
possible?
B
So,
in
this
case,
for
instance,
create
account
even
if
it's
a
built
in
route
would
actually
be
implemented
as
a
simple
graph,
QL
type
just
enough,
so
that
when
we
request
from
our
client
side,
what
is
the
identity
of
create
account,
it
does
at
least
return
a
type
name.
These,
of
course,
seem
like
you
shouldn't
have
to
bounce
off
the
server
to
do
it,
but
potentially
in
the
future,
there
would
be
enhancements
by
which
we
can
analyze
the
schema
at
build
time
in
order
to
build
these
routes.
C
B
Layer
updates
in
this
case
are
not
fully
supported.
It's
like
layout
updates
have
a
lot
of
complex
features,
and
so
this
is
a
move
in
that
direction.
But
right
now
all
we're
doing
is
using
built-in
graph
QL
introspection
to
get
the
type
name,
as
just
as
a
string
for
us
to
use
in
our
own
product
to
resolve
things
like
route
components.
So,
unlike
layout
directives,
this
is
much
simpler,
binding.
B
It
doesn't
have
instructions
in
it,
besides
a
type
name
which
you
can
then
search
for
implementations
of,
and
maybe
one
string
value
that
we
could
later
use,
but
this
already
exists
in
our
graph.
Ql
schema,
you
know
I'm,
so
you
know
this.
This
shouldn't
be
too
much
of
an
implementation
burden.
Yeah.
B
That
would
require
that
they'd
actually
be
declared
in
a
schema,
so
implementers
of
graph
QL
today
and
people
refactoring
the
graph
QL
scheme
as
it
stands.
We'd
have
to
additionally
write
this
type
information
into
the
schema
document,
or
whatever
generates
the
schema,
you
would
need
to
add
something
that
declares
routable
types
like
this
to
say
that
they
implement
the
routable
interface.
C
D
D
To
return
a
specific
product
type,
it
is
easy
to
say
that
specifically
represents
product,
because
we
can
just
use
some
regular
expression
and
we
know
like
how
it
works.
On
the
back
end,
we
take
URL.
We
look
at
your
little
write
table.
We
find
the
base
URL,
which
is
like
products
ID
and
then
idea
of
the
product
or
category
ID
I
give
the
category
and
person
that
URL.
We
know
that
this
is
product,
for
example,
but
we
hope
we
have
no
way
of
knowing
type
of
that
product.
D
B
D
A
A
B
We
can
I
mean
we
want
to
support
it,
but
if
there's
a
significant
performance
burden
to
it,
I
think
it
would
still
a
useful
for
us
to
know
whether,
for
instance,
it
implements
product
interface,
but
that's
more
complex
to
do
in
the
graph
QL
intersection
language.
You
know
in
in
this
demonstration,
like
we
just
asked
for
possible
types
at
Build
time
on
routable
interface,
and
it
would
return
us
this
full
list
of
all
of
the
concrete
types
which
implements
it.
That's
not
to
do
with
any
particular
entities.
B
B
But
since
we
could
say
a
component
might
exist
that
displays
both
simple
products
in
configurable
product,
then
we
would
just
have
to
have
that
component
say
list
fully,
that
it
supports
simple
product
and
configurable
product
and
product
interface,
and
then,
maybe
all
that
we
would
receive
from
the
from
the
query
that
returns
the
route
when
we
request
for
type
name.
It
would
have
to
be
the
concrete
type
right
because
that's
graph
QL
s
actual
implementation,
but
we
can
ask
for
what
interfaces
are
implemented.
B
I,
don't
know
offhand
what
intersection
that
is,
but
if
that's
cheaper,
we
can
do
that.
Instead,
we
just
you
know
we
would
need
then
to
make
sure
we
have
more
complex
type
query
than
that
and
see
if
we,
for
instance,
have
a
component
that
can
that
can
display
anything
of
type
product
interface.
So
we
can
make
compromises
here.
I
just
know
that
we
want
to
use
the
type
system
wherever
possible.
D
E
D
D
B
I
hope
that
implementing
an
additional
interface
and
an
existing
type
would
not
be
a
backwards
incompatible
change
because
it
doesn't
make
any
existing
type
queries
break
as
far
as
I
know,
but
I
don't
want
this
to
be
a
backwards,
incompatible
change.
We
I
can
change
this
proposal
until
it
isn't
one.
If,
if
we
see
that
it
is
1.
B
Hope
so
another
possibility
would
be
that
that
we
still
have
to
to
conduct
two
queries,
which
is
acceptable
because
there
are
still
other
advantages.
But
since
I
guess
it
just
makes
sense
to
us
that,
since
the
graph
QL
Curry
is
already
finding
out
that
it's
a
category
of
ID
19,
then
it
makes
sense
because
of
graph
QL
being
what
it
is
that
we
would
also
fetch
that
link.
Whether
we
would
kind
of
in
theory
do
that
join.
D
B
But
even
in
the
case
where
the
built
application
encounters
a
URL
of
a
type
that
it
doesn't
know
how
to
handle
or
that
this
doesn't
this
can't
fetch
it
at
least
will
load
the
the
base
app
shell
and
then,
if
there
is
another
component
which
subscribes
to
the
output
of
that
query,
then
that
could
act
that
can
one
can
perform
a
follow-up
inquiry.
So
that's
just
that's
the
less
optimized
pathway,
but
we
still
want
to
support
it.
B
On
the
other
hand,
right
now
we're
not
using
fragments
very
much,
but
we
want
to,
and
we
want
to
be
able
to
say,
modify
a
query
at
build
time
so
that
it
can
include
more
fragments.
Potentially,
we
would
make
the
route
query
special
so
that
the
build
time
process
would
actually
edit
the
query
tree
in
place
before
writing
it
out
onto
the
filesystem
as
a
bundle.
B
Because
the
business
user
should
be
able
to
change
routes
in
vania
like
this
Valyria
to
layer
tank,
that's
a
URL
key,
that's
controlled
on
the
admin
side
in
the
product
entry
form
or
is
controlled
by
the
data.
That's
like
uploaded
through
an
integration
and
the
only
way
to
route
that
client
side
would
be
to
build
all
of
that
data
into
the
the
application.
B
That's
delivered
at
the
client,
which
would
mean
like
putting
it
as
a
big
literal
object
into
a
javascript
file
so
for
a
large
site
or
with
a
large
catalogue
that
could
potentially
be
many
megabytes.
So
the
only
place
to
store
site
information
that
may
change
between
deploys
like
if
you
change
a
URL
key
would
be
to
store
it
on
the
server.
So
that
has
to
be
at
least
one
source
of
truth
for
it,
and
that
means
that
we
would
at
least
want
to
have
as
few
sources
of
truth
as
possible.
B
You
could
make
a
PWA
that
doesn't
respect
our
SEO
URLs
at
all
and
that
just
it's
own
dynamic
routing
scheme,
where
it
would
support
like
product
/q,
category
/
ID,
but
it's
a
bad
bad
SEO
problem
and
it
reduces
confidence
to
show
that
there's
been
such
a
downgrade
in
functionality
in
order
to
move
to
a
PWA.
So
it
was
important
for
us
to
support
custom
URLs
generated
by
the
business
user
out
of
the
box.
So
even
though
this
is
a
little
slower
than
having
a
hard
coded
scheme,
it's
important
to
the
project
and.
C
C
C
F
C
B
Thank
you
sure.
So.
Are
you
suggesting
that
that
we
don't
use
the
route
string
to
navigate
that
instead,
for
instance,
when
the
application
creates
this
tile
or
like
this
anchored
link
tag
that
it
would
not
just
dispatch
a
new
URL,
but
would
instead
already
know
that
it's
supposed
to
load
a
product
detail
page
and
then
do
that
and
then
update
the
URL
when
the
page
loads.
B
It's
something
that
we've
Trott
well,
it's
something
that
applications
have
tried.
It's
a
reasonable
suggestion,
because
it's
you're
right
the
information
is
there.
The
trouble
is
that
it's
an
additional
code
path,
because
if
I
want
to
link
and
share
this
URL,
it
also
needs
to
fully
load
from
route
yeah.
C
B
That's
true
server-side
rendering
would
help
here,
but
again,
that's
two
different
code
paths
to
get
to
the
same
place.
This
isn't
an
application
that
can
use
this
same
gonna
end
and
back
into
render.
We
don't
have
in
our
own
pro
cloud.
We
don't
have
the
ability
to
render
like
the
react,
application
that
generates
this
HTML
on
the
server
side.
B
So
right
now
we
already
kind
of
have
a
hybrid
approach
with
the
PWA,
where
it
renders
just
the
outer
shell
of
HTML
with
a
simple
template
and
then
it
loads
and
renders
the
rest
clients,
and
it
does
it
does
that,
because
the
outer
template
is
already
placing
a
server-side
request
to
get
this
same
information
like
products
and
the
products
ID.
So
it's
like.
A
B
Sure
it
sounds
like
it
sounds
like
we
need
to
find
out
how
how
much
runtime
performance
penalty
there
will
be
to
implementing
that
whole
intersection
chain,
and
also
there
are
other
ways
that
we
could
represent
this
routing
information
in
the
graph
guilds
from
them.
So
we
could
discuss
those
to
later.
A
G
E
E
E
E
E
E
E
H
Company
has
unique,
unique
schools,
come
like
one
company,
as
I
know,
would
not
have
multiple
products
with
the
same
scope,
but
potentially
on
on
magenta.
You
may
have
products
with
the
same
school
if
you
trying
to
sell
products
from
different
companies
on
your
website
and
those
companies
and
school
of
those
companies
overlap.
Yeah.
E
Unique
identifiers-
and
we
have
a
rich
attributes
management
system
to
support
such
cases,
but
we
need
a
source
of
truth
inside
of
magenta
how
we
identify
that
this
product
is
exactly
this
product
in
other
k
in
a
second,
each
integration
with
PB
s--
tum'
will
not
be
able
to
update
your
product.
It
always
has
to
create
a
new
product,
because
you
cannot
say
that
what
is
even
what
is
an
unique
attribute
in
your
system.
H
Yeah
it
just
the
matter
of
supporting
this
use
case
and
our
priority
of
it.
I,
don't
think
that
it
will
affect
a
lot
of
people,
because,
in
order
to
like
you,
need
to
sell
products
from
multiple
companies
and
schools
or
products
of
this
companies
install
app
it's
it's
possible,
but
probably
unlikely.
I
I
E
A
E
Believe
in
most
cases
so
existed,
I
don't
know
III
III
III
cannot
imagine
this
case.
When
somebody
created
unique,
not
unique
is
skilled
in
this
in
our
system,
especially
taking
into
account
faxes.
We
are
you,
our
UI
and
our
application.
Php
business
logic
has
a
constraint
which
we
had
to
prevent
to
do.
This
is
only.
E
Actually,
we
have
it
two
strategy
here,
so
we
can,
we
can
upgrade
all
the
screws
and
provide
to
merchants
represents
okay,
we
found
this
number
of
duplicates
and
we
resolve
them
in
some
ways,
but
you
can
do
something
with
them
because
I
believe
it.
In
most
cases
this
is
redundant,
duplicates
and
version.
Technically,
don't
means
does
not
need
such
IDs
other
case
other
case.
I
E
I
Along
with
that,
probably
we
may
have
several
or
many
product
ID
dependencies
on
the
product,
which
should
be
we
going
to
be
removed.
So
we
need
to
change
all
the
dependency
on
product
ID
for
the
for
the
correct
product
right.
So
let's
say
you
have
two
overlapping
with
the
same
excuse:
oh
sta
one,
but
the
you
will
have
two
different
product
ID
like
one
and
two,
then
other
dependencies
will
which
actually
rely
on
the
q1,
but
they
have
dependent
on
either
one
or
two.
So
the
merchant
supposed
to
choose
the
correct
product.
I
E
Possible
but
I
believe
in
our
case,
it's
better
to
provide
the
maximum
possibility
to
update
a
screw
for
our
old
old
product
versions,
I
believe,
in
most
cases
money
we
have
a
screw
duplication.
This
is
a
different
version
of
the
one
product
that
appears
as
a
some
kind
of
import
scenario
or
in
case
management,
in
this
case
merchant
steel,
but.
E
We
can
add
unique
suffix
for
previous
versions
and
provide
the
merchant
even
report
which
will
show
the
Chiemsee
okay.
We
identify
these
duplicates.
We
resolve
these
collisions,
but
maybe
you
don't
need
this
as
cows
in
your
system
at
all,
or
you
can
keep
it
for
for
data
consistency
in
case,
as
you
mentioned,
you
have
orders
or
I,
don't
know,
Thompson
else
connected
to
it.
I
I
I
Mean
work
so
I
decide
to
go
with
the
solution
predefined.
So
we
can
do
it
like
that
disabled
by
default
for
those
who
make
it
upgrading,
it
would
be
enabled
for
those
who
make
the
fresh
installation
so
I
believe
that
main
work,
and
we
just
need
to
describe
how
this
tool
that'll
work
and
what
exactly
as
all
dimensional
a
detective
problem
is
gonna
fall
and
how
this
problem
may
appear
for
particular
merchants,
because
maybe
this
is
not
the
only
key
to
and
we
don't
care
for
the
sq
top
occasion.
I
A
B
You
there's
business
value
for
the
consumers
at
the
graph
QL
API,
because
this
makes
product
much
more
like
other,
like
top
level
entities
in
this
email,
and
it
would
probably
make
it
easier
for
the
graph
QL
team
to
implement
a
common
type
across
all
entities
and
then
that
makes
it
much
easier
for
client
systems
like
progressive
web,
apps
or
native
apps
to
store
a
normalized
representation
of
the
sitemap
or
the
catalog.
That
can
then
be
like
easily
synchronized.
Once
everything
has
a
common,
unique
ID.
So
there's
definitely.
A
A
A
E
A
B
Difficult
for
us,
as
consumers
of
graph
QL
as
graph
QL,
includes
a
specific
ID
type
he's
represented
as
a
string
in
the
transmission
layer,
but
ie
types
are
there
to
do
uniqueness
across
an
entity
and
things
based
soon.
All
of
the
good
tools
like
expect
an
ID
type
to
be
there,
but
because
some
of
our
entities
use
integer
types
as
IDs
and
some
of
them
use
strings
like
skews.
B
A
E
A
A
E
I
We
don't
pay
that
it's
not
valuable,
but
for
heroes
of
such
major
changes.
We
definitely
need
to
work
more
carefully
and
we
need
to
prepare
the
document.
We
describe
all
the
pros
and
cons
and
we
also
describe
the
implication
for
merchants
and
the
backwards
incompatible
changes
which
may
resist
proposal
introduced.
F
H
A
chat
interesting
article,
it
talks
about
different
identifiers
and
it
suggests
that
school
for
merchants
should
be
unique.
So
if
you,
if
merchants
sells
product
from
different
companies,
it
would
probably
make
sense
for
this
merchants
to
have
different
identifiers,
different
schools
for
the
same
product
that
belongs
to
multiple
companies.
So
it
will
have
different
schools,
but
some
other
identifiers
was
this
product
made
might
be
the
same
because
it's
the
same
product.
E
E
In
this
case,
I
will
add
more
details
to
this
document.
Let's
wait
for
more
more
feedback
from
community
guys
because
I
believes
it's
mine
for
most
importantly,
we
have
to
do
this,
but
maybe
exist
the
reasons
this
I
don't
know
why
we
cannot
apply
this
and
yeah
understand
specific
needed,
compatible
change,
but
my
point
says
we
don't
have
other
options.
We
have
the
already
has
this
shape,
but
this
check
does
not
work
om
yeah.
To
make
this
week's
we
have
to
do
a
breakfast
of
compatible,
maybe
even
bump
major
ration
of
catalog
model.