Re: RSocket Followup (post TOC meeting)
Ben Hale <bhale@...>
Is mobile the primary use case today?RSocket’s primary use-case is distributed systems communication. I mentioned the above example as it’s difficult to do that today and you usually need additional components like Socket.io, long-polling, etc, where as with RSocket it is natural. Resumabilty was added for the mobile use-case and today's implementation is warm resumablity where theserver side hasn’t timed out the subscriptions and flushed them. There has been talk to do cold resumabilty where you could have streams that are able to resume when there isn’t a active subscription on the producing side. Rsocket uses client-slide load balancing to achieve this?You could do it with client-client load balancer, or a middle-ware load-balancer that understands RSocket. Steve Gury can provide more context about load-balancing on a large scale. OOC, how much work does cancellation save in practice? Presumably it mostly applies to requests that haven't yet been picked up by their consumers.Depending on what you are doing, it could be lots of work. RSocket provides Reactive Stream semantics across a process boundary. In Reactive Streams there are three ways to terminate a stream: it completes, it errors, or you cancel it. All streams (including request/response) support cancellation to allow efficient cleanup of responder resources. This is essential with interaction models such as streams and subscriptions - you need it to cleanly signal to stop streaming data where the stream doesn’t complete or error. An example how how this works could be a stream of data that has 1,000,000 items, and you want to take a 100 items from it. With ReactiveStreams you can ask for 100 items, and then cancel when you receive them. Before RSocket you could only do this in the same process. With RSocket you can do this between services, even across multiple services it you want (A->B->C……->N). If you use a ReactiveStreams library like RXJava, Reactor-core, Akka-streams, Yarl, etc. all this happens automatically. You basically need to write something like this: ``` Payload p = null; requestStream(p) .limitRequest(100) .subscribe(doSomethingInteresting()); ``` The developer doesn’t need to concern them with back pressure or cancellation but the implementation will use this to create the behavior the developer wants. -Ben |
|