3 ms·

> There's no fall back to a different protocol in a practical sense (yes, the specification does not state it has to be websockets, it just defaults to web sock

by holler 5y ago

> There's no fall back to a different protocol in a practical sense (yes, the specification does not state it has to be websockets, it just defaults to web sockets). Its for all practical purposes, web sockets or bust. Why this matters to me? Because Server Side Events would be a more efficient way to push messages to clients when the total volume of pushes is several factors greater than pulls, from the server side. That is, the server in aggregate is going to push more data to all the clients than any one client is going to push to the server. Therefore, it would have been nice for this to be abstracted around different models for flexibility of architectural approaches. That sounds interesting! I've implemented mqtt in a chat project but have not investigated SSE as a fallback/hybrid approach. Are you only using SSE or hybrid? I guess I need to read more about SSE but I am curious to compare it to websockets/mqtt and learn tradeoffs.

no_wizard 5y ago
I'm using SSE to push from the server to the client. I'm just sending normal HTTP requests to send from the client to the server, as they're much smaller in volume. Its really...simple. SSE streams are unidirectional so you're only listening for incoming messages, never outgoing on the client, conversely, you just broadcast out to your clients over SSE. Just have an HTTP/2 connection makes it even more efficient. Its not great if you need users to have multi-tab workflows (you can only have 6 connections over HTTP 1.1 for a single user), but that has not been an issue for us. There's some logic you can do on the backend to close duplicate connections. When Web Transport hits, I'm hoping we can do SSE on the client as well, and have two separate unidirectional (one for the server to push to the client, one for the client to push to the server) and have SSE both ways, this way we can terminate the streams independently for efficency
- rabbidruster 5y ago
  Websockets seems strictly more efficient than this strange attempt to create your own protocol. Not sure what challenges you've had with websockets, but I can't see how SSE is more efficient. Especially when creating protocols like client -> server where you'd need really custom edge proxy configuratings.
  - no_wizard 5y ago
    Actually it’s not strange at all, we came up with similar architecture that we found our later is much like RAMEN: https://eng.uber.com/real-time-push-platform/ https://eng.uber.com/real-time-push-platform/
- chrisweekly 5y ago
  Are you limited to HTTP/1.1 for some reason?

by holler 5y ago

no_wizard 5y ago

I'm using SSE to push from the server to the client. I'm just sending normal HTTP requests to send from the client to the server, as they're much smaller in volume. Its really...simple. SSE streams are unidirectional so you're only listening for incoming messages, never outgoing on the client, conversely, you just broadcast out to your clients over SSE. Just have an HTTP/2 connection makes it even more efficient. Its not great if you need users to have multi-tab workflows (you can only have 6 connections over HTTP 1.1 for a single user), but that has not been an issue for us. There's some logic you can do on the backend to close duplicate connections. When Web Transport hits, I'm hoping we can do SSE on the client as well, and have two separate unidirectional (one for the server to push to the client, one for the client to push to the server) and have SSE both ways, this way we can terminate the streams independently for efficency

rabbidruster 5y ago
Websockets seems strictly more efficient than this strange attempt to create your own protocol. Not sure what challenges you've had with websockets, but I can't see how SSE is more efficient. Especially when creating protocols like client -> server where you'd need really custom edge proxy configuratings.
- no_wizard 5y ago
  Actually it’s not strange at all, we came up with similar architecture that we found our later is much like RAMEN: https://eng.uber.com/real-time-push-platform/ https://eng.uber.com/real-time-push-platform/
chrisweekly 5y ago
Are you limited to HTTP/1.1 for some reason?