PWAs with Angular: Being Reliable

If you've been in the world of web development during the past two years you've probably heard the term Progressive Web Apps (PWAs for short). PWAs are essentially web applications that provide a near-native experience on mobile devices. According to Google they must be:

Reliable - Load instantly and never show the downasaur, even in uncertain network conditions.

This app depends on The MovieDB's APIs. Get an API key (check this out) and put it as the moviedb environment variable in yoursrc/environments/environment.tsandsrc/environments/environment.prod.ts.

Now that we have everything set up, lets run our application npm run start:pwa, open up Chrome and go to localhost:8080 and see what it does.

Well it runs, and if you click on a movie we can get more details about it. AWESOME! But what happens when we're offline?

Hmm… that’s not that good. If there was a test for PWAs that would definitely fail it…

Wait a sec! There is a test for PWAs! Google provides an extension for Chrome called Lighthouse (install it!) that will run a barrage of tests against our application and will generate a report on how well the app did. And, as I expected, this app failed hard.

We can do better than this, so lets make this app more reliable!

The first thing we can do to address a lot of these issues is to use a Service Worker. A Service Worker enables our PWA to load instantly, regardless of the network state. It sits as a proxy between our application and the outside world, and puts us in control of the cache and how to respond to resource requests. Our Service Worker allows us to cache essential resources to cut down on our dependence on the network, giving an instant and reliable experience for your users even when there is no internet.

Now the Angular team actually provides us with an easy tool to add a Service Worker as well as another set of tool (we'll get into them later), so let's install our tools with the following.

That was easy, but we will also need to update our .angular-cli.json to tell it we want to include a Service Worker. That way, every time we make a production build, it will include our Service Worker.

ng set apps.0.serviceWorker=true

Now if we run a production build ng build --prod and check our dist/ folder, we'll see a file called ngsw-manifest.json and if we look into it we will see all of our assets that will be cached by our Service Worker.

But this doesn't include our routing configuration, so we can create one with the ngu-sw-manifest tool (part of ng-pwa-tools we installed before).

./node_modules/.bin/ngu-sw-manifest --module src/app/app.module.ts

Now, you probably got an error like this…

ENOENT: no such file or directory, open 'app.component.html';

Our ngu-sw-manifest tool isn't able to traverse through our application when there are relative paths for our component's templates and stylesheets. So we'll add moduleId: module.id to the @Component decorator of our three components. (src/app/app.component.ts, src/app/home/home.component.ts, and src/app/movie/movie.component.ts) So we should have decorators that look like this.

This sets our default caching strategy. (Modify the dynamic.groups[0].name and dynamic.groups[0].urls based on how you plan on hosting your app) Just remove the comments included, and now we can run the ngu-sw-manifest tool to take our assets, routing, and our custom defined manifest file and output it into our dist/ngsw-manifest.json.

Then we can run our app npm run start:pwa. Try running the application after disabling the network connection in the Chrome Dev Console, heck we can even run Lighthouse on it again!

So we're doing a little bit better (some things like the HTTPS we wouldn't be able to fix until we deployed this). But at least we've doubled that PWA score! Next week we're going to up that score by improving our speed (perceived and real).

To look at the code differences from where we started to right now click here. Also if you feel so inclined, I invite you to deploy up your app to Firebase. If you run Lighthouse on the deployed app you'll get a much higher score:

There have been some changes to the @angular/material where @angular/cdk has been broken out and needs to be installed separately as you said. Also there is an issue with lazy loading with the latest CLI building which requires the installation of enhanced-resolveyou can see here.

In regards to the service worker stuff I would need to see your code before I can say anything for sure.

I feel like this issue of mine is not related to the actual content of your tutorial, and thus don't want to bother you with it. I shall post on SO if that is of interest to the Javascript Angular crowd.