Push Notifications using WebSocket with Spring Boot and React(Part-1)
A few days back, I had the opportunity to integrate WebSocket with Spring Boot and React to push notifications to the client. In this series, I am going to share my learnings and experience during my WebSocket integration journey.
In part 1, I will talk about the definition of the WebSocket— What is it actually? How does it work? And How is it beneficial for specific use cases?
What is WebSocket?
WebSocket is a full-duplex, bi-directional, persistent connection between server and client(i.e. Web Browser). Persistent connection means once the connection is established between server and client, the connection stays open until either end tries to close it. It is different from the HTTP protocol in a way that in HTTP protocol connection stays alive till the response comes back to the client. So, in every request-response cycle, there is a new connection in the HTTP protocol.
Previous Alternatives?
Well, the main purpose of the WebSocket is to provide the user with a real-time experience while using the application. Traditionally, this real-time experience is provided with the help of 3 techniques.
Traditional Polling/Short Polling
In this technique, the client keeps sending HTTP requests to the server in an interval for the updated data. After getting the response, the client updates the page. This technique works perfectly for the scenarios where data need not be sent as soon as possible.
The problem with this technique is that there is no specific time for data to be generated and hence you might end up calling unnecessary API calls.
Long Polling
In Long Polling, the server holds the request for a certain period of time sent by the client until there is no data to send in response. The server gives a response as soon as there is data to send. After getting the response, the client will send the request again.
In this technique, threads for accepting the requests might exhaust and the server might end up discarding the following requests.
HTTP streaming
Unlike Long Polling, in HTTP streaming, the connection stays open even after sending the response back to the client. Using the same connection, the server can send further data whenever possible. In this way, there is no need for polling.
The problem is that streaming is still encapsulated in HTTP messages so proxy servers may buffer the responses and message delivery latency will increase.
How does WebSocket work?
Initial Handshake
At the initial stage of the WebSocket connection, a handshake is performed between the server and the client to ensure that they both support the protocol and establish the connection. As we can see in Fig 1, the initial handshake is performed using the HTTP protocol to request a protocol upgrade(or in this case a protocol switch) to which the server can respond with HTTP status 101 (switching protocols) if it agrees. Assuming the handshake succeeds, the TCP socket underlying the HTTP upgrade request remains open and both client and server can use it to send messages to each other at any time. None needs to request other for data but this option is also open to use if anyone needs to. Whenever any event occurs, one can acknowledge it to the other without the need to wait for the acknowledgment. In short, WebSocket enables event-driven data transfer between the server and the client.
Sub-protocol
WebSocket is basically a thin layer on top of TCP which converts a stream of bytes to a stream of messages(binary or text). In HTTP protocol, there is enough information to know how to process or route a request, like action verbs(POST, PUT, DELETE, etc), different URLs for specific actions. But in WebSocket, there is only one URL for the initial handshake and after that, all messages are transferred using the established socket connection. There is not enough information in the message on how to process or route it. In a nutshell, WebSocket is a low-level protocol compared to HTTP which is an application-level protocol.
For the above reasons, WebSocket has the flexibility to specify sub-protocols that are application-level like HTTP. During the initial handshake, the client can specify the sub-protocol to use in the Sec-WebSocket-Protocol header. After agreeing on this sub-protocol, both ends can continue exchanging data using the specified sub-protocol.
However, this header is not mandatory to use if there is no requirement to support clients with different sub-protocols on the server-side. Even if it is not used, there should be a default messaging format for the client and server to communicate properly. Spring Framework provides support for using STOMP messaging protocol which is an application-level protocol.
When should we use WebSocket?
The best fit for WebSocket is where the client and server need to exchange events or data with low latency and high frequency like any real-time web application as follows:
- Finance/Stock market
- Multiplayer gaming
- Collaborative tools(coding/drawing)
- Chat
- Real-time dashboard
- Real-time push notification etc.
Once the connection is established, both the client and the server can send and receive messages in real-time. WebSockets allow for a higher amount of efficiency compared to REST because they do not require the HTTP request/response overhead for each message sent and received.
That’s all in part-1 of the WebSocket series. In the next part, I will talk about integration and scaling WebSocket in a Spring Boot and React environment for push notification.
