►
From YouTube: Gitter infrastructure, UI and code overview
Description
Eric Eastwood gives an overview of the Gitter infrastructure, UI and codebase to the Static Site Editor team to enable the team to support with Gitter code reviews.
B
B
C
B
C
Okay,
the
first
point
is
just
some
notes
about
getting
the
app
running
locally.
The
big
thing
that
can
save
you
a
lot
of
time
is
using
this
create
seed
data
script
that
thomas
wrote.
It
allows
you
to
create
an
account
in
the
database
without
having
to
set
up
the
github
gitlab
twitter
oauth
applications,
which
is
kind
of
messy
to
set
up
and
lengthy.
C
C
Oh,
I
need
to
look
at
something
on
my
phone.
How
do
I
get
the
get
a
web
app
running
on
my
local
network
so
that,
like
I,
can
access
it
across
devices?
I'm
not
just
on
my
local
host
machine
stuff
like
that
and
then
gitter
was
acquired
by
git
lab
back
in
2017
and
nowadays,
just
like
thomas
has
done
with
gitter.
Today
I
used
to
work
with
him
for
about
over
a
year
year
and
a
half,
but
now
I'm
going
to
be
starting
as
a
sole
developer.
C
C
That
way
in
terms
of
how
the
application
there's
a
whole
bunch
of
different
clients
like
the
ios
android,
desktop
clients
that
interact
with
the
server
through
like
api
requests,
but
also
web
sockets.
Like
real-time
connection,
going
back
and
forth,
we
use
a
library
called
halle,
which
is
something
that
andrew
wrote
and
it's
it's
based
on
the
bay
bayou
fey
like
protocol,
which
is
just
a
layer
on
top
of
websockets.
C
This
is
kind
of
how
the
infrastructure
is
set
up.
Like
there's
multiple
boxes,
we
have
nginx
set
up
in
front
of
them
that
just
point
to
the
different
processes
so
like
there's
a
box
for
web
apps
like
this,
would
be
this
one
where
it
has
web
and
api
is
running
on
it
and
there's
web
socket
servers
which
is
to
have
websocket
processes
running
on
them
and
those
are
just
load
balanced
out
to
the
different
processes
and
there's
eight
of
each
each
of
these.
C
C
We're
using
mongodb
for
is
redis
we're
using
redis
for
a
bunch
of
a
bunch
of
different
things,
so
some
persistent
storage
non-persistent,
which
should
be
maybe
like.
No,
no,
maybe
notifications
or
something
like
that.
Caching
is
just
like
for
requests
and
actually
faye
would
be
for
the
real
time
stuff,
but
there's
a
bunch
of
different
databases.
I
guess
they
called
fredis,
maybe,
but
I
barely
have
to
ever
touch
redis.
That's
it's
nice
that
the
reddest
stuff
has
been
mostly
fine.
C
C
B
C
I
know
that
the
free
code
camp
room
had
a
cookie
bot
which
was
super
integrated
into
the
room
like
they
would
give
karma
points
to
like
people
answering
questions
and
how
they
interacted
and
stuff.
There
was
a
bunch
of
different
commands
they
had,
but
that
that's,
like
the
main,
that's
like
the
biggest
sort
of
deep
dive
I've
seen
used
into
it.
C
Other
people
use
it
for
like
archiving
uses
like
they
have
their
guitar
room,
but
then
they
also
kind
of
want
it
synced
over
to
their
site
for
legacy
purpose,
so
they
can
review
it
at
any
time.
In
case,
getter
is
not
a
thing
anymore
like
they
want
it
available
on
their
platform
and
there's
also
bridges
which
that
people
use
the
api.
C
C
C
Not
like
bare
bones,
but
a
few
tests
like
creating
a
room,
sending
a
message
just
to
make
sure
that
between
releases,
the
app
still
works
and
we
can
kind
of
be
more
confident
like
it
works
on
my
machine,
but
it
also
works
in
ci.
So
that's
nice
to
verify
that
things
are
working
in
another
environment
as
well.
C
C
Yeah
and
nci
would
be
the
same,
docker
setup,
it's
just
like
gillab
ci
services
that
you
can
run
parallel
to
your
job.
That
hook
in,
I
think
it.
I
think
it
is
possible
to
run
against
the
other
environments
like
you
can
just
switch
out
the
url,
and
since
it's
kind
of
like
box
testing
you
might
be
able
to,
there
is
a
case
of
we
have
like
a
fixture
endpoint,
that's
very
sensitive,
like
it
just
allows
you
to
create
whatever
you
want
for
the
testing
wise
like.
C
Oh,
I
need
a
user,
just
api
request
it
and
it
creates
it.
So
you
wouldn't
want
to
run
that
in
production.
But
technically
you
could
like
add
some
authentication
there
and
do
the
same
thing:
the
desktop
app
in
mobile
apps.
So
the
desktop
app
is
using
nwjs,
which
just
wraps
it's
just
a
way
to
wrap
a
web
application.
C
So
you
can
display,
like
a
url
page
as
like
a
seamless,
frameless
kind
of
application,
but
we're
looking
to
deprecate
that,
probably
after
the
next
major
release
that
we're
doing
just
because
we
the
only
time
we
ever
look
at
it,
is
when
it
breaks.
So
not
the
best
of
situations
on
that
the
mobile
apps
are
hybrid.
There's
like
a
chat
view
that
you're
able
to
see
the
markdown.
C
As
in
like
a
iframe
sort
of
thing.
The
web
frames
that
both
ios
and
android
use,
because
it's
hard
to
like
render
markdown
as
like
native
components,
but
these
are
much
more
broken
and
like
not
as
fun
to
work
with
so
they're.
Also,
since
it's
not
just
wrapping
at
the
whole
web
app
itself
when
we
want
to
add
new
features
like
threads,
we
have
to
like
think
about
adding
it
to
the
apps
and
that's
no
fun.
C
I
I
don't
think
the
progressive
web
app
will
be
like
in
place
and
totally
feature
full
of
like
the
same
mobile
and
desktop
experience,
but
I
I
did
want
to
add
those
in
there
to
like
at
allow
people
to
track
them
so
that
they
know
like
we're.
Definitely
thinking
about
it,
but
it's
not
gonna,
be
this.
It's
not.
It's
not
gonna,
be
the
same
experience.
It's
just
gonna,
be
our
focus
is
gonna
be
on
the
web
app
because
I
can't
maintain
all
platforms,
basically.
A
So
the
the
one
question
I
had
on
on
that
area-
and
I
haven't
looked
at
this
at
all
yet
so
it
may
be
dumb
questions,
but
previously
on
the
app
I
worked
in,
it
was
a
backbone
focused,
and
then
we
tried
to
add
parts
of
the
react
and
ran
into
a
lot
of
problems
of
just
the
way.
The
backbone
works,
which
is
essentially
sort
of
a
restful
database
type
paradigm
versus
react
and
vue
which
have
an
event
loop
and
assume
a
single
immutable
store.
C
A
C
A
C
C
C
And
so
far
we
have
we're
not
doing
a
global
view,
application
and
mixing
and
backbone
components
into
it.
Yet,
right
now,
it's
it's
just
single
view:
components
rendered
in
kind
of
the
backbone
interface
we're
still
using
the
backbone
router
in
that
ecosystem,
but
we're
I
like,
I
can
definitely
see
the
end
of
like
making
the
chat,
chat,
view
and
view
js,
and
then
we
can
kind
of
convert
all
the
way
over
to
vgs
completely
and
use
the
view
router
and
nice
stuff.
There.
C
Other
lexi
stuff,
the
weirdest
thing
in
the
code
base
is
that
rooms
are
called
troops
in
the
code
base.
So
there's
the
thing
called
like
troop
service,
but
that
just
means
like
room
service.
It
was
it's
a
legacy
aspect
of
how
the
product
used
to
be
like
was
made,
and
it
was
called
troop
back
in
the
day
and
then
they
pivoted
over
to
gitter
and
open
source
and
stuff
like
that.
C
This
one
isn't
as
weird
but
a
community
is
it's
called
community
on
the
user
side
and
a
group
on
the
back
end.
The
ui,
a
breakdown
is
like
the
left
menu.
This.
This
section
is
all
in
view
nowadays
and
there
used
to
be
iframes
between
the
left
menu
in
the
chat
area,
but
all
that's
gone
once
we
switch
to
view.
I
migrated
over
to
a
single
actual
application,
which
is
very
nice,
because
we
had
syncing
problems
between
the
iframe
v4.
C
C
C
And
we
don't
plan
to
like
migrate
it
over
to
gcp
or
anything
we
have
considered
in
the
past,
maybe
doing
kubernetes,
but
since
everything's
just
working
and
not
really
worried
about,
we
don't
plan
to
actually
use
it
or
migrate
it
to
that
sort
of
stuff.
Most
of
the
infrastructure
runs
on
ubuntu
14,
which
is
an
unsupported
lts
now,
but
we've
just
recently
upgraded
all
the
web
app
servers
to
ubuntu
16,
which
is
nice
to
see
it.
B
C
C
C
It
just
runs
like
shell
scripts,
and
it
has
its
own
like
yaml
language,
for
like
setting
up
directories
or
installing
stuff
in
terraform.
We
use
that
to
manage
aws
stuff.
So
like
I
want
to
create
an
instance
it
can.
It
knows
the
aws
config
and
all
their
proprietary
stuff
to
know
what
to
do
there.
So
we
can
set
up
auto
scaling
groups
and
manage
that
sort
of
stuff.
There's
still
plenty
of
these
boxes
and
like
volumes
and
images
and
whatever
stuff
is
still
snowflake.
C
C
B
C
A
C
C
C
Deeply
have
a
thing
called
staging
and
next,
which
is
where
we
put
like
upcoming
releases
on
and
there's
a
document
section
about
what
it
is.
But
basically
it's
just
the
same
as
git
I
am.
But
if
you
go
to
go
to
this
thing
first
and
turn
on
next,
then
you
get
at
the
upcoming
release
and
this
allows
us
to
test
on
a
smaller
subset
of
users
and
make
sure
things
are
going
right
and
we
can
check
century
before
things
go
wrong
to
win.
C
Yeah
there's
some
feature
flags.
A
lot
of
them
should
be
just
left
at
the
fault,
and
this
one
is,
for
example,
is
known
to
cause
bugs,
so
we
add
comments
around
it.
There
was
more
relevant
ones
before,
like
threaded
conversations
was
here,
but
now
that's
rolled
out
generally
available.
It's
was
removed
from
this.
A
C
It's
all
running
on
the
same
database
so
when
we
do
do
upgrades
like
that,
we
just
iteratively
push
stuff
out
and
because
we
can
do
continuous
deployment
it's
much
easier
to
just
like.
Oh
here's,
the
first
set
of
changes
plan
it
out
next
one
and
then
migrate
fully
to
it.
So
usually,
if
the
code
supports
the
new
one
old
way
at
the
same
time,
and
then
once
all
the
servers
are
switched
over
to
like
the
possible
new
way,
we
just
remove
that
old
support
out
of
there.
A
C
C
C
Yeah
they're,
just
recently
someone
was
asking
about
how
can
I
find
my
messages
in
search
and
then
someone
came
in
there
with
all
their
fancy
elastic
search
queries
because
you
can
kind
of
put
those
in
our
search
and
use
them.
I
wasn't
like
familiar
with
the
syntax
as
much,
but
now
we
now
we
have
those
documents
in
our
docs
and
I
plan
to
add
them
directly
to
the
search
panel,
so
that
people
can
just
reference
them
right
away
and
be
more.
C
You
know
empowered
to
like
find
what
they
need.
That
was
exciting
contribution.
Recently
the
get
chat,
git
chat,
twitter,
that's
where
we
announce
all
our
down
time,
and
we
also
have
our
releases
ping
there.
So
anytime
we
put
something
on
staging
anytime.
We
put
something
on
production.
We
announce
that
getter
27,
whatever
is
out
here's
the
change
log.
C
C
C
C
C
C
It
was
a
bit
scary
to
set
up,
of
course,
because,
like
you're
in
public
with
secrets
and
stuff,
it's
like,
I
don't
do
anything
weird
with
all
this
log
output,
but
it's
really
cool
to
see
where
I
can
just
like
tweet.
The
link
and
people
can
follow
along
on
the
release.
When
I'm
doing
productions
like
they
see
the
pipeline
running
and
then
I
just
press
deploy
prod
and
it
all
flows
out.
C
And
it
has
a
snapshot
of
our
database
from
a
long
time
ago,
so
we
have
data
to
play
with
and
when
we
like
test
features
on
there
we're
able
to
like.
Oh,
I
can
switch
them
with
a
bunch
of
rooms,
add
scroll
a
bunch
of
messages
and
everything
is
easy
to
see.
It's
just
public
like
we
stripped
all
the
sensitive
private
stuff.
It's
just
all
public
messages
over
there
and
it's
available
to
the
like.
C
C
Toggle
develop
branch,
this
it's
it
gets
deployed
to
beta,
just
as
a
sanity
check
you
can
switch
between
them
and
see
like
okay
is
my
beta
staging
feature
branches
broke
compared
to
the
sort
of
more
stable,
develop
branch?
The
master
branch
doesn't
really
have
a
purpose.
It
just
gets
back
merged
into
whenever
you
do
a
release.
C
The
release
branches
get
deployed
to
staging
so
like
we
take
what's
on
develop.
Okay,
say
it's
good
enough
right
here
we
put
it
on
the
release
branch
and
it
gets
deployed
to
staging,
and
then
once
it's
been
validated
on
sentry
and
making
sure
that
things
still
are
working
as
expected,
we
can
merge
it
and
tag
the
release
and
those
go
straight
to
production
security
fixes.
We
have
a
whole
document
about
it,
but
that's
a
bit
different
and
probably
won't
be
relevant
to
you.
C
A
cookie
toggle
and
it's
it
just
depends
on
what
code
is
running,
so
it's
similar
to
getter
production
and
getter
staging
it's
just
the
upcoming
sort
of
testing
environment
that
you're
able
to
test
on
base
staging
you're
testing,
like
your
random
feature
code
that
doesn't
matter
and
beta
is
just
a
way
to
test.
What's
on
develop
so
that,
oh,
I
can
go
to
beta
itself,
see
if
it's
good
and
then
make
a
release
branch
which
goes
to
staging.
C
C
For
example,
like
we
cut
out
a
bunch
of
animations
across
the
site,
just
because
it's
extra
random
code
that
I
didn't
want
to
worry
about,
so
things
just
open
immediately
and
stuff
like
that,
there's
a
bunch
of
getter
web
packages
in
the
package.json,
but
these
are
just
locally
in
the
repo
like
files,
it's
just
a
mono,
repos
kind
of
sub
module
structure.
So,
like
this
api
client,
you
can
just
find
it
directly
in
the
modules
folder.
C
Main
thing
performance,
wise
is
probably
on
the
back
end
and
the
main
entity
that
gets
created
often
and
stuff
is
messages.
So
whenever
I'm
working
on
messages,
I
just
want
to
I
kind
of
double
check
to
make
sure
I'm
not
like
looping
through
all
the
messages
and,
like
you
know,
processing
things
before
it's
served,
trying
to
make
it
as
simple
as
possible.
Maybe
let
indexes
handle
a
sorting
for
me
or
something
like
that.
C
C
For
the
vgs
code,
we
can
lean
on
whatever
sort
of
get
labs
doing.
There
are
some
differences
like
the
server-side,
rendering
that
we're
doing
or
like
top-level
ux
store.
I
know
that
in
gitlab
the
stores
are
kind
of
individualized
to
the
component
right
now
and
the
big
hairy
audacious
goal
is
to
have
everything.
C
In
the
the
top
level
of
ux
store
that
way,
we
can
snapshot
that
little
object
and
like
pass
it
over
to
send
it
over
to
us.
So
we
can
like
reproduce
the
bug
and
see
what's
going
on
or
be
able
to
step
through
time,
it's
like
the
step
before
it
is
broken
and
a
step
now
and
oh
I'm
sending
out
this
random
action.
That's
breaking
the
whole
app
okay,
easy
to
fix
just
makes
things
easier
to
debug.
C
C
Another
difference
is
we're
using
less
styles
that
are
scoped
to
the
view
component,
so
they
they
don't
bubble
up
and
mess
with
the
global
styles,
and
that's
a
really
nice
feature
of
of
having
to
be
compatible
with
the
backbone
marionette
stuff
and
the
new
view
stuff,
because
all
the
backbone
styles
are
kind
of
global
and
can
affect
everything
on
the
page
versus
these
styles
are
are
get
generated
with
little
tags
that
make
them
specific
to
the
these.
Like
elements
here.
C
The
string
string
interpolation
is
nice
every
once
in
a
while,
but
I
have
in
the
past.
There's
some
sas
features
that'd
be
nicer,
but
I
do
like
how
less
kind
of
acts
more
like
css,
with
their
dependent
order
stuff.
I
think
sas
is
more
like
a
language
language
where
it's
it
runs
as
it
goes.
Instead
of.
C
C
C
C
They
receive
it
via
the
web,
socket
connection
from
the
bayou
cluster,
and
then
we
render
it
just
like
normal
on
the
front.
End,
eges
or
backbone
stuff
down
here
is
a
bunch
of
the
details
around
it.
For
example,
the
chat
view
is
still
in
backbone,
so
we're
using
like
the
live
collections
there,
which
is
kind
of
like
a
two-way
binded
collection
from
like
the
ui
and
the
real
time
like
you
change
something
on
the
client
in
the
collection
it
goes
back
up.
But
if
the
server
changes
something
comes
back
down.
C
Let's
see
if
there's
anything
interesting
in
here
that
I
can
explain,
maybe
this
is
like
a
mongoose
object,
so
it's
we
use
mongoose
on
top
of
mango
to
manage
like
required
fields
or
validating
stuff.
I
guess,
if
you
don't
do
stuff
quite
right.
According
to
the
schema,
then
it'll
throw
errors.
I
can
show
you
the
chat
message.
C
B
C
C
C
C
So
it
goes
into
this
bayou
event,
events
bridge,
which
kind
of
connects
our
database
and
the
real-time
cluster
so
like.
Whenever
something
happens
in
the
database,
we
also
want
to
tell
the
clients
that,
oh,
this
message
updated
someone
edited
a
message
and
we
want
to
give
you
the
latest
or
if
something
was
added
or
deleted.
That's
where
that
connection
is
made
so
that
we
don't
like
desync
and.
C
C
C
C
C
C
C
C
Small,
but
the
right
toolbar
will
move
into
like
collapsible
sections,
and
then
this
displays
certain
the
sums
same
information
we
have
now,
but
in
the
future
we
can
easily
add
more
glam
integration
here,
like
oh
here's,
the
pipelines
running
for
your
project
stuff,
like
that
simplifying
the
chat
header
relationship
compared
to
the
room
details
currently
on
getter.
This
sort
of
information
is
global
in
terms
of
the
profile,
but
then
also
room
relevant,
which
doesn't
always
make
it
obvious
of
like
what
controls
control.
What.
C
C
C
But
we'll
have
this
similar
thing
right
here
and
then
the
chat
actions
will
be
displayed
directly
instead
of
under
a
hamburger
menu,
which
makes
a
lot
more
sense.
When
now
that
we
have
threads,
because
before
those
actions
were
kind
of
seldom
used
like
deleting
a
message
is
not
always
what
you
want
to
do
right
away.
But
starting
a
thread
is
an
action.
You
kind
of
just
want
to
hop
on
and
reply
to
someone.
C
So
big
changes
this
milestone.
I
plan
to
work
on
the
right
toolbar.
So
me,
you'll,
probably
see
some
merge
requests
come
your
way
on
vujs
right
to
r
and
I'm
guessing
I'll,
probably
put
that
behind
a
feature.
Toggle
have
the
old
one
in
the
new
one
in
place,
but
then
go
to
just
have
a
feature
toggle
on
next.geter.m
to
toggle
the
new
one
versus
the
old
one.
C
This
is
what
I
did
with
the
the
left
menu
when
I
did
that
vue.js
refactor,
the
old
one,
the
new
one
were
side
by
side,
and
then
you
could
talk.
People
who
want
to
try
it
out.
Experiment
could
turn
it
on
and
we
also
able
to
collect
bugs
that
way
and
then,
once
we
were
happy
with
it,
put
it
out
generally
available
and
remove
the
feature
toggle.
C
C
B
C
C
B
Cool
well,
thank
you
very
much
for
the
overview
eric.
I
think
you
from
a
next
step
point
of
view.
You
know
just
picking
both
chad
and
me
on
on,
mrs,
as
as
they
become
radiant,
it
might
take
us
a
few
emotions
really
just
getting
the
groove
of
things
you
get
familiar
with
where
things
are
and
and
maybe
even
if
we,
if
we
feel
like
you,
know
one
one,
one
or
two
mores
that
we
kind
of
like
do
a
sinkhole
for
you
to
take
us
through
it
as
well.
B
A
C
C
A
C
C
C
C
C
And
instead
of
hitting
the
get
lab
api
that
fetched
my
projects
or
projects
I
have
access
to,
I
was
hitting
the
endpoint
that
fetched
all
projects
so
are
all
public
projects.
So
every
time
someone
was
using
signed
with
git
lab
and
trying
to
create
a
room,
they
were
fetching
like
400
pages
of
git
lab
projects
before
the
server
would
just
crash
and
be
like
nope.
C
I
can't
I
can't
the
paginator
would
go
forever
until
the
gitlab
api
would
end,
but
it
would
never
end
because
there's
millions
of
projects,
thousands
of
projects
on
gitlab
that
you
would
have
to
get
through
to
possibly
finish,
but
that
was
just
a
case
of
using
the
wrong
api,
endpoint
and
maybe
bad
testing.
But
first
the
tests
I
wrote
were
passing.
So
that's
the
problem.
Basically,
I
wrote
tests.
C
Yeah
api
projects-
I
didn't
realize
it
fetched
all
projects
versus
your
own
projects.
We
have
a
similar
github
repo
service
and
the
in
the
end
point
that's
similar
to
that
fetches
only
your
own
stuff,
so
I
was
going.
I
was
basing
everything
off
that
and
it
didn't
work.
The
same
so
ran
into
big
issues.
There.