All you need to know about Web Push APIs
The Web Push API gives visitor and users of web applications the ability to receive messages pushed to them from a server (operated by web application provider), whether or not the web app is actively open in the web browser. This also lets developers deliver on-demand web push notifications and updates to users that opt in to receive push notifications. Push messaging lets developers engage users by providing timely and customized content outside the context of the web page. It is one of the most critical APIs to come to the web, giving users the ability to engage with web experiences even when the browser is closed, without the need for a native app install.
What are Web Push APIs?
Web Push APIs is a set of functions recommended by W3C and supported by the leading browsers - Chrome, Firefox enabling websites to send push notifications to their visitors. While different browsers are at different stages of the adoption, there are two distinct ways through which browsers have exposed web push functionality. First, is through Service Workers. All browsers except Safari (More on Safari Push Notifications here) follow this model. Second is through Push Package concept which Safari follows.
We will now take you through key concepts and considerations to keep in mind as you begin your journey to integrate web push APIs in your web application.
If you are still not completely sure about web push, take a lookg at our HTML5 Push Notification Demo to see push in action.
How does Web Push API work?
Each browser manages push notifications through their own system, called a "push service". When the user grants permission for Push on your site, you can then subscribe the app to the browser's push service. This creates a special subscription object that contains the "endpoint URL" of the push service, which is different for each browser, and a public key. You send your push messages to this URL, encrypted with the public key, and the push service sends it to the right client.
Key Web Push API Concepts & Usage
For any web app to receive push messages, it must have an active service worker. Think of this service worker as the thread that is responsible for three primary functions/tasks involved in web push: 1- subscribing to receive push notifications, 2- unsubscribing to cease receiving push notifications, and, 3- displaying push notifications when they are received.
You might wonder that such a service worker will consume resources - particularly battery resources on a mobile device. You are not wrong there. Different browsers employ different mechanisms to reduce such resource consumption. Bottom line is that there is no standard mechanism. For example, Firefox allows a limited number of push messages to be sent to web application. Chrome, on the other hand, applies no such limit.
A service worker generally goes through following lifecycle steps:
1- Dowload. Service worker is downloaded whenever a user accesses the web page controlled by service worker. Even after a service worker is registered, it's downloaded periodically for consistency and updates.
2- Install. As soon as the service worker is downloaded, browser tries to install and activate it. InstallEvent.InstallEvent() creates a new installation object, InstallEvent.activeWorker returns the service worker currently active on the webpage. You can keep listening to service worker install event and prepare supporting stuff such as building cache, defining service worker operations.
3- Activate. Whenever a service worker is installed, the browser tries to activate it provided that there is no service worker currently active. If another instance of service worker is already running, the new service worker goes in 'Worker in Waiting' stage. It is activated when the web pages no longer refer to the older service worker.
How does the push service know which client to send the message to?
The endpoint URL (think of this as the address information associated with the endpoint that you receive once the user opts to receive push notifications) contains a unique identifier. This identifier is used to route the message that you send to the correct device, and when processed by the browser, identifies which service worker should handle the request.
The identifier is opaque. As a developer, you can't determine any personal data from it. Also, it is not stable, so it can't be used to track users.
Do sites need to be HTTPS to support Web Push API?
Because push notifications are paired with a service worker, apps that use website push notifications must be on HTTPS. This ensures that the communication channel between your server and the push service is secure, and from the push service to the user is also secure.
However, HTTPS doesn't ensure that the push service itself is secure. We must be sure that the data sent from your server to the client is not tampered with or directly inspected by any third party. You must encrypt the message payload on your server.