Here is Why we did not use service worker for runtime data caching

We all building a web app which is more Frontend heavy, We want show the content to user as quickly as possible even if data has to be fetched from server / after the heavy computation. In both case we don’t want to show spinner to user when ever we fetch / compute data for user; here we talk more specifically about when the data has to come from server.

Let’s take the problem of fetching data from server : -

when ever we navigate to the different page of our app, typically browser will wait for server to serve both assert files (image, js, css, fonts) and api json data. To convey the progress of fetching data(both assert and json data) from server to user, we will display the spinner which more annoying now days if we show the spinner more often.

In order to provide the better experience to user, we could use the service worker to cache assert files, so that next time user visit the our page, they will see the page quickly instead of spinner. Caching assert files is good but we cannot cache the json data using service worker because there are chances that user may see the older data when he/she re-visit the page.

But, yeah, there are various caching strategy when using service worker. if you not familiar about this, refer here. we could use the Stale while revalidate strategy when we have to cache the api response.

Stale while revalidate strategy

1. Page makes a request, which is intercepted by service worker.
2. Service worker checks cache for response.
3. If the response is cached before, return response from cache..
4. Service worker sends request to network to get latest data.
5. Get new response from network and update in cache.

But there is one problem with this approach, user will only see the newest data on subsequent visit of page.

But what if we don’t want to show the older data to user but still we want to cache api data for displaying data faster. In order to do that we need to slightly alter the Stale while revalidate strategy as follows,

Modified Stale while revalidate strategy

1. Page makes a request, which is intercepted by service worker.
2. Service worker checks cache for response.
3. If the response is cached before, return response from cache..
4. Service worker sends request to network to get latest data.
5. Get new response from network and update in cache.
6. Send back the newest data from network to page.

But there is caveat, Notifying the page about availability of new data from service worker has to happen via Message Channel which is not supported by all the browser (safari specifically).

To solve this problem, we have to opt out of service worker for caching api data. Need to implement cache layer by our self. Todo that, all the data request from the page should go via common layer called dataProvider as follows.

DataProvider will have the logic described by modified version of stale while revalidate strategy. If you observed data flow in diagram, we are re-notifying the page about arrival of new content from network, which is not possible when we use Promise for getting data from server because Promise cannot be resolved twice. So we need to have some way that mimic functionality of what Promise does with ability to cancel the request as well as re-notifying about new data.

Here is the implementation of DataProvider

Here is the working example

Note: We have to clear the cache whenever user logs-out / reload page. Feel free to comment the approach you have taken to solve this problem.