►
From YouTube: DEx Engineering Sync 09/18/2023
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
Oh
someone
said
one
sec,
oh
Javi.
Oh,
he
left
okay!
Well,
this
is
an
awkward
intro,
but
this
is
our
Monday
September,
18th,
bi-weekly
engineering,
sync
I
think
it's
probably
yeah
we'll
jump
in
to
it.
Maybe
wait
a
sec
for
heavy
I'm,
not
sure
but
Megan,
maybe
don't
just
start
on
the
first
one.
We
only
have
25
minutes,
so
we
probably
should
start.
B
Yeah
sure
yeah
I
wanted
to
bring
up
the
internationalization
plan
and
how
that
pertains
to
the
CMS
I
just
wanted
to
clarify
where
we're
at
right
now,
like
we're
just
getting
our
English
content
into
the
CMS
right
now,
there's
no
need
to
worry
about
translated
content,
so
I
didn't
want
to
scare
anyone
as
they're
they're
building
up
Pages
like
oh
now
we
have
to
to
enter
the
German
French
and
Japanese
stuff,
like
no
don't
worry
about
it.
B
We
have
like
our
first
iteration
of
this
plan
and
that's
just
to
use
that
kind
of
hybrid
data
fetch
method
to
bring
in
the
yaml.
From
my
experience
and
then
the
Jason
from
contentful
and
yeah,
the
Json
output
is
a
bit
cluttered
if
you
haven't
seen
that
yet
from
contentful
there's
a
lot
of
extra
properties
and
nested
objects
in
there.
B
You
have
to
sift
through,
so
you
might
have
to
do
some
updates
to
make
those
the
yaml
schema
and
the
Json
schema
kind
of
work
well
with
the
components
and
John
is
a
note
here
and
he'll
get
to
that
later.
Just
about
his
proposal.
But
I
wanted
to
add
on
to
that.
Like
this
is
a
lot
of
work
as
it
is
to
get
the
English
content
into
contentful,
and
it's
just,
it
is
a
pain
to
get
that
to
work
with
all
the
translated
content.
B
So
just
do
whatever
the
boring
solution
is
right.
Now,
at
the
end
of
the
day,
our
goal
is
to
get
our
Pages
migrated.
Let's
not
spend
too
much
time
playing
around
with
with
translations
whatever
that
might
mean.
Lauren
is
async,
but
had
a
note
just
plus
one.
B
We
have
translations
in
contentful
for
the
next
steps
and
the
navigation
right
now,
mostly
because
that
translated
content
lived
where
this
the
English
content
did
already,
and
one
is
built
out
with
the
field
level
way
of
adding
translations
and
contentful
on
the
entry
level,
and
if
you
have
any
questions
on
what
that
means.
Please
look
at
that
internationalization
issue.
I
looked
at
and
we're
using
those
to
kind
of
look
and
like
how
Argo
might
work
with
this
in
the
future.
B
Then
one
thing
I
didn't
have
this
in
here,
but
like
again,
if
you
do
have
any
questions
or
if
you
have
like
concerns
or
maybe
better
ideas
like
I-
know,
I
kind
of
wanted
to
stick
with
entry
level
versus
field
level.
But
if
you
do
have
any,
like
other
notes
like
please
add
that
to
the
issue:
I,
don't
really
agree
with
us,
like
kind
of
maybe
flipping,
and
that
was
just
all
by
hearsay,
because
I
was
very
confused.
So
let's
like
really
stick
to
the
issue
in
documentation.
So
thanks.
B
So
much
Javi
has
the
next
one.
If
he's
back.
C
I'm
back
I'm
back
yeah
a
little
bit
of
a
tech
issue
there
with
my
son
but
I'm
okay,
so
this
sounded
great
in
my
head
and
now
that
I'm
back
on
Monday,
it's
like
all
right.
This
is
a
question
all
back
down,
but
all
right
so
pretty
much.
There's
both
some
of
our
Veet
work
with
the
nav
and
looking
at
how
performance
was
working
for
our
mobile
site.
C
I
started
to
get
into
this
Rabbit
Hole,
like
figuring
out
how
to
like
help
improve
the
site
as
a
whole,
and
so
one
thing
I
wanted
to
bring
up
with
all
of
our
Engineers
was
to
start
figuring
out
what
a
performance
budget
would
look
like
for
our
buyer
experience
site
and
pretty
much.
What
that
is.
C
Is
we
set
like
a
metric
for
how
well
the
page
is
performing
so
I
did
some
research
and
I
dropped
some
examples
of
some
links
here
in
the
in
the
document,
and
so
then
an
example
would
be
like
you
know,
reduce
the
bounce
rate
to
achieve
a
time,
a
time
to
interactive
under
five
seconds
under
3G,
slash,
4G,
there's
a
couple
of
other
ones.
I
listed
here,
like
total,
blocking
time
maximum
size
of
images.
C
Last
the
total
amount
of
images,
the
total
amount
of
size
of
the
average
page
with
all
of
everything
included
that
would
be
fonts,
JS
images,
everything
so
web
averages
averages
web
web
page
averages
in
2022
are
about
2500
kilobytes
and
right
now
we're
at
8
700
kilobytes
come
press
size
of
all
resources.
Then
I
figured
that
out
by
taking
a
network
analysis
of
our
Chrome
Dev
tools.
C
That
was
fine.
That's
actually
the
reason
why
I
got
pinged.
My
security
on
Friday
was
because
I
used
that
har
file
that
gets
included,
and
that
has
my
my
cookie
that
lets
me
log
into
GitHub,
which
is
a
big
issue,
because
I'm
someone
yeah
anyway
pretty
much
there's
a
good
amount
of
like
low
hanging
fruit
things
that
I
listed
here.
It's
like
you
know,
for
instance,
the
Vimeo
player.
Can
we
lazy
load
back?
Can
we
do
anything
about
the
cooking
consent
matter?
Can
we
try
to
Lazy
load,
maybe
like
the
search
in
the
nav?
C
Is
there
like
smart
things
that
we
can
try
to
figure
out
there?
There's
a
file
there?
That
I
saw
in
my
that
was
really
interesting,
which
is
like
essentially
the
Json
of,
like
all
of
our
content
of
our
site,
why
this
gets
loaded
on
every
page.
It's
like
1.4
Megs,
which
is
interesting.
How
that's
getting
there?
That's,
probably
not
good.
Until
then,
I
wanted
to
end
with
kind
of
like
a
you
know,
we're
we're
a
gold
company.
You
know
not.
Everyone
has
access
to
the
same
Hardware
internet
connections.
C
I
wanted
to
kind
of
take
all
of
this
and
action
it
towards
something
because
it's
like
this
is
not
useful
for
US
unless,
like
we
like,
you
know,
figure
a
way
out
with
this
and
I
kind
of
shared
some
some
of
this
beforehand
with
some
of
the
folks
and
one
of
the
many
things
that
I
heard
from
feedback
from
some
of
you
all
is
how
not
everything
in
our
site
is
under
our
control.
And
so
then
that's
like
you
know.
C
Let's
keep
that
into
account
with
like
some
of
this
like
we
can
only
move
the
Toledo
so
much,
and
so
you
know
with
with
the
things
that
we
can't
control,
let's
try
to
to
be
as
smart
as
we
can
with
how
to
use
that
performance
measure,
because
yeah
it
ends
of
impacting
our
users
and
making
those
improvements,
especially
when
they're
low
hanging
can
help.
You
know
move
that
needle,
for
you
know
our
metrics
that
we're
working
on
so
unless
anyone
has
anything,
I
think
we
could
just
move
on
to
John.
A
I
think
there's
some
really
good
college
here
and
yeah
I've
heard
about
this
Json
object
before
from
SEO
the
SEO
team
I
have
no
idea
what
that
was
or
how
it
got
there,
but
yeah
I
think
what
we
just
need
to
do
is
just
get
these
in
issues
and
somehow
you
know
get
them
prioritized,
so
we
can
actually
start
working
on
them,
but
yeah
there's
for
sure
a
lot
here
we
can
do
I
didn't
know.
We
were
like
nine
Megs
on
page
load
nice
to
be
like
a
CD
back
in
the
day
from
leimore.
D
Okay,
I
I
can
continue
hi
guys
what
I
know
that
some
of
you
have
seen
the
proposal
that
I
did
for
implementing
a
design
pattern
in
our
architecture.
D
I
will
do
a
little
walkthrough
about
these
sub
proposal
and
let
me
share
it
to
you
real,
quick.
So,
first
of
all,
what
is
this
proposal?
This
proposal
is
to
have
a
separation
of
concerts
in
our
project.
Our
project
is
quickly
growing
and
we
already
are
consuming
data
from
contentful.
We
have
data
from
jaml
files.
We
have
localization,
so
the
project
is
really
big
right
now
and
it
is
a
good
practice
to
have
design
patterns
in
this
kind
of
projects.
D
So,
in
this
case,
I
propose
enough
separation
of
concerts
and
mbb
mbvm
design
pattern,
that
is
to
have
the
business
logic
or
fetching
logic
or
whatever
you
may
may
call
it
and
they
display
in
logic
or
rendering
logic
separated.
So
I
will
show
you
first.
What
is
the
end
goal?
The
end
goal
is
to
have
only
this
line
of
code
in
our
components
or
pages.
So
I
did
this
by
implementing
a
dependency
Injection
Service.
What
is
the
independent
dependency
Injection
Service?
D
We
will
have
services
like
this
one
that
is
called
solution
service,
and
the
only
thing
that
we
need
to
do
in
the
pages
is
to
call
this
service.
It
can
be
a
solution
service.
Why
gilab,
Service
Enterprise
service,
one
service
per
module?
Let's
say,
and
we
call
the
content
and
we
pass
this
log
for
the
pattern,
and
that
will
be
it.
The
rest
is
invisible
or
hidden
from
our
display
logic.
That
is
this
component.
This
logic
will
be
separated
from
this
other
logic.
What
is
this
other
logic?
Is
this
solution
service?
D
So
what
we
have
here?
Sorry
for
all
these
boilerplate
codes.
It
is
not
the
final
code,
it
is
only
an
example,
but
we
will
have
in
all
services
these
get
content
method
that
will
deliver
to
the
display
in
or
view
layer
the
same
as
same
interface,
no
matter
what
what's
the
source,
so
our
source
can
be
a
database,
our
source
can
be
gml,
our
source
can
be
content
whatever
we
want,
and
this
is
decoupled
from
from
this.
D
So,
every
time
we
change
our
data
source,
this
code
won't
change,
so
our
Pages
would
be
the
same,
and
our
pages
will
always
display
the
solutions
with
ETO
or
whatever
dto
we
need
so
here.
As
an
example
in
this
solutions
beautyo,
we
will
have
the
hybrid
approach
from
Megan,
so
answering
negan's
question.
We
will
have
to
implement
the
same
logic,
no
matter
what,
but
what
we
are
removing
or
what
we
are
saving
is
to
have.
D
Here
in
these
components,
so
the
spaghetti
code-
that's
or
business
logic
will
will
be
in
the
in
these
services,
and
the
hybrid
approach
will
be
here
as
well.
So
in
this
case,
I
have
the
context:
I
have
no
localization
here
injected
and
at
the
end
of
the
day
it
would
be
like
validation
if
it's
a
default,
local
or
English
local.
We
will
return
here.
It
won't
be
like
this,
but
we
will
return
contentful
data.
D
We
will
we
will
need
to
pass
that
data,
because,
if
you,
if
some
of
you
have
seen
the
data
from
content,
will
contain
some
parameters
as
system
or
IDs
or
Fields.
So
you
can
have
like
you
can
have
Parts
like
solutions
that
Fields
the
header.pls
DOT
a
text
that
Fields,
so
we
need
to
do
a
logic
to
format
that
data
to
be
parsed
and
displayed
in
our
component.
So
all
that
logic
will
be
stored
here
in
the
service
and
our
page
will
be
the
same.
D
It
will
only
call
a
centralized
source
of
data,
and
if
it's
not
an
English
page
but
another
kind
of
page,
we
will
return
the
same
as
always.
That
is
the
content.
Let's
say
here
sample.
D
We
will
return
the
same
method
that
we
are
always
have
been
calling
always
so
to
summarize
again
sorry
for
this,
all
this
information
I
know
it's
a
lot
to
summarize
is
the
goal
of
this
proposal
is
to
separate
our
business
logic,
our
patch,
in
logic,
from
our
displaying
or
UI
logic,
in
order
to
have
a
good
data
decoupling
and
a
good
following
good
practices
for
big
projects
like
budget
experience.
So
I
don't
know
if
you
have
questions
about
this.
A
In
this
example,
this
is
for
kind
of
a
reusable
Solutions
page.
Yes,
yes,
so
I
guess
we're,
because
right
now,
what
we're
doing
is
essentially
just
grabbing
a
full
page
right,
we're
grabbing
a
full
page
and
just
rendering
each
thing
individually.
So
would
we
have
a
service,
for
you
know
things
that
are
reusable
so
like
resources,
a
service
for
like
each
section
and
then
on
a
page,
we'd
reference,
multiple
services,
or
is
it
one
service,
that's
going
to
serve.
D
Yes,
for
example,
Solutions
has
a
lot
of
child
components,
sort
of
child
modules,
so
in
this
case
for
Solutions
and
all
child
Pages,
it
will
work
the
same
so
depending
on
the
on
this
law.
In
this
case
parents,
it
will
call
the
same
service,
so
we
won't
need
a
service
for
each
page.
It's
only
a
service
for
a
whole
bunch
of
pages
or
a
bunch
of
or
a
whole
modules.
So
in
this
case
our
model
is
Solutions.
A
Okay,
are
we
concerned
that
for
small
things
like
I
know,
was
it
Michael,
someone
yeah
I,
think
like
the
CE
versus
ee,
for
example
like
that
page
is
pretty
much
just
a
unique,
one-off,
and
so
are
we
gonna
have
a
lot
of
just
kind
of
services
that
are
just
serving
one
page.
D
Those
Services
can
be
stored
here,
for
example,
if
you
don't
don't
want
to
create
another
service,
only
for
a
small
page,
you
can,
let's
say,
create
a
new
method
here,
for
example,.
D
Yeah
yeah,
something
like
that.
Sorry,
yes,
something
like
that
like
this,
so
you
can
have
the
logic
Forum
that
little
page
in
a
separated
method
inside
the
service.
So
you
don't
need
to
create
another
service
only
for
that.
So
that's
why
it
is
cool
to
have
Services,
because
you
can
store
any
solutions
related
logic
inside
this
service.
So
you
can
save
a
lot
of
small
files
for
a
small
pages.
E
We
could
also
have
like
different
pages
that
follow
the
same
structure
as
the
ECE
or
e-page,
where
we
have
like
a
hero:
the
SEO
objects,
then
the
Json
data
and
finally
The
Next
Step.
So
we
could
have
like
generic
data
fetching
logic
there,
and
also
like
specific
data
featuring
Logic
for
templates
that
are
more
complex.
For
example,
the
solutions
template
will
benefit
a
lot
from
separating
that
logic,
and
we
also
will
do
Eddie,
don't
repeat
yourself,
stuff,
yeah,.
D
D
This
follows
the
don't
repeat
yourself
principle,
so
any
logic
that
we
are
maybe
we
are
duplicating
duplicating.
We
can
store
it
here
in
the
services
and
we
can
fetch
it
whatever.
We
want,
for
example,
next
steps
component.
Let's
say
we
need
to
call
Next
Step
data
from
all
pages.
You
only
need
to
call
a
single
service,
and
that
will
be
it
and
what
else
up?
We
have
also
models.
For
example,
what
Miguel
said
we
can
have
a
video?
D
What
is
a
dto
is
a
model
that
the
pages
will
ask
in
order
to
display
data.
We
need
to
consider
here
that
to
not
be
two
abstract,
for
example,
having
hero
and
a
hero
can
be
a
hero.
Dto
and
the
hero.
Dto
has
other
videos
above
in
a
tree
Shake.
We
shouldn't
do
that.
We
can
be
flexible
here,
because
one
of
the
problems
of
these
kind
of
designs
is
too
much
too
much
abstraction.
So
we
need
to
to
be
careful
in
this
case.
D
I
have
a
page
detail
and
that
it
will
serve
for
all
pages
and
all
pages
have
a
title
and
a
description
and,
let's
say
an
image
for
for
SEO
things
and
also
I,
have
a
Solutions
view,
detail
that
I
have
seen
in
the
template
in
the
templates
in
the
Jammer
files
that
we
use
components,
for
example,
I
can
play,
for
example,
Enterprise
or
industry
template
or
whatever
each
page
should
have
a
dto,
but
don't
be
too
abstract.
D
D
I
don't
know
if
we
have
more
questions
that
yeah,
oh
okay,
so
it
will
be
a
learning
curve.
So
this
is
not
the
real
example,
the
POC
that
I
did
but
I
can
Implement
a
real
example
when
I
implement
the
YG
lab
page
when
I
have
that
I
can
share
that
example,
real
example
to
the
team,
and
then
we
can
decide
when
we
can
continue
working
on
this
approach.
If
we
go
down
this
path.
A
Yes,
I:
do
it
yeah?
Let's
see
it
that'd,
be
awesome,
no
I
think
it's
a
good
idea.
I
think
it's
somewhere
that
we
have
to
go.
I
agree
like
we
can't
be.
You
know,
throwing
100
lines
of
API
calls
in
each
single
view
file,
because
it's
just
going
to
be
ridiculous.
A
I
know
we're
having
single
page
or
single
file,
components,
festivals,
extreme,
but
I
guess.
My
only
concern
now
is
I.
Don't
know
where
we
are
on
this
contentful
timeline
thing
and
so
I'm
a
little
concerned
that
this
might
set
us
back
a
bit.
I
guess
the
good
part
to
it
is
right.
Now
it
could
be
opt-in
like
if
you
want
to
do
it,
do
it.
If
you
don't
want
to
do
it,
you
don't
have
to,
and
eventually
we
can
go
back
and
update.
A
Some
of
those
calls
so
I
guess,
in
my
opinion,
I
think
it's
a
great
idea
and
I
think
if
you're
comfortable
doing
it
or
you
know
starting
to
migrate
to
the
service,
go
for
it,
if
not
I
say
keep
going
as
is
just
to
try
and
hit
our
deadlines
and
then
maybe
Justin.
We
can
have
some
time
later
on
to
go
back
and
you
know
fix
some
of
these
things
that
we
rushed
when
we
were.
You
know
migrating
to
a
contentful.
F
D
B
F
We
know
that
we're
going
to
continue
to
iterate
on
the
CMS
and
our
bio
experience
code
base
after
this
quarter
is
done
so
I
don't
and
then
also
what
Nathan
said:
I
think
that
there's
benefit
in
seeing
it
seeing
how
it
can
be
extremely
useful
and
then
once
everything's
migrated
and
we
you
know,
we
make
an
engineering
decision
to
say
like
yes,
this
is
the
way
forward
to
make
sure
that
we
can
scale
appropriately.
F
What
does
it
look
like
to
extract
this
up
for
the
entire
site,
all
the
contents
where
it
needs
to
be
so
it
should
be
less
work,
it's
just
more.
Creating
those
services
and
making
sure
things
are
wired
up
quickly.
So
I
can
see
as.
F
D
Thank
you
so
much
so
I
will
earlier
our
example.
Let's
say
a
real
case
scenario
and
whenever
we
like,
we
can
Implement.
But
thank
you
for
for
checking
on
and
and
approving,
let's
say.
A
D
Yes
and
I
I
know
this,
because
I
have
worked
with
angular
a
lot
angular
has
like
these
built
in,
so
they
have
like
these
separation
of
concerns
array
from
from
the
start
with
services
and
the
mbb
mbbm
pattern,
so
I
know
it,
it
works
it
works
and
as
a
long
time
solution,
it's
the
best
in
group
in
good
practices,.
A
We
are
kind
of
coming
close
to
times.
Does
anyone
have
anything
else?
They
want
to
add
a
restaurant
before
we
move
on
to
Justin's
last
topic,.
F
F
Sections
that
they're
working
on
either
inverted
Pages
or
specific
things,
but
a
lot
of
the
stuff
on
our
site
is
the
is
the
same
like,
for
example,.
B
B
F
B
F
Another
example
would
be
this
one:
this
we
could
create
a
whole
content
type
that
is
headline
and
this
field
for
this.
F
F
F
Thinking
about
certain
things
that,
like.
B
B
B
A
F
F
So
this
is
like
a
another
like
idea
or
another
conversation
that
as
everyone's
as
everyone's
working
towards
things,
be
mindful
of
like
the
content
that
you
see
in
contentful
and
as
you
are
looking
through.
What's
currently
there,
it
might
be
worthwhile
to
reach
out
to
you,
know,
Miguel
or
Javier
Megan
and
be
like
oh
I,
see
you're
making
this
component
with
this
content
type.
Could.
E
F
Try
to
keep
keep
things
more
high
level.
Don't
you
know
we
were
kind
of
bad
at
like
when
we
name
components
and
like
by
our
experience.
A
lot
of
them
are
nested
under
solutions
or
nested
under
events,
but
really
they
start
to
get
used
elsewhere
and
that's
how
we
run
into
this
sort
of
like
duplication
of
like
components.
F
B
E
I
I
added
a
comment
on
the
best
practices
for
contentful
and
there
we
have
existing
content.
So
it's
really
nice
because
you
can
go
and
search
for
entries
that
can
can
help
you
so
I
already
did
it
with
the
next
step,
entry
that
Laura
did
and
I
looked
for
it
and
it's
very
simple
to
to
look
for
existing
content
and
it's
something
that
we
should
also
pass
down
to
stakeholders
in,
because
we
don't
want
duplicate
images
and
stuff.
So
yeah
wanted.