►
Description
Offline capabilities are not normally associated with web applications, but the latest advancements in web technologies enable the development of a web application that can function regardless of the network state. In this talk, I’ll show you how we created a truly offline-first progressive web application by using modern web technologies such as Service Workers and IndexedDB.
You will learn what progressive web applications are, which characteristics make them behave and feel like mobile applications and why we chose to develop one for our client. I’ll also show you some of the techniques we used to ensure optimal performance regardless of the amount of data that was stored, what the network conditions were like, and what device it was running on. We will also cover some of the sync mechanisms that made the application fully functional even in the most remote areas of South Africa. Lastly, we will have a look at the upcoming advancements in web technologies and how this will further enhance the development of next-generation web applications.
This talk was recorded at the Jozi.JS meetup group on 23 May 2019.
https://www.meetup.com/Jozi-JS/events/260470684/
Disclaimer: The opinions in this talk are those of the individual and do not necessarily represent those of this channel, the meetup group, or its sponsors.
A
Hi
everyone
I'm
a
Dean
and
tonight
I
would
like
to
share
my
experiences
and
the
lessons
that
I
learned,
while
building
a
next-generation
web
application
and,
as
Mike
said
I
will
be
available
for
questions.
So,
if
you
have
a
question,
please,
you
know
you're
welcome
to
ask
me
afterwards
cool,
so
I
am
a
software
engineer
at
intellect
and
as
part
of
my
day-to-day
work.
A
Okay
enough
about
me,
I'd
like
to
tell
you
a
bit
more
about
the
project
that
I've
been
working
on
for
almost
a
year
and
a
half
now,
and
my
entire
talk
is
based
on
my
experiences
while
working
on
this
project.
So
our
client
is
a
chemicals
company
and
they
produce
fertilizer
on
a
very
large
scale
and
they
sell
this
fertilizer
to
some
of
the
most
prestigious
farmers
in
the
country
and
I
must
say
before.
Starting
on
this
project,
I
wasn't
actually
aware
of
the
precise
science
involved
with
farming
practices.
A
So
it's
actually
a
very
interesting
and
unusual
domain
for
developer
to
working.
Ok,
but
in
any
case
our
clients
has
sales
representatives
and
these
sales
representatives
traveled
to
their
customers
on
their
forms
and
those
forms
could
be
in
remote
areas
with
low
need
to
a
coverage.
So
our
clients
wanted
an
application
that
the
sales
reps
could
use
to
create
orders
for
fertilizer
while
they
are
at
the
farmers
on
their
forms
and
it
could
be
in
a
completely
offline
environment.
A
So
the
sales
rep
should
be
able
to
use
this
app
on
their
own
devices,
which
could
be
a
laptop
or
a
mobile
phone.
But
the
client
also
wanted
the
same
application
to
be
available
for
the
back-office
personnel.
Who
would
be
using
this
app
on
desktops,
so
it
we
ended
up
building
was
an
application
that
can
function
regardless
of
the
network
state
and
that
can
be
used
on
multiple
platforms
and
devices.
A
So
basically,
what
we
were
striving
for
was
an
innovative
new
way
to
create
applications
for
mobile
devices.
Apps
that
look
and
behave
exactly
like
apps.
On
a
phone
just
put
them
on
an
internet
server,
they're
also
easy
to
update
so
you'd
think
someone
said
this
last
year,
but
in
actual
fact
it
was
Steve
Jobs
that
say
this
at
the
launch
of
the
iPhone
in
2007,
and
this
was
how
he
described
how
to
build
apps
for
the
very
first
iPhone,
and
it
was
surprisingly
web
apps.
So
little
did
he
know.
A
A
A
So
since
you
only
need
a
browser
to
use
the
application,
the
app
would
be
available
over
multiple
platforms,
so
the
sales
reps
could
use
the
application
on
their
phones
and
that
very
same
application
could
be
used
by
the
back
office
personnel
on
their
desktops.
Our
team
was
also
very
familiar
with
web
technology
already
and
that's
why?
So?
We
could
harness
that
existing
knowledge
to
build
the
application.
A
The
offline
capabilities
that
pwace
offer
were
also
perfect
for
us,
because
we
could
then
build
an
app
that
the
rapes
could
use
on
forms
with
not
low
network
coverage,
since
we'd
only
be
building
a
single
web.
App
we'd
have
a
single
codebase,
which
makes
it
just
so
much
easier
to
maintain
I'm
sure
there
are
a
few
of
you
who
have
experienced
multiple
code
bases
and
you'd
know
that
they
are
usually
plagued
with
inconsistencies,
because
multiple
teams
work
on
them.
So
a
single
codebase
also
just
gives
you
so
much
more
consistency.
A
This
application
is
going
to
be
used
for
many
years
to
come.
So
that's
why
we
also
need
educator
for
the
possibility
of
future
platforms.
So,
for
example,
if
the
Chrome
operating
system
becomes
mainstream
one
day,
then
we'll
really
have
support
for
it
and
then,
lastly,
and
browsers,
are
constantly
updating
their
code
or
of
optimizing
their
code
for
older
devices,
which
means
that
our
app
could
our
apps
features
would
be
reliable
and
performant,
even
on
all
the
devices
as
well,
so
the
biggest
challenge
for
us.
While
building
this
app
was
the
offline
capabilities.
A
A
So
in
order
to
develop
an
app
that
can
function
in
offline
environments,
you
need
to
store
some
data
on
the
user's
device.
So
there
are
two
kinds
of
data
that
you
need
to
consider:
static
content
and
dynamic
content,
so
static
content
is
NATO,
agree
sources
that
your
app
requires
in
order
to
learn
load
while
the
device
is
offline.
So
an
example
here
is
your
apps
shell,
so
that
includes
the
HTML,
the
JavaScript,
the
CSS
images,
whatever
resources
your
app
needs
to
load.
A
On
the
other
hand,
we
have
dynamic
content,
so
dynamic
content
causes
changes
to
your
websites,
and
it
also
differs
depending
on
the
user's
preferences
and
interests.
For
example,
this
could
be
a
list
of
news
articles,
so
let's
first
have
a
look
at
how
you
store
the
static
content
of
your
web
app.
You
can
do
this
by
using
a
serviceworker,
so
a
serviceworker
is
a
script
that
your
browser
runs
in
the
background
separate
from
your
main
web
page,
and
it
has
the
ability
to
intercept
network
requests
and
respond
to
them
in
different
ways.
A
A
Then,
since
you
can
intercept
Network
requests
with
the
service
worker,
it
also
gives
you
very
fine-grained
control
over
the
caching
of
your
website.
You
can
even
precache
resources
even
before
the
user
has
access
them,
and
then
you
also
have
access
to
the
background
sync
API,
which
will
allow
you
to
send
messages
to
the
server,
even
if
the
app
isn't
open
in
the
in
the
browser.
A
A
So
the
process
starts
off
with
your
app
requesting
a
resource
from
the
network.
The
service
worker
intercepts
this
request
and
it
then
forwards
that
request
to
the
net
due
to
the
server.
So
let's
say
this:
the
response
is
taking
a
bit
too
long
to
say
longer
than
400
milliseconds.
The
service
worker
then
goes
and
has
a
look
in
the
cache
to
see
if
it
maybe
has
a
local
copy
of
that
same
resource
if
it
finds
a
cached
version.
It
then
responds
to
the
original
request
with
that
cached
version.
A
A
So
if
you
use
this
strategy,
a
user
in
an
environment
with
good
connection
will
have
the
best
user
experience
because
they'll
always
have
access
to
the
latest
version
of
the
content.
However,
if
your
sales
rep
on
a
form-
and
you
need
to
get
you
need
to
create
this
order,
it's
okay!
If
you
are
using
an
old,
older
version
of
the
app
eventually,
your
app
will
update,
but
at
least
you
could
get
some
work
done.
A
Cool
so
use
the
serviceworker
to
store
your
static
content,
but
for
dynamic
content.
It's
better
to
use
index
DB
so
index
DB
is
a
low-level
API
for
client-side
storage
and
you
can
actually
store
large
amounts
of
data
in
index
DB,
including
files
and
blobs
so
index
DB
is
asynchronous,
meaning
you
can
execute
queries
on
index
DB
without
affecting
the
performance
of
your
app.
A
A
Okay,
so
in
X,
DV
had
a
lot
of
characteristics
that
made
it
ideal
for
our
project.
So
since
we'd
be
storing
the
dynamic
data
on
the
device,
the
app
would
always
have
access
to
that
and
we
could
eliminate
our
dependency
on
the
network
and
therefore
the
app
could
function
even
in
offline
environments
due
to
the
user's
domain
and
the
amount
of
data
we'd
be
storing
the
indexes
in
index.
A
A
So
what
you
could
do
is
you
could
make
use
of
the
persistence
API.
So
with
the
persistence
API,
you
can
request
permission
from
the
browser
to
persist
the
user's
data.
The
browser
will
then
grow
on
this
permission
under
certain
conditions,
and
then
it
won't
actually
automatically
delete
the
data.
The
user
will
be
prompted
and
be
asked
which
data
should
be
cleared.
So
this
gives
the
user
a
much
more
reliable
experience
and
it
places
the
control
in
the
hands
of
the
right.
A
So
now
that
we
have
got
the
storage
limits
covered,
how
did
we
actually
keep
all
this
data
in
sync
and
up
to
date?
Well,
the
answer
is
WebSockets.
So
by
using
WebSockets
we
were
able
to
create
an
offline
sync
that
was
quick
and
it
used
the
minimum
amount
of
data.
So
since
the
WebSocket
was
always
connected,
we
could
quickly
seemd
and
receive
updates
that
were
available
both
on
the
server
and
on
the
user's
devices.
A
We
also
used
a
push
based
mechanism
on
the
server,
so
the
server
pushed
all
the
latest
changes
to
the
device,
and
this
also
meant
that
the
client
didn't
have
to
constantly
poll
for
changes,
and
we
were
only
sending
data
that
actually
changed.
So
this
lowers
the
amount
of
data
that's
being
used.
We
also
have
real-time
interaction
between
a
user's
devices,
for
example,
if
the
sales
rep
created
an
order
on
his
phone
within
moments,
he'd
be
able
to
see
that
same
order
on
his
laptop.
A
A
So
to
achieve
a
background
sync,
you
can
use
one
of
two
ways,
so
you
can
use
the
serviceworker,
so
the
serviceworker
has
access
to
the
background
sync
api.
So,
for
example,
say
the
sales
rep
was
on
the
forum
and
he
created
an
order,
but
there
was
no
network
coverage.
He
then
closes
the
app
gets
into
his
Bucky
and
drives
home
and
on
his
way
home
somewhere.
He
regains
connectivity.
A
A
Sync
API
is
only
available
in
Chrome
at
the
moment,
so
another
way
that
you
could
achieve
a
similar
effect
is
by
using
push
notifications,
so
the
server
could
periodically
send
push
notifications
to
the
device,
and
then
that
would
also
wake
up
the
service
worker
and
the
service
worker
could
then
send
the
updates
to
the
server.
So
by
using
one
of
these
two
mechanisms,
you
can
always
be
assured
that
you
have
the
latest
updates
and
changes
on
the
server
okay.
So
now
we
have
all
of
the
data
stored
locally
on
the
user's
device.
A
So
luckily
for
us,
web
workers
came
to
our
rescue,
so
we've
workers
our
scripts,
that
your
browser
runs.
In
the
background
separate
from
your
main
page
and
since
it's
running
on
a
background
thread,
it
allows
you
to
do
some
work
in
the
background
without
affecting
the
performance
of
your
app.
So
what
we
ended
up
doing
was
executing
all
of
our
queries
on
indexdb
inside
a
web
worker,
and
this
drastically
improved
the
performance
of
our
application.
A
You
can
even
share
web
workers
across
multiple
tabs
and
was
also
really
cool.
Is
web
workers
are
supported
in
all
of
the
major
browsers,
so
yeah,
that's
really
nice.
So
web
workers
communicates
with
the
main
app
via
messages,
so
these
messages
need
to
be
serialized
and
deserialized,
and
that's
why
it's
important
to
keep
those
messages
as
small
as
possible
to
improve
performance.
A
So
what
we
ended
up
doing
was
posting
each
entry
that
we
received
from
the
database
separately
on
a
message.
However,
we
were
using
angular
for
our
front-end
and
angular.
Has
this
feature
called
zones,
so
the
angular
zone
is
basically
a
boundary
between
changes
happening
inside
of
the
angular
app
and
changes
happening
in
the
outside
world,
for
example,
user
clicks,
Network
requests
and,
in
our
case
messages
from
a
web
worker.
A
So
this
boundary
is
constantly
monitored
and
whenever
an
external
event
crosses
this
boundary,
angular
evaluates
all
its
bounded
variables
to
determine
what
should
update
on
the
front-end.
So
if
you're
a
web
developer.
This
is
very
nice
because
you
can
fire
off
a
network
request
and
when
there's
once
comes
back
the
front
Indus
magically
updates,
but
in
our
case
it
was
causing
a
bit
of
chaos
because
imagine
retrieving
two
thousand
products
from
indexdb
the
site.
The
change
detection
cycle
would
run
two
thousand
times
and
our
F
became
extremely
slow.
A
So
to
counteract
this,
we
processed
all
of
our
database
queries
outside
of
the
angular
zone
and
then
once
we
had
all
the
results,
we
manually
triggered
the
angular
zone
to
run
so
yeah
that
that
made
a
big
performance
improvement
right.
So
now
we've
got
the
zone
issue
sorted,
but
now
we
needed
to
display
two
thousand
products
in
a
list
on
the
front
end
and
rendering
2000
elements
in
the
Dom.
It's
not
really
advisable.
A
So
that's
why
we
use
virtual
scrolling,
so
virtual
scrolling
is
an
efficient
way
for
you
to
display
an
infinitely
growing
list
of
items,
so
how
it
works
is
only
a
small
amount
of
elements
that
actually
fit
into
the
dot
into
the
viewport
or
rendered,
and
then,
as
the
user
Scrolls.
These
elements
are
just
reused,
so
it
makes
it
efficient.
Is
your
only
rendering
a
small
amount
of
elements
at
the
time,
regardless
of
the
amounts
of
items
in
in
the
list
cool?
A
However,
we
were
reading
large
amounts
of
data,
then,
firstly,
we
discovered
the
blocking
issue
on
Chrome,
so
we
moved
all
of
our
queries
to
a
web
worker.
Then
we
had
the
issue
of
the
angular
zone,
so
we
decided
to
execute
all
of
the
queries
outside
of
the
angular
zone,
so
we
went
only
storing
dynamic
data.
A
We
also
needed
to
keep
all
of
this
dynamic
data
up-to-date
and
in
sync,
and
for
that
we
used
a
web
worker
dedicated
to
the
syncing,
so
the
web
worker
established
a
WebSocket
connection
with
the
server
over
which
it
seemed
and
receive
all
updates
that
were
available.
So
whenever
an
update
was
made
in
the
app,
for
example,
an
order
was
created.
The
angular
app
would
notify
that
sync
web
worker
and
the
sync
web
worker
would
then
retrieve
that
update
from
the
database
and
send
it
to
the
server
via
the
WebSocket
connection.
A
So
when
you
develop
a
web
app,
you
always
need
to
keep
browser
support
in
mind,
and
especially,
you
have
pwace,
because
PWA
should
work
for
every
user,
regardless
of
what
browser
they
use
cool.
So,
let's
have
a
look
at
service
workers.
Service
workers
are
actually
supported
in
Chrome,
Firefox
age
and
most
recently,
Safari
has
also
added
support
for
service
workers.
A
Background
sync,
unfortunately,
is
only
supported
in
Chrome.
At
the
moment,
however,
push
notifications
are
supported
in
Chrome,
Firefox
and
edge.
Safari
for
Mac
has
their
own
implementation
of
push
notifications,
so
you'll
have
to
do
a
custom
implementation
there
and
unfortunately,
Safari
for
mobile
is
the
job
they
don't
support.
Push
notifications
at
all.
Unfortunately,
the
second
version
of
indexdb
is
supported
everywhere,
except
in
age,
but
age
does
support
the
first
version,
though,
and
web
workers
very
nice
supported
in
all
of
the
major
browsers
right.
A
So
that's
what
the
current
state
of
web
technology
looks
like,
but
let's
have
a
look
at
what
the
future
might
hold,
so
people
are
used
to
looking
for
apps
in
app
stores,
and
that
is
why
some
of
the
big
companies
are
actually
starting
to
support
progressive
web
apps
in
their
app
stores.
So,
for
example,
Google
with
chrome
72
for
Android
I
think
it
was
at
the
beginning
of
the
year.
A
Then
you
can
also
package
and
wrap
your
Pete,
your
PWA
as
a
native
app
using
tools
like
PW
a
builder,
and
then
you
can
publish
that
to
the
App
Store
so
with
all
of
those
companies.
Paging
support
for
pwace
they'll
also
keep
on
improving
their
browsers,
and
there
are
all
kinds
of
new
and
exciting
api's
available
or
well
yo
coming
out
in
the
near
future.
So
one
of
them
is
a
web
authentication
API.
So
this
will
allow
for
password
less
authentication
and
it
could
possibly
standardize
authentication
on
the
web
and
make
it
much
easier.
A
Webassembly
is
a
new
kind
of
code
that
allows
you
to
run
languages
like
C++
on
in
a
browser
and
what
we
could
possibly
be
seeing
in
the
future
is
frameworks
like
angular
using
web
assembly
to
improve
the
performance
of
their
frameworks,
and
there
are
even
machine
learning
libraries
that
are
built
well,
that
can
run
on
web
assembly.
So
imagine
you
can
run
machine
learning
algorithms
in
a
browser,
then
the
streams
API
gives
you
access
to
content
as
it
is
streamed
from
the
server.
A
So
you
no
longer
have
to
wait
for
the
termination
signal
and
before
you
can
access
the
content,
so
you
can
access
the
content
as
it
comes
through
and
react
to
it.
Web
share
payment
request:
Web
USB,
shape
detection.
Those
are
all
new
and
exciting
at
the
eyes
to
look
out
for
in
the
future,
so
as
progressive
web
apps
gained
popularity
they'll
also
start
getting
more
access
to
native
api's,
which
in
the
past
were
only
reserved
for
native
mobile
apps,
so,
for
example,
the
device
orientation
a
the
I.
A
This
will
give
you
access
to
the
physical
orientation
of
the
device.
So
I
don't
know.
If
some
of
you
may
have
used
that
stargazing
app,
which
you
point
to
the
sky
and
then
you
can
see
the
star
constellations
so
imagine
having
that
app,
but
on
the
web,
you
can
also
have
will
use
the
vibration
API
to
give
your
users
non
audible
feedback,
the
media
capture,
API
grants
you
access
to
the
device's
camera
for
image
capturing
so,
for
example,
capturing
your
credit
card
details
and
then
also
a
really
cool
one
is
the
ambient
light
API.
A
So
with
with
all
of
these
new
features
and
and
and
advancements
in
web
technology,
I'd
like
to
leave
you
with
the
following
inspiration
to
always
look
for
new
and
better
ways
of
doing
things.
The
key
is
to
embrace
disruption
and
change
early.
Don't
reactivate
decades
later
you
can't
fight
innovation.