Service worker is another great invention in the web development domain. It has the ability to intercept the request and respond to them, whether through the network or cache, helps to provide a consistent experience even when there is no connection. It is also the backbone of the Progressive Web Application promoted by Google (I do have some opinions for PWA at the end).

One of the best feature it provides for your web application is it can make your web app “offline”. Basically it can cache two kind of things: one are static files, or “required files” that your app will fail to load if without them; the other one is the dynamic content, such as an api call your users made when your app is running.

In CS3216’s assignment 3, we are required to make use of service worker and make our application “offline”. The way introduced in the assignment guide line is following the service worker lifecycle:

  1. Add files to the cache when ‘install’ event is triggered.
  2. Update the cache, such as invalidate the outdated files, at the ‘activate’ event.
  3. Serve the cached files by respond the ‘fetch’ event, in which the ‘fetch’ represents a web request.

Though this is the standard way to implement the service worker cache, developers may manually spent quite a number of time updating and debugging cached contents. One of my friends complains to me that they have to manually update all cached files in the service worker file after their web app got rebuilt and updated.

There are only two hard things in Computer Science: cache invalidation and naming things.

Phil Karlton

At the age that automation is part of the development requirement, why manage the cache manually? Google already gives us the solution: sw-precache

By using sw-precache, instead of writing the service worker module and handle events yourself, it automatically generate the service worker module that pre-cache all required static resources from the configuration for you.

If you are familiar with gulp or grunt tasks, you can build a service worker offline ready app within seconds!
Suppose you want to pre-cache all the html, css, javascript, image files when the service worker is installing, if you are doing it manually, in the install event, you will have a long list of files:

1
2
3
4
5
6
7
8
9
cache.addAll([
'/',
'/index.html',
'/style/style.css',
'/view/view1.html',
'/view/view2.html',
'/script/app.js',
...
]);

Then, you also need to care about handling the cache update/invalidation in activate event, which is still a pain in the ass.

But with sw-precache, you just need to register it as a task in your build process, and specific the staticFileGlobs, which are files that should be precache:

1
2
3
4
5
6
7
'staticFileGlobs': [
'*.html',
'style/**.css',
'images/**.*',
'view/**.html',
'script/**.js'
],

Build your project as normal, and the sw.js will be generated for you, with all the service worker events are already handled for you.

What’s more, you can also use sw-precache to help you cache dynamic requests. You just need to set up the runtimeCaching in the task config, and choose a url pattern and a handler for it. Again, the service worker module will be generated for you and everything works in seconds.

1
2
3
4
5
6
7
8
9
10
11
12
13
runtimeCaching: [{
urlPattern: /^https:\/\/example\.com\/api/,
handler: 'networkFirst'
}, {
urlPattern: /\/articles\//,
handler: 'fastest',
options: {
cache: {
maxEntries: 10,
name: 'articles-cache'
}
}
}]

Example usage: cache all the Facebook avatar of your friends and display them using service worker.

The drawback of automation is you may lose some customization on the file generated. If you need to do some extra handling in the service worker lifecycle, you may still need to fallback and do it manually, or you can modify based on the generated file.

In conclusion, if you are using build tool in your development process, and are considering using service worker in your app, do go and give a try for sw-precache as it just works, and really can save you many headaches when dealing with service worker :)

IMAO: PWA has bright future, but we are not in the future yet

I like the idea of progressive web application. It provides a clear guideline for a future mobile web app. Google also gave us with some really interesting demo case for PWA, and install it and use it as a native app on Android is really awesome.
However, the bad news is iOS does not support service worker yet, maybe in the future, but not now. iPhone users won’t gain any benefit from the PWA because there is no way for them to experience it. This indicates that PWA already lost a large group of user on the earth. As for “Add to Home”, seriously, I don’t use it at all, and I can’t see the real usage of it as it just open a new safari window for me to display the application…
Also, from the angle of mobile application companies, do they really benefit from PWA? PWA is an enhancement from traditional mobile web app, even if it could be installed and used offline on mobile phones, it is still a web app and lacks many native features. If we just want a web app with some native taste, why not using React-native or Ionic to build hybrid app that can do more than PWAs? If you do some research on how many big names are using PWA, you will be disappointed.
This doesn’t mean we should just stand still. Service Worker is definitely something that can change the mobile web industry. What if one day iOS has fully support on service worker? Onward to a better web for everyone. If that means Progressive Web Apps, let’s do it.