And just like that, now web apps are 1 step closer to mobile apps

What & why

Web push is the ability of a web-application to send the user notifications as a background process, just like a native mobile application

What happens is that your browser runs scripts in the background that fire a notification to the user on the behalf of the target web-app, when these browser scripts receive a message from a notification server


Explaining it to a 5 year old

  • There are 3 main entities involved in this setup :
    1. App notification server - sends notifications to a registered subscriber
    2. Browser push service - A feature provided by the browser which serves as a medium of communication between the app notification server & the service worker on the client
    3. Service worker on the client - Responsible for setting up subscription object & displaying the notifications of messages it receives

I will explain this process in 2 phases

Making the client web-app subscribe to the notification server

  • When the service worker (just a JS file, running in the background in the browser) is registered, we get a registration object that contains the details of this registered service worker.
  • On this object, we call the pushManager.subscribe() function to get a subscription object. The client will see a ‘do you want to allow notifications’ banner in their browser. If they say yes, the subscription is successful & we get a subscription object. If they say no, the process just exits here.
  • In this subscription object, we have the subscription endpoint + publicKey.
    The subscription endpoint is the the exact address of the client web app on the given browser in the given device being used.
    The public key is just for encrypted communication between client web-app & app notification server.
  • We convert this subscription object to JSON & send it to the our app notification server.

Displaying messages from the notification server as notifications on the client web-app

  • Now, the app server, whenever it sends a message, it is received by the Browser’s push service, which resolves it to the respective client using the subscriptionId param inside the endpoint URL & then it directs the decoded message (using the public key) to the necessary client application with a push event.
  • This push event is then picked up by the service-worker registered on the client, who parses the title & body of the message & shows it as a notification on the client using the registration.showNotification() function.
  • And thus, the client is able to register for notifications & then receive them.
  • The subscription object might change from time to time on the client so we should always check for this object & send it to the app server accordingly
  • For any web push notification feature with a browser there are 3 main components :
    1. App notification server - eg : CleverTap, MessageBird
    2. Push service on the browser - eg : Google Chrome browser managed push-service, Mozilla Firefox's browser push-service, Microsoft Edge's browser based push service.
    3. Service worker of the app - Just a JS file on the client side that will help make the client become a subscriber of the notifications & show notifications whenever received.

Conclusion

This is the basic procedure of how web push notifications work in Progressive Web Apps, hypercharging them with the ability to send notifications even when the web app is not open in the user's device.

Subscribing client to notification server

Sending notifications from server to client