Gain insights into Progressive Web Apps. Delve into service workers, caching strategies, and their advantages. Learn about real-world Angular projects and deploying PWAs using Firebase. Optimize your web solutions efficiently.

angular.tar.gz

appId

authDomain

projectId

appKey

Angular-copy

Angular

Angular-deploy

Offline_page

Angular-prod-build

Progressive Web Applications are the state of modern web solutions. With the proper strategies, it is possible to drastically improve the overall performance and providing data even without a network connection. 
In an increasingly mobile-first world, optimising the time to load web pages can be our business's success. 

We will start by describing what PWAs are and their advantages over native and plain web applications. We then go deeper analysing fundamental concepts like service workers, caching strategies and when to use them in different scenarios. 

Aside from generic, framework-agnostic code samples, there will be an entire "hands-on" section dedicated to Angular, where we will create a complete, real-world PWA project from scratch.

Finally, we will learn how to deploy our PWAs to the cloud with different providers, describing in detail the approach with the Firebase platform. Thus, concluding our journey in the PWAs world.

Optimize your web projects with Progressive Web Apps

## Definition

A service worker is a special kind of web worker, but there is a subtle difference between them:

> A **service worker** is a JavaScript file acting as a proxy between our web application and the network.

> **Web workers** are scripts with a generic purpose, commonly used to lift heavy tasks from the main thread and run them in a different context.

A service worker (in short, *SW*) can intercept HTTP requests and serve the responses from the network or a local cache, according to which caching strategy you implemented (more details in the next chapter).

 

We’ll describe the main characteristics:

### Secure
Service workers only function on secure connections (HTTPS). This is a safe decision because otherwise, you easily expose your application to *man-in-the-middle* attacks. Let’s imagine what might happen if anybody could substitute your SW with a manipulated one and be capable of sniffing ALL the network requests… you for sure don’t want that!

 On the other hand, the `localhost` is considered secure, testing the application before deploying it.
> ⚠️ **Note!** One extra word about Angular: we cannot use the `ng serve` command to build and serve our application locally because it doesn't work with service workers. In this case, we have to use an HTTP server of our choice, for example, [http-server](https://www.npmjs.com/package/http-server) package or the [Web Server](https://chrome.google.com/webstore/detail/web-server-for-chrome/ofhbbkphhbklhfoeikjpcbhemlocgigb?hl=en) Chrome extension.

 

### No direct DOM interaction
SW cannot access the DOM directly. They can, however, communicate with the pages under their scope through the `postMessage` interface. These pages can then manipulate the DOM allowing indirect access.


 

### Non-blocking
Service workers, similarly to web workers, run on an independent thread separate from the one used by our application. Therefore, here, “non-blocking” means that heavy load operations or SW crashes would not affect the performance of our web application in any way. 
 Their capability of running in the background is also why we can display web notifications to our users, even when they are not actively accessing our web application. 

 

## Service worker compatibility

You can verify the browser support for SW by consulting the following links:

<be>

![](/api/collection/5884426195042304/5823759446441984/page/5786603650809856/image/5537627639119872?page_type=collection_lesson)

- [Source Can I use](https://caniuse.com/#feat=serviceworkers)

 
 


![](/api/collection/5884426195042304/5823759446441984/page/5786603650809856/image/6136756572258304)
- [Source is Serviceworker ready](https://jakearchibald.github.io/isserviceworkerready/)

# Definition

A service worker is a special kind of web worker, but there is a subtle difference between them:

> A **service worker** is a JavaScript file acting as a proxy between our web application and the network.

> **Web workers** are scripts with a generic purpose, commonly used to lift heavy tasks from the main thread and run them in a different context.

A service worker (in short, *SW*) can intercept HTTP requests and serve the responses from the network or a local cache, according to which caching strategy you implemented (more details in the next chapter).

 

We’ll describe the main characteristics:

## Secure
Service workers only function on secure connections (HTTPS). This is a safe decision because otherwise, you easily expose your application to *man-in-the-middle* attacks. Let’s imagine what might happen if anybody could substitute your SW with a manipulated one and be capable of sniffing ALL the network requests… you for sure don’t want that!

 On the other hand, the `localhost` is considered secure, testing the application before deploying it.
> ⚠️ **Note!** One extra word about Angular: we cannot use the `ng serve` command to build and serve our application locally because it doesn't work with service workers. In this case, we have to use an HTTP server of our choice, for example, [http-server](https://www.npmjs.com/package/http-server) package or the [Web Server](https://chrome.google.com/webstore/detail/web-server-for-chrome/ofhbbkphhbklhfoeikjpcbhemlocgigb?hl=en) Chrome extension.

 

## No direct DOM interaction
SW cannot access the DOM directly. They can, however, communicate with the pages under their scope through the `postMessage` interface. These pages can then manipulate the DOM allowing indirect access.


 

## Non-blocking
Service workers, similarly to web workers, run on an independent thread separate from the one used by our application. Therefore, here, “non-blocking” means that heavy load operations or SW crashes would not affect the performance of our web application in any way. 
 Their capability of running in the background is also why we can display web notifications to our users, even when they are not actively accessing our web application. 

 

# Service worker compatibility

You can verify the browser support for SW by consulting the following links:

<be>

![](/api/collection/5884426195042304/5823759446441984/page/5786603650809856/image/5537627639119872?page_type=collection_lesson)

- [Source Can I use](https://caniuse.com/#feat=serviceworkers)

 
 


![](/api/collection/5884426195042304/5823759446441984/page/5786603650809856/image/6136756572258304)
- [Source is Serviceworker ready](https://jakearchibald.github.io/isserviceworkerready/)

Service workers are at the base of all PWAs, and allow us to intercept network requests and implement the appropriate caching strategy for these calls.

Introduction

The Progressive Approach

Install a PWA on a Device

Service Workers

Caching Strategies

PWA Tools and Libraries

Angular PWA

Deploying our PWA

Wrap up

What is a service worker

Definition