►
From YouTube: Community Engineering Hangouts - Storefront Application
Description
Community Engineering Hangouts
The aim of these hangouts is to update the community on all our progress and demo some new tools and features. During this hangout we shared some of the progress and vision of the Storefront Application project.
1. General Overview (presentation https://www.slideshare.net/maghamed/magento-storefront-architecture)
2. Project Roadmap
3. Catalog Storefront Application design
4. Back Office demo
5. GraphQL and Storefront API integration demo
6. Development tools
7. How to join the project
Feel free to join in, comment and ask questions. The aim of these hangouts is to provide a platform for Magento to give the community regular updates but also for the community to give feedback to Magento.
For any more information feel free to reach us in Slack https://opensource.magento.com/slack
A
B
Those
components
are
like
a
highly
coupled
to
one
another
so
that
it's
not
possible
to
scale
those
components
independently
out
of
each
other,
and
it's
quite
a
typical
approach
of
scallion
magenta
is
when
you
just
duplicate
this
existing
component
and
just
multiply
it
many
times,
even
so
that
in
Enterprise
Edition
of
magenta,
we
provide
the
possibility
to
extract
the
data
storage,
for
example,
as
we
as
you
can
see
it
here.
On
the
slide,
we
provide
the
possibility
to
extract
the
Scout
database.
B
B
Here
you
might
already
notice
that
we
have
two
different
data
flows
and
which
handle
which
both
of
them
will
require:
handle
user
requests
differently
for
admin
scenarios
and
for
the
for
the
shopper
scenarios.
We
have
different
set
of
api's
for
admin
scenarios.
We
have
rest
while
or
store
phones.
We
have
graphical
and
like
actually
like
everything
is
pretty
different
until
the
time
we
come
to
the
implementation,
because
for
graphical
implementation,
we
still
rely
on
the
same
set
of
service
contracts.
B
We
have
for
rest
and
that's
why,
for
example,
this
is
the
main
route
cost
for
us
that
our
graphically
guys
are
not
more
performance
efficient.
That
rustic
endpoints,
because
we
currently
don't
have
don't
have
the
benefits
of
using
either
patch
updates
and
taking
into
account
that
the
underlying
layer
is
pretty
much
the
same
for
both
rest
and
graph
QL.
We
supposed
to
easily
retrieve
entity
as
a
whole
or
persist
entity
as
a
whole,
and
we
are
not
and
we
are
losing
the
potential
potential
performance
benefit.
B
So
this
is
a
public
design
document
which
is
available
on
magenta
architectural
github,
and
this
document
introduces
the
idea
of
the
separation
on
two
different
application.
So
you
might
see
the
storefront
application
and
the
admin
application,
and
the
main
idea
here
was
that
for
quite
a
long
time
we
tried
to,
we
would
have
considered
that
admin
and
the
storefront
is
just
two
different
representation:
two
different
two
different
representation
of
the
same
business
scenarios,
just
sent
and
so
on
and
so
forth.
B
While
since
that
time,
they've
proposed
this
proposal
was
introduced,
we
started
to
consider
consider
as
two
different
application
work:
two
different
set
of
applications.
The
debt
here
you
might
see
with
different
colors.
We
try
to
to
highlight
the
corresponding
components
which
should
be
synchronized
to
one
another
between
between
those
applications,
and
we
are
not
like
the
time
the
time
flies
and
our
our
design
ideas
and
our
like
design
vision
also
also
changes
along
that
time.
B
Here
you
might,
you
might
find
the
way
how
we
end
up,
how
we
and
what
end
up
with,
in
particular,
for
catalog,
catalog,
storefronts
application
and
Anton
Coppola
will
later
talk
it
through
in
more
details.
But
the
main
idea
was
that
we
are
just
forced
to
introduce
two
different
applications:
the
storefront
application
and
the
store
management
application,
and
the
current
current
admin
panel
and
existing
monolith
might
be
considered
a
test
or
management
application,
because
we
don't
want
to
introduce
the
Packard
incompatible
changes
there.
B
We
want
to
preserve,
preserve
existing
ApS
as
much
as
possible,
but,
along
with
that,
we
want
to
introduce
in
your
application
on
his
side
and
taking
into
account
that
this
new
application
being
developed
from
scratch.
We
are
not
impacting
and
we
are
not
introducing
the
custom
incompatible
changes
to
exist
in
monolith
and
another
thing
that,
and
especially
we
started
to
face
those
cases
of
the
of
the
Adobe
acquisition.
We
see
that
many
merchants
who
come
to
Magento
right
now.
They
already
have
some
ecommerce
ecommerce
environment
in
play.
B
So
the
main
point
here
is
the
exchange
abilities
of
each
of
those.
If
each
of
those
applications
might
be
might
be
substituted
to
do
to
another
part-
and
here
you
might
see,
the
intermediate
part
of
the
event
broker
event
broker
is
also
in
application,
which
supposed
to
provide
the
ET
ends
of
the
extract
transformation
and
the
world
from
one
system
to
another
systems
or
the
main
responsibilities
to
just
much
different
API
provided
by
both
systems.
B
And
let
me
talk
through
and
just
to
highlight
and
just
emphasize
that
we
are
not
trying
to
represent
the
same
API
in
different
way.
I
mean
because,
especially
we
face
this
problem
at
the
beginning.
When
we
started
to
provide
a
graphical
coverage,
we
started
to
provide
a
graphical
coverage,
repeating
all
our
mistakes
and
just
trying
to
to
implement
our
existing
REST
API
on
another
language
on
another
on
another,
with
another
semantics
of
graph
care.
B
While
here,
for
example,
for
either
for
customer
domain
or
for
checkout
domain,
we
will
end
up
having
two
different
data
flows
because,
for
example,
in
case
of
customer,
the
same
customer
might
be
either
created
on
a
on
by
admin
on
admin
part,
while
the
same
customer
might
be
created
as
a
result
of
the
user
registration.
We
are
the
storefront
application,
and
here
we
need
to.
We
need
to
introduce
the
possibility
of
synchronizes
data.
B
B
If
you
go
deep
end,
we
will
I
just
wanted
to
make
you
some
brief
introduction
of
all
the
domains
which
will
be
affected
by
the
storefront
application
and
by
the
new
design
which
we're
going
to
introduce
in
the
scope
of
the
endoscope
of
effort
which
we
combine
as
a
storefront
application.
But,
for
example,
here
we
have
the
checkout
flow,
and
many
of
you,
especially
those
who
face
and
some
performance
problems
with
chakal
knows
that.
Currently,
we
don't
have
the
explicit
segregation
between
the
between
the
cars
and
unquote
and
we
like
we.
B
We
call
them
interchangeably
either
card.
What
on
the
level
of
our
API,
but
taking
into
account
that
we
have
explicit
separation
of
the
carton?
Would
we
called
in
and
we
are
cultivated,
all
the
totals
on
each
operation
of
Eden
item
to
the
cart
and
this
this
introduced
quite
a
lot
of
problems
for
us,
especially
for
for
b2b
scenarios
where
the
the
size,
the
the
size
of
card
may
be,
may
be
really
big.
B
B
You
might
also
find
the
explicit
design
which
which
which
describe
all
the
existing
is
existence
state
and
how
we
might
proceed
further
on
much
on
target
manage
an
architectural
get
hot,
using
the
search
phrase
as
an
alternative
checkout
flow.
So
there
you
might
find
the
design
required
by
you
games
in
turbo
which,
which
describe
a
year
behind
the
new
jacquard
warmer
here.
B
Another
problem
which
we
are
also
trying
to
address
is
a
it's
a
huge
number
of
permutations
of
prices,
which
also
which
also
a
big
issue
for
b2b
merchants,
and
the
main
root
cause
of
the
problem
is
the
currently.
We
are
storing
all
the
possible
permutations
of
prices
based
on
product
ID
website
ad
and
the
customer
group,
and
why
it's
the
biggest
problem
for
b2b,
because
we
have
quite,
as
you
know,
we
have
quite
a
lot
of
logic
in
b2b
based
on
the
customer
group.
So
this
is.
B
So
and
now
the
index
actually
make
all
those
permutation
and
that's
why
we
are
building
such
such
a
big
in
the
graph.
It's
why
we
spend
quite
a
lot
of
time
on
building
systems
and
sometimes
become
a
bottleneck
for
us.
That's
why,
in
the
scope
of
the
store
for
publication,
we
are
going
to
introduce
a
new
entity
which
we
call
the
price
book
and
the
price
book.
B
So
you
I
also
see
that-
and
here
I
just
I
just
want
to
emphasize
that
we
are
not
trying
to
duplicate
of
what
we
already
have
in
magenta
monolith,
but
we
are
trying
to
reconsider
all
the
existing
approaches
and
we
are
trying
to
fix
all
the
non
issues
and
norm
design
gaps.
We
already
have
in
models
here.
You
might
see
that
we
on
the
level
of
storefront
application.
B
B
We
are
introducing
the
BFF
there's
a
layer
of
BFF
which
stands
back
and
for
front-end,
and
we
account
the
playing
around
with
with
a
different
stand
along
a
few
servers
like
Polo
FASTA
file,
and
we
are
trying
to
stitch
the
graphical
schemas
provided
by
by
each
of
those
independent
pranams,
and
the
main
idea
was
a
graphical
standalone.
Graphical
server
will
be
to
route
the
request
to
the
to
the
precise
component
and
and
heaven
heaven.
This
is
now
here
in
a
way
of
the
standalone
govco
server.
We
what
what?
B
What?
What
we're
changing?
Fundamentally
here,
we're
changing
the
idea
of
the
API,
because
those
of
you
who
are
with
Magento
for
quite
a
while
when
here
one
here
in
the
term
of
API
you're
unavoidably
I,
consider
some
either
pitch
interface
a
pitch
because
all
like
some
PHP
entity,
we
have
in
our
code
base.
Well,
here
we
are
changing
the
idea
behind
the
API
terminology
that
we
are.
We
are
starting
to
consider.
B
B
Since
a
and
the
communication
between
those
services
will
be
done
through
the
through
the
through
the
service
mesh,
and
it
will
be
done,
we
we
are
either
ERP
C
or
a
similar
set
of
technology.
Also,
you
might
also
see
that
we
are
trying
here
like
we,
like.
All
our
services
will
be
more
and
more
integrated
with
Adobe
that,
for
example,
to
provide
the
better
demand
for
security,
we'll
get
more
integration
and
the
authorization
also
certification
will
be
done
through
the
identity
management
services.
B
In
our
case,
you
might
find
here
that
we
already
started
to
define
all
our
new
ApS
in
the
data
structure,
in
proto
definitions
and
based
on
those
proto
definitions.
We
we
are
generating
so
here
you
might
see
the
product
description
in
product,
and
here
the
shipping
service
described
described
in
proton
to
that.
Based
on
those-
and
you
should
know
the
definition
we
might
just
generate-
generate
some
language
specific
entities
with
the
protesta
compiler.
B
Now,
too,
is
pretty
much
all
from
my
side.
This
is
just
a
brief
introduction
and
you
might
think
the
main
idea
here
was
just
to
show
you
that
we,
we
are
reconsidering
and
reintroducing
quite
a
lot
of
eight
years
to
all
the
existing
domains
of
Magento
that
we
are
trying
on
the
level
of
design
to
solve
all
the
existing
problems,
and
some
of
those
problems
were
in
the
magenta
from
the
very
beginning
like,
for
example,
Chicago
process,
and
we
just
cannot
solve
them
earlier,
because
it
would
introduce
such
such
a
drastic
changes
to
Magento.
B
A
C
Yes,
yes,
okay,
I've
been
having
my
tissues
and
non-trans
morning.
All
right,
so
I
will
keep
it
brief,
since
Igor
covered
most
of
it.
One
thing
I
want
to
make
sure
I
reiterate,
is
a
storefront
will
be
an
open
source
effort
and
we
are
working
right
now
to
open
up
the
catalog
repo
to
public.
So
all
of
you
can
contribute
and
participate
in
making
this
a
great
project
and
in
terms
of
scope,
we
are
looking
at
an
early
access
program
for
catalog,
storefront
q1
of
2021,
so
about
in
three
quarters
and
the
scope
for
that.
C
Early
access
program
will
be
the
existing
catalog
and
search
graph,
QL
coverage.
So
all
the
catalog
queries
product
categories,
layer,
navigation,
all
of
that
will
be
covered-
will
have
separate
indexes
or
whatever
storage
we
are
going
to
be
choosing
for
catalog,
and
then
we
are
also
looking
at
the
bulk
support,
including
patch
and
Igor,
showed
you
the
proto
definition.
C
So
that
means
we
will
ensure
that
the
storefront
API
is
our
gr
PC
compatible
and
the
last
one
on
the
scope
is
the
node.js
implementation,
just
look
either
Apollo
or
FASTA
Phi,
which
our
technology
we
end
up.
Choosing
we
will
have
a
separate
implementation
outside
of
the
monolith
for
the
graph
QL.
So
this
is
the
current
scope.
C
It
is
on
our
catalog
storefront
repo,
which
is
currently
private
and,
as
I
said,
we
are
working
on
opening
it
up
and
we
have
a
pretty
heavy
backlog
already
with
a
lot
of
over
60
issues
already
created,
and
if
you
are
familiar
with
the
Magento
2
backlog,
it's
exactly
the
same
process
looks
exactly
the
same,
but
it's
less
effective,
catalog
storefront.
So
as
soon
as
we
open
this
up,
you
are
going
to
start
contributing
and
collaborating
with
us.
C
A
D
Okay,
I
believe
it's
Egan
has
already
covered
the
main
concept
in
idea,
so
I
will
speak
more
about
the
details,
don't
name
so
what
we
have
right
now
that
current
helps
the
Ferrante's,
which
is
a
graph,
kill
highly
cap
couple
twists
our
modern
use
application.
We
travel
through
the
resolvers
which
which
limit
us
in
many
many
different
ways.
First
of
all,
we
are
limited
scalability
because
it's
got
a
village
all
of
our
storefront,
as
it
was
always
the
same
scalability
as
we
have
for
a
horizontal
performance
also
affected
by
direct
invocation
of
models.
D
It's
this
women.
We
have
on
presentation
there
is
this
not
bad,
but
still
it
has
some
limitations
and,
of
course,
it's
big
because
of
our
normalized
structures
as
we
have,
we
have
to
perform
some
calculation
on
each
request,
even
from
the
font
operations.
This
is
what
we
want
to
change
with
a
new
design,
so
we
I
think
I
mentioned.
D
So
to
achieve
this,
we
have
to.
We
have
to
build.
An
integration
is
an
existing
data
because
we
don't
want
to
change
a
wheel.
We
don't
want
to
offer
homage
and
responsibilities
the
head
right
now:
magenta
works
well
at
the
admin
application
and
we
don't
want
to
change
it
at
all.
But
people
want
to
provide
a
way
to
extract
data
from
magenta,
transform
data
in
some
manner
and
sort
of
this
data
through
the
different
storage,
different
API,
which
which
will
give
us
much
better
of
performance
and
scalability.
Virtually
Forrester
found
requests.
D
To
see
more
bigger
picture,
I
believe,
that's
all
all
of
you
fight
situations
that
you
have.
You
have
to
integrate
a
multiple,
multiple
services.
Together,
we
got
it,
so
our
storefront
will
be
capable
to
connect
not
only
this
magenta,
which
has
to
be
capable
to
be
connected
to
any
systems.
It's
me.
We
main
want
to
degrade
into
it.
For
instance,
it's
in
case
you
have
a
separate
beam
system
or
we
have
separate
content
system
in
future
in
desirable
future.
D
Instead
of
right
and
during
integration
into
magenta,
you
will,
you
will
have
to
provide
a
separate
connector.
A
capacity
broker,
which
will
which
will
connect
original
source
of
data.
Is
the
data
projector
projections
that
we
are
going
to
build
resistor
from
kettle
diving
into
details.
What
should
be
done
to
achieve
this?
First
of
all,
we
know
that
right
now,
magenta
ape
it
does
not
have
enough
coverage
to
return.
Allow
the
data
to
build
a
storefront
projection
in
scope
of
this
project.
D
We
are
going
to
extend
our
export
API,
and
this
is
expert
API
partially
we
will
rethink
some
of
our
entities,
but
not
too
much
mainly
mainly
expose
the
data.
This
you
and
rakia
will
really
need
to
build.
A
storefront
part
will
expose
not
only
export.
Also.
We
are
going
to
expose
a
series
of
events
which
will
mattify
outside
observers
about
changes
inside
the
pantaloons.
All
of
you
are
already
familiar
these
concepts
of
events.
D
Messaging
broker:
this
is
another
another
sub
applications,
as
you
would
always
hear
in
this
project
there.
All
of
this
component
is
to
connect
different
system
together
at
the
first
step
of
definitely,
we
will
be
focus
it
on
integrating
magenta
and
your
compatriots,
but
for
future
we,
you
will
see
more
message,
brokers
or
integration
brokers.
It
really
depends
on
books,
you're
reading
it
could
be
named
in
both
ways.
D
Swarming
data
to
be
compatible,
this
storefront
ap
Ives
and
import
this
data
into
storefront
storage
and
the
last,
but
not
the
least
component
in
our
diagram.
This
is
the
look
storefront
as
I
mentioned
before
we
would
like
to
own.
We
would
like
to
break
limits
by
biased
vegans.
That's
we
here
right
now,
these
magenta
scaler
division.
So
the
main
purpose
of
this
component
is
to
be
here:
it's
performant.
Is
it
possible
and
scalable?
Is
it
possible
and
we
are
going
to
put
into
it-
not
a
lot
of
logic.
D
E
Hello,
all
right,
I'm,
going
to
show
I'm
going
to
show
a
demo
very
quick.
This
demo
will
include
creation
of
the
product
in
Magento
admin,
which
is
which
was
called
the
back-office
on
intense
diagram,
or
sometimes
you
reference
it
too,
as
a
pin
and
also
on
this
setup,
I
have
a
message
broker,
which
will
call
Magento
back
office
when,
when
the
up
this
event
was
was
published,
that
product
was
created,
fetch
the
data
from
the
coffee,
Sakai
and
ingest
the
data
in
the
storefront
application.
E
So
currently
it's
still
deployed
on
my
instance
as
one
with
application,
but
the
idea
that
in
the
future
this
will
be
three
different
applications
all
right.
So
I
have
this
a
graph
kill
request
to
the
restaurant
part
of
the
application.
I
currently
have
just
one
product
with
some
Eevee
attributes.
I'm
gonna
go
ahead
and
create
another
simple
product.
E
E
And
now
I
am
saving
the
product
and
the
ones
after
after
the
product
is
saved
or
indexer
is
running.
On
the
program.
Three
indexes
updates
in
the
expanded
on
the
back
office
in
the
back
office
is
complete
back
office
will
publish
event
that
hey
we
have
this
product
created
and
that
event
is
going
to
pick
up
by
a
message.
Broker
and
message
broker
will
call
the
coffee
set
guy,
get
the
data
of
new
with
needed
product,
and
by
now
it
should
be
ingested.
E
To
buy
storefront
application
much
the
broker
pushers
data
in
the
storefront
application.
So
now
we
can
see
our
product
with
visit
named
test2
in
in
our
storefront
application,
and
this
is
basically
the
demo
if
you
want
to
look
at
the
code
base
and
familiarize
yourself
what
is
going
on
and
where
the
project
are
one
of
the
things.
One
of
the
pages
that
might
be
helpful,
for
you
is,
is
this
page
where
it's
described
Javier?
Have
you
going
to?
Are
we
introducing
api's
in
the
storefront
expert,
apic
imported
guys
get
all
storefront
it
the
ice?
E
A
F
Hello,
so
actually,
today,
I
will
show
you
the
integration
of
storefront,
a
guy
with
our
grotto
server,
so
the
demo
will
be
the
first
part
of
the
demo
will
be
very
similar
to
what
a
girl
just
shown
you
so
for,
but
but
I'm
doing
it
in
more
headless
way,
so
for
demo
purposes,
I
just
injected
in
some
of
existing
graph.
Ko
tests
grab
the
fixture
from
it
and
the
query
and
the
query
should
actually
return
the
data.
So
nothing
really
new
here.
F
Wait
a
little
bit
and
yeah
you
can
see
that
data
is
coming.
There
is
not
so
much
difference
from
the
flow
point
of
view
right
now,
maybe
except
the
performance.
So
we
are
currently
taking
the
data
from
very
separate
storage,
which
is
elasticsearch.
As
you
can
see,
there
is
some
category
data
with
product
data
as
well.
I
can
actually.
F
F
So,
as
eager
already
mentioned,
we
are
using
the
protocol
in
order
to
specify
our
store
front
a
guy.
So
we
are
actually
writing
the
code
in
throat
about
and
then
we
are
launching
a
special
compiler
which
creates
magenta
modulus
for
us,
so
catalog
store
from
a
care
model
generated
automatically,
and
you
can
see
that
we
are
asking
not
to
edit
those
files.
F
What
else
so
I
saw
the
question
in
chat
about
Java
and
why
we
have
Java
and
throw
in
some
proto
files
and
your
rights?
We
may
use
gap
Java,
you
may
be
Java,
because
the
proto
wrote
about
format
is
cross-platform
cross
language
and
let's
say
if
you
already
have
some
inventory
management
written
on
goal
and
or
Java.
We
can
easily
connect
your
inventory
to
our
catalog
using
contracts
describe
it
in
front
of
format.
F
Yeah
we
are
describing
everything
in
proto
and
crota
is
native
format
for
your
OPC
services.
So
why
not
to
try
to
expose
our
generated
code
through
June?
You
see
actually
and
see
what
happens
so.
This
work
is
not
yet
it
is
very
early
stages,
but
it
works
right
now,
I'm
trying
to
launch
the
PC
server
on
top
of
the
same
code,
which
is
used
in
our
graph
QL.
So
we
are
sharing
the
code
and
also
I
will
try
to
launch
the
support
yeah.
F
F
C
F
We
can
go
back
to
the
console
and
there
was
some
warm-up
case
and
then
we
we
just
start
handling
requests
real,
really
fast.
We
are
spending
by
ten
eight
milliseconds
on
one
request,
one
request
and
good
thing
about
these
interfaces
that
their
support
batching
and
if
we
need
to
fetch
information
for
two
products,
for
example,
we
can
specify
two
IDs
and
get
twice
more
data
back
and
a
good
thing
is.
F
F
One
more
nice
thing
about
new
schema
is
that
module
which
is
generated
from
the
proto
bus
is
very
portable
and
could
be
installed
in
two
ways.
For
the
merchants
who
are
happy
with
performance
happy
with
current
things
on
their
instances,
we
can
install
that
module
in
monolith,
and
it
will
work
very
similarly
to
what
you
just
see
in
branchial
part
of
the
demo.
All
merchants
who
want
to
improve
the
performance
scalability
attach
completely
different
systems.
F
A
G
G
So
if
you
are
joining
the
project,
there
is
page
onboarding
which
should
help
you
start.
So
there
are
two
important
parts
here
called
sources.
As
you
know,
magenta
consists
of
multiple
repositories,
even
right
now
for
this
project,
it's
it
becomes
more
complex
and
more
posters
can
be
added
to
how
you
can
find
well.
G
Branches,
you
need
a
few
ways
to
do
it.
First
of
all,
if
you
are
working
on
the
project,
you
should
find
such
information
in
the
ticket
to
look
like
this
example,
an
example
ticket,
and
there
should
be
wisdom,
branches
that
you
need
to
use
for
this
ticket.
If
this
doesn't
exist,
ping
us
in
sweat
channel,
you
have
dedicated
slack
channel,
which
is
also
linked
here.
G
In
contacts
it's
closed,
so,
if
you're
not
on
the
project,
a
problem
won't
access
it
right
now,
then
another
way
to
find
the
list
of
branches
and
repositories
is
to
go
to
storefront
called
project
that
we
have
and
it
has.
If
you
are
familiar
with
cloud
project,
it
has
magenta
violent.
It
describes
all
the
Reapers
and
like.
If
you
choose
some
branch
feature
branch,
it
would
describe
all
the
branches
that
you
need.
So
that's
another
way.
G
If
you
know
your
feature,
branch
in
cloud
project
and
third
way
is
just
asking
in
almost
like
channel
like
not
so
documented,
and
next
thing
is
local
development.
So
if
you
know
all
the
branches,
how
do
you
actually
run
it
locally?
There
are
three
ways
that
we
describe.
First
is
magenta
cloud
doubles,
it's
official
magenta
cloud,
the
boss,
and
it
should
be
good
if
you
just
want
to
run
and
test
the
application
to
see
how
it
works.
G
You
can
find
steps
that
you
need
to
do
to
run
our
application,
but
also
we
have
a
script
that
you
can
create
just
copy
and
create
a
script
with
it
and
run
it
with
project
dear,
which
is
just
empty
dear
or
non-existent.
Dear,
very
where
you
want
to
create
your
project
github
token
and
in
the
documentation.
You
can
find
the
link
to
give
her
a
video
describes
how
to
create
github
talking
here.
It's
needed
to
fetch
repositories
because
they
are
private
and
Brighton
branch
name,
which
is
a
branch
of
cloud
project
that
I
just
showed.
G
So,
if
you
run
this
script,
it
will
pull
all
the
repository,
switch
to
the
branches
and
run
done
box
to
access
magenta
and
it
will
be
under
magenta
to
docker.
For
you,
that's
one
easy
way
and
each
approach
describes
pros
and
cons.
In
this
case,
it's
a
little
bit
difficult
to
really
develop
because
files
are
not
linked
today,
I
just
copied
to
magenta
file
structure
and
the
box
which
we
have
is
from
our
colleague
Andrea
locally,
and
it
actually
links
all
the
files,
and
there
is
a
link
here
that
you
can
find
with
these
doctors.
G
We
just
clone
the
repository.
You
go
to
this
link
and
read
the
documentation
on
how
to
set
it
up,
and
the
third
option
is
custom.
They'll
go
straight.
So
if
you
are
happy
with
the
infrastructure
that
you
already
have
for
local
development,
you
just
go
to
code
sources,
section
find
which
repository
trenches.
You
need
and
set
up
your
custom
dev
box
yeah.
There
is
some
information
about
testing
and
troubleshooting,
but
basically
I
think
that's
easy.
A
H
All
right,
I
have
two
minutes
and
I
guess:
I,
don't
have
much
information
to
share
so
excited
to
see
this
meeting
and
sharing
information
this
community.
We
are
working
hard
right
now
with
legals
to
prepare
all
the
code.
All
the
code
bases
to
be
open
source,
so
I
guess
it
will
take
a
couple
weeks
to
make
them
available
for
everyone
for
contribution
as
well
as
we
have
wrapping
up
with
documentation.
You
saw
a
lot
of
very
interesting
new
things
in
architecture
changes
and
etc.