rsocket
rsocket copied to clipboard
rsocket
The successor of websocket is being worked on
https://wicg.github.io/web-transport/
They will bring QUIC (http3 UDP) to the successor of websocket. It's API could also have breaking change that would allow for improvements: (it will have fallback mechanisms over http2 and 1.1 for when UDP is unsupported)
I am using RSocket in production and it is objectively the actual current successor to websocket. To me the most important features are: 1) The ability to bidirectionally do: FireAndForget (0 to one) RequestResponse (one to one) RequestStream (one to many) RequestChannel (many to many)
This expressivity gain over raw websocket allow to have: A consistent api instead of reimplementing ourself a worse rsocket like in webscoket. And to easily build rich real-time logics.
And 2) Bring reactive streams (and backpressure) over the network.
I really think that you (the architects of rsocket) should suggest improvements to the web-transport protocol https://github.com/wicg/web-transport/blob/master/explainer.md You should give them your expertise, Show them the importance and how to design a proper API / spec for 1) It would really be accidental mediocrity if this new protocol didn't offer the expressive power of 1) Also it is the time where you could bring breaking changes to things that would be currently suboptimal in rsocket.
As for bringing 2) I am not knowledgeable enough to see whether they could bring 1) without the need of a client side reactive streams implementation. They might need to bring rxjava inside the browser. Not having backpressure and other reactive streams features over the network would be sad for web-transport but at least rsocket 2.0 could bring said support over web-transport, as a superset. But if they couldn't bring 1) (in the case where 2) would be necessary) then it would be a big disappointment for the web. It's all about democratizing to developers the best technology. Rsocket objectively is but is not (at least yet) a web standard. If web-transport didn't bring 2) nor 1) we (the knowledgeable dev minority) would still benefit from a future rsocket over web transport that would bring websocket improvements and QUIC support. But for everybody else they would still need to reimplement those behaviors (fire and forget, etc) themelseves leading to unemcapsulated complexity, suboptimal performance and APIs and non standardization therefore reinventing a custom API on each project like websocket real-time webapps do...
Pretty late in catching this, but it seems worth exploring if there's any opportunity here if it's not too late to do so.
cc @nebhale @stevegury Perhaps we could discuss this and explore more.
I've queued this up to read the protocol.
They might need to bring RxJava inside the browser.
I believe @jhusain is likely the the best to comment on this. https://github.com/tc39/proposal-observable is an example of where this has been explored.
I dont know how to proceed with that. In any scenario, we will be able to use that API as RSocket transport and bring our semantic in.
