Developing a PWA Using Angular 7

For quite a while we have been noticing a huge interest in Progressive Web Applications (PWAs) in the front-end world.

More and more companies develop applications using the concept. Users creat 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 developers to add PWA applications to the Windows Store.

We described on our blog, some time ago, the features of such applications, and their pros and cons. Those who are interested I refer to this article.

Why is 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.

How many applications smartphone users download from stores within a month?

How much time smartphone users spend in most popular applications?

By analyzing the graphs above, we may draw the following conclusions:

• Having installed a few necessary applications, users don't download a lot of new apps.
• Users spend over 95% of their time in the 10 most popular applications: Facebook, Messenger, Youtube, Google Chrome, Gmail, Instagram, WhatsApp, and Spotify. Where is the place for our brand new application here?
• Not willing to download new applications can be understood in two ways: most people use smartphones to browse through Facebook or the current application installation process via stores is too complicated and nobody wants to deal with that. Personally, I am in favor of the second interpretation, which is why I think that PWAs are a chance to change these habits.

In this post, I would like to focus on the technical aspects of developing PWA applications using Angular 7. Just so you know, version 7 is the newest available version at the moment.

Angular PWA Using Angular CLI

That’s all. Now, we have the structure of an application which uses PWA concept.

What have we actually done here?

In the first line, we installed the Angular CLI using npm.

Using the installed Angular CLI, we have developed a structure for a new application called pwa-example. In the third step, we moved to created folder and added the  @angular/pwa bundle that automatically settled a few matters for us related to configuring the mechanism of service workers (more on this late on) For more information, check out the Angular docs.

What happened after add @angular/pwa.

All that CLI did for us, we may also do manually. The question, thus, is: why use the CLI?

We don’t have to do it manually, but without any doubt we should understand what happened under the hood, and what the configuration looks like.

What Happened – package.json

In the package.json file, dependencies have been added to the necessary bundles.

What Happened – angular.json

In the angular.json file, a notification, including service workers, has been added to the section related to configuration.

What Happened – Service Workers

The term service workers has been used a few times in the article, however, it has not yet been explained.

Service workers expand the web workers mechanism, which allows us to start scripts in the background and in the thread separated from the browser’s main thread. Service workers are used as a “proxy” between the client-side and server-side application. Thanks to service workers, we may cache static resources or trigger specific API calls (for example, querying an API for a purchase list saved on the server and downloading this least even without access to the Internet). Furthermore, they give support to such mechanisms as push notifications and background syncs.

Service worker’s mechanism of acting as an interceptor of requests from an application.

A few important notes about service workers:

• Service workers have been developed so as to be fully asynchronous, which is why synchronous operations and local storage mechanisms should not be used together with them.
• Service workers do not have direct access to the DOM tree. To communicate with an application, we should use dedicated methods.
• We should not use service workers as the place to save global states between particular events. If we need such a mechanism we should use a database, such as IndexedDB.
• Service workers are not related to the browser’s standard cache control.

Currently, all of most popular browsers support the mechanism. If the topic seems interesting, I suggest reading the Web Workers API and Service Workers API articles on MDN. Furthermore, it is worth looking at great the article by Jake Archibald on caching mechanisms and related topics related – Offline Cookbook.

What Happened – ngsw-config.json

ngsw-config.json is a file where we can configure behaviors related to caching particular resources in an application.

What can we figure out from the configuration above?

In the assetGroups section, we have two objects. The first one we configure by caching the index.html, JS, and CSS files; the second one is related to the caching of local resources from the assets folder.

Entries differ in setting options: installMode and updateMode. The official Angular documentation explains the difference between these specific modes.

For caching APIs, we use  dataGroups as shown in the sampe configuration below. 

What Happened – app.module.ts

In app.module.ts, ServiceWorkerModule has been added. This module gives us the opportunity to inject SwUpdate (which allows us to manage the update of our application, for example, by informing the user of a new version) or  SwPush services (related to push notifications) and registers the Angular Service Worker in the browser. Using the enabled parameter, we may navigate when SWis supposed to be registered. In the code above, our basis is the production variable of the environment file, which specifies whether the application is launched within the production environment. More information can be found here.

What Happened – Summary

That’s all. The explanation does not end with two sentences, that’s why it is important to become familiar with auto-configuration from the inside.

How to Launch Angular PWA

A very important thing, – ng serve, is the standard command to launch Angular applications during development. But, this doesnot support service workers, which is why we are unable to test how PWA applications work.

It is necessary to have a little server on which out app will be launched.

In the first line we install a little server on which our application will be hosted. The ext command builds our application as a production version. Then we launch the server with after switching off caching (-c-1 flag) by pointing to the folder where the developed version of the application is housed.

If everything goes well, we may enter the URL address, http://localhost:8080, and check if the service workers are registered correctly. In my case, it looks like this:

Add to Startup Screen – One-Click Install

The application works, so now we have to deal with adding a functionality, Add to startup screen. With this functionality, 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.

Adding a manifest.json File to the Project

This is the so called Web App Manifest where we can enter basic information about the application. I won’t go into too much detail, here, about the configuration of particular areas. You can take a deeper dive using the docs I linked to above.

Adding the manifest.json File to angular.json and index.html

In the angular.json file, we have to add a manifest.json file to the assets section.

In the index.html file in the head section, we must add link to the created file.

We also have to remember that this functionality works only with applications served over HTTPS.

Informing the User About a New Version

In native applications, informing users about new versions 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 the refresh page!

If we want the user to be informed about such a situation, it is enough to add a few code lines:

This results in displaying message to a user, as shown below:

Sample Progressive Web App

Claim Register is a sample application – a very simplified version of an application to register insurance claims.

The code is available on GitHub.

It consists of a very simple claim registration form and list of claims. The basic assumptions/functionalities:

• The application connects with a free API to download information about car brands. API requests are cached to select the car brand without access to the Internet.
• All that we write in registration form fields is saved in cache.
• We do not cache a list of claims (My claims) intentionally in order to show differences in action.
• You may add photos, which are also saved in cache, thanks to which we may add photos even without access to the Internet, and when we retrieve it, click the Save button, and send everything to server.
• On the 'register new claim' screen, the Enable notifications and Send notification buttons, which are used to test functionalities related to notifications, are available.
• Apart from the client (claim-reporter-app), claim-reporter-server has been added in the repository – it is a simple backend written in Node.js which allows us to save tge claim in an in-memory database, add notification subscribers (a person to whom notifications are going to be sent), and send notifications.

It seems that applications have been developed correctly in terms of “is it definitely a PWA.” It has been tested with Lighthouse from Google tool.

Report from Lighthouse related to sample Claim Register application.

Summary

We should remember that the idea and mechanisms used by PWAs are not really all that new.

Before service workers, the Application Cache (AppCache) mechanism was available. In Mozilla’s archival materials we may find information about the 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 this article, we’ve gone through the process of developing a PWA application’s structure using Angular 7. This framework has very strong support of the concept. React and Vue can also handle it very well. Interestingly enough, from quite some time, all React applications have been Progressive Web Apps.

I encourage you to familiarize yourselves with our repository on GitHub and develop new applications as PWAs!

If you enjoyed this article and want to learn more about Angular, check out our compendium of tutorials and articles from JS to 8.