Real-time web application: What're the different ways to play with live/real data
Sandeep Rastogi
Solution Architect - AWS, Azure? Cloud Certified, Microsoft Certified Professional(MCP?), Microsoft Specialist?, CSM?, ITIL?, LowCode?
Recently I have been curious about the best way to implement a?real-time web application. That is an application containing one or more components that automatically update, in real-time, reacting to some external event. Building a real-time web application is challenging, as we need to know how we will send our latest (real-time) data from server to client more efficient way and with low latency, the reason this research has made me more curious as I was working on a recent project where we need to wait for the background process (having back and forth backend external API calls) to complete/update the status and notify to the user based on the outcome.
There are various techniques to retrieve real-time data from the server:
Client pull — client asks the server for updates at certain regular intervals
Server push —?server is proactively pushing updates to the client (reverse of client pull)
Let’s take a simple use case to compare the above technologies and choose the right one.
There are so many use cases that we could think of for real-time web applications and a few of them are here for your reference point.
Polling is a technique by which the client asks the server for new data regularly.
Short polling (client pull)
Short polling?is an AJAX-based timer that calls at fixed delays
The simplest way to get new information from the server is periodic polling. That is, regular requests to the server: “Hello, I’m here, do you have any information for me?”. For example, once every 10 seconds.
That works, but there are downsides:
So, if we’re talking about a very small service, the approach may be viable, but generally, it needs improvement.
export default {
name: 'PollingOutcome'
data() {
return {
polling: null
}
},
methods: {
async pollData() {
this.polling = setInterval(() => {
this.pollingOutcome()
}, 3000) // polling every 3 secs
async pollingOutcome(){
this.$store.dispatch('GetEndpoint');
if(this.getStatus === 'Done'){
clearInterval(this.polling); // destroy polling
}
},
async getRealTimeData()
{
this.pollData();
}
},
beforeDestroy() {
clearInterval(this.polling)
}
};
Long polling (client pull)
Long polling is the simplest way of having a persistent connection with the server, that doesn’t use any specific protocol like WebSocket or Server-Sent Events. It is a much better way to poll the server instead of using short polling.
This situation, where the browser has sent a request and keeps a pending connection with the server, is standard for this method. Only when a message is delivered, the connection is closed and re-established.
The flow:
If the connection is lost, because of, say, a network error, the browser immediately sends a new request.
Server should be ok with many pending connections?
Long polling is much more resource intensive on servers whereas WebSockets have an extremely lightweight footprint on servers. The maximum number of connections a web application may make is limited by each web browser. This implies that the load time and performance of your application may suffer as a result.
The server architecture must be able to work with many pending connections.
Certain server architectures run one process per connection, resulting in there being as many processes as there are connections, while each process consumes quite a bit of memory. So, too many connections will just consume it all
There are a few more issues to consider:
Headers Overhead
Connection Establishment
Maximal Latency
Performance Degradation
Timeouts
Multiplexing
You can read about more real-world challenges?here.
When to use
Long polling works great in situations when messages are rare.
subscribe: (callback) => {
const pollUserEvents = () => {
$.ajax({
method: 'GET',
url: 'https://localhost:8080/githubEvents',
success: (data) => {
callback(data) // process the data
},
complete: () => {
pollUserEvents();
},
timeout: 30000
})
}
pollUserEvents()
}
WebSockets (server push)
A WebSocket is a helpful alternative to lengthy/long polling in HTML5. A WebSocket is a technology that allows users to communicate in full-duplex over a single TCP connection. The WebSocket protocol allows for more interaction between a browser and a website, allowing for live content and removing the need for long polling cycles.
This is ideal for real-time apps since, after the initial HTTP handshake, a single WebSocket connection can handle all of the messages for a single session, without any further handshakes. When the session finishes, the connection should be closed as part of the clean-up.
领英推荐
Because WebSocket provides a full-duplex, bi-directional communication channel, the server can send messages to the client, and both can send messages at the same time. This makes two-way, multi-user real-time apps such as chat rooms possible and performant. WebSockets can transmit binary data and UTF-8 meaning that apps can support sending plain text and binary formats such as images and video.
$(function () {
// if user is running mozilla then use it's built-in WebSocket
window.WebSocket = window.WebSocket || window.MozWebSocket;
const connection = new WebSocket('ws://localhost:8080/githubEvents');
connection.onopen = function () {
// connection is opened and ready to use
};
connection.onerror = function (error) {
// an error occurred when sending/receiving data
};
connection.onmessage = function (message) {
try {
const githubEvent = JSON.parse(message.data);
} catch (e) {
console.log('This doesn\'t look like a valid JSON: '+ message.data);
return;
}
// handle incoming message
};
});
What is wrong with WebSockets
Two-way channels and low latency are extremely good features. Why bother looking further?
WebSockets have one major drawback:?they do not work on top of HTTP, at least not fully. They require their own TCP connection. They use HTTP only to establish the connection, but then upgrade it to a standalone TCP connection on top of which the WebSocket protocol can be used.
This may not seem a big deal, however, it means that?WebSockets cannot benefit from any HTTP feature but that doesn't mean that you can not enhance further.
As mentioned above, there are a number of libraries that are popular WebSockets-based libraries like Socket.IO which solve the Fallback to HTTP and support for reconnection.
Server-Sent Events (server push)
Server-Sent Events?enable the server to send low-latency push events to the client, at any time. They use a very simple protocol that is?part of the HTML Standard?and?supported by every browser.
Unlike WebSockets,?Server-sent Events flow only one way: from the server to the client. This makes them unsuitable for a very specific set of applications, that is, those that require a communication channel that is?both two-way and low latency, like real-time games. However, this trade-off is also their major advantage over WebSockets, because being?one-way,?Server-Sent Events work seamlessly on top of HTTP, without requiring a custom protocol. This gives them automatic access to all of HTTP’s features, such as compression or HTTP/2 multiplexing, making them a very convenient choice for the majority of real-time applications, where the bulk of the data is sent from the server, and where a slight overhead in requests, due to HTTP headers, is acceptable.
The protocol is very simple. It uses the?text/event-stream?Content-Type and messages of the form:
In other words. Server-Sent Events (SSE) are based on Server-Sent DOM Events. Browsers can subscribe to a stream of events generated by a server using the EventSource interface, receiving updates whenever a new event occurs. EventSource accepts an HTTP event stream connection from a specific URL and keeps the connection open while retrieving available data. Server-sent events are pushed (rather than pulled, or requested) from a server to a browser.
Server-Sent Event is a standard describing how servers can maintain data transmission to clients after an initial client connection has been established. It provides a memory-efficient implementation of XHR streaming. Unlike a raw XHR connection, which buffers the entire received response until the connection drops, an SSE connection can discard processed messages without accumulating all of them in memory.
Summary of key Server-Sent Events Features
SERVER-SENT EVENTS ADVANTAGES:
SERVER-SENT EVENTS DISADVANTAGES:
What is the difference between WebSockets and Server-Sent Events?
The following table provides a quick summary of the key differences between WebSockets and Server-Sent Events.
WebSockets
Server-Sent Events
Should I use WebSockets or Server-Sent Events?
Which technology to use depends on your use case. In this section, we will look at suitable use cases for both.
When to use WebSockets
WebSockets are more complex and demanding than SSE and require a bit of developer input up front. For this investment, you gain a full-duplex TCP connection that is useful for a wide range of application scenarios. For example, WebSockets are preferable for use cases such as?multiplayer collaboration?and?chat apps.
Why use Server-Sent Events over WebSockets?
Server-Sent Event is a good?alternative to WebSockets?for simple real-time use cases that only require one-way communication (from server to client).
Ideal use cases of SSE:
Keep in Mind:
To be continued...
References: