►
Description
Your user closes the browser tab and your excellent frontend app immediately disappears. But what if you want to build even better UX by keeping a portion of your app always alive - to send & receive events, to finish network operations, and to run some code even when a user does not have your website open? During my session, let's explore all the possibilities we have in the Service Worker-driven APIs to create true Phantoms of our apps. All for good: to keep the app itself and content always fresh, network operations - resilient, and user - notified
A
My
name
is
maxim
salnikov.
I
work
as
a
developer.
Engagement
lead
at
microsoft,
norway
and
I'm
big
big
fan
of
the
modern
web
front-end
development
to
share
my
knowledge
to
share
my
passion
and
expertise
with
this
area.
I
organize
multiple
meetups
and
conferences,
and
I'm
often
speaking
and
presenting
at
events
like
conferences,
meetups
workshops,
hackathons
all
for
the
technical
community.
A
You
can
find
me
on
twitter,
webmax
ru.
I
tweet
mainly
about
web
platform,
about
progressive
above
service
workers
and
everything
around
I'll
be
happy
to
stay
connected
with
you
back
to
our
topic.
What
is
the
current
state
of
web
platform
in
terms
of?
What
can
we
do
for
our
front-end
part
of
web
project?
A
A
So
we
somehow
can
inform
our
dear
users
about
some
scheduled
event,
regardless
of
their
connection
status,
or
we
can
automatically
replay
requests
which
were
failed
for
for
whatever
reason,
for
example,
when
our
dear
users
suddenly
went
offline
or
we
can
provide
long
fetches,
which
are
connection
resilient,
I
mean,
of
course
we
cannot
have
any
magic
secret
internet
channel,
but
at
least
our
fetch
will
not
be
canceled.
If
something
went
wrong
with
the
connection,
it
can
be
paused,
it
can
be
continued
after
so
very
good
user
experience.
A
This
functionality
cannot
work
after
user
closed
the
tab
with
our
application
right,
so
the
code
we
have
in
our
main
javascript
bundle
will
disappear
right
after
our
application.
Tab
was
closed,
but
not
with
the
background
services.
We
can
have
all
these
features
available
in
the
background.
This
is
why
it
has
a
name
like
this
right
and
I
will
explain
how
this
works,
but
first,
what
is
a
background
service?
A
This
is
a
part
of
the
browser
of
browsers
engine
which
allows
us
to
write
and
run
a
code
which
will
work
in
a
background
and,
of
course,
this.
This
code
is
quite
specific
in
in
multiple
terms
compared
to
our
main
javascript
code.
First,
it
runs
in
a
parallel
thread,
parallel
to
our
main
thread.
It's
always
good,
because
this
way
we
have
less
competition
for
processor
resources
for
memory,
so
it
allows
us
to
build
smoother
and
faster
ui's.
A
It
has
completely
different
life
cycle.
As
I
already
mentioned,
life
cycle
of
the
main
application
thread
is
quite
trivial.
We
start
on
our
javascript
code
right
after
the
user
opens
the
tab
and
types
our
our
url
and
some
first
bytes
of
our
javascript
bundle
were
fetched
and
we
close
everything
we
unload
from
memory.
Everything
right
after
user
closes
the
tab
or
maybe
the
browser
itself.
A
It
started
by
completely
different
occasion,
which
is
event
so
basically,
everything
we
have
in
our
background
services
is
a
reaction
to
this
or
that
event
so
event
came
our
code
ran
and
then
this
this
code
disappears
so
background.
Services
is
not
something
that
we
want
to
run
for
for
too
long.
So
it's
a
fast
and
short
reaction
to
particular
event.
There
are
multiple
reasons
for
this
and
I
believe
the
main
one
is
we
don't
want
to
over
use
the
resources
of
the
browser
for
running
code,
which
is
part
of
background
services.
A
A
Let's
call
this
wake
up,
regardless
of
the
state
of
the
main
application
itself,
so
the
code
can
wake
up
and
run
even
when
the
browser
itself
or
to
be
more
precise,
its
visible
part,
is,
is
closed
and
looking
at
these
parameters,
I
have
analogy
with
phantom
or
ghost,
because
our
application
is
dead
there.
It
doesn't
exist
in
in
memory
and
the
tab.
This
application
is
closed,
but
pieces
of
this
application,
which
we
have
as
a
part
of
background
services,
is
waking
up
here
and
there
they
live.
A
A
First
everything
connected
to
the
network
state
yeah,
for
example,
the
situation
when
we
go
from
offline
state
to
online
state
there
is
a
corresponding
event
which
we
can
receive
in
our
service
worker
and
write
corresponding
code.
Of
course.
In
that
case,
we
are
mainly
talking
about
the
code
which
will
try
to
replay
failed
request,
which
we
tried
to
do
while
we're
offline.
A
A
I
already
mentioned
that
all
the
code
we
have
as
a
part
of
background
services
intended
to
be
located
at
service
worker
inside
service
worker.
Basically,
this
is
the
only
place
of
our
application
where
we
can
get
life
cycle
we
need,
which
is
completely
separate
from
the
main
thread,
and
this
is
the
only
place
where
the
code
is
like
always
on
on
duty,
regardless
of
anything,
and
then
multiple
sources
can
send
events
to
our
service
worker
first
application
itself,
then
browser
then
operating
system
proxy
via
browser.
A
A
First,
we
can
organize
bi-directional
communication
channel
between
service
worker
and
application,
for
example,
to
update
number
of
unread
messages
on
our
ui.
If
we
build
something
like
mail,
client
or
news
client,
but
what
if
the
tablets
application
is
not
open
what
if
it's
only
service
worker
who
is
always
on
on
duty?
Well,
we
can
start
the
the
browser
and
open
this
application
from
our
service
worker
and
maybe
then
to
organize
this
bidirectional
channel
or
maybe
for
some
scenarios.
We
don't
need
to
do
this.
A
Let's
say
obtrusive
action
like
starting
the
browser.
Maybe
we
just
want
to
show
the
notification
it's
possible
and
yeah.
In
that
scenario,
we
only
need
service
worker
and
maybe
the
most
interesting
scenario
when
we
can
run
some
custom
code
without
any
kind
of
user
notification.
I
mean
we
do
not
start
the
application
itself.
We
do
not
show
any
notification
sounds
a
bit
scary,
but
I'll
explain
you
why
it's
still
it's
still
cool
back
to
background
services,
how
to
find
the
list
of
what's
available
in
the
particular
browser.
A
A
How
to
find
this
list
go
to
devtools
application,
tab
and
somewhere
on
the
left
hand,
side
in
the
bottom
you'll
find
this
list,
of
course,
as
any
part
of
devtools.
It's
very
convenient
and
very
important
for
us
developers,
because
this
particular
piece
of
dev
tools
helps
us
to
debug
these
background
services,
which
might
be
non-trivial
tasks
at
all
without
this
special
feature
of
devtools.
A
As
I
mentioned,
it's
all
based
on
the
events
and
sometimes
it's
very
challenging
to
predict
when
this
event
will
come
and
in
which
form
and
what
kind
of
reaction
will
be
provided
from
my
service
worker
side.
So
devtools
gives
us
a
chance
to
record
all
these
events,
which
is
super
convenient
for
testing
and
debugging.
A
Okay,
let's
briefly,
go
through
this
list,
I'll
explain
you:
what
kind
of
services
are
those
and
we'll
stay
on
a
couple
of
them
to
have
more
details?
Let's
start
with
api
called
payment
handler,
it's
quite
niche
one
for
the
scenario
when
you
wish
to
build
web-based
payment
service,
or
even
more
precise
web
heavily
web
front
and
web
front-end-based
payment
service.
A
It's
uniqueness
in
the
fact
that
I
believe
it's
the
only
api
and
only
possibility
to
install
service
worker
on
the
flight
without
even
visiting
the
origin
of
of
this
particular
service
worker
with
multiple
limitations.
But
still
it's
quite
interesting
feature,
and
mainly
we
use
this
api
for
managing
ui
of
the
payment
services.
A
Of
course,
I
think
it's
a
good
idea
to
provide
some
ui
notification
about
hey
now.
We
cannot
send
your
data
to
the
servers,
but
it
will
be
delivered
later
automatically.
It's
the
main
power
of
this
particular
api
background.
Fetch
gives
us
possibility
to
detach
data
fetching
process
from
the
application
lifespan
from
the
main
thread
of
the
application
lifespan.
A
For
example,
we
want
to
download
some
large
resource,
some
mp4
video
file
and
the
download
started,
and
then
user,
for
example,
decided
to
close
the
application
or
something
bad
happened
with
the
internet
connection.
Again,
then,
we
have
all
the
tools
to,
for
example,
pause
this
download
and
then
to
continue
with
this
when
it
becomes
possible.
So
we'll
have
the
ui
very
similar
to
ui.
We
have,
for,
let's
say
classical
download
using
anchor
tag
at
the
same
time.
A
What
differentiates
this
way
to
download
resources
from
the
one
with
anchor
tag
we
have
full
control
over
the
bytes
downloaded.
So
it's
not
just
the
next
file
on
our
operating
system,
which
was
downloaded.
No.
We
have
these
bytes
available
in
our
javascript
code
and
we
decide
what
to
do
in
many
cases.
We
just
want
to
put
them
into
cache
storage
for
later
usage
from
our
front-end
code.
A
Push
messaging,
it's
the
most
mature
api
from
that
list,
and
here
I
just
want
to
remind
that.
We
have
possibility,
in
addition
to
showing
the
notification
itself
to
also
run
custom
code,
so
we
are
closing
to
running
custom
code
as
a
background
task,
but
in
that
case
we
must
show
the
notification,
so
there
is
no
chance
for
us
to
organize
this
in
invisible
for
the
user
way.
Okay,
what's
left
notifications,
on
the
one
hand,
it's
the
best
friend
of
push
messaging
api.
A
As
I
mentioned,
there
is
no
sense
in
sending
push
notifications
without
showing
the
the
notification
itself,
but
hereafter
we'll
talk
about
different
part
of
this
api.
Called
notification
triggers
and
both
notification
triggers
and
periodic
background.
Sync
are
time-based
activities
we
can
run
as
a
part
of
background
services.
A
I
believe
this
is
the
only
what
makes
them
similar
and
they
have
very
many
differences.
I
gathered
full
table
of
this
to
better
explain
these
apis
first,
what
are
they
designed
for
periodic
background
thing?
It's
to
give
a
chance
to
the
developers
to
organize
refresh
of
the
application
and
data
it
consumes
in
a
background.
A
That
means
that
it
only
makes
sense
to
run
this
this
code
and
to
send
this
event
event
to
the
service
worker,
while
the
user
is
online
notification
triggers
is
designed
to
give
us
developers
a
chance
to
schedule
some
notifications
for
the
future
time,
regardless
of
the
connection.
Okay,
let's
go
through
some
of
the
parameters.
A
A
What
can
we
do
here
and
there
in
pbs?
We
write
the
custom
code
itself,
so
there
is
no
any
magic
way
for
having
our
application
fresh
and
data.
It
consumes
fresh
without
the
code
we
write
ourselves,
so
we
just
have
this
trigger
when
to
run
this
code,
notification
triggers
is
limited
to
only
show
the
notification
visibility
for
the
user.
A
A
We
can
have
custom
code
there
within
this
event
handler
hello,
bitcoin
mining,
and
this
will
happen
all
completely
invisible
for
the
user
sounds
scary
right.
It's
exactly
the
the
custom
code
I
mentioned
in
my
slide,
where
I
described
sources
of
the
events.
This
is
why
there
are
multiple
limitations
and
multiple
considerations
about
this
api
about
the
case
when
this
event
can
ever
come
to
the
service
worker.
A
First
connection,
I
already
mentioned
that
it
all
makes
sense
for
pbs
to
run
in
online
only
it
was
designed
to
run
like
this,
while
maybe
the
main
power
of
notification
trigger
is
for
offline
mode,
when
we
don't
have
any
chance
to
reach
out
to
particular
user
device,
for
example,
to
to
wake
them
up.
If
we
build
some
web
front,
end
based
alarm
clock,
so
notification
triggers
will
work
on
both
online
and
offline
prerequisites
needed
to
ever
run
this
code.
A
Luckily,
these
days,
it's
quite
simple
to
organize
installation
of
your
web
front
application
using
web
app
manifest
using
the
fact
that
browsers
are
well
integrated
with
operating
systems
now,
but
still
it's
a
quite
a
serious
requirement.
Also,
what
I'm
not
listed
here,
but
also
very
important,
this
event
as
a
part
of
periodic
background,
sync
will
come
to
the
service
worker
only
on
the
same
network
where
it
was
registered.
Let's
say
it:
it's
the
same:
wi-fi
network,
for
example.
Again
it's
designed
like
this
to
not
break
the
user
privacy.
A
A
We
do
it
in
our
main
javascript
bundle
and
I
always
recommend
to
do
feature
detection,
because
this
api
might
be
available
or
might
be
not
available
under
particular
circumstances,
and
we
don't
want
to
pollute
our
console
with
red
lines
and
we
definitely
don't
want
to
ruin
core
user
experience,
and
then
we
provide
only
one
parameter
called
mean
interval,
so
we
don't
have
full
control
over
this
intervals
where
we
want
to
receive
this
event
in
our
service
worker.
We
only
can
say
something
like
hey.
A
Please
do
not
send
this
event
more
often
than
more
often
than
24
hours,
for
example,
and
what's
next
next
we
go
to
the
service
worker
and
with
inside
service
worker,
we
receive
periodic
sync
event
if
we
are
lucky,
if
we,
if
all
these
conditions
are,
are
true
and
what's
next
next,
we
write
our
own
code
and
there
is
no
magic
which
will
help
us
to
update
the
application.
We
have
to
write
everything
manually
in
majority
of
scenarios.
You
fetch,
for
example,
updated
version
of
the
application
shell.
A
Maybe
you
trigger
some
api
endpoints
to
keep
the
data.
It
consumes
only
also
fresh,
and
I
think
that
if
we
receive
this
event,
we
are
already
lucky,
but
we
can
do
step
further
towards
best
user
experience
and
do
extra
checks
before
running
our
update
code.
For
example,
we
can
check
network
connection
type
and
only
run
this
update
when
we
are
on
a
fast,
stable
network,
maybe
the
user
in
data
saver
mode,
and
then
I
I
suggest
we
can
skip
update
at
all.
A
And
after
all,
if
we
are
talking
about
fetching
some
data,
maybe
it's
a
good
idea
to
check
if
there
is
a
space
available
on
the
user's
device.
If
we
talk
about
timing,
how
often
can
we
receive
these
events?
If
we
only
say
if
we
only
provide
a
minimum
interval
in
the
best
case
scenario,
it's
12
hours
and
by
the
way,
it's
something
that
not
part
of
the
specification
every
browser
decides
themselves.
A
What
is
this,
let's
say:
timing
schema
what
it
depends
on
engagement
score.
This
is
artificial
index
calculated
by
by
the
browser,
and
it's
about
how
long
and
how
often
the
user
interacts
with
your
application.
So
browser
tries
to
do
the
best
guess
how
popular
your
application
is
for
particular
user
to
decide
on
how
much
resources
it
might
dedicate
to
this
particular
application.
A
If
we
look
at
the
notification
triggers,
it
starts
also
in
the
main
thread
and
same,
I
strongly
recommend
you
to
start
with
feature
detection
and
by
the
way
here,
I
illustrated
how
this
notification
might
look
like
on
windows
10
operating
system.
Here
we
specify
exact
time
point
when
we
want
to
show
this
notification
and
then,
as
a
trigger
we
provide
timestamp
trigger
and
maybe
in
the
future,
we'll
have
more
triggers
not
only
based
on
timing
but
maybe
based
on
geolocation,
maybe
based
on
some
other
parameters.
A
So
I
hope
I
inspired
you
to
have
a
closer
look
on
background
services
and
maybe
on
these
two
specific
apis.
What's
about
availability
and
behavior
of
these
apis
on
particular
browsers
and
on
particular
operating
systems,
I
have
a
long
answer
for
you.
It
really
depends
platform
and
operating
system
browser
and
its
version,
browser
settings
and
even
flags
and
after
all
origin
itself
and
the
fact
is
application
installed
or
not.
A
You
can
get
all
this
details
about
every
single
browser
and
every
single
situation
on
the
links
I
mentioned
on
this
slide,
but
I
have
a
shorter
answer
for
you.
Let's
just
think
about
these
features
like
part
of
progressive
web
application
and
p
in
this
acronym
means
progressive
in
terms
of
progressive
enhancement.
So,
let's
just
think
about
these
features
like
about
something
that
might
improve
user
experience
and
it
might
happen
or
not
and
of
course,
technically
feature.
Detection
is
the
mechanism
where
we
check
all
these
availabilities.
A
Let's
sum
up
the
goal
of
these
apis
and
many
other
apis,
which
are
part
of
service
worker
family
is
to
catch
up
with
what
native
code
can
do
and
in
some
scenarios
web
can
do
even
better
than
native
code.
These
days,
let's
really
keep
user
experience
in
the
focus
and
by
using
these
apis,
we
give
something
right
in
term
in
terms
of
better
features,
more
convenient
usage
of
the
application,
but
we
require
something
in
return:
multiple
things.
First,
all
these
annoying
permissions.
A
Second,
all
security
and
privacy
considerations.
Third
consumption
of
resources
needed
for
running
this
background
services.
So,
let's,
let's,
together
with
authors
of
these
specifications,
find
proper
balance
between
what
we
give
and
what
we
require
in
return
when
it
comes
to
developer
experience,
I'm
super
happy
with
the
current
situation.
We
have
web
standards,
we
have
great
tooling,
and
what
I'm
super
happy
about?
It's
just
a
beginning
of
this
great
great
journey.