by 
It happens many times during the process of writing a web application that both client and server have to constantly communicate with each other. And even keep a connection open. To achieve that there are several methods available such as WebSocket, Server-Sent Events (SSE) and Ajax polling. In this article, I discuss each of them and provide a use-case on each for better understanding.
Ajax Polling
The first and easiest approach is the Ajax call. In this case, the client (front end application) calls the server (back end application) whenever it needs data. However, there is no way for the server to push data to the client. A way to work around this problem is to implement a polling mechanism.
In the polling mechanism, the client calls the server regularly to get the latest data. In this way, the server does not need to push the data to the client. Since the client requests to the most recent data frequently. The implementation is rather straightforward. For instance, a Javascript timer does the trick.
There is also long polling in which the server does not provide the result to the client immediately. However, it keeps the connection for that request open. And sends the result whenever it’s available.
Ajax polling is useful mainly if no real-time data is needed. One example is the weather app. Since the weather does not change immediately, the client can call the server every X minutes to get the last weather update.
WebSocket
By contrast of the Ajax polling which is unidirectional, WebSocket is bidirectional. This means that a TCP connection is always open between the client and the server. Unless, the communication is disturbed (closing the browser tab, or connection drop).
With WebSocket, both server and client can push and request data in real-time very easily. However, the communication is not over HTTP which is one of the main drawbacks.
One advantages of WebSocket over Server-Sent Events and Ajax Polling is the platform support. WebSocket is supported by many legacy browsers.
WebSocket is very good for chat applications and games where the real-time reaction is critical.
Server-Sent Events
Server-Sent Events (SSE) is the new kid on the block in the world of client/server communication. It’s introduced as a part of HTML 5 standard which is not supported by Internet Explorer. So it is not the best option if your application must support legacy browsers.
SSE has two major differences with WebSocket:
- The communication is unidirectional
- The client/server communication is over HTTP
In SSE an HTTP connection establishes between client and server, similar to Rest API which never closes. Then the server can stream data to the client whenever is needed. But the client cannot communicate with the server over the same connection. The client has to request for any data using the conventional Rest APIs. In other words, SSE is exactly the opposite of the Ajax polling.
If you use HTTP 1.1 you are bound to a maximum eight connections per client. To solve the issue you can easily enforce HTTP in the Nginx or Apache settings.
A common use case for SSE is stock rate changes where the client does not need to communicate with the server.
If you are keen to know about SSE implementation check the following articles:
