QR Code contains TinyURL of this article.The New Shiny Thing

drawing: factory workers on an assembly line

For nearly two decades — centuries in Internet years — I’ve been creating websites and writing the server-side applications that drive them. In all these years, the words network resilience never really came up.

It seems strange to me then that only now, twenty-plus years after the first, basic website went online, are we starting to take seriously the idea that a website should be tolerant of network faults. Loss of connectivity and server down-time happen. When they do, websites become unavailable to the clients that are trying to connect to them. That was the way of things, the nature of the beast.

Today, the cool thing is to build websites that behave more considerately when we lose connectivity. The end user should be able to continue using a website, albeit with some potential loss of functionality, regardless of the network or server condition.

We achieve this with the so-called service worker — which exposes an API that sits between the network and the browser’s rendering engine. A common service worker design pattern consists of:

  1. caching successfully retrieved resources;
  2. servicing requests with resources delivered from the network or, failing that, from the cache;
  3. falling-back to an offline page when the absence of connectivity occurs in conjunction with a cache miss.

Now I have a history of wanting to play with all the new, shiny things so — inspired by the pioneering experiments of Jeremy Keith, Nicolás Bevacqua, et al — I have spent the past week or so building out my first service worker — let’s call her Charlotte — here on the Perpetual βeta. I put the service worker live earlier today so, if you are using a client that supports them, Charlotte should already be busy installing herself on your system. Once she’s running, you’ll be able to continue to use this website even when your train goes into the tunnel.

Charlotte caches the Perpetual βeta pages you visit as you traverse the site (excluding the Camera Roll). If you go offline, Charlotte will attempt to service your page requests from her cache. If you haven’t previously visited a given page, it won’t be in the cache. In which case Charlotte will tell you that you are offline (or that the Perpetual βeta server is down) with a highly appropriate image of Edvard Munch’s “The Scream”.1

The Scream, by Edvard Munch
The Scream.

Also on the offline page is a link to the Archives and, what should happen, is that the Archives page should include a “you are offline…” notice and it should only hyperlink those pages that you have available in your cache. Non-cached pages should be de-linked and grayed-out (as illustrated below):

screen capture of the Perpetual βeta's Archives page in offline mode

You may have noticed my liberal use of the word “should” in the above paragraph. I have noticed, while testing in Chrome, that some first visits to the Archive page — following a loss of connectivity — result in a page that doesn’t exhibit the behaviours I describe and that it requires a page refresh to fix the issue.

I haven’t yet figured out why it doesn’t work perfectly. I suspect a race condition between the connectivity test my scripts perform and the DOM manipulation that occurs when we have the result of those tests. I’ll fix it as soon as I’ve identified the exact cause.

So now I have my first fault-tolerant website (and a new imaginary friend, Charlotte). The next target was to transform the Perpetual βeta into a full-blown progressive web app (PWA) — then I would truly earn the right to look down my nose at lesser websites.

Turning the website into a PWA was easy. I already had the majority of the prerequisites in place: TLS; service worker; responsive design… all I was missing was an appropriately configured manifest.json file. It was but the work of a moment… now the Perpetual βeta has become one with all the new, shiny things. Hurrah!

  1. “The Scream” perfectly sums up how I feel when faced with the loss of Internet connectivity. ↩︎