Server-Sent Events: an alternative to WebSockets • Hacker News Board

Re: Server-Sent Events: an alternative to WebSockets

#81

Post by nickjj » Sat, Feb 12, 2022, 5:06 PM UTC

This is why I really really like Hotwire Turbo[0] which is a back-end agnostic way to do fast and partial HTML based page updates over HTTP and it optionally supports broadcasting events with WebSockets (or SSE[1]) only when it makes sense.

So many alternatives to Hotwire want to use WebSockets for everything, even for serving HTML from a page transition that's not broadcast to anyone. I share the same sentiment as the author in that WebSockets have real pitfalls and I'd go even further and say unless used tastefully and sparingly they break the whole ethos of the web.

HTTP is a rock solid protocol and super optimized / well known and easy to scale since it's stateless. I hate the idea of going to a site where after it loads, every little component of the page is updated live under my feet. The web is about giving users control. I think the idea of push based updates like showing notifications and other minor updates are great when used in moderation but SSE can do this. I don't like the direction of some frameworks around wanting to broadcast everything and use WebSockets to serve HTML to 1 client.

I hope in the future Hotwire Turbo alternatives seriously consider using HTTP and SSE as an official transport layer.

[0]: https://hotwired.dev/

[1]: https://twitter.com/dhh/status/1346095619597889536?lang=en

Re: Server-Sent Events: an alternative to WebSockets

#82

Post by coder543 » Sat, Feb 12, 2022, 5:08 PM UTC

jcheng wrote: post #80

coder543 wrote: post #70

Earlier quoted context omitted.

Browsers also limit the number of websocket connections. But, if you're using HTTP/2, as you should be, then the multiplexing means that you can have effectively unlimited SSE connections through a limited number of TCP connections, and those TCP connections will be shared across tabs. (There's one person in this thread who is just ridiculously opposed to HTTP/2, but... HTTP/2 has serious benefits. It wasn't develope…

> Browsers also limit the number of websocket connections True but the limit for websockets these days is in the hundreds, as opposed to 6 for regular HTTP requests.

https://stackoverflow.com/questions/26003756/is-there-a-limi...

It appears to be 30 per domain, not “hundreds”, at least as of the time this answer was written. I didn’t see anything more recent that contradicted this.

In practice, this is unlikely to be problematic unless you’re using multiple websockets per page, but the limit of 6 TCP connections is even less likely to be a problem if you’re using HTTP/2, since those will be shared across tabs, which isn’t the case for the dedicated connection used for each websocket.

Re: Server-Sent Events: an alternative to WebSockets

#83

Post by szastamasta » Sat, Feb 12, 2022, 5:11 PM UTC

jFriedensreich wrote: post #50

szastamasta wrote: post #33

My experience with sse is pretty bad. They are unreliable, don’t support headers and require keep-alive hackery. In my experience WebSockets are so much better. Also ease of use doesn’t really convince me. It’s like 5 lines of code with socket.io to have working websockets, without all the downsides of sse.

sounds like you did not really evaluate both technologies at the heart but only some libraries on top?

Yeah, sorry. In socket.io it’s 2 lines. You need 5 lines with browser APIs :).

You simply get stuff like auto-reconnect and graceful failover to long polling for free when using socket.io

Re: Server-Sent Events: an alternative to WebSockets

#84

Post by szastamasta » Sat, Feb 12, 2022, 5:13 PM UTC

mikojan wrote: post #38

szastamasta wrote: post #33

My experience with sse is pretty bad. They are unreliable, don’t support headers and require keep-alive hackery. In my experience WebSockets are so much better. Also ease of use doesn’t really convince me. It’s like 5 lines of code with socket.io to have working websockets, without all the downsides of sse.

What? How do they not support headers? You have to send "Content-Type: text/event-stream" just to make them work. And you keep the connection alive by sending "Connection: keep-alive" as well. I've never had any issues using SSEs.

I mean you cannot send stuff from client. If you’re using tokens for auth and don’t want to use session cookies, you end with ugly polyfils.

Re: Server-Sent Events: an alternative to WebSockets

#85

Post by JeanMeche » Sat, Feb 12, 2022, 5:16 PM UTC

mikojan wrote: post #38

szastamasta wrote: post #33

My experience with sse is pretty bad. They are unreliable, don’t support headers and require keep-alive hackery. In my experience WebSockets are so much better. Also ease of use doesn’t really convince me. It’s like 5 lines of code with socket.io to have working websockets, without all the downsides of sse.

What? How do they not support headers? You have to send "Content-Type: text/event-stream" just to make them work. And you keep the connection alive by sending "Connection: keep-alive" as well. I've never had any issues using SSEs.

SSE won't work with tokens, see https://stackoverflow.com/questions/28176933/http-authorizat...

Re: Server-Sent Events: an alternative to WebSockets

#86

Post by bullen » Sat, Feb 12, 2022, 5:23 PM UTC

HWR_14 wrote: post #77

bullen wrote: post #16

