Last updated: 14.09.2021 02:54
For quite a while we have been noticing a huge interest in Progressive Web Application (PWA) in the frontend world.
More and more companies develop applications using the concept. Users created catalogs (PWA Stats), where we may find the information about use cases and positives (improving conversion, increasing the number of subpages visited during the session or time spent on the page). Market giants, such as Microsoft also promote the technology by allowing to add PWA application to Windows Store.
We described on our blog some time ago, what the features of such applications, pros and cons. Those who are interested I refer to this article.
Why are our company also interested in this topic? I think that instead of writing an essay, it is enough to show graphs from research carried out in the year 2017.
By analyzing graphs above, we may draw the following conclusions:
In this post I would like to focus on technical aspects of developing PWA application using Angular 7. Just so you know – version 7 is the newest available version at the moment 😉
That’s all. At the moment we already have the structure of an application which uses PWA concept.
What have we actually done here?
In the first year we installed Angular CLI using npm.
Using installed Angular CLI, we have developed a structure of a new application called pwa-example. In the third step we have moved to created folder and added @angular/pwa bundle that automatically settled a few matters for us related to configuring the mechanism of service workers (more information about it in further part of this article) More info in docs.
All that CLI did for us, we may also do manually. The question is: what for?
We don’t have to do it manually, but without any doubt we should understand what happened under the hood, and how created configuration looks like.
In package.json file dependencies have been added to necessary bundles.
In angular.json file a notification including service workers has been added to section related to configuration.
An expression Service Workers has been used a few times in the article, however, itself has not been explained yet.
Service Workers expand Web Workers mechanism, which allows to start scripts in the background, in the thread separated from the browser’s main thread. Service Workers are used as a “proxy” between Client’s and Server application. Thanks to them we may cache static resources or triggering specific API (for example, enquiry about purchase list saved on the server may be downloaded from SW, if currently we don’t have access to Internet). Furthermore, they give support to such mechanisms as push notifications and background sync.
We mention a few important tips:
Currently, all of most popular browsers support the mechanism. If the topic seems interesting, I suggest reading Web Workers API and Service Workers API. Furthermore, it is worth to look at great article by Jake Archibald on caching mechanisms and topics related to that – Offline Cookbook.
ngsw-config.json is a file where we can configure behaviors related to caching particular resources in application.
What can we figure out from the configuration above?
In assetGroups section we have two objects where in the first one we configure caching the index.html, JS and CSS files, the second one is related to caching local resources from assets folder.
Entries differ in setting options installMode and updateMode. Official Angular documentation very well explains the difference between specific modes.
For caching API we use section dataGroups. Sample configuration used in our project has been placed below:
In app.module.ts, ServiceWorkerModule has been added. This module gives us opportunity to inject SwUpdate (it allows to manage the update of our application, for example inform the user about a new version) or SwPush services (related to push notifications) and registers Angular Service Worker in the browser. Using enabled parameter we may navigate when SW are supposed to be registered. In the code above our basis is production variable of environment file, which specifies whether application is launched within production environment. More information here.
That’s all. The explanation does not end with two sentences, that’s why it is important to become familiar with the autoconfiguration from the inside.
A very important thing – ng serve, meaning the standard command to launch Angular applications during development, does not support Service Workers, which is why we are unable to test how PWA application works.
It is necessary to have little server on which it is going to be launched.
In the first line we install a little server on which our application will be hosted. Next command builds our application as a production version. Then we launch server with switched off caching (-c-1- flag) by indicating the folder where developed version of application is.
If everything goes well, we may enter URL address http://localhost:8080 and check if Service Worker are registered correctly. In my case it looks like:
Application works, now we may deal with adding a functionality Add to startup screen. Thanks to that we will be able to attach PWA applications to main screen of our smartphone. We must not forget that the functionality is related to mobile browsers. It’s no coincidence that it is called Add to startup screen instead of Add to desktop.
Adding this functionality consists of taking two steps.
It is so called Web App Manifest where we can enter basic information about application. I won’t be going here into too much detail about configuration about particular areas. All is well described in documentation linked in the sentence above.
In angular.json file we have to add manifest.json file to assets section.
In index.html file in head section we must add link to created file.
We also have to remember that this functionality works only with applications served by HTTPS.
In native applications informing about new version takes place via store functionalities. You have to download a new version of application, while it is installed in the background. In PWA applications in order to receive a new version of application, all you need to do is refresh page!
If we want the user to be informed about such situation, it is enough to add a few code lines:
It results in displaying such message to a user:
Claim Register is a sample application – a very simplified version of an application to register insurance claims.
The whole code is available on GitHub.
It consists of a very simple claim registration form and list of claims. Basic assumptions/functionalities:
It seems that application has been developed correctly in terms of “is it definitely PWA”. It has been tested with Lighthouse from Google tool.
We should remember that the idea and mechanisms used by PWA are not the newest discovery which changes the world.
Before Service Workers era, already in the year 2010, Application Cache (AppCache) mechanism was available. In Mozilla’s archival materials we may find information about Open Web Apps standard. In the year 2012 W3C issued Packaged Web Apps (Widgets) recommendations. Similar concepts have been existing for years.
Current users, mobile devices and browsers are ready for PWA.
In the article we’ve gone through the process of developing PWA application’s structure using Angular 7. This framework has very strong support of the concept. React and Vue also handle it very well. Interestingly enough, from quite some time all React’s applications have normally been Progressive Web App.
I encourage you to familiarize yourselves with our repository on GitHub and develop new applications as PWA 🙂
Author: Robert Witkowski, Senior Software Engineer, ASC LAB