Building a Browser Push Notification Service — Long Polling and the Web Socket protocol
What’s the ideal pattern /design / tech stack for a push notification service (also, what’s a push notification?) (using websocket, also, what’s a websocket?) that would allow efficient usage of resources, be lightning fast, and also scale horizontally? In these series of blogs, lets try to break this down into smaller chunks and answer them individually.
Before we dive deep into the details, lets gets some terminologies clear.
What are websockets / websocket protocol?
`WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection`. Lets try to take the sophistication out from the previous sentence, and understand the basics. WebSocket is simply another communication protocol like HTTP, or TCP. HTTP works in a simple client-request - server-response manner, for example, it could be like the militants talking over a radio, where, the personnel sitting at the base asks for information, only after which the person on the field responds with the answers, and the other way around is not allowed. (You never question your superiors in the army :P)
WebSocket protocol allows both the client (or as we call in this article, the target) and the server to send any piece of information to each other at any point in time, provided the connection is established. Similar to you talking to your friend over a call, where either of you can talk and /or listen, once the call is placed, anytime.
What is a push notification?
As far as this blog is concerned, a push notification is simply some piece of information / data you want to convey to your target client, without the client explicitly asking for it. Like for example, when you open your mail, anytime you get a new mail, you would like to see a popup on the top of the tab that says ‘You have a new mail’. Now here, the browser tab (our client / target) did not ask the backend if you have a new mail. Rather, the backend realized that someone sent you a mail, and now wants to send you this information / notification. This type is what we’re calling push notification here.
The Use Case: Now lets talk of a use case. Say, you have a desktop dashboard. Now, you want to enable push notifications from the backend servers to this desktop UI (which is opened on a browser tab). This is slightly different compared to the usual requirements out of APIs, where the UI (target) makes a specific request to our servers and the data is sent back as a response of it (classic use case of HTTP protocol). For push notifications, however, the client has not made a request, but instead, the backend is the initiator and it said, hey, I want to send this information (notification) that is important for the target (UI) to see right away, like we saw for the new email notification. Lets see how we can enable this.
Push Notification with long polling: Now that we get the peculiarity of this requirement, let us brainstorm about how we can get this done. One simple way could be long polling. Meaning, the target simply sends an HTTP request to the backend. The backend, instead of responding to the request immediately, just keeps it in pending state. Now, only when there is a push notification to be sent to a target, the backend server figures the pending HTTP requests sent by that target and now, sends the push notification as a response. This is actually how the push notifications were handled traditionally. For multiple reasons, in the smart-ass-land, this method is now looked down upon, mostly because of how intensive it turned out to be on the server side.
Push Notification with WebSockets: There’s a better solution possible. Say, how about we just register and persist with the server, the connection aganist the targetID instead? Meaning, the target UI, as soon as is fired up, a connection is made and persisted with the push-notification service. The target, keeps listening over this connection, if there’s any new notification and then processes it accordingly. The target and the push-notification service can both keep polling at effective intervals to make sure the connection is functional for robustness. If the connection is detected dead by the target, it can simply make a new connection request. And if the server detects a dead connection, it simply cleans the connection related objects from it’s memory. This exact philosophy is harvested in the websocket protocol.
How is the WebSocket communication channel created, an example? Imagine this like you are walking up to a bank, and requesting to open a Savings Account, and at the same time, requesting an upgrade for thisnewly created account that allows you to have a credit card as well. The bank will then authenticate your documents, check for your CIBIL score and approve or deny your request accordingly. If approved, an account will be created and a credit card alloted, so you can make transactions over it. Also, if you fail to make transactions for a consecutive period of three months say, your account may be marked dormant and later closed.
How is the WebSocket communication channel actually created? Similarly, for a websocket connection to be established, the target makes an HTTP request to the server backend, with something called an ‘Upgrade’ header set to convey that the client wants to upgrade the communication protocol to WebSocket. The server then checks for the authentication credentials, and accordingly approves the upgrade / denies it (and closes the connections). If the upgrade is approved, the target gets a confirmation after which it can continuously listen over this connection for any new notifications. In addition, there is continuous polling to ensure that the connection has not gone ‘dormant’ or like we call it, it has not become a dead conenction.
In conclusion, for multiple reasons, the websocket connections turn out be efficient in terms of resource consumption on the server side, greatly reducing the costs. The details about the comparison about the ways to enable push notification, can be in itself, another article. But for now, in the following articles, we’ll try to address the challenges faced when developing a websocket server (here).
