►
From YouTube: Real Time: Summary of Progress 2021-03-12
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
Hi
everyone-
this
is
john
hope,
I'm
the
facilitator
of
the
real-time
working
group
and
I've
been
asked
a
couple
of
times
recently
about
the
progress
of
real
time.
So
I
thought
I'd
make
a
quick
summary
video
to
demonstrate
the
first
feature
that
uses
web
sockets
and
talk
about
the
next
steps
that
we're
taking
to
make
it
easier
for
teams
within
get
lab
and
members
of
the
wider
community
to
build
real-time
features
using
web
sockets.
So
you
may
be
thinking,
don't
we
have
real
time
already.
A
So
if
somebody
makes
a
change
to
an
issue,
you
might
not
see
that
change
for
three
seconds
or
more,
that's
not
ideal
for
our
ultimate
goal,
which
is
collaborative
editing
of
issue
descriptions.
So
the
purpose
of
the
working
group
was
to
discover
and
implement
a
solution.
That's
low,
latency,
that's
reliable,
and
that
gets
us
closer
to
the
goal
of
a
snappy,
truly
real-time
application
and
we
chose
websockets
implemented
via
action.
A
Cable
action,
cable
is
included
with
rails,
it
uses
ruby,
so
we
understand
the
source
code
and
it's
relatively
mature,
so
its
limitations
are
are
well
known.
So
what
I'll
do
now
is
just
I'll
demonstrate.
The
first
feature
that
uses
web
sockets
for
a
real-time
experience,
and
this
feature
was
built
by
heinrich
who's,
really
driven
the
real
time
project
from
the
start
and
has
stewarded
this
feature
all
the
way
to
production.
The
feature
is
signees
on
the
issue
sidebar.
So
what
I've
got
here
is
two
browser
windows
open
side
by
side.
A
Looking
at
the
same
issue
you
can
see
nobody's
assigned,
so
I'm
going
to
assign
myself
and
you'll
see
the
assignees
update
here
on
the
right,
and
that's
it.
That's
the
feature
this
is
available
to
everyone
on
gitlab.com.
It's
been
enabled
for
over
a
month.
It's
also
available
to
self
hosting
customers
who
enable
the
feature
flag,
and
they
have
a
number
of
different
ways.
They
can
deploy
it
depending
on
their
cluster
size,
or
instance,
size,
and
you
can
try
it
yourself.
I
mean
you,
don't
have
to
have
two
browser
windows
open
side
by
side.
A
You
can
just
use
quick
actions
to
assign
or
unassign
yourself
and
see
the
the
sidebar
update
in
real
time.
So,
although
this
is
a
small
feature,
it
actually
represents
really
good
progress.
We
encountered
a
number
of
challenges
on
the
way
to
delivering
this
first
feature.
You
know
going
from
zero
to
one,
for
example.
A
In
order
to
support
this
feature,
we
have
to
maintain
an
open,
websocket
connection
for
everyone,
who's
currently
viewing
an
issue
on
gitlab.com
and
that
peaks
at
around
40
000,
open
connections,
sometimes
spikes
even
much
higher
than
that,
and
these
differ
from
your
typical
hdb
traffic
that
you
would
see
on
the
web
app
which
is
short-lived,
and
it's
stateless
and
it's
designed
to
facilitate
the
request
response
cycle.
These
are
persistent,
open,
tcp
connections
that
are
intended
for
bi-directional
communication.
A
A
So
this
is
just
one
example
of
why
the
cost
of
implementing
the
first
feature
was
so
high,
and
it's
taken
us
a
while
to
get
this
right.
So
where
are
we
going
next?
Well,
we
have
an
okr
in
q1
to
mature
real
time,
and
you
can
follow
it
in
this
epic.
A
If
the
okr
is
successful,
we'll
have
refactored
the
current
implementation
to
a
sustainable
state,
we'll
provide
metrics
and
developer
documentation
from
which
any
team
can
self-serve
to
build.
Real-Time
features
using
web
sockets
we'll
also
understand
the
cost
of
scaling
connections
to
new
parts
of
the
application,
but
there's
already
a
proof
of
concept
here,
built
off
of
branched
off
of
the
work
to
refactor
to
graphql.
Subscriptions
the
proof
concept
is
built
by
phil
hughes
and
its
real-time,
mr
widget
states.
A
So
as
soon
as
we
know
the
cost
of
supporting
connections
on
mrs,
we,
how
we'll
have
a
next
feature
to
implement
there
as
well,
if
we're
successful
in
this
okr
as
a
whole,
we'll
have
unlocked
websockets
as
a
usable
technology
for
the
whole
team,
and
while
I
explained
the
fixed
cost
of
supporting
websockets
and
implementing
the
first
feature
was
high.
The
marginal
cost
of
adding
new
features
is
comparatively
low,
especially
in
the
case
of
adding
new
features
to
the
issue.
View
page,
which
we
already
have
a
connection.
We
can
reuse
there.
A
So
that's
where
I'll
leave
it
for
now,
you
can
check
out
this
slide
deck
if
you'd
like
more
information
or
you
can
follow
along
using
the
epic
for
the
okr
for
this
quarter.
We
also
have
a
slack
channel.
You
can
reach
out
to
any
of
the
dris
as
well,
and
if
you'd
like
to
read
further
into
our
progress
with
real
time,
you
can
use
the
working
group
handbook
page
or
the
design
document
and
depend
on
how
far
you
want
to
go.