Hacker News Reader

Comment by skrebbel | Hacker News Reader

> I don't believe that HTTP streaming was designed with this pattern in mind

> server-sent events are a simpler solution

Fwiw Server-Sent Events are a protocol on top of HTTP Streaming.

In fact I'm somewhat surprised that the article doesn't mention it, instead rolling their own SSE alternative that looks (to my non-expert eyes) like a lower level version of the same thing. It seems a bit weird to me to use chunks as a package boundary, I'd worry that that has weird edge cases (eg won't large responses be split into multiple chunks?)

View on HN

I pretty much always prefer SSE over websockets just because of the simplicity end-to-end. It's "just HTTP", so all the HTTP-based tech and tools apply out-of-the-box without any really special configuration that is required for WS. Curl (or even netcat) "just works", no special client. I don't have to do any special CDN configuration to proxy connections or terminate SSL aside from just turning off buffering.

Websockets requires almost a completely new L7 stack and tons of special configuration to handle Upgrade, text or data frames, etc. And once you're out of "HTTP mode" you now have to implement the primitive mechanics of basically everything yourself, like auth, redirects, sessions, etc.

It's why I originally made Tiny SSE which is a purpose-built SSE server written in Rust and programmable with Lua.

https://tinysse.com

https://github.com/benwilber/tinysse

If you only care about events in one direction, it's a perfectly fine solution, but if you need something other than that, things might get awkward using SSE and regular HTTP calls, even with long-lived HTTP connections.

> once you're out of "HTTP mode" you now have to implement the primitive mechanics of basically everything yourself, like auth, redirects, sessions, etc.

WebSockets do support authentication via cookies or custom headers, don't they?

> WebSockets do support authentication via cookies or custom headers, don't they?

It will depend on how the websocket architecture is implemented. A lot of systems will terminate the HTTP connection at the CDN or API gateway and just forward the upgraded TCP socket to the backend without any of the HTTP semantics intact.

Interesting, do you have any examples for that? I haven't used WebSockets in such a context yet but was always curious how it would be exposed to the application servers.

Sure. If you need http header / cookie based auth with websockets, then you need the full http request with all the headers intact. This is the common case or at least something for which it is pretty straight forward to architect for.

Authenticating a websocket is just as easy as authenticating a regular http request. Because it is exactly the same.

>If you only care about events in one direction, it's a perfectly fine solution

i feel like clients sending requests to servers is a pretty well-solved problem with regular http? i can't imagine how that could be the difficult part of the equation.

not if you need bidirectional communication, for example a ping-pong of request/response. That is solved with WS, but hard to do with SSE+requests. The client requests may not even hit the same SSE server depending on your setup. There are workarounds obviously, but it complicates things.

Everything 'just works', yet you needed to create your own server for it which needs scripting support?

IMO 'just works' means Apache suupports it out of the box with a simple config file and you can just start sending messages to client IPs.

"just works" in the sense that this is a complete SSE client application:

    while true; do
        curl example.com/sse | handle-messages.sh
    done

Because it's just text-over-http. This isn't possible with websockets without some kind of custom client and layer 7 protocol stack.

It’s functional, but I wouldn’t say it’s complete without Last-Event-Id handling.

You could do a lobotomized WebSockets implementation that was an extremely thin layer on top of http, similarly to this.

In this way SSE and WebSockets are exactly the same. They are HTTP requests that you keep open. To firewalls and other network equipment both look the same. They look like long lived http requests, because that is what they are.

Because of TCP, large chunks are always split into smaller chunks. It’s just that at the HTTP level we don’t know and don’t see it. UDP forces people into designing their own protocols if the data is a defined package of bytes. Having done some socket coding my impression is web sockets would be good for a high end browser based game, browser based simulations, or maybe a high end trading system. At that point the browser is just a shell/window. As others have pointed out, there are already plenty of alternatives for web applications.

The problem for things like video games and trading is that websockets only support TCP by default. Technologies like WebRTC allow for much faster updates.

I think websockets certainly have their uses. Mostly in systems where SSE isn't available quickly and easily, or when sending a bunch of quick communications one after another as there's no way to know if the browser will pipeline the requests automatically or if it'll set up a whole bunch of requests.

My problem with SSE is that it has a very low connection limit of 6 per domain across the entire browser session.

That's an HTTP 1.1 problem, not SSE. Websockets has the same restriction.

You just use HTTP/2. It's a solved problem.

Reply on news.ycombinator.com