Goeleven.com

Building offline Progressive Web Apps

B

This guide is intended to point you to all the resources needed to learn how to build offline capable Progressive Web Apps.

You can click through on each referenced article to learn more details about the respective technique.

At the bottom of each referenced article you will find a link back to this guide so that you can keep exploring.

Should you end up on another article not included in this guide, you can always find your way back via the guides section accessible through the top navigation bar.

Strategies

There are two main strategies to build offline apps:

These strategies are not mutually exclusive, and can be combined if needed, but in general they serve different online/offline needs.

Common base

Every Progressive Web App, regardless of the online/offline strategy you select, will require a common set of practices:

Most Progressive Web Apps will in addition leverage the App Shell Pattern to guarantee instant loading on the users screen.

This App Shell can be made available offline by plugging Google Workbox into the ServiceWorker.

Cache aside + store and forward

Use this strategy when:

  • You can't trust the user
  • You can't modify an API

This strategy consists of two parts:

  • A cache aside implementation which serves data both when online or offline, and refreshes the data only when online.
  • A store and forward implementation where the commands are stored before being forwarded to an API, when online.

The main downside of this strategy is that it cannot stay offline for an extended amount of time:

  • Cached data will get stale.
  • Outcome of the commands is unknown, making it hard to proceed any ongoing work while offline.

Client side event sourcing

Use this strategy when:

  • You want to allow a user to work offline for an extended amount of time
  • You can trust the user well enough to allow command handling on the client side
  • You can modify the API to allow event replication

The workhorse for this strategy is client side eventsourcing.

By modifying the API to allow event synchronization, with built in conflict handling, the changes made by the user while offline can be merged with changes made elsewhere in the system in the same timeframe.

Combining the patterns

Under the assumption that the API uses server side event sourcing for command handling and keeping state up to date as well, both of these strategies can be combined to serve all online/offline scenarios.

About the author

YVES GOELEVEN

I love to build web and cloud apps and have been doing so for the past 20 years.

My main areas of expertise are progressive web applications, event driven architecture, domain driven design, event sourcing, messaging, and Microsoft Azure.

Through this blog I hope to share some of this experience with you.

Get in touch

Sign up to my newsletter to get notified about new content

You can unsubscribe at any time by clicking the link in the footer of your emails. I use Mailchimp as my marketing platform. By clicking subscribe, you acknowledge that your information will be transferred to Mailchimp for processing. Learn more about Mailchimp's privacy practices here.