►
From YouTube: Tracing is for Everyone, Not Just Backend Engineers. (How Tracing Could Help Front-e... Nina Stawski
Description
Join us for Kubernetes Forums Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Tracing is for Everyone, Not Just Backend Engineers. (How Tracing Could Help Front-end Engineers to Build a Better UX) - Nina Stawski, Omnition
There's been a lot of talk about the importance of observability and tracing for microservice-based applications. The usecases involved are usually focused on backend engineers and DevOps. But what about us front-end engineers? We also want to know how things work. More often than not, we get blamed first when something breaks, and it is important to understand the whole application, not just the front-end.
Currently, observability is not the top concern for front-end engineers, and I will show why it should be. In many cases, even if the application speed cannot be changed significantly, you can apply little tricks and add microinteractions to improve the UX. Besides, emerging tooling in OpenCensus and OpenTelemetry is easy to configure, enriches the existing data and helps developers to correlate traces between backend and UI.
A
Hello,
everyone,
my
name,
is
Nina
Starsky
I
am
originally
from
a
small
startup
called
the
mission,
but,
as
it
happens,
we
recently
got
acquired
by
a
much
bigger
company.
Splunk
and
I
am
actually
a
front-end
engineer
and
just
to
get
a
sense
of
basically
the
crowd.
Let
me
know
how
many
front
that
engineers
are
here.
A
Cool,
so
why
did
I
decide
to
give
this
talk?
Well,
as
front-end
insurance,
you
know
anything
happens.
Your
customers
see
you
I.
First
in
you,
I
always
get
blames.
First,
something
happens.
You
gotta,
like
you,
get
bad
feedback
from
your
back-end
engineers
from
ops.
It's
like
it's
must
be
in
a
UI,
you
say
no,
no,
it
must
be
in
the
backend,
it
must
be
somewhere
else
and
the
truth
is
the
is
sober
there.
A
It's
somewhere
in
between
it
could
be
front-end
could
be
back-end
and
there
is
no
easy
way
to
track
like
difficult
performance
issues,
especially
in
the
front
end.
It's
tough
to
really
look
for
issues
within
your
codes,
using
analytics
alone,
it
looks
like
while
you're
just
trying
to
find
a
needle
in
a
haystack,
sometimes
you've
gotta
go
and
look
at
your
back-end
logs.
A
If
it's
micro
services
you've
got
to
go
in
look
into
your
traces,
but
then
it
turns
out
to
be
somewhere
else
and
back
into
engineers,
and
also
you
guys
have
really
good
tools
at
your
disposal,
especially
with
now
a
lot
of
open
source
projects
and
data
collection.
So
well
we
front-end
our
engineers.
We
also
want
to
find
out
what
happens
and
we
also
want
to
build
micro-services
it's
new,
but
this
also
like
this
is
a
new
thing
that
is
especially
hard
to
track.
A
And
we
have
well,
as
I
mentioned,
there
is
a
project
that
helps
you
collect
you
data
and
make
sense
of
your
distributed.
Data
and
I
will
be
talking
about
it.
A
little
bit
and
open
telemetry
is
basically
a
combination
of
two
projects
up
and
tracing
and
open
census,
and
it's
basically
just
lets
you
do
distributed
tracing,
but
for
back
end
and
because
my
company
is
a
big
contributor
into
open
telemetry
first
thing,
I
asked
myself
was
okay,
can
you
do
something
in
the
front
end
here
and
I
found
out?
A
A
Taking
you
with
me
on
this
quest
to
find
out
if
it
can
run
in
the
browser
and
what
we
can
do
with
it,
and
this
is
I,
think
gonna
be
the
first
time
I'm
gonna
be
coding
in
front
of
so
many
people
watching
me
code,
so
Kathleen
sounds
like
and
I
have
an
application
here
that
we're
gonna
be
instrumenting.
So
I
have
a
set
of
actions
you
can
take.
Basically
you
will
be
taking
a
set
of
actions
and
then
we
gonna
be
ending
these
actions.
A
A
A
All
right
so
I
have
my
application.
I
have
a
bunch
of
buttons
that
do
certain
actions
when
you
click
the
first
button.
You
start
a
chain
of
actions
and
then
there
is
an
option
to
and
actions
so
right
here
and
I
want
when
I
click
my
first
button.
I
want
to
be
able
to
create
a
span
and
actually
create
the
trace
and
start
adding
spans
into
that
trace,
and
when
I
finish,
I
want
to
post
it
to
Zipkin.
So
there
are
two
parts
to
that.
A
I
commented
out
some
code,
but
we're
gonna
be
using
this
so
and
we
we're
gonna,
be
creating
a
react
hook.
If,
like
fronting
people
know
what
react
is
probably,
but
you
can
do
it,
it
doesn't
have
to
be
react.
You
can
do
it
with
other
backends,
it's
just
something
I'm
more
familiar
with,
and
it's
simpler
to
do
so
we
got
to
be
creating
a
tracer
first
and
you
can
see
there
are
a
few
libraries
conveniently
existing
in
open
telemetry
project
already.
A
A
A
Open
telemetry
and
we'll
not
here
and
we're
gonna
initialize
the
global
tracer
with
my
tracer.
Basically,
that's
all
you
need
to
wire
up
open
telemetry
into
your
projects.
That's
it
well,
we'll
need
to
create
a
function
that
let
us
create
spawns,
but
this
is
as
easy
as
it
is
so
yeah.
Let's
continue
with
creating
a
span.
It's
also
gonna
be
pretty
quick
so
and
thanks
to
already
creating
existing
types
for
typescript,
it's
easier
to
do
as
I
mentioned.
If
we
want
to
create
a
trait,
so
we
have
a
set
of
spans.
A
This
is
basically
maybe
our
actions
and
it's
failed
to
compile,
of
course,
because
I
haven't
finished
this,
but
basically
this
is
our
actions
when
I
click
the
button.
Every
time
I'm
going
to
create
this
span
a
piece
of
my
data
that
I'm
tracking
tracking
and
if
I,
want
to
connect
them
together.
I
need
to
put
them
together
into
your
trace
and
to
do
that.
I
create
one
span
and
everything
else
I
will
put
inside
of
it.
So
you
can
see.
I
have
an
attribute
parent
right
here.
A
A
A
A
A
And
we
actually
done
so
after
we
created
a
spun.
We
if
we
want
to
track
performance,
we
want
to
make
sure
the
spun
ends
right
like
if
it's
the
button
click,
for
example,
the
spun
as
ends
right
when
I
click
it,
but
if
I
want
to
track
performance,
if
maybe
a
some
larger
function,
I
would
separate
it
into
two
different
functions.
I
would
start
a
spun
right
here,
but
I
would
also
add
a
separate
function
for
and
spam.
A
In
this
case
we
don't
need
this
so
I'll
just
end
the
spawn
right
here
and
and
I'm
gonna
return
it.
So
so
my
application,
when
it's
returned
can
track
our
current
parent
span
to
create
a
trace.
So
this
should
actually,
let's
see
my
app,
is
back
up
and,
as
you
can
see,
I
have
no
traces
in
Zipkin
right
now.
So
let's
click
on
a
few
buttons
and
see
what
happens?
Yes,
it's
true
and
you
can
see
all
of
my
button
clicks
are
clicked
three
or
four
one,
three,
eight
and
seven,
and
you
can
see
that.
A
A
Yes,
see
you,
okay,
you
can
see,
there
is
a
button
one.
Some
reason
it
doesn't
show
me
that
it's
been
a
click
event,
but
it
should
be
so
live
demos
yeah.
So
basically,
we
just
found
out
that
up
until
I
materially
can
run
in
the
browser,
and
it
opens
actually
a
lot
of
a
lot
of
different
possibilities
and
by
the
way,
the
code
that
I
just
wrote
in
a
bottom.
There
is
a
github
link
and
I
also
have
it
at
the
end
of
the
slides.
A
So
you
can
check
it
out,
as
you
can
see
like
we
could
do
it
right
here
live
at
stage.
So
it's
short,
it
doesn't
take
a
lot
of
time,
but
it
gives
you
a
lot
of
power.
So
alright
it
it
is
now
traceable,
front
end.
You
can
run
it
in
the
browser.
You
can
build
it
for
react.
Is
it
really
useful?
What
can
we
do
with
that
and
well,
there
is
a
bunch
of
things
you
could
do.
A
One
is
basically
have
separate,
separate
functions
in
there
and
your
front
end
to
track
performance
of
your
applications
of
different
pieces.
Maybe
you
receive
a
JSON
from
a
back-end
and
you
want
to
check
how
long
does
it
take
to
basically
to
parse
on
in
different
environments
when
your
front-end
runs
in
different
browsers?
If
you
have
multiple
front
ends,
you
want
to
be
sure
you
connect
these
front
ends
with
specific
data
in
the
back
back-end.
You
can,
if
you
see
that
something
is
taking
longer,
but
you
cannot
influence
that.
A
A
You
can
use
this
open
telemetry
in
the
browser
or
you
can
not
use
it
in
the
browser.
So,
alternatively,
for
example,
if
you
have
multiple
back
and
multiple
front
ends,
front-end
applications
connecting
to
your
back-end-
it's
not
necessarily
all
JavaScript.
It's
not
necessarily
all
react.
It
could
be
native
apps.
You
could
still
take
advantage
of
open
telemetry.
You
could
still
create
your
spans
in
front
end.
You
can
pass
them
to
the
backend
and
you
can
connect
them
with
the
data
that
you
have
and
also
don't
get
locked
into.
A
single
vendor.
A
Open
source
is
a
wonderful
thing.
So
is
this
all
nice
with
running
in
the
browser?
Not
really
if
you
want
to
run
open,
telemetry
live
in
the
browser.
Of
course.
It's
in
my
local
environment,
that's
easy,
I,
spin,
the
doctor
instance
and
I
just
post
there,
no
authentication,
nothing,
it
works,
but
you
have
to
take
care
of
basically
cross-site
resource
sharing.
You
can
you
need
to
take
care
of
authentication,
you
need
to
make
sure
it's
secure,
so
there
is
some
work
around
that
the
traces
you
get,
especially
if
you
connect
them
to
the
backend
info.
A
They
will
give
you
a
view
on
your
system
in
general.
It
probably
doesn't
give
you
a
view
on
your
front-end
only
so,
basically,
you
look
at
the
whole
stack
from
click
in
the
front-end
and
maybe
some
actions
to
do
all
the
requests
in
the
database
and
as
I
mentioned
some
front
ends
like
native,
will
not
support
the
lab
and
you
will
have
to
customize
them.
A
You
will
have
to
do
something
else,
but
you
get
more
tools
more
context
to
help
solve
your
issues
faster
and
I
can
see
two
ways
to
approach
this
specifically
with
open,
telemetry
running
it
in
the
browser
running
in
the
browser,
so
you
can
create
spans.
Then
the
way
I
showed
you
you
can
post
directly
to
the
collector
or
you
can
just
collect
it.
A
You
can
create
your
custom
expert
or
you
just
can
collect
it
in
the
front-end
and
you
can
post
it
through
with
your
calls
to
your
back-end,
so
you
don't
need
to
add
anything,
any
additional
connections,
and
then
you
can
put
together
your
back-end
and
front-end
traces
and
make
sure
your
application
runs
smoothly.
So
thank
you.
This
is
a
link
to
the
code
that
I
showed
you
and
there
is
a
little
bit
more
over
there.
Basically,
you
can
you'll
see
some
more
code
over
there,
and
this
is
how
to
contact
me.
Thank
you.
B
We
have
a
little
bit
of
time
for
questions.
If
anyone
has
a
question
I'm
curious,
who
here
is
trying
to
get
observability
data
out
of
the
browser
show
of
hands
who
here
how's
that
going
show
hands
who's
like
totally
satisfied
with
their
current
experience,
getting
it
no
hands,
no
hands
yeah
I'm
curious.
Is
there
something
anyone
wishes
they
had,
but
they
don't
have
right
now.
You.
A
C
C
A
C
A
C
A
C
A
A
D
So
the
the
pattern
of
having
the
tracing
go
through
the
front
end.
We
considered
this
and
basically
went
against
it
because
having
the
front
and
decide
on
multiple
micro-services
to
talk
to
raises
our
surface
area
exposed
to
to
the
public,
and
so
we
we
generally
would
have
the
front
end
talk
to
one
consistent
app
that
acts
as
a
proxy
on
to
all
the
other
subsystems.
So,
given
that
would
you
at
this
direction,
would
you
would
you
prefer
this
or
would
you
prefer
the
other
like,
like
proxy
I,
guess
contrasting
the
two
so.
A
A
A
B
Questions
I
just
wanted
to
make
one
point:
actually
there
was
a
question
about
open
telemetry
and
whether
various
like
vendors
and
backends
were
supporting
that
project,
but
people
who
are
from
dynaTrace
or
New
Relic
or
Splunk
or
lights
up
or
any
of
these
vendors
who
are
working
on
open
telemetry.
And
here
can
you
raise
your
hands
yeah?