What are Push Notifications?
A notification is a message that pops up on the user’s device. Notifications can be triggered locally by an open application, or they can be “pushed” from the server to the user even when the app is not running. They allow your users to opt-in to timely updates and allow you to effectively re-engage users with customised content.
Why WebSockets?
Every time I worked on a project where we had to implement any kind of a “real-time” component, usually a chat or an event feed, the word WebSockets started to circulate. Though, most people use them because they either aren’t aware of the alternatives, or they blindly follow other people’s examples.
WebSockets enable the server and client to send messages to each other at any time, after a connection is established, without an explicit request by one or the other. This is in contrast to HTTP, which is traditionally associated with the challenge-response principle — where to get data one has to explicitly request it. In more technical terms, WebSockets enable a full-duplex connection between the client and the server.
In a challenge-response system, there is no way for clients to know when new data is available for them (except by asking the server periodically —polling or long polling), with Websockets the server can push new data at any time which makes them the better candidate for “real-time” applications.
It’s important to note that WebSockets convert their HTTP connection to a WebSocket connection. In other words, a WebSocket connection uses HTTP only to do the initial handshake (for authorization and authentification), after which the TCP connection is utilized to send data via its own protocol (hybd).
WebSockets are a part of the HTML5 spec and they are supported by all modern browsers (meaning, there is a JS API to use them natively in the browser). They provide a mechanism to detect dropped (disconnected) clients and can handle up to 1024 connections per browser, though they aren’t compatible with most load balancers out-of-the-box and have no re-connection handling mechanism.
The most common example for WebSockets is either a chat or push notifications. They can be used for those applications, but present an overkill solution to the problem, since in those applications only the server needs to push data to the clients, and not the other way around — only a half-duplex connection is needed.
Good reference are: