3 ms·

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

> 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?)

notjoemama 2y ago
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.
- jeroenhd 2y ago
  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.
benwilber0 2y ago
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://tinysse.com https://github.com/benwilber/tinysse https://github.com/benwilber/tinysse
- lxgr 2y ago
  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?
  - VWWHFSfQ 2y ago
    > 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.
    - lxgr 2y ago
      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.
    - Sammi 2y ago
      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.
  - notatoad 2y ago
    >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.
ranger_danger 2y ago
My problem with SSE is that it has a very low connection limit of 6 per domain across the entire browser session.
- VWWHFSfQ 2y ago
  That's an HTTP 1.1 problem, not SSE. Websockets has the same restriction.
- CharlieDigital 2y ago
  You just use HTTP/2. It's a solved problem.

notjoemama 2y ago

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.

jeroenhd 2y ago
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.

benwilber0 2y ago

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://tinysse.com https://github.com/benwilber/tinysse https://github.com/benwilber/tinysse

lxgr 2y ago
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?
- VWWHFSfQ 2y ago
  > 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.
  - lxgr 2y ago
    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.
  - Sammi 2y ago
    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.
- notatoad 2y ago
  >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.

ranger_danger 2y ago

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

VWWHFSfQ 2y ago
That's an HTTP 1.1 problem, not SSE. Websockets has the same restriction.
CharlieDigital 2y ago
You just use HTTP/2. It's a solved problem.