Web Push Notifications through VAPID method
The future of the modern web
First, web push notifications are messages those come from a website where you as a user from it have been accepted on receiving notifications related to that website. These messages shows up on the screen of any of your devices even when the web page is not opened in the browser, like an app notification.
There are some differences regarding to the push notification those are important to explain. A Push is a service that works behind the scenes of your browser and call it a Service Worker. A service worker is all about what a website needs to process to maintain some information and in our case to send the notifications. It uses APIs (Push and Notification) from the browser in order to receive the messages.
What is VAPID method?
The VAPID (Voluntary Application Server Identification) is the newest way to receive and send push notifications through the web. Many browsers support the protocol nowadays, but before it takes its place, the notifications were sent trough the FCM/GCM keys (Firebase Cloud Messaging / Google Cloud Messaging). But what has Google to do with it? Well, they have started everything.
As VAPID is a new protocol for messaging in the web, most of the applications are migrating to it, because of the easier implementation.
Notification API
Let’s code something to simplify what really happens.
It is always necessary to ask for the user permission from the browser if it wants to receive notifications from that website. The following code should do the trick.
The permission automatically requested when subscribing to the push service. Because of that, the code is not required when using only push notifications.
We also need to check for the current state of the users permission and for that we have to configure and verify some things.
The code checks whether the permission has been granted and if so it calls the showNotification() method which comes from the service worker registration itself only passing as parameter the notification title. Although it’s also possible to pass some other options, like on the code below.
The body property is the message text of the notification. The icon is the image displayed as an illustration for the notification to identify, for example, the website symbol. The vibrate is the vibration pattern for smartphones. The data is not mandatory, but is recommended for identifying the notification in the web app.
The next picture shows a good example of a web push notification.
There are also some notification events those are possible to be handled when the user interacts with the notification.
- notificationclick: when the user clicks on the notification (not closing it), this event is triggered.
- notificationclose: triggered whenever the notification is dismissed by the user action from the close button.
Sending and Receiving Push Notifications
When the user grants permission for the notifications, the user subscribes to the browser’s push service. It creates a subscription object that includes a public key to enable messages to be encrypted and an endpoint URL for the browser’s push service which is unique for each user.
From a back-end server the message has to be sent as a push to a URL encrypted with the public key in order to reach the right client which is handled by the service worker.
In the front-end’s app the PushManager.Subscribe() has to be called on the service worker registration object to get the subscription object and convert it to JSON. At this point, it is possible to get the endpoint URL, public key and send back all the info to the back-end for saving.
The flow is something related to the following picture.
Subscribing to the push service
- Registering the service worker from the main page, main.js, triggers a request to the user agent which returns a service worker registration object. This object access the push manager API and it goes from that request to subscribe to the service. Then, all that process is made.
- When it is ready to send the push notifications, the register for push service has to be created as the following code.
Each subscription is unique to the service worker and the endpoint URL needs to be kept as a secret, otherwise other applications might be able to push messages.
Below is an example of the subscription object.
At this point your back-end should do the job on pushing the message to the web page.
The back-end service sends a push message to the push service using the endpoint URL from the subscription object. Then, the message must be encrypted with the public key.
The push service uses subscription IDs encoded in the endpoint URL to send the message to the right user. The push event is picked up by the service worker and it gets the data from the message and shows the notification.
Please, make sure that there is secure communication between the user and the server and between the server and the push service and also between the push service and the user.
Voluntary Application Server Identification (VAPID) was created for this purpose, as it uses JSON Web tokens to carry on identifying information.
That’s just a sample to show how a notification works behind your code and as we could see it is not so simple as it usually was. Hope, I brought to you some new expectations about the context.
