How we use and what we expect from the internet is changing: as users we don’t want to sit around and wait for a page to load. WebSockets hail from 2008 and are a communications protocol that opens a bidirectional socket between a server and a client. Server-Sent Events allow the server to push data to the client. On 25th February 2017, Audrey Neveu of Streamdata.io will be comparing WebSockets and Server-Sent Events at Voxxed Days CERN. We asked her what Server-Sent Events are and why they are one of her technologies of choice.
In your talk, you will be comparing web sockets and server-sent events. What is a server-sent event, and when would I want to use them?
Server-Sent Events is a push-technology which appeared 2 years before WebSockets, but it’s much less known about in comparison. Sever-Sent Events are much more lightweight than WebSockets, and are based on HTTP, whereas WebSockets are based on their own protocol. You don’t have to reconfigure your proxy and your load balancer to use Server-Sent Events. It allows you to send data – only text – but you can send data from the server to the client without a lot of code. That’s the main advantage of Server-Sent Events over WebSockets, because WebSockets need a lot of configuration to work.
Why does StreamData.io use Server-Sent Events?
It’s because we know that real time is very important for applications right now. If you’re looking at the most popular applications on the Apple and Google stores at the moment, most of them are based on real time. Its really something that your users are expecting. Otherwise, if you have to push on a refresh button, it’s not the best way to interact with your user. Most of the time, you don’t really need WebSockets. WebSockets have become popular because, I think, before understanding that we can use real time in our applications, we’ve built chat and video games. WebSockets are very useful for chat and video games – they are bidirectional and support binary. But in most applications in our day-to-days lives, it’s mostly the server which needs to send data to the client. Most of the time it’s only text. This is the other reason why we chose this technology – which is much more simple and easier to integrate, and way more efficient in most cases.
So WebSockets support binary and text data, and Server-Sent Events only support text. Will Server-Sent Events ever support binary?
Both technologies are under the W3 specification. They have co-existed for a long time, for 10 years almost. I think they will stay the same because it is a completely different use – for me there is not a need to make chances in the Server-Sent Events specification. As often in programming, first you need to understand what your need really is before choosing a technology. Each one is really useful for different use-cases.
What should developers do/ bring to prepare for the tools in action?
Absolutely nothing! It’s really made so that everyone can understand it – even non-technical people.
To learn more about Server-Sent Events and Websockets, join us at Voxxed Days CERN for Audrey’s talk.