Have you ever heard of Streaming Data?
Streaming data is a mechanism used to keep data up to date. Streaming Data is mainly used to make applications with real-time experiences, such as social network or any application that necessitates a real time notification system, video games, chat applications, etc. It concerns all kind of data such as online purchases, localization services, log files, etc. If some companies first begin with simple applications, such as emitting alarms when thresholds are exceeded, it is interesting to go further, such as applying machine learning algorithms. Generally speaking, Streaming Data provides companies with information which delivers enriching insights, and improves their visibility into many aspects of their business and customers activity, among them : activity on website, geolocation, service usages, etc.
How does it work?
Now that you have a better understanding of what is behind Streaming Data, let’s have a look at the methods that exist and the differences between them.
One of the oldest and most popular method that has been used is “polling”. Polling consists of sending the same request over and over again to the server at a fixed rate to have real time data. The limit of this method is obviously that we are going to have many useless requests that have empty responses or that have the same response over and over again (because nothing in the server has changed in the meantime). In this process, we will waste significant resources such as CPU (Central Processing Unit) and bandwidth to transfer useless data. Moreover, this effect will be multiplied by the number of clients accessing the data and, therefore, waste is experienced by each client device.
Then Long Polling appeared. In this case the client requests information from the server in a similar way to a regular polling method, but the server doesn’t respond until some new information is available. Once the response is sent the client immediately send another request and so on. That resolves some part of the problem but still necessitate many requests to keep the real time data effect.
The emergence of new alternatives
From this limit, two new solutions were developed : WebSockets and Server Sent Events. What are the differences between them? And which one should you use according to your project?
On the other hand, Server-sent events (SSE) is a technology where a browser receives automatic updates from a server via HTTP connection.
Therefore, the main advantage of Websockets is that the connection is bidirectional so the client and the server can send each other data. It handles also both text and binary messages and support all the browsers while the Server Sent Events handles only text and only supports the modern browsers. Nevertheless, Server Sent Events can handle lost connections, and according to a performance test in different browsers it appears much faster than WebSockets. Despite the fact that WebSockets is older, it also includes larger areas of use and this is why it had received greater attention and adoption while the Server Sent Events stays unfamiliar for many.
However, if each solution has its advantages and limits, you should pick up your tool and method according to the goal of your application. For instance, if you want to make a chat, a video game, a messaging app or any interactive experience, WebSockets will be the method you should use since it allows bidirectional dialogues between the server and the client. However if you just want to send text data from server to clients, to implement a real time dashboards for example, Server Sent Events will be the most appropriated solution since it is faster and easier to implement for such use case.
You are interested in Streaming Data? You like to learn more about it? Contact us! We will be pleased to have a chat with you!Contact us !