Skip to main content

Progressive Web Apps

Deliver amazing user experience for WEB


Progressive Web Apps (PWA) are user experience that reach for web. Its useful to users from the very first visit with no installation required. As the user spends more time with the web app it becomes more and more powerful, It loads quickly even on slower networks. Can have offline support, push notification, icon on home screen, full screen support. PWA are:
  • Reliable - load instantly even on slower/uncertain network.
  • Fast - Respond quickly to user interactions
  • Engaging - Feel like natural app on device with amazing user experience.


When launched from the user’s home screen, service workers enable a Progressive Web App to load instantly, regardless of the network state. A service worker, written in JavaScript, is like a client-side proxy and puts you in control of the cache and how to respond to resource requests. By pre-caching key resources you can eliminate the dependence on the network, ensuring an instant and reliable experience for your users.


Users will abandon a site if it takes longer than 3 seconds to load! And once loaded, users expect them to be fast—no janky scrolling or slow-to-respond interfaces. Check more on Performance


Progressive Web Apps are installable and live on the user's home screen, without the need for an app store. They offer an immersive full screen experience with help from a web app manifest file and can even re-engage users with web push notifications. The Web App Manifest allows you to control how your app appears and how it's launched. You can specify home screen icons, the page to load when the app is launched, screen orientation.

Service worker:

A service worker is a script that your browser runs in the background, separate from a web page, opening the door to features that don't need a web page or user interaction. Screen Shot 2017-05-31 at 10.19.19 AM

Service worker is proxy between our APP and Network, its has control for our incoming and outgoing secure network request as well as our browser cache. It helps how app should behave when its offline, should use cache. Check various browser supporting service worker status here. Most of the part of our app is unchanging. The dynamic content is changed using API requests. So ideally we would like to tell the browser to hold onto that unchanging content of our app to prevent extra requests and to speed up rendering. This is where Service Workers come in. Using Service Workers we can explicitly tell the browser: “I want you to hold static content (JavaScript, CSS & HTML) until i tell you”. This allows the browser to use our application shell by default. Instead of requesting the resources from the network, we use the cache every time even when there is no network connection. This in turn speeds up our app startup and allows our app to work better offline.

Sample Application

We will create simple Angular application. Will use Service worker to make app lightning fast, have offline capability, cache static content, caching runtime calls with Network First strategy. Create application using Angular CLI, "ng new my-app" is command to create default application. Enable the service worker by making following changes in index.html file. Add below code bottom of file exactly before "</body>" tag.

  Screen Shot 2017-05-31 at 12.59.45 PM.png

Create blank "service-worker.js" file in src folder. Add following entry in "angular-cli.json"

  Screen Shot 2017-05-31 at 1.45.47 PM.png

Serve the app using "ng serve" command.

  Screen Shot 2017-05-31 at 1.48.44 PM.png

Open chrome developer

  Screen Shot 2017-05-31 at 1.49.10 PM.png

Here we can see Service Worker is successfully installed. Browser will always use this copy, if there is change browser will re-install service-worker.js. Now service worker is successfully installed, we can write logic for caching. But writing logic is complex and needs to handle various scenarios. To avoid this complexity Google Developer has created small library SW Precache on top of Service Worker to create some of useful offiline patterns. SW Precache is a build time tool that looks at our generated static (JS, CSS and HTML) and generates a Service Worker file for us. This generated Service Worker contains a hash specifically for each file in that build for the browser to cache and use even when offline. In subsequent builds the hash changes which causes the browser to request the updated files. Now Build the project : "ng build --prod", this command will compile code and put in dist folder which can deploy and serve as angular app.

  Screen Shot 2017-05-31 at 5.06.03 PM.png

Install SW Precache: "npm install  --save-dev sw-precache" We need to add couple of npm scripts to our project, make following changes to package.json.

Screen Shot 2017-05-31 at 2.27.43 PM.png

Create "sw-precache-config.js" file and add below content. More details on every attribute can be found here.

  Screen Shot 2017-05-31 at 2.29.00 PM.png

Now lets run our npm command "npm run sw"  Screen Shot 2017-05-31 at 2.24.15 PM.png

If we look in our generated Service Worker in our dist directory we should see some generated code. If we look through it we can get a idea of how the code is handling all the cache logic for our application. Copy the dist content to any HTTP sever and open in browser.

  Screen Shot 2017-05-31 at 2.35.09 PM.png

Goto chrome developer tool -> Application and select offline mode, Reload the page, All the content will be served using service-worker from cache.

  Screen Shot 2017-05-31 at 2.38.13 PM.png

Now we will add more functionality to this Angular APP, we will create page (as a default route) which will display list of mobiles. Copy app & assets folder from GIT to app folder. App folder contains below set of files -
  • app.component.html
  • app.component.ts
  • app.module.ts
  • app.routes.ts
  • app.service.component.ts
  • mobiles.component.html
  • mobiles.component.ts
Previously we had cached the static content, we will add some changes for runtime-caching, we will cache service request based on strategy. Make runtime caching changes in "sw-precache-config.js".

  Screen Shot 2017-05-31 at 4.33.46 PM.png

Above runtime caching config is caching url with pattern "../api/..". If network is available it will be served from network otherwise served from cache. Form more info on handlers click here.

As we are using bootstrap styles add bootstrap dependencies. Add "bootstrap": "^3.3.7" in devDependencies section in package.json

Screen Shot 2017-05-31 at 4.25.45 PM.png

 Add bootstrap style in angularcli.json also.

  Screen Shot 2017-05-31 at 4.27.50 PM.png

Now build the application "ng build --prod" Make service worker changes "npm run sw" Copy the dist folder to your http-server and open in browser.

  Screen Shot 2017-05-31 at 4.32.26 PM.png

Goto chrome developer tool -> Application and select offline mode, Reload the page, All the content will be served using service-worker from cache.

  Screen Shot 2017-05-31 at 4.52.27 PM.png

The xhr request over network has failed and its served from cache using service worked.

Source code for sample application is on GIT

Useful links

Cheers – Happy learning 🙂

Ketan Gote


Popular posts from this blog

Redis Basic CRUD

We have seen how to setup on your linux machine here , now we will see how to perform basic CRUD operations using Spring Data & Redis server We will be creating a simple application that would persist an employee information into redis database. You will be needing certain JARs like jedis.jar, spring-data-redis.jar etc details of which you can download and view at  First of all we will be creating the Employee entity, plz note that we are using the Serializable interface which automatically mapps the objects against the key. import ; public class Employee implements Serializable { private static final long serialVersionUID = - 8243145429438016231L ; public enum Gender { Male , Female } private String id; private String name; private Gender gender; private int age; public String getId () { return id; } public void setId ( String

CRUD in MongoDB & Spring Data

Now, since we have already been introduced to mongo and its server is setup. We shall now move on to performing basic CRUD operations. Lets take a use case example of ‘Company’ database that stores employee information.  We wish to store employee name, email address, age and multiple addresses. Traditionally in RDBMS we would create an Employee table and Address Table having foreign key reference to ‘employee id ‘ Incase of NoSQL, we will be creating Employee documnet which will have store employee information like name, email, age and an array of employes address. Following is a snippet of the schema defined { "name" : "", "email" : "", "age" : “”, "address" : [ ... ] } Thus to begin with, we will first define the entities. We have employee as an aggregate root entity that stores list of address having 1-M relatioship. Address Entity is represend as @Embeddable as it is embaded in another aggregate root entity. Employee is