I made the backend for this MMO on SSE over HTTP/1.1: https://store.steampowered.com/app/486310/Meadow/ We have had a total of 350.000 players over 6 years and the backend out-scales all other multiplayer servers that exist and it's open source: https://github.com/tinspin/fuse You don't need HTTP/2 to make SSE work well. Actually the HTTP/2 TCP head-of-line issue and all the workarounds for that probably make it hard…

Your license makes some sense, but it seems to include a variable perpetual subscription cost via gumroad. Without an account (assuming I found the right site), I have no idea what you would be asking for. I recommend making it a little clearer on the landing page. That's said, it's very cool. Do you have a development blog for Meadow?

Added link in the readme! Thx.

No, no dev log but I'll tell you some things that where incredible during that project:

- I started the fuse project 4 months before I set foot in the Meadow project office (we had like 3 meetings during those 4 months just to touch base on the vision)! This is a VERY good way of making things smooth, you need to give tech/backend/foundation people a head start of atleast 6 months in ANY project.

- We spent ONLY 6 weeks (!!!) implementing the entire games multiplayer features because I was 100% ready for the job after 4 months. Not a single hickup...

- Then for 7 months they finished the game client without me and released without ANY problems (I came back to the office that week and that's when I solved the anti-virus/proxy cacheing/buffering problem!).

I think Meadow is the only MMO in history so far to have ZERO breaking bugs on release (we just had one UTF-8 client bug that we patched after 15 minutes and nobody noticed except the poor person that put a strange character in their name).

Re: Server-Sent Events: an alternative to WebSockets

#87

Post by keredson » Sat, Feb 12, 2022, 5:25 PM UTC

samwillis wrote: post #24

I have used SSEs extensively, I think they are brilliant and massively underused. The one thing I wish they supported was a binary event data type (mixed in with text events), effectively being able to send in my case image data as an event. The only way to do it currently is as a Base64 string.

SSE supports gzip compression, and a gzip-ed base64 is almost as small as the original jpg:

$ ls -l PXL_20210926_231226615.*

-rw-rw-r-- 1 derek derek 8322217 Feb 12 09:20 PXL_20210926_231226615.base64

-rw-rw-r-- 1 derek derek 6296892 Feb 12 09:21 PXL_20210926_231226615.base64.gz

-rw-rw-r-- 1 derek derek 6160600 Oct 3 15:31 PXL_20210926_231226615.jpg

Re: Server-Sent Events: an alternative to WebSockets

#88

Post by bckr » Sat, Feb 12, 2022, 5:26 PM UTC

samwillis wrote: post #75

jtwebman wrote: post #69

Earlier quoted context omitted.

Send an event that tells the browser to request the binary image.

In my case I was aiming for low latency with a dynamically generated image. To send a url to a saved image, I would have to save it first to a location for the browser to download it form. That would add at least 400ms, probably more. Ultimately what I did was run an SSE request and long polling image request in parallel, but that wasn’t ideal as I had to coordinate that on the backend.

I'm curious if you could have kept the image in memory (or in Redis) and served it that way

Re: Server-Sent Events: an alternative to WebSockets

#89

Post by samwillis » Sat, Feb 12, 2022, 5:39 PM UTC

bckr wrote: post #88

samwillis wrote: post #75

Earlier quoted context omitted.

In my case I was aiming for low latency with a dynamically generated image. To send a url to a saved image, I would have to save it first to a location for the browser to download it form. That would add at least 400ms, probably more. Ultimately what I did was run an SSE request and long polling image request in parallel, but that wasn’t ideal as I had to coordinate that on the backend.

I'm curious if you could have kept the image in memory (or in Redis) and served it that way

That’s actually not too far from what we do. The image is created by a backend service with communication (queue and responses) to the front end servers via Redis. However rather than saving the image in its entirety to Redis, it’s streamed via it in chunks using LPUSH and BLPOP.

This lets us then stream the image as a steaming http response from the front end, potentially before the jpg has finished being generated on the backend.

So from the SSE we know the url the image is going to be at before it’s ready, and effectively long poll with a ‘new Image()’.

Re: Server-Sent Events: an alternative to WebSockets

#90

Post by samwillis » Sat, Feb 12, 2022, 5:43 PM UTC

keredson wrote: post #87

samwillis wrote: post #24

I have used SSEs extensively, I think they are brilliant and massively underused. The one thing I wish they supported was a binary event data type (mixed in with text events), effectively being able to send in my case image data as an event. The only way to do it currently is as a Base64 string.

SSE supports gzip compression, and a gzip-ed base64 is almost as small as the original jpg: $ ls -l PXL_20210926_231226615.* -rw-rw-r-- 1 derek derek 8322217 Feb 12 09:20 PXL_20210926_231226615.base64 -rw-rw-r-- 1 derek derek 6296892 Feb 12 09:21 PXL_20210926_231226615.base64.gz -rw-rw-r-- 1 derek derek 6160600 Oct 3 15:31 PXL_20210926_231226615.jpg

Quite true, however from memory Django doesn’t (or didn’t) support gzip on streaming responses and as we host on Heroku we didn’t want to introduce another http server such as Nginx into the Heroku Dyno.

As an aside, Django with Gevent/Gunicorn does SSE well from our experience.