Hacker News Reader

Comment by szastamasta | Hacker News Reader

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.

View on HN

HTTP headers must be written before the body; so once you start writing the body, you can't switch back to writing headers.

Server-sent events appears to me to just be chunked transfer encoding [0], with the data structured in a particular way (at least from the perspective of the server) in this reference implementation (tl,dr it's a stream):

https://gist.github.com/jareware/aae9748a1873ef8a91e5#file-s...

[0]: https://en.wikipedia.org/wiki/Chunked_transfer_encoding

Maybe I misunderstood your claim, but there is: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Tr...

Which seems to be what you need to send 'headers' after a chunked response.

You understood correctly; I was mis-informed. Today I learned about the "Trailer" header. I'm curious how HTTP clients handle that. A client like window.fetch will resolve with a headers object-- does it include the trailers or not? I'd have to test it out.

More so the issue is the "native" browser client, EventSource [1] is pretty much just url and "withCredentials" (send/don't send cookies)

You can kludge it with fetch(...) and the body stream

1. <https://developer.mozilla.org/en-US/docs/Web/API/EventSource>

SSE comes from a time when browser APIs toward Javascript forced a full download of the response body before it was handed to the Javascript.

With current day APIs, including streaming response bodies in the fetch API, SSE would probably not have been standardized as a separate browser API.

Mind expanding on your experience and how are websockets more reliable than SSE? one of the main benefits of SSE is reliability from running on plain HTTP.

I've done both. One big one is Sse connections will eventually time out, and you WILL have to renegotiate, so there will be a huge latency spike on those events. They are easier in elixir than most pls, but honestly if you're using elixir, you might as well use phoenix's builtin we socket support.

How is this different from websockets? They will eventually close for various reasons, sometimes in not obvious ways.

Not if you send "noop" messages.

In my experience, sse times out way more than ws, even if you are always sending (I was streaming jpegs using sse).

I think it might be your ISP. For example one of my ISPs cut off my SSH connections no matter what I do. They simply dislike hanging SSH connections.

It's just random that your ISP like WebSockets more than long HTTP responses, and it can change in a heartbeat and for most people it will be different. As I said before 99,6% successful networking is an unheard of number for real-time multiplayer games.

I only care about that number, until you proove with hard stats and 350.000 real users from everywhere on the planet that WebSocket has 99,7% success rate, I'm not even going to flinch.

It's not random. Having limited timeouts for http is policy set at often time several layers to prevent certain types of security regressions.

Ok, what security regressions?

I am sure you can figure it out. I'm not bullshitting you.

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.

> If you’re using tokens for auth and don’t want to use session cookies

That sounds like a self-inflicted problem. Even if you’re using tokens, why not store them in a session cookie marked with SameSite=strict, httpOnly, and secure? Seems like it would make everything simpler, unless you’re trying to build some kind of cross-site widget, I guess.

I need to work with more than 1 backend :)

This is such an opaque response, I don't know what else could be said. If you're sending the same token to multiple websites, something feels very wrong with that situation. If it's all the same website, you can have multiple backends "mounted" on different paths, and that won't cause any problems with a SameSite cookie.

Then you need a single point of failure that is handling session validation. Without it part of your app might work even without your sessions storage.

You can store a JWT in a session cookie. You don’t need a SPoF for session validation, if that’s not what you want.

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

> 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.

You can also implement websockets in 5 lines (less, really 1-3 for a basic implementation) without socket.ii. Why are you still using it?

They don't support headers in javascript, that is more a problem with javascript than SSE.

Read my comment below about that.

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

SSE EventSource also has built-in auto-reconnect, and it doesn’t even need to support failover to long polling.

Neither of those being built into a third party websocket library are actually advantages for websocket… they just speak to the additional complexity of websocket. Plus, long polling as a fallback mechanism can only be possible with server side support for both long polling and websocket. Might as well just use SSE at that point.

2 lines vs 5 lines. did you check your payload size after adding socket.io? you added way more than 2 lines.

long polling shouldn’t be needed anymore, and auto reconnect is trivial to implement.

WebSockets are also quite unreliable but Socket IO hides all this from you.

socket.io doesn’t do as much as the bloat warrants. implementing the same features (heartbeats and reconnects) takes minimal code. socket.io was useful when certain browsers didn’t support websockets, now it’s used mostly by people scared of sockets imo

Reply on news.ycombinator.com