What is a Progressive Web App?
Historically, native apps have been classified as more capable due to their access and control on the device functionalities like geolocation, push notifications, background updates etc. but often the reach of native apps is a bit limited.
In order to use a native app, user has to explicitly install an app, and the app takes a memory footprint on the user’s device and a majority of the users are not comfortable in doing that especially for the apps they occasionally use. Users often fallback on the web based alternatives but using the web application comes at an expense of reduced functionality.
Hosting and maintaining web app is usually more expensive compared to the maintenance of a native app but for a native app development, handling different operating systems is also a development overhead.
This creates a double whammy situation for both developers as well as end users. What if we can leverage the rich functionalities of native apps and the outreach of the web applications? Now, that’s where progressive web apps come in. Progressive web apps are essentially light weight web applications which emulate the behaviour of native apps. You must be wondering how they do it. Well that’s where web workers come into picture.
What is a service worker?
A service worker is essentially a web worker which runs as a background process separate from a web page which caters to features that don’t need the web page or the user interaction.
Upon instantiation, the app can interact with the service worker via event handlers specified in its code and vice versa. This is mostly done by the APIs like postMessage() which send data as a ‘message’ event this ‘message’ event can be captured as a part of navigator.serviceWorker object.
Why service workers?
Service workers are increasingly gaining popularity in the development of progressive web apps as they emulate native app behaviours. Some of the widely used functionalities facilitated by service workers for a progressive web app development are as follows:
Offline Access: Service workers can provide the offline access by caching the static files using the Cache API which can maintain the cashed instances of request/response pair. Although, there is fixed quota available for a browser cache storage hence adequate purging schemes have to be put in place while using the Cache API in a productive landscape. Typically Fetch API and Cache API are used in conjunction to facilitate offline access.
Background Sync: Serving the application during downtime can be addressed by offline access but what if based on user action, some data is needed to be sent to the server?
The solution for this problem lies in requesting a one-off sync from the service worker and then listen for ‘sync’ event in service worker. Here is how it works:
Now that we know service workers are powerful web development tools, modern progressive web applications can greatly leverage service workers to carry out predictive prefetching, bounce rate management, offer-relevant recommendations, payment requests etc. As it’s an introductory overview, more details on the usage, lifecycles, best practices and case studies will follow.