Blog

The Magic of Service Workers

Improve user experience with high performance

blog pic
The battle lines are drawn, yet again. Before smartphones, every website was server-driven. With smartphones came native apps which moved the user-interface onto the user device. As a result, frontend processing of code came on the device and server access reduced proportionately. This was a huge improvement in user experience particularly in the social media age where app performance is key and user patience rare.

Unfortunately apps came with their own baggage. Users needed to make their device resources available for app installs and frequent upgrades. App developers had to keep separate software versions, one for the website, the second for iOS and the third for Android. Furthermore, app stores started charging in-app commission on subscriptions paid by users in the app thereby making the native app proposition further expensive. As a response to this not so favourable situation, a new battle-front is being drawn now by an emerging technology, called Progressive Web Apps (PWAs).

PWA is a suite of browser technologies at the center of which is the Service Worker. Very simply, think of the Service Worker as the control engine of a web app page rendered on a user device. It provides Cache API to store static and other page resources in its cache, Share API for sharing data and files with other apps installed on your device, Share-Target API to receive shared data and files from other apps, Push API for push notifications, methods to make one or more pages work offline (without internet connectivity), the concept of promises for advanced asynchronous performance, and much more. In summary, Service Workers can make a website work as great as a native app keeping user experience at the core just as native apps do.

The magic of Service Workers is not so easy to harness. All its methods work on a new concept called ‘promises’. Promises extend the ‘asynchronous concept’ at code execution granularity (not just at function level). It is therefore important for a developer to go gradually, explore each feature in-depth, read, learn and figure the promise execution methodology with patience. Even though a Service Worker is merely javascript code, it is one of the most complex and powerful technologies we have encountered in our work.

In Riddlock (www.riddlock.com), we have used the Service Worker, Cache API, Share API, Share-Target API and the Push API, along with several other emerging (and existing) technologies such as WebCrypto, IndexedDB, SignalR and SQL-Table-Dependency. Riddlock being a privacy app, it uses encryption at multiple levels, with WebCrypto at the frontend and AES-256 at the backend. It has offline data access features for which IndexedDB is heavily used (with encryption of course). Our private connect features between users use the SignalR and SQL-Table-Dependency technologies. All of this (and more) makes achieving performance and user experience a big challenge. Thanks to the Service Worker and its associated technologies, we have been able to achieve some major goals quite efficiently. Our performance is over 90% on all browsers and devices currently. We have used the Service Worker in unique ways to enhance the user interface and experience. We now plan to exit the app world completely and focus solely on PWA.

The following are some of our learnings about Service Worker nuances:

Install with Cache-Reload
Service Worker ‘install’ will fetch existing cache resources by default if it ‘determines’ that the resource is unchanged. Use ‘cache: reload’ in ‘fetch’ if you want the resource (html page, javascript, bundle or file) to be re-fetched from the server mandatorily.

Understand Service Worker Activation
Updating the Service Worker version is a challenge as it follows a process of ‘install’ and ‘activate’ without disturbing user experience. This means the previous Service Worker version, including its cached files, will continue to apply until the new Service Worker gets activated and takes control of the page. Since the cached files may be partial code only, one must be very careful while changing frontend and backend code because their versions may differ with respect to the Service Worker. For example, if a new API parameter is added in the javascript code, its API will fail until the javascript is activated by the new Service Worker version. You will find various workarounds for the Service Worker versioning issue on online technical forums but none of them will be fool-proof.

Avoid Caching Unnecessary Resources
Choose resources for caching strictly by your business need and not merely for convenience. Caching will have limits on different browsers and devices.

Graduate in Promises
Give yourself time to understand the concept of ‘promises’. It is a wonderful technology but not so easy to understand at the first go. Once you get it, you will enjoy it and perhaps start using it in non-Service Worker areas too.

Communicate between Service Worker & Web Page
Do not use any page (DOM) element in the Service Worker and vice versa. Your page and the Service Worker need to be independent of each other. However, they can ‘communicate’ by sending and receiving messages.

Accept that Service Worker is the Boss
Do not try to control how the Service Worker works because you will fail. Align your software design and coding style instead.

Test
Test thoroughly on different browsers and devices.

In summary, although the Service Worker technology provides numerous features and advantages specific to various business needs, we found the following to be most beneficial:
PWA
Performance
Offline access

To connect, please feel free to email at pravin.shah@riddlock.com. Till then, let’s keep learning.
Share this blog