Did you know you can build offline capable Progressive Web Apps?
This guide will show you techniques how to build them.
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.
Strategies
There are two main strategies to build offline apps:
- Combine caching of state with store and forward of commands, while leaving command handling and state changes to the server.
- Replicate event streams to the client and perform command handling and state projections locally using client side eventsourcing.
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:
- A static site generator to generate HTML, javascript and CSS prior to deploying the app. There are hundreds of static site generators to choose from, but I have decided to build my own.
- Hosting, for example hosting on a CDN
- To augment a regular website into a Progressive Web App, three prerequisites need to be put into place: HTTPS only, a ServiceWorker and a Web App Manifest
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.
- Which allows handling commands even while offline.
- And keep state up to date through client side projections.
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.
