Open
Description
RSocketConnector and RSocketServer can be configured with a SocketAcceptor that handles all requests. A framework can build on this low level mechanism and decide how to route requests internally. However there is no easy way to have multiple frameworks, e.g. rsocket-rpc-java and spring-messaging, side by side in the same application.
Given the existence of the Routing Metadata Extension, RSocket Java could provide a mechanism to delegate requests to one of multiple RSocket handlers depending on the route. This could be as simple as a route prefix that helps to decide which RSocket should handle the request.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Participants
Activity
OlegDokuka commentedon Jan 22, 2021
Drafted a diagram of a possible design of the implementation
MetadataDecoder(note, a requester side should use aMetadataEncoderto encode route in the payload metadataRouteryschimke commentedon Jan 22, 2021
Playing devil's advocate - Isn't this the point of the framework code above rsocket? Should this be part of the base library?
I know it's awkward if rsocket-rpc-java and spring-messaging are peers that are unaware of the other, but seems like something would need to configure how to decide where to delegate calls to. That logic seems likely to be similar to any framework like spring or rsocket-rpc.
No strong opinion here against, just probing.
OlegDokuka commentedon Jan 22, 2021
Actually, this logic is in rsocket-rpc as of now, but, after a few discussions, @bsideup and I ended up that rsocket-router logic should sit in a different place than rpc. Thus it is either should be
rsocket-router-javaorrsocket-javawith submodulersocket-routeryschimke commentedon Jan 22, 2021
Makes sense. So I'd change my argument to be that it shouldn't be that routing has pride of place in rsocket-java. But a module allowing frameworks to coexist, has an attraction.