3 ms·

Only big downside to this (its WAMP[0] under the hood) from when I implemented this, and ultimately abandoned was the following: - The clients are huge. I shou

Only big downside to this (its WAMP[0] under the hood) from when I implemented this, and ultimately abandoned was the following: - The clients are huge. I should preface I'm a Software Engineer that focuses on the web, so this matters a lot to me. They really need to be run in a web worker if used, (they're 1MB + of JS, and don't tree shake well. They don't export ES Modules either, last I checked). We have real time chat infrastructure for context. Web Socket Support in Workers Can be weird too - 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. Ultimately we did go with an SSE push (from the server) model, and just send individual requests via HTTP Requests. It actually was less load on the server and faster over all (updates were still extremely fast, but no one client was ever pushing to the server more than the server was pushing out to them) [0]: https://wamp-proto.org/ https://wamp-proto.org/

holler 6y 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 6y 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 6y 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 6y 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 6y ago
    Are you limited to HTTP/1.1 for some reason?
jFriedensreich 6y ago
sse is way underestimated. i also found for most applications where some people immediately scream "websockets" (like web chat, some kinds of live updating interfaces) the operational complexity and simplicity of the implementations are unparalleld for sse with http2.

holler 6y 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 6y 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 6y 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 6y 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 6y ago
  Are you limited to HTTP/1.1 for some reason?

jFriedensreich 6y ago

sse is way underestimated. i also found for most applications where some people immediately scream "websockets" (like web chat, some kinds of live updating interfaces) the operational complexity and simplicity of the implementations are unparalleld for sse with http2.