►
From YouTube: Community Engineering Hangouts - Storefront API
Description
Agenda:
1. Product Manager’s introduction (Nishant Kapoor, Adobe)
2. New Price Group design presentation. Evolution of prices architecture for multiple scopes. (Andrii Konosov, Adobe)
3. Media content as part of Product data. DAM and CDN support on store frontend (Olga Kopylova, Adobe)
4. Presentation of latest updates and what has been done since last hangout (Mykhailo Slabko )
5. Demonstration of Category data transfer to Storefront (Kovalenko Sergii, ObjectWave)
A
B
Yep
all
right,
so
thank
you
for
joining
the
community
hangout
for
storefront
api.
I
will
give
a
brief
introduction.
My
name
is
nishant
kapoor
and
I'm
a
product
manager
on
magento
commerce.
I
work
on
graphql
microservices
initiative
and
storefront
api,
obviously,
and
I'll
give
you
a
kind
of
a
vision
where
we
are
headed
what
we
are
building
towards.
So
if
you
can
see
my
screen,
this
is
kind
of
an
end
state
block
diagram.
It's
not
an
architecture
diagram.
B
B
They
have
written
any
third
party
service
that
they
want
to
integrate
into,
so
they
we
will
do
another
hangout,
specifically
on
the
node
graphql,
but
one
layer
down
from
the
the
graph
layer
is
where
the
microservices
initiative
comes
in,
which
is
the
storefront
api.
So
what
we
are
doing
is
slowly
breaking
down
the
monolith
into
smaller
microservices.
We
are
starting
with
the
storefront
functionality,
the
the
pieces
that
you
need
to
build
a
storefront
and
we
are
focusing
right
now
on
catalog
microservice.
B
So
the
idea
is,
we
will
take
the
functionality
out
of
the
monolith
without
actually
changing
the
monolith.
So
monolith
does
not
change,
there's
no
impact.
You
can
continue
to
use
monolith,
it's
just
we
are
taking
it
out
in
into
a
separate
application.
Catalog
will
have
its
own
storage
and
you
will
be
able
to
deploy
it
separately
into
its
own
container,
so
we'll
start
with
catalog,
and
we
have
search
customer
cart
and
checkout.
B
So
if
you
have,
if
you
missed
that
hangout,
I
think
the
recording
I'm
sure
is
available
somewhere.
You
can
check
it
out,
it's
pretty
cool,
so
I
will
stop
here.
This
is,
if
you
have
any
questions
on
on
the
vision,
what
we
are
building,
please
feel
free
to
reach
out
to
me
on
on
community
slack.
I'm
there
there
to
answer
any
questions
or
if
you
have
any
questions
that
you
would
like
to
ask
now,
just
put
it
in
the
chat
window
of
blue
jeans.
B
As
far
as
timing
is
concerned,
we
are
looking
for
an
early
access
program
for
for
catalog,
around
q1
of
2021
so
end
of
the
year
or
beginning
of
next
year.
So
if
you
are
interested
in
testing
it
out,
please
again
reach
out
to
us
and
we'll
chat
more,
so
I
will
pause
here
and
and
give
the
control
back
to
stanislav.
B
C
So
I
will
show
you
the
design
of
our
new
pricing
system.
It's
just
one
of
the
boxes
on
the
diagram
that
nissan
just
showed
you
and,
as
you
probably
know,
we
have
some
issues
with
a
pricing
in
magento
right
now,
and
the
main
issue
is
that
we
are
building
two
large
index.
We
are
trying
to
recompute
all
possible
combinations
of
prices
beforehand
and
for
some
merchants
this
is
completely
unnecessary
and
takes
a
long
long
time.
C
C
C
C
So
instead
of
one
direct
lookup
into
the
index,
we
propose
to
have
one
preliminary
lookup
that
will
resolve
a
new
entity
called
price
books.
For
example,
we
may
extract
the
10
percent
discount
price
book
from
the
database
store
it
in
customer
session,
and
then
we
will
look
up
prices
based
on
the
price
books.
C
One
more
issue
we
have
with
the
pricing
is
that
our
price
index
supposes
that
we
have
to
store
all
products
there.
However,
our
customers
usually
have
customer
group
specific
prices
only
for
few
products
in
catalog,
for
example,
they
those
custom
prices,
may
be
a
result
of
physical
contract
with
another
companies
and
usually.
C
Introduce
the
concept
of
default
price
books
which
will
contain
all
prices
for
all
products,
but
it
will
contain
only
default
prices
and
we
introduce
a
customer
group,
specific
price
books
that
will
contain
prices
for
specific
price
groups
and,
in
addition,
for
only
some
set
of
the
products.
So
now
it
will
be
possible
to
create
a
price
book
with
single
product
in
it,
and
we
also
hope
that
this
will
re
reduce
the
size
of
of
press
index
significantly
and
what
what
else
so
yeah?
C
Let's
talk
a
bit
more
about
that
picture.
So
on
top
of
that
picture,
you
can
see
the
existing
pricing
structure
for
one
customer
group
and
one
website
in
the
model
leaves
so
we
can
see
the
base
price
here.
The
next
layer
is
a
customer
group
price.
Then
we
have
a
catalog
crew
prices
and
special
price
in
the
new
structure.
We
will
have
only
two
layers
and
it
will
be
kind
of
snapshot
from
the
monolith.
C
So
this
is
the
shape
of
api.
You
can
you
can
see
on
our
magento
architecture,
github
offline.
I
will
not
take
a
lot
of
your
time
reviewing
the
api,
but
here
is
the
pull
request:
magento
price
books
in
magento
architecture-
github,
you
can
explore
it
if
you
interested
another
thing
here
is
to
try
to
split
our
customer
groups
per
the
use
case.
We
know
that
our
customer
groups
are
used
in
many
behaviors
many
places
in
the
system,
and
we
may
make
customer
groups
more
specialized
here.
C
So
in
that
proposal
we
also
want
to
have
some
separate
customer
groups
which
are
connected
with
pricing
and
another
customer
groups
which
are
connected
with
other
parts
of
the
system.
This
will
also.
We
hope
that
it
will
reduce
the
data
size
in
index
and
make
things
more
clear
and
structured
one
more
important.
C
Feature
of
new
design
is
that
we
want
to
increase
the
number
of
supported
prices
for
for
a
single
product
for
now,
it's
more
or
less
real
to
have
up
to
100,
maybe
200
prices
per
product
in
new
design.
We
are
targeting
for
15
000
prices
per
product
and
we
want
to
make
the
reliable
platform
for
future
and
we
that
platform
shouldn't
include
customer
specific
prices.
So
it's
not
the
customer
group
pricing.
C
We
are
moving
towards
the
personalized
pricing
feature
and
our
existing
design
of
catalog
service
supposed
to
have
some
kind
of
projection
of
product
that
contain
all
information
like
sq,
name
and
prices.
This
is
required
to
serve
search
capability
to
be
able
to
filter
product
by
prices,
so
everything
should
be
combined
into
one
big
document.
C
However,
the
catalog
service
is
designed
to
handle
large
number
of
products,
but
not
large
products
inside
the
catalog.
That's
why
putting
15
000
additional
fields
into
the
product
is
a
little
bit
challenging
for
catalog
service
and
for
such
scenarios,
where
we
have
too
much
product
too
much
prices
per
product,
we
will
introduce
the
fallback,
so
the
fallback
will
happen
on
the
pricing
service
and
in
comparison
to
the
first
first
purple
example,
where
we
have
very
few
prices
in
the
product
and
lookup
happens
in
one
pass.
C
So
this
allows
us
to
pick
appropriate
storages
for
prices
and
appropriate
scale
for
prices
if
needed
and
make
a
separation
of
concerns
here.
So
the
catalog
will
be
targeted
to
handle
a
large
amount
of
products
of
small
products,
and
the
pricing
service
will
serve
the
large
amount
of
prices
per
product.
C
So
I
guess
that's
it
just
to
recap
and
summarize
everything.
We
know
that
our
dimensions
are
too
heavy
for
pricing
and
we
can
attack
the
existing
problem
with
from
three
directions.
We
can
reduce
the
number
of
products
in
price
books.
We
can
try
to
reuse
the
prices
for
different
price
books
and
we
can
try
to
reuse
prices
for
different
websites
if
it's
possible-
and
this
proposal
just
compiles-
that
together.
C
A
Yep,
thank
you.
Audrey
looks
very
promising
so
guys
if
you
are
interested
in
some
new
prices,
design
feel
free
to
reach
out
on
three
or
to
find
the
issue
in
the
architecture.
Repository
leave
the
comments
and
so
on
so
guys.
Let's
move
on
and
talk
about
some
media
content
as
a
part
of
product
data.
So
political
coupolo
will
tell
us
about
that.
D
So
now,
let's
talk
about
catalog
images,
and
a
note
here
is
that
this
document
reflects
general
vision
from
magento,
but
it
is
also
focused
specifically
on
catalog
images
or
catalog
media
to
be
less
abstract
and
to
be
able
to
focus
on
specific
needs
that
we
have
right
now
in
scope
of
catalog
storefront
project,
but
in
general
it
shows
our
direction
as
magenta
product.
Our
vision
on
how
we
handle
media
and
the
main
idea
is
that
we
want
to
offload
media
management
to
specialized
systems
and
also
to
make
magenta
more
open
to
integration
with
those
systems.
D
First,
let's
start
from
terminology,
so
we
are
on
all
on
the
same
page,
so
we'll
be
talking
about
assets.
Asset
is
anything
that
exists
in
binary
format
in
case
of
magenta,
catalog
or
magenta.
Products
for
those
are
images
and
video,
but
asset
is
something
bigger.
Something
broader
also
we'll
be
talking
about
them.
Systems
pretty
like
frequently,
and
the
management
systems
and
the
responsibility
of
them
is
to
actually.
D
D
D
B
D
B
A
A
D
D
One
okay:
I
think
that's
all
my
minutes
that
I
had
so
and
again.
If
it
doesn't
work,
let's
try
again
if
it
doesn't
work.
I
have
video
recording
so
of
everything
which
is
one
or
think
we
should
be
able,
maybe
to
pair
it,
let's
see,
but
so
far
yeah.
We
are
talking
about
catalog
images
and
I
want
to
cover
our
vision
on
media
management
or
asset
management
in
magento,
and
the
main
idea
is
to
offload
the
asset
management
to
specialized
systems.
D
So,
first,
let's
talk
about
terminology.
We
will
be
talking
about
assets
in
simple
words
in
as
part
of
products
or
catalog.
Those
are
images
and
videos,
but
there
can
be
more.
We
will
be
talking
about
dem
systems,
digital
asset
management
systems.
They
are
responsible
for
actual
asset
management
cdn,
which
is
content,
delivery
network
and
it's
important
part.
Usually
it
can
be
part
of
a
dem
system
or
built
on
top
of
like
functional
asset.
D
Delivery
is
actually
the
process
of
delivering
the
asset
to
the
client,
because
one
thing
is
just
to
manage
assets
and
another
thing
is
to
deliver.
Those
can
be
combined
in
one
system
or
those
can
be
separate
systems,
image
transformation.
That's
I
think,
where
I
stopped
so
image
transformation
in
magento.
We
have
such
things
as
resizing
rotation
watermarking,
but
it
can
be
a
more
broad
set
of
features
about
image
transformation.
D
So
we
will
talk
a
little
bit
about
image
transformation
and
how
we
see
it
magento
back
office
or
magento
admin.
I
think
every
everybody
knows
what
is
it
in.
We
say
that
magento
admin
is
responsible
for
product
management
and
images
or
assets
to
the
products
block
storefront
application.
This
is
what
so.
This
is
a
representation
of
catalog,
which
is
managed
in
pin
system
product.
D
D
It's
about
terminology
next,
what
I
want
to
cover
is
a
scenario
quickly
and
or
scenarios
quickly
and
the
I
want
to
cover
what
changes.
What's
the
difference
in
the
vision,
there
is
a
pull
request
in
architecture,
catalog,
media
tech,
vision
where
it
would
be
great
if
you
can
leave
some
comments.
If
you
have
concerns
about
the
vision,
for
example,
you
know
that
some
use
cases
won't
be
covered
with
a
new
approach.
D
D
D
After
that,
the
green
area
is
how
this
data
is
used.
So
there
is
a
client
or
there
is
a
visit
it
uses,
pwa
or
whatever
client
we
have
and
to
it
makes
requests
to
graphql
patches
product
data
and
as
part
of
this
product
data,
we
will
have
pro
image
urls
after
that
client
fetches,
those
images
and
the
urls
are
pointing
to
the
urls
provided
by
the
dumb
system.
D
Usually
there
will
be
some
cdn
involved,
and
this
cdn
can
also
make
some
transformations,
because
some
cdns
support
it.
I
think
most
cdn
supported
in
one
or
another
way
if
the
image
is
not
present,
it's
being
fetched
from
the
dump
system,
where
there
can
be
additional
transformation
on
the
fly
as
well.
D
D
Some
system,
depending
on
what
this
system
supports,
to
perform
on
the
fly,
transformations
that
transformation
that
urls
should
parameters
so,
for
example,
so
in
our
case
magento
return,
original
url
to
the
image.
All
the
way
from
the
admin
and
to
the
storefront
and
to
the
client
va
adds
additional
parameters
to
specify
what
exact
like
aspect,
ratio
or
quality
or
whatever
it
needs,
and
the
cdn
or
dump
system
returns
that
kind
of
image.
D
So
that's
ex,
and
let
me
talk
quickly
about
couple
of
things
that
are
changing,
so
I
already
mentioned
that
transformation
is
not
supposed
to
happen
on
the
magenta
side.
This
may
cause
some
issues
for
the
development
scenarios,
but
we
don't
expect
issues
for
production
scenarios
because
we
expect
that
there
will
be
at
least
cdn.
Even
if
there
is
no
dumb
system
and
cdn
can
provide
transformation
for
developer
scenarios,
it
is
possible
to
involve
web
servers
such
as
nginx
or
apache,
to
perform
some
transformations.
D
D
I'm
just
saying
that
a
couple
we
were
looking
at,
they
support
some
kind
of
water
marking
and
I'm
just
covering
what
we
like
what
we
can
use
here.
So
in
case
of
magenta
cloud,
we
can
use
fastly
and
with
a
specific
fastly
configuration
if
you're
talking
about
am
products,
they
also
provide
some
water
market
water
marking
capabilities.
D
There
are
still
some
questions
about
scoping
that
would
need
to
be
covered
in
more
details
when
we
get
to
it,
but
in
general
it
is
supported
and
then
the
last
thing
is
placeholders,
so
placeholders
can
be
used
in
couple
use
cases.
One
use
case
if
there
is
no
image
assigned
to
the
product
and
another
use
case
if
image
is
assigned
but
is
not
physically
present
on
the
in
the
storage,
in
both
cases
right
now,
magento
returns
placeholder,
which
is
which
can
be
configured
by
the
now.
D
We
are
saying
that
we
are
not
going
to
this
logic
of
deciding
whether
the
image
is
a
placeholder
or
real
image.
We
are
not
going
to
handle
it
on
the
magenta
side
on
the
side
of
storefront,
we
are
going
to
just
return
empty
string.
If
there
is
no
image
assigned
or
we
will
be
returning
just
image
url
without
any
validation,
whether
such
image
is
physically
present
and
the
responsibility
of
the
client
is
to
handle
the
situation.
D
D
So
there
is
this
possibility.
It's
easy
for
the
client
now
to
understand
whether
it
is
a
placeholder
that
should
be
displayed
or
really
imaged,
but
in
the
use
cases
where
client
still
wants
to
display
magenta
configured
placeholder,
we
are
saying
that
we
can
provide
the
graphql
api
for
the
magenta
for
the
magenta
configuration
which
returns
configured
placeholders.
D
In
that
case
again,
client
decides
whether
to
use
it
or
not,
and
it
can
display
to
support
kind
of
existing
functional
functionality
in
magenta.
That's
all
from
my
side.
I
think
I
took
more
time,
especially
because
of
the
connection
problems,
but
yeah
I'm
done
here
and
if
please
leave
your
comments
in
the
pull
request.
Thank
you.
A
Yeah,
thank
you
oliver
for
the
great
presentation.
So,
let's
move
on
to
the
presentation
of
the
latest
changes
that
was
done
since
the
last
kangaroo
mission-
hey
everyone.
So
let
me
share
my
screen,
so
I
will
be
brief
and
shall
not
take
a
lot
of
your
time
since
the
last
coming
out.
We
merged
12
requests
for
cloud
storefront
reaper
and
we
covered
some
functionality
related
to
functional
extensibility
and
functional
coverage.
A
A
So
currently
we
communicate
with
ulster
from
the
application
over
introduced
api,
it's
related
to
storefront
part,
but
we
also
have,
as
I
said,
another
repository
repository
related
to
expert
api,
and
here
we
have
more
work
because
we
trying
to
add
more
features,
and
this
rib
already
use
it
in
production
for
some
our
services,
maybe
some
perex.
We
have
recommendation
services
also
we'll
have
some
search
service
that
will
use
all
this
data
and,
as
you
already
heard,
we
have
the
huge
proposal
related
to
price
books
and
collec
media
that
nga
and
olga
mentioned.
A
Also,
we
have
another
documents
in
design,
some
of
them
already
merged,
some
of
them
still
on
the
market.
We
are
trying
to
build
a
unified
approach
for
product
options
and
combine
different
options
for
complex
products,
for
custom
options
and
move
it
to
one
entity.
Also.
We
are
rebuilding
our
vision,
how
we
want
to
save
and
work
with
product
variants.
A
A
A
E
D
E
This
event
is
saying
that
we
need
to
take
data
from
this
field
from
that
cache
and
process.
This
data
and
put
this
data
in
elasticsearch,
graphql
and
all
requests
that
will
come
from
graphql
will
fetch
this
data
from
that
indexer.
So
basically,
it's
how
it's
working
it's
just
over
overview
of
how
it's
working-
okay,
so
and
now
I'm
going
to
demonstrate
you
how
it's
working
right
now.
So
we
have
graphql
graphql
extension
and
we
can
just
query
a
very
basic
information.
I
like
categories
id
and
some
basic
attributes
with.
E
As
you
can
see,
we
have
on
the
default
category
right
now.
Let's
add
one
more
circle
today,
let's
say
that
it
will
be
configuring
one,
I'm
not
adding
any
other
attributes
to
it,
just
saving
it
right
now.
This
category
should
be
re-indexed,
it
should
be
cached
in
fit
indexer
cache
in
this
table
and
reddit
and
new
message
should
be
published
through
reddit
and
queue
then
represent.
You
should
take
data
from
fit
and
shoot
so
we
have
some
ids.
E
For
example,
id
number
one
and
id
number
two
category
consumer
is
taking
the
data
by
id
number
one
and
id
number
two
from
this
cache
processing
it
and
putting
it
to
elasticsearch
I'll
show
you
how
it
looks
like
so
we
have
two
indexers
and
we
have.
This.
Indexer
is
catalogues
catalog
from
v11
category
yeah
and
all
data
is
actually
stored
in
the
index.
Let's
just
see
this
okay,
we
have
our
new
category
created
and
we
have
also
default
categories.
E
E
E
Saving
this
data
and
I
need
to
query
these
products
as
well,
so
I
am
on
the
level
category
and
I'm
just
creating
products,
products
items
you
name
and
they
also
have,
as
you
can
see
the
product
it's
configurable
product
and
virtual
product.
We
also
can
get
count
of
the
products
this
product
count
attribute.
E
As
you
can
see,
it's
that
include
manifold,
that's
basically
it
it's
very
pretty
for
its
pretty
short
from
the
demo
perspective,
but
it
was
a
lot
of
work
on
this,
because
category
has
a
lot
of
attributes
and
we
needed
to
take
into
account
of
the
contributors
thanks.
Maybe
someone
have
some
questions.