►
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
B
B
So
to
give
some
context,
I'm
gonna
approach
it
from
the
angle
of
storefront
performance
and
scalability,
and
I
wanna
make
sure
that
everyone
understands
like
we
are.
We
are
talking
about
storefront
and
not
anything
in
the
back
end.
We're
not
talking
about
like
management
of
products
or
entities
in
the
admin
grants.
B
The
median
response
time
for
catalog
data
is
about
two
seconds,
meaning
about
half
of
the
requests
today
take
longer
than
two
seconds
right,
so
two
seconds
plus
which
the
impact
of
this
is
that
slow,
page
load
times,
obviously
dramatically
reduce
side
conversion
and
there's
been
a
ton
of
different
studies
done
on
this
by
a
bunch
of
different
organizations.
But
basically
it
comes
down
to
right,
the
slower
your
pages
load
on
your
ecommerce
site.
B
B
You
know
the
number
of
categories
you
should
have
an
ecommerce
number
number
four,
you
know
attributes
custom
options,
customer
groups
etc,
and
the
reality
is
that
these
these
limitations
hinder
our
customers,
ability
to
run
their
business
on
on
commerce
on
our
platform,
right,
which
is,
which
is
also
not
not
very
good,
and
the
last
one
is
reliability
here.
We
talk
about
our
sometimes
we
talk
about
our
cloud
platform
right
there's.
We,
we
lack
an
auto
scaling
feature
today.
B
This
results
in
kind
of
manual
cloud
upsizing,
downsizing
of
resources,
but
also
here
we
talk
about
how
our
features
are
deployed.
So,
as
you
all
know,
we
started
building
new
features,
new
commerce
features
that
are
deployed
as
sas
right.
So
examples
are
product
recommendations,
live
search,
payment
services
as
well,
and
so
so
the
impact
of
having
a
reliable
product
right
is
in
commerce.
Any
amount
of
downtime
is
basically
not
only
acceptable.
B
So
this
is
this
kind
of
describes
the
some
limitations
or
issues.
If
you
will
of
the
performance
of
current
state
and
we
we
are,
we
started
thinking
about
how
to
leverage
our
existing
sas
capabilities
to
address
some
of
these
concerns
and
we
started
with
catalog
so
catalog
domain.
This
is,
as
you
all
know,
kind
of
the
most
complex
and
most
beefy
part
of
our
platform.
And
again
I
want
to
specify
that
we're
talking
about
like
catalog
data,
for
storefront
right
and
to
kind
of
ground
us.
B
I
like
to
show
this
diagram.
It's
a
bit
it's
a
bit
much,
but
if
you
focus
on
the
yellow
parts,
first,
the
yellow
parts
indicate
kind
of
like
the
current
state.
So,
with
the
emergence
of
headless
applications,
pwas,
you
know
am
as
well
custom
implementations.
We
have
this
kind
of
decoupled
architecture
right,
so
you
have.
We
have
the
monolith
at
the
bottom
and
then
we
have
the
storefront
or
the
client
at
the
top
making
requests,
and
in
order
for
the
storefront
to
render
experiences
we
need.
B
B
I
know,
even
in
the
m1
days
or
communities,
built
solutions
that
are
basically
extremely
similar.
Where
you
you
know,
I
I
don't
know
exactly
what
to
recall,
but
I
know
there's
patterns
where
you,
you
know
sis
and
there's
solutions
out
there,
that
index
commerce
data
into
repositories
like
for
storage
solutions
like
elasticsearch,
and
then
it's
extremely
fast.
You
know
you
have
extremely
fast
retrieval
times
from
there,
so
this
is
basically
a
very
similar
pattern.
B
So
that's
it's
intentional
that
it
sits
next
to
the
the
core
graphql
api
surface,
it'll
be
it'll,
be
additional
and
it'll
be
optional
to
consume
it
right
we're
not
going
to
force
anyone
to
adopt
it.
But
if
you
are
interested
in
realizing
some
performance
benefits,
then
it'll
it'll
be
there
available.
The
only
thing
is
that
the
it
probably
shouldn't
be
larger
than
the
core
graphical
surface.
The
thing
box
would
probably
be
slightly
smaller.
B
That's
the
only
thing
about
this
diagram
and
and
in
the
future,
we're
thinking
about
kind
of
a
broader
picture.
Beyond
catalog
we
we
may,
we
may
build
some
other
additional
kind
of
service
domains
right
things
like
customer
things
like
tax
pricing,
et
cetera,
et
cetera,
so
these
the
holistic
set
of
these
services
we're
calling
right
now
calling
storefront
services
services
because
they
will
be
built
as
multi-tenants
multi-tenant
sas
services.
C
B
Now
the
latency
should
be
the
same
for
all
the
calls.
The
if
you
talk
about
the
indexation
piece
like
that.
That
is
something
that
that
runs
separate.
It's
a
separate
process,
there's
basically
like
a.
I
simplified
it
with
the
indexation
arrow,
but
it's
it's
basically
like
a
whole
kind
of
it's
export
pipeline
that
we
have
that
indexes
that
will
index
data
from
the
monolith
so
yeah
the
way
to
to
to
dive
into
that
a
little
bit
the
way
that
it
works
today
and
it
actually
like
that.
B
That
piece
actually
exists
today
for
features
like
product
recommendations
and
search
when,
when
a
merchant
first
onboards
and
starts,
you
know,
installs
the
necessary
components
to
to
make
this
work.
There's
a
there's
kind
of
like
an
initial
load
of
catalog
data
right
like
a
bulk
upload.
If
you
will
and
then
and
then
from
then
on,
there's
like
an
ongoing
process,
it
just
it's
just
deployed
as
cron
that
listens
for
changes
and
products,
and
then
it
you
know
it
sends
product
deltas
effectively
into
our
sas
systems.
B
B
B
Of
course,
yeah
and
feel
free
to
jump
in
by
the
way
with
questions,
and
this
is
kind
of
an
informal
conversational
session,
so
feel
free
to
do
that
cool.
So
let
me
keep
going
here
just
to
to
level
set
on
like
the
the
purpose
of
this
new
service
right
is,
is
to
provide
rich
view
model
catalog
data
to
fully
render
these
product
related
store,
broken
experiences
and
to
unpack
that
a
little
bit.
What
do
we
mean
by
view
model
catalog
data?
B
Well,
we
just
mean
that
it's
a
another
name
for
the
service
could
be
a
catalog
projection
service
because
we,
basically
we
we
denormalize
data
and
we
store
it
in
these
systems
and
then,
where
it's
easy
and
very
fast
to
retrieve
right.
So
we
support
view
operations,
basically
like
view
or
get
operations,
but
we,
you
know
we're
not
going
to
support
any
like
mutations
or
any
sort
of
like
write
operations
right
so
and
so
what
do
we
mean
by
product
related?
Storefront
experiences?
B
That's
kind
of
a
mouthful,
so
we
mean
shopper
experiences
right
like
product
detail,
pages
category
pages
search
results.
You
know
these
are
called
pdps
and
plps,
sometimes
where
you
just
need
to
fetch
some
data,
and
then
you,
you
paint
paint
the
page
right.
So
beyond
those
we,
you
can
invoke
the
service.
You
use
the
service
to
power
things
like
product
carousels
and
really
any
other
place
where
product
data
is
displayed
on
the
storefront
right.
B
So
things
like
product
data
in
your
cart
or
mini
cards,
right
product
data,
like
line
items
and
orders
or
wish
list
or
product,
compare
all
those
all
those
things
where
product
data
appears,
and
I
think
I've.
I
think
I've
already
mentioned
this,
but
this
is
like
the
new
service
we've
built
on
an
existing
sas
foundation.
B
We
we
we
have
most
of
this
in
place
already
and
if
you
get,
if
anyone
has
experience
with
like
product
recommendations,
live
search
effectively
like
that
pipeline,
the
indexation
pipeline
is
is
built
and
we're
we're
using
a
lot
of
a
lot
of
the
patterns
that
have
worked
really
well.
For
those
features
the
service
can
work,
can
work
standalone
or
together
with
existing
application
services.
So
with
existing
features.
So
standalone
use
case
is
basically
a
pdp
right.
B
You
you
can
provide
a
sku
to
the
service
and
it
will
respond
with
kind
of
like
a
full
product
data
model
that
allows
you
to
paint
the
pdp,
for
example,
and
it
can
work
kind
of
conjointly
with
the
existing
features
like
recommendations
live
search
when,
when
those
services
return,
data
returned
product
data
today,
the
the
product
data
representation
of
a
product
may
not
be
exactly
complete.
We
know
we
have.
B
So
this
is
where
this
additional
service
can
be
invoked
to
provide
additional
product
data
and,
as
an
example
like
today,
neither
recommendations
nor
search,
provide
ratings
interviews,
data
as
an
example.
So
that's
something
that
this
this
new
service
can
take
on
and
provide
for
for
these
services.
B
B
You
know
to
deliver
a
10x
improvement,
which
would
be
great,
and
we
talked
about
how
this
improvement
should
translate
to
a
conversion
rate
increase
for
our
customers,
we're
looking
to
solve
some
of
these
eq
limitations
and
b2b
at
scale,
and
you
know
when
we
say
b2b
normally
means
number
of
customer
groups
number
of
price
books.
You
know
customer
specific
pricing,
customer
specific
visibility
rules
like
category
permissions,
the
chair,
catalogs
things
like
that.
We're
actually
looking
to
some
of
the
bottlenecks
today
have
to
do
with
the
current
indexers.
B
So
the
indexers
for
like
categories
for
pricing,
indexer
and
what's
the
other
one,
the
category
commission
indexer,
are
basically
like
we've
identified
those
as
bottlenecks
and
we'll
be
looking
to
either
refactor
them
or
or
remove
them
from
the
from
the
chain
completely,
so
that
so
that
we
can
minimize
the
the
amount
of
time
that
it
takes
for
us
to
to
reflect
a
change
on
the
storefront.
So
so
this
near
real-time
sync
of
product
changes
forefront
right.
B
What
that
means
is
if
we
go
back
to
this
indexation
arrow,
the
php
monolith
remains
the
system
of
record
for
any
sort
of
like
product
management
or
creation
right.
This
is
where
products
are
updated
or
or
added,
and
but
so
once
the
product
is
changed
right.
We
need
to
like
it's
in
our
best
interest
to
minimize
the
amount
of
time
that
goes
through
indexation
and
into
our
sas
systems,
and
then,
when
a
when
a
storefront
requests
a
product
right,
we
want
to.
B
B
Hopefully,
you
know
some
somewhere
in
the
seconds
range,
maybe
like
one
or
two
minutes
we'll
see,
but
but
those
but
the
indexers
in
the
model,
if
they're,
actually
a
big
part
of
the
problem,
we're
looking
to
resolve
that
and
to
come
back
to
the
to
the
last
pillar
of
the
slide,
this
will
be
deployed
as
a
multi-tenant
test
service.
Like
I
said,
for
greater
stability,
we've
seen
a
good,
really
good
response,
success
rate
so
far
with
our
with
our
existing
sas
services,
so
we're
we're.
B
We
are
learning
our
lessons
there
and
are
building
kind
of
almost
on
this
robust
foundation
that
has
served
us
really
well
so
far
we
for
so
for
the
existing
services.
I
can
actually
mention
this,
like
recommendations
are
being
served.
Product
recommendations
are
being
served
on
a
few
hundred
sites
today,
live
in
production
and
search
search
is
also
gaining
adoption.
B
Okay,
so
this
is
the
this:
is
the
fun
part
right
like
when
can
I
when
is
this
available?
So
today
we
are
in
active
design
and
development
with
the
team
we're
working
on
spreading
awareness,
as
I
am
right
now
with
partners
and
merchants,
and
we're
trying
to
identify
early
adopters,
who
would
be
good
fits
for
the
program
so
in
q3
we're
looking
to
go,
live
with
beta,
you
know,
fidelity
will
be
a
little
bit
limited.
B
B
These
are
not
exactly
super
committed
timelines,
but
these
are
our
target
target
dates
and
you
know,
obviously,
as
soon
as
we
have
our
g8
we're
going
to
be
looking
to
to
ga
plus
plus,
you
know,
work
on
improvements,
enhancements,
etc,
etc,
react
to
customer
feedback
and,
of
course,
at
the
end
of
november,
we
have
our
holiday
season
here
in
us
in
terms
of
the
black
friday
cyber
monday
deals.
You
know
those
are
most
taxing
periods
of
our
of
over
a
year,
a
lot
of
the
time.
B
You
know
a
lot
of
the
shopping
experiences
during
these
high
peak
seasons
and
therefore
the
monolith
has
less
to
do
right.
Normally,
the
monolith
is
responsible
for
for
answering
these
fulfilling
these
requests
that
come
in
from
the
shoppers,
but
if
you've
implemented
kind
of
this
paradigm
right,
if
you
built
on
this
architecture,
then
the
model
has
less
to
do
and
it's
less
susceptible
to
traffic
peaks,
because
the
responsibility
is
then
on
the
service
that
adobe
manages
right,
adobe,
manages
and
scales
and
maintains
so
for
beta.
B
Just
a
couple
things
again
to
repeat
what
I
said
in
the
very
beginning:
this
will
be
a
adobe
commerce
licensed
feature
only
or
it's
for
licensed
merchants.
That
is
just
like
our
other
existing
sas
features
as
well.
It's
it'll,
also,
if
you
look
at
the
bottom
it'll
also
be
kind
of
deployed,
has
the
same
cost
structure,
which
means
like
it's
basically
free
for
the
commerce
for
the
licensed
merchants
and
there's
no
additional
fees.
B
It's
it'll
be
included
in
the
in
the
commerce
license,
so
you
don't
have
to
pay
anything
additional,
it's
free
for
them.
Ideally,
the
the
merchants
for
best
fit
would
be
some
sort
of
a
headless
implementation,
whether
it's
a
pwa,
you
know
am
some
custom.
You
know
custom
written
storefront
that
uses
graphql
today
and
the
reason
is
again
because
like
to
go
back
to
the
to
go
back
to
the
diagram
right.
This
is
this
this.
B
This
is
kind
of
designed
to
be
used
in
this
decoupled
architecture,
where
the
monolith
and
the
storefront
are
decoupled
and
so
headless
headless
cases
are
the
best
here
we
we
have
heard
the
question
about
how
like
whether
this
would
be
possible
to
consume
and
luma
implementations,
or
you
know
basically
like
the
the
classic
storefronts
or
I
don't
know
what
else
to
call
it.
So
it
it
may
be
possible,
but
like
luma
implementations
are,
will
not
be
our
first
target
audience
so
to
speak,
but
we
are.
B
We
are
considering
basically
making
some
sort
of
a
php
sdk
to
help
consume
the
service,
even
in
like
luma
based
implementations.
So
that
way,
it's
you
know
it's
a
little
bit
easier
to
to
invoke
a
service,
get
data
back
and
then
you
know
somehow
render
these
experiences
in
in
those
types
of
implementations
as
well.
But
headless
is
kind
of
our
first
first
priority
because
it's
it's
kind
of
a
better,
it's
kind
of
a
better
fit
for
those
merchants
that
consume
graphql
today.
B
Good
fits
are
those
merchants
that
have
maybe
voiced
concerns
about
performance
in
the
past.
Specifically,
you
know
storefront
performance
they're.
They
want
to
or
looking
to
invest
in
performance
solutions
such
as
this
one
for
sis
or
our
partners.
You
know
we're
talking
to
a
few
already.
They
seem
to
kind
of
validate
the
these.
Are
you
know
the
problems
that
we're
solving
are
real
problems
and
they
they
they
see
this
in
the
real
world
with
real
customers.
B
So
someone
we're
looking
for
someone
who's
willing
to
spend
some
time
on
evaluating
these
solutions
and
provide
feedback
to
us
again
we're
looking
to
go
to
beta
around
august,
so
the
duration
will
be
about
one
or
two
months.
We're
you
know
we're.
This
is
we're
planning
for
one
two
months
right
now,
so
it's
kind
of
a
time
box
exercise
here
and
then
again,
there's
no
cost
to
consume
the
service,
both
partners
and
merchants.
B
B
A
I
don't
see
anything
on
the
chat,
but
yeah
I
mean
if
anybody
has
please
feel
free
to
ask
a
question
to
misha
and
misha.
Can
I
request
you
to
please
give
your
email
id
on
the
chat
so
that
you
know
if
anybody
is
interested
in
beta
opportunity
and
if
you
have
any
questions
related
to
that,
you
can
reach
out
to
misha
directly.
B
Yeah,
absolutely
I
I
did
think
that
I
probably
should
provide
some
sort
of
like
a
you
know,
cta
or
action
item
here
for
for
those
who
who
are
curious
and
maybe
want
to
reach
out,
or
you
know
any
any
other
partners
on
the
line
or
you
have
merchants
who
would
benefit
from
us
for
sure.
So
you
can
reach
out
to
me.
I
will
probably
most
likely
be
making
like
creating
a
a
channel
in
our
in
our
community
workspace
as
well.
B
A
A
So
if
you
have
not
subscribed
to
the
community
newsletters,
which
is
through
the
news
and
announcements
tab
on
the
forum,
please
do
so
because
every
month
we
are
publishing
the
newsletters
and
you
would
have
a
lot
of
information
coming
into
it.
All
the
you
know
upcoming
beta
opportunities
latest
releases.
So
how
do
you
do
that?
Basically,
when
you
go
to
a
community
forum
here
under
news
and
announcements,
you
would
see
these
three
dots
options
so
make
sure
that
you
hit
subscribe.
B
A
Okay-
and
I
would
also
like
to
you
know
just
throw
it
out
there
that
if
you
want
to
participate,
like
you
know,
if
you
want
to
present
in
this
hangout,
please
feel
free
to
reach
out
to
me.
We
would
love
to
have
you
as
a
speaker
on
these
hangout
sessions.
So
don't
hesitate.
Just
let
me
know,
and
you
know
we'll
schedule
something
soon.