Cache Recipes
CacheStorage API allows you to save data securely in form of request-response pairs. It is the key player behind “offline” support of progressive web apps. Over time, usage of CacheStorage API has evolved few common patterns that are simple, straightforward and should be able to handle 90% use cases. Most of these are coupled with the Service Worker API but of course not limited to it as CacheStorage is accessible through the global window object as well.
In this article, we are going to take a look at patterns using CacheStorage. Although this is about CacheStorage usage but we will be using few features of Service Workers API and finally the Promise API to couple these two. Very basic knowledge of Service Worker Life Cycle Events and Promises is expected. If you are unfamiliar with CacheStorage API, you can take a quick look on the previous article or in the resources below. Let’s start diving into use cases and recipes for cache
Use case:
Prefetch all static app content on update to serve instantly in future, even when offline.
Recipe:
We’ll use the Service Worker install event to intercept first visit/update to our app and add all resources, paths required by our app. You need have the list of resources and paths already placed..you can either manually fill the array that should also work but it is recommended to bake this into the build process itself.
Use case:
Clear cache by deleting old non required cache.
Recipe:
Service Worker activate event is a good fit for this kind of task, since we are sure that the old Service Worker has been removed and this one is controlling clients. We can do this in couple of ways. One of the things can be to append version name at end of each storage name and delete all those that do not match currency version.
Use case:
Serve contents from cache only to save data usage. This case can be very helpful with static resources such as app’s CSS or javascript files that we prefetched at install time.
Recipe:
In the Service Worker fetch handler, we can look if the request is made for one of prefetched contents, then we’ll respond with local data directly instead of going to the network..serving content fast and lightweight in terms of data usage.
Use case:
We have some data that is we want to be updated always if we have a working connection. But if the device has no connection, we want to fallback to the stored content. For example, comments on a Facebook post.
Recipe:
We’ll catch the requested data and initialize a network call to the request. If the network request succeeds, we then update the cache in parallel and respond with fresh data. But in case the network is not available, we can directly deliver the content from cache itself and show the user some kind of UI to express that the data is not fresh.
Use case:
Think of a music player app. The app caches last 50 songs and also songs marked for offline playing in the cache. Here it makes sense to actually look into cache whenever a song request is intercepted and if found, serve the content instantly from the cache without going to network. But if the content is not there…the app should fetch it from the network, pass that to the UI as well as store it in the cache for future usage.
Recipe:
This follows some really simple steps,
- look into cache and serve content
OR
- fetch, serve content + store into cache.
Use case:
Provide generic fallback content. For example, to show forbidden UI page, 404 Not Found page or even custom offline page we can use cache storage by prefetching the required things on the client and then respond according to content requested.
Recipe:
With the ability to intercept network requests, we can also check for a specific server response to provide special custom UI. For example, to show custom offline page instead of the Dinosaur one, or to show forbidden pages.
Use case:
As I’ve mentioned, CacheStorage really plays well in combination with Service Worker but the promise based architecture and global availability really make it free for all kind of usage and tricks.
We can use caches to prefetch some stuff for future use if the user wants so. This can be achieved by initiating a prefetch from CacheStorage by listening to user events.
Recipe:
The process is same. Suppose there is some music playing app that wants to allow user download playlists for offline usage or to reduce network by adding frequent playlists to cache. As you might have guessed already, caches.addAll is what we need here.
Apart from user interactions and worker events, there are other ways as well to leverage cache such as using in combination with web push to refresh app data in background periodically. I hope this through the article, you get a clear understanding of how to plug same features in different ways to extract desired results and also handle general and edge cases of the offline web.
Additions/Reviews to article are more than welcome. Want to chat about something let’s connect in comments or on twitter just 🔊🔊 @ritikrishu
