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