4 ms·

SSE fixes some of the cargo cult practices formed around Websockets.

by Timber-6539 2y ago

whilenot-dev 2y ago
Care to explain a bit more? (otherwise I'd feel like being cargo cultured into SSEs)
- Timber-6539 2y ago
  Going off my personal experience I don't see SSE being mentioned anywhere at all. But I always come across some new shiny web framework/wsgi listing websockets as a feature. The reality is a lot of applications simply do not need bi-directional client-server communication but for some reason this abuse has been adopted as standard.
  - gorjusborg 2y ago
    > The reality is a lot of applications simply do not need bi-directional client-server communication but for some reason this abuse has been adopted as standard. I suspect the treatment as 'standard' is what thread OP is talking about. See my sibling comment in the thread. Unless you absolutely need websocket, SSE is simpler, and due to that, better. I suspect the reason many select websocket over SSE is due to its limitations (connection limit under HTTP/1.1, no client->server sends), but SSE for server->client events and normal HTTP requests for state fetching is better architecturally for bog standard apps in my experience.
gorjusborg 2y ago
I have certainly seen people reach for websockets to just reverse the direction of data flow from server to client. On HTTP/1.1, the main issue people can hit is the max connection limit. This connection limit does not apply when using SSE over HTTP/2+, because server connections are multiplexed onto a single connection. I also prefer starting with SSE where possible, as it is simple conceptually, easy to implement (even from scratch), and doesn't introduce a secondary client to server path. Having that ability (even if unused) tends to create a temptation to use it, and when that happens it introduces a choice of whether to use normal HTTP requests or make an equivalent request over websocket. Using websocket for things HTTP can handle is a mistake, in my opinion, because HTTP is simpler than websocket to fetch state. Of course, if you need websocket, you need it, but there are some that just want to play with it in production or add it to their resume. I suspect that dynamic is what causes the 'cargo culting' you talk about.

SSE fixes some of the cargo cult practices formed around Websockets.

whilenot-dev 2y ago

Care to explain a bit more? (otherwise I'd feel like being cargo cultured into SSEs)

Timber-6539 2y ago
Going off my personal experience I don't see SSE being mentioned anywhere at all. But I always come across some new shiny web framework/wsgi listing websockets as a feature. The reality is a lot of applications simply do not need bi-directional client-server communication but for some reason this abuse has been adopted as standard.
- gorjusborg 2y ago
  > The reality is a lot of applications simply do not need bi-directional client-server communication but for some reason this abuse has been adopted as standard. I suspect the treatment as 'standard' is what thread OP is talking about. See my sibling comment in the thread. Unless you absolutely need websocket, SSE is simpler, and due to that, better. I suspect the reason many select websocket over SSE is due to its limitations (connection limit under HTTP/1.1, no client->server sends), but SSE for server->client events and normal HTTP requests for state fetching is better architecturally for bog standard apps in my experience.

gorjusborg 2y ago

I have certainly seen people reach for websockets to just reverse the direction of data flow from server to client. On HTTP/1.1, the main issue people can hit is the max connection limit. This connection limit does not apply when using SSE over HTTP/2+, because server connections are multiplexed onto a single connection. I also prefer starting with SSE where possible, as it is simple conceptually, easy to implement (even from scratch), and doesn't introduce a secondary client to server path. Having that ability (even if unused) tends to create a temptation to use it, and when that happens it introduces a choice of whether to use normal HTTP requests or make an equivalent request over websocket. Using websocket for things HTTP can handle is a mistake, in my opinion, because HTTP is simpler than websocket to fetch state. Of course, if you need websocket, you need it, but there are some that just want to play with it in production or add it to their resume. I suspect that dynamic is what causes the 'cargo culting' you talk about.