I have chosen websockets over sse for quite a few projects because of windows antivirus and firewall that would block sse / long polling in a weird way. No issues with websockets.
It’s not new - but it’s also one of those standard protocols that the industry’s missing out.
In my last job every project that needed to have a one-sided streaming of events, or a very lightweight pub/sub solution that allows clients to receive data (resulting from scheduled heavy background work), either chose polling from the backend or using SignalR. I am not to say SignalR is a bad product but it was an overkill for all projects that used it (but one). I had written an easy wrapper for pub/sub for .NET and published it for everyone in the org and it took you exactly 20 minutes to set it up in your project (given you had a queueing mechanism if you had to go through load balancing, since you don’t know where the client that’s interested in a specific payload was).
The amount of documentation or community knowledge I found for SSE on .NET was basically minimalistic - in the small things that make all the difference - the caveats, the issues and configuration settings needed (we had an issue that the client would not receive a data from the server because it was compressed by IIS). For big organizations that lack standards quality engineers and clone the architecture of other projects without understand how it works, or why they need it (if at all), it’s a real pain to set something like SSE as a standard. I’ve tried and it was barely used. Everyone would rather throw an unneeded bloated library, change the whole way they communicate with their backend and move to websockets - because others already did it. Almost everyone had not known what SSE is, but they all knew what websockets are. The amount of network hog, connectivity issues, lost connections was off the charts.
This is what standards are for. But it’s being missed out. (Websockets is also a standard but it is widely adopted by the industry)
Oh I agree, it doesn’t get used in a lot of places where it would make a lot of sense - while WebSockets get used in a lot of places where it doesn’t make sense.
I have used it in log viewing project of mine and I find it super awesome for simple use cases like that. Way better than bringing all the stuff needed for WebSockets.
I needed something similar for a project I did during my vacation with a couple friends, in my case it was just streaming messages from an IRC channel to display them on top of a video stream. I considered SSE but after seeing the poor language support I decided to just go with HTTP streaming.
Very simple implementation in both the JS and Rust clients, we ran into some issues with caching (both on nginx and client side) like in the post and I think every now and then you’d see two messages clumped together in the JS implementation, probably because they were sent very close to each other, but in our use case it wasn’t such a big deal and fixing it by appending a \n after every message would be trivial if we really wanted to.
SSE is no hyped enough. It’s so simple and it works. It works well with HTTP/2 and is much simpler than WebSocket.
I have chosen websockets over sse for quite a few projects because of windows antivirus and firewall that would block sse / long polling in a weird way. No issues with websockets.
It’s good to see more use of SSE but it’s not new.
It’s not new - but it’s also one of those standard protocols that the industry’s missing out. In my last job every project that needed to have a one-sided streaming of events, or a very lightweight pub/sub solution that allows clients to receive data (resulting from scheduled heavy background work), either chose polling from the backend or using SignalR. I am not to say SignalR is a bad product but it was an overkill for all projects that used it (but one). I had written an easy wrapper for pub/sub for .NET and published it for everyone in the org and it took you exactly 20 minutes to set it up in your project (given you had a queueing mechanism if you had to go through load balancing, since you don’t know where the client that’s interested in a specific payload was). The amount of documentation or community knowledge I found for SSE on .NET was basically minimalistic - in the small things that make all the difference - the caveats, the issues and configuration settings needed (we had an issue that the client would not receive a data from the server because it was compressed by IIS). For big organizations that lack standards quality engineers and clone the architecture of other projects without understand how it works, or why they need it (if at all), it’s a real pain to set something like SSE as a standard. I’ve tried and it was barely used. Everyone would rather throw an unneeded bloated library, change the whole way they communicate with their backend and move to websockets - because others already did it. Almost everyone had not known what SSE is, but they all knew what websockets are. The amount of network hog, connectivity issues, lost connections was off the charts. This is what standards are for. But it’s being missed out. (Websockets is also a standard but it is widely adopted by the industry)
Oh I agree, it doesn’t get used in a lot of places where it would make a lot of sense - while WebSockets get used in a lot of places where it doesn’t make sense.
I have used it in log viewing project of mine and I find it super awesome for simple use cases like that. Way better than bringing all the stuff needed for WebSockets.
SSE is one of my secret weapons, it’s much nicer than Websockets for a ton of use cases. My go-to implementation in Go is bernerdschaefer/eventsource.
[Comment removed by author]
I needed something similar for a project I did during my vacation with a couple friends, in my case it was just streaming messages from an IRC channel to display them on top of a video stream. I considered SSE but after seeing the poor language support I decided to just go with HTTP streaming.
Very simple implementation in both the JS and Rust clients, we ran into some issues with caching (both on nginx and client side) like in the post and I think every now and then you’d see two messages clumped together in the JS implementation, probably because they were sent very close to each other, but in our use case it wasn’t such a big deal and fixing it by appending a \n after every message would be trivial if we really wanted to.
Why would you use server-sent-events rather than a websocket?
It’s considerably simpler, and has built-in affordances for re-connection and event replay.