Realtime Push Notifications for Kinto!

Hi reader!

This week, I’m going to introduce the basic concept of my project, “Realtime Push Notifications for Kinto.”

Disclaimer: Monsters, old age, death, SPIDERS, there are already too many things in the world to be scared of, open source projects should not be one of them. So this blog post is my humble dedication to all the new comers out there who are intimidated by the technical stuff or as I like to call it “the alien language”.
I’ll try my best to keep this article as simple and as far from the alien language as possible. All the non-technical people can adore me, and all the technical people can point out my mistakes and tell me what an idiot I am! 🙂

Okay, let’s get started!

First things first!

What are Push Notifications?

Push notification is a type of client-server communication where the request for a given transaction (transmission of data) is initiated by the server, and not the client.

There are generally two scenarios:
1. Pull: The user (client side) requests some sort of data from the web server, and the server responses to the request by providing the desired information.
2. Push: In case of push notifications, the server is initiating the transaction, which is very common in cases where the client has opted for receiving certain timely updates from applications, like getting a live sports score or receiving messages on web chat, or online betting, auctions, etc.

What is a Push API?

Push API (application programming interface, i.e. an interface between different software programs, that facilitates their interaction) enables the user to receive messages pushed to them from a web application server, even when the application is not loaded, or not running in the foreground.

Basic working:
1. Client or the user agent subscribes to certain “channels” in advance. That is, they give their consent for receiving push notifications from a particular web application.
2. When new content is available on these channels, the application server pushes that information to the client.

Simple, right? 🙂

Now, let us look at some of the dreadful technical terminology:
(Oh, how I have hated these terms for the last few days, only to finally understand them and realize that the world is not a cold, harsh place after all! 🙂 )

  • Service worker: Formally, a service worker is a script that is run by your browser in the background, separate from a web page, for features that don’t need a web page or user interactions. They allow access to push notifications and background sync APIs. So, to receive push notifications, a service worker is installed by a web page, which remains active in the background even when the tab is closed.
  • Push subscription: The web page having an active service worker may subscribe to a push service. Each subscription is unique to a service worker. The resulting push subscription includes all the information that the application needs to send a push message:
    1. An endpoint (which is a capability URL; where the data is to be sent) and,
    2. The client’s public key to encrypt the data for safe and authentic transmission.
    NOTE: Each browser has its own unique URL. This way a push message can be sent to a particular person (e.g new message on Facebook).
  • Push message: The entire game is of the app server trying to send data to a web page. This push message is delivered to the service worker associated with the push subscription to which the message was submitted.

Okay, so, now that we know some terminology, we can act cool and proceed further to look at the push workflow. 🙂 Here’s a flowchart of how the things work. Follow it up with the step wise explanation below it.

 

push notiThe entire process or workflow of Push Notification can be explained in a few simple steps:

  1. Request permission for web notification. Having a permission is simply a web page saying, “Hey, I would like to receive realtime notifications from this web application”.
  2. Register a service worker with the WebPush service, to control one or more pages that share the same origin.
  3. Subscribe to push service. The push subscription has an associated endpoint URL and client generated public key which is used in encrypting the push message.
  4. Retrieve the notification URL from the WebPush server. This endpoint URL is where the push messages are received, and then routed to the client that has subscribed for the notifications.
  5. The notification URL and the public-key is sent to our buddy, Kinto. This information is stored at the server, and is used when a push message needs to be sent to a push subscriber.
  6. When a trigger is initiated (such as modification of data) that generates a push message, the Kinto server encrypts the data using the public key and calls the notification URL to notify the client.
  7. Webpush server routes the message to the proper client websocket without the ability to actually read its content.
  8. On the client side, the service worker sets up a push event handler to respond to the push message being received.
  9. The handler may then respond to the push message by firing a system notification that pops up with the pushed message.
  10. The workflow cycle actually ended at point 9, I just wanted to add this point to round it off to 10. 🙂

And just like that, you receive realtime notifications from a web application. *phew*

That’s it from my side for this post. See you next week! 🙂

Cheers!

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s