backtalk
backtalk copied to clipboard
lord
Websocket support
Just curious to know, if you're planning to support websockets instead of (or in addition to) SSE?
Not currently planned, since at least as of two weeks ago, there's no good tokio-based websockets library for Rust that I could find. That said, if one appears, I'll definitely be adding it — it shouldn't even require an API change for users of Backtalk. Also, once HTTP/2 support lands for Backtalk, or even if you stick it behind a HTTP/2 reverse proxy, my understanding is that the overhead from placing new requests to the server and the per-domain browser limits on number of requests should also stop becoming a problem, mitigating the major reasons to prefer websockets over SSE.
I'll keep this open as a reminder to check for tokio websocket libraries ever now and then. There's currently https://github.com/snapview/tokio-tungstenite, but it doesn't quite look ready maybe? We'd also want to make sure there was a way to pass an upgrade request from the hyper server to whatever websocket library we end up using, so that we don't have to host multiple servers on different ports.
Ok cool - I've written very simple layer in nodejs and react/redux for client side where all the comms are done over websocket. There's no REST API, all the "event" requests go to central registry and registry service invokes all registered services with the payload. Then at a later point in time individual services send data back to central registry which pushes data with event identifier to web socket client(or clients). And on client side these events are mapped to different functionalities. This model worked very well and I was looking around for doing something similar on server side with rust. This requires 2 way comms though. I'll watch out for websocket support and how this library shapes going forward.