Web Push APIs Explained

Understand What Runs in the Background

Introduction

Web push notificationshave emerged as a powerful channel for websites and webapps to engage their users. All the leading browsers -Chrome,Safari,Firefox, Opera,Edgesupport web push notifications, covering more than 90% of the total web traffic. Marketers now have a very effective channel at their disposal to drive traffic and conversions.

While more and more websites are getting adapted to web push notifications, browsers are moving aggressively towards adding more capabilities to notifications, following common protocols for communication, adding support for native notifications.

Browser updates can be overwhelming and marketers often find it difficult to follow different implementation methodologies set by browsers and to keep up with the updates. And hence they would typically turn to third-party service providers such as iZooto to implement web push. It’s an advisable approach, considering the efforts involved in setting this scratch up, however, as the website owner, you should be aware of what goes in the background.

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 –

Using service workers, followed by Chrome, Firefox, Opera, Edge

Using Push Packages, followed by Safari

The Service Worker Approach

Service worker is an event driven worker registered in the browser, it’s a JavaScript file that can control the webpage it is associated with by intercepting and modifying navigation and resource requests, caching resources to control offline behavior. Using service workers one can hijack and control connections, fabricate responses. Powerful stuff. Hence service workers are allowed to run only on HTTPS domains. Service workers run asynchronously with the web pages and handle web push events for users.

Before we dive deep into the details of web push API, let’s see how the web push operates. It constitutes three important workflows as mentioned below

A. Service Worker APIs

Service worker goes through the following life cycle :

Download- 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.

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.

You can add listeners for event object to see the installation status and initialize your system accordingly.

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.

You can add listeners to check activation status for service worker and proceed further.

Service worker also support functional events - fetch, sync, push, which are invoked during the notification delivery. You can go through the detailed documentation here.

B. Subscription Prompt APIs

Subscription prompt APIs provide information about users current subscription status and may request the browser to prompt the user for subscription.

Notification.permission():It indicates the current permission given by the user for notifications. Response 'granted' tells that the user has already allowed for notifications, 'denied' indicates that the user chose to block notifications from the site and website can't ask for the notification permission again, 'default' indicates that the user has not responded to the subscription prompt yet and browser may choose to prompt the user for subscription again.

D. Notification APIs

Notification APIs are used to display an actual notification to the user and to capture their responses. Service worker keeps listening to the push requests in the background. As soon as it receives a request to display notification, it fetches required notification data from the application server and displays a notification to the user.

Additionally, user responses to the notifications can be tracked using Notification.Event. NotificationEvent.NotificationEvent() creates a new notification object which can be accessed to capture user response to notification. It inherits its properties from parent object - Event, hence all the functions defined for Event object can be accessed by NotificationEvent object. Notification Event object has following properties that store information about the notification which was clicked.

E. Voluntary Application Server Identification

(VAPID) for Web Push

VAPID entirely eliminates the need of using FCM when it comes to identifying the endpoints.

Watch this video to understand the Vapid method clearly

When a user signs up with iZooto, a public/private key-set is generated. The key-set is a pair generated using Elliptic Curve Digital Signature Algorithm (ECDSA) over the P-256 curve. This key establishes a continuous identity for the application server and makes sure that the notifications get pushed to the subscribers.

VAPID keys are unique for each iZooto account and remains same for all the domains. The key-set is accessible under the General Settings.

The Safari Way

A. Get Website Push Certificate

Every website is required to create a push certificate through the apple developer account, the developer account provides a simple user interface to create a push certificate for the website.

B. Add Notification Support To The Server

This step deals with taking subscriptions from users and delivering notifications to the subscribers.

1. Take subscription - Every subscription generates a unique ID which can be used as the end-point to deliver notifications. The first step is verifying the user’s current permission for notifications and prompt the user for subscription accordingly as the next step.

Query Permission - This API returns the current status of subscription.

2. Configure web service backend - Once the subscription is completed, following functions can be called to manage device tokens.

/* It's invoked in order to store registrations against the websitePushID in your system. */POST /v1/devices//registrations//* It can be called to log messages in the system. */POST /v1/log/* Whenever a user unsubscribes, the device token can be deleted from the system. */DELETE /v1/devices//registrations/

3. Send push notifications- In the last step, APNS push API is called to deliver notification to the subscriber. Safari notifications operate on payload and hence the notification data is sent along with the push request itself. Following is a snippet of the sample notification request made.