Is there any plan to implement rsocket-rpc within ...

# rsocket

[rocketraman]

Is there any plan to implement rsocket-rpc within the rsocket-kotlin framework? Ideally with some kind of pluggable serialization layer that defaults to kotlinx-serialization.

[Oleg Yukhnevich]

Hey, there is a plan, but what kind of RPC do you want?
Do you want like with rscoket-java-rpc generated from protobuf schemas, or something else?

Here f.e. sample of possible fully kotlin RPC: https://github.com/rsocket/rsocket-kotlin/pull/227

[rocketraman]

Thank you, that looks really interesting, and I'm pretty sure it would work for my use cases. I have no need to define the rpc's in the grpc/protobuf/rsocket-java-rpc style -- I actually much prefer defining the rpc's in code.

Longer term, I would see defining the RPCs as Kotlin interfaces (with particular signature types mapping to the various interaction models under the hood), and using code gen at compile time (via something like KSP) to generate the boiler-plate client/server code. That would make doing RPCs as simple as defining interfaces that use serializable classes in their signatures (along with Flows), along with the responder implementations. The #kvision project does this pretty well, using JSON-RPC as the serialization model under the hood (and with all the attendant limitations of that rpc protocol).

I see that it supports multiple handlers, keyed by the type / serial name of the request, and it uses kotlinx-serialization with both json and protobuf encoding. Great.

I guess back-pressure support on the stream handler is missing right?

[Oleg Yukhnevich]

I would see defining the RPCs as Kotlin interfaces

That was on my plan at some time, but no free time to work on it in near future
You can look at multiplatform chat sample (https://github.com/rsocket/rsocket-kotlin/tree/master/samples/chat) that uses such pattern, but handwritten (api- https://github.com/rsocket/rsocket-kotlin/blob/master/samples/chat/api/src/commonMain/kotlin/MessageApi.kt, client - https://github.com/rsocket/rsocket-kotlin/blob/master/samples/chat/client/src/commonMain/kotlin/MessageApiClient.kt, server - https://github.com/rsocket/rsocket-kotlin/blob/master/samples/chat/server/src/commonMain/kotlin/MessageApi.kt)

back-pressure is implemented - by default (with no strategy) it will request by 64 elements with requesting next 64 elements when 16 elements will be left to be consumed (so to make it more smooth), but also can be customized - https://github.com/rsocket/rsocket-kotlin#reactive-streams-semantics

[Oleg Yukhnevich]

It will be very cool if you will create an issue in repository with expectations, of what will you want from such RPC: features, how customisable it should be, etc
This will also help me to get more feedback, and prioritize it

[rocketraman]

Thank you for that information, and the hand-written interface-based chat example. Very useful.

t will be very cool if you will create an issue in repository with expectations, of what will you want from such RPC: features, how customisable it should be, etc

I will think about it a bit and try to write something up.

[Oleg Yukhnevich]

thx!

[Oleg Yukhnevich]

BTW: do you have some time to write an issue ? 🙂 It will be easier to track if something will change with RPC in rsocket-kotlin

[rocketraman]

I'm gaining experience with rsocket before I presume to create an intelligent issue on this point 🙂

[Oleg Yukhnevich]

even minimal info will be good, as someone can come there, see an issue, and add there use cases
I will create an issue by the end of the week if you will have no time to do it
after it, you will be able to add your use case there 🙂

[rocketraman]

So far, I've based my implementation on the chat sample with a couple of additional extensions to simplify/improve the encoding/decoding process, as well as support the stream-stream interaction.

My implementation is working ok but of course it is boiler-platey (which would be solved by a code generator) and there is no simple solution for the server->client initiated requests, which I would love to see part of the RPC framework for rsocket. It would be a real differentiator over other common RPC frameworks.

[rocketraman]

My first thought is being able to create two interfaces with RPCs: one for client-server RPCs and another for server-client RPCs, and be able to inject and call these in various places in my code. The server-client of course has the complexities of selecting which client to send to as per our other thread.

[Oleg Yukhnevich]

in rsocket-kotlin rpc, in my mind, any RPC will be just some wrapper over RSocket for client, and implementation of it for responder, and as every side has both connection side has requester/responder - server->client requests will be automagically available)

but this is for simple cases, for more complex things we need more use cases to understand, what API we can and should provide

let's create an issue, and will see where it come...

[rocketraman]

implementation of it for responder, and as every side has both connection side has requester/responder - server->client requests will be automagically available)

Not sure what you mean here. Say, I have an RPC interface with some methods. In the current code, it is assumed that the client calls these method, and the server implements them.

How would some code on the server call an RPC method that the client implements?

[Oleg Yukhnevich]

As you now, CoonectionAcceptor can be configured both for client and server now
And it's the same interface there
So for RPC style, let's define that our RPC api will be some interface (which can be implemented to handle requests) tha can be converted to RSocket (responder) and it's implementation that takes RSocket (requester)
And now it has no difference if you will wrap requester on client side or on server side, or provide responder on server or client side - configuration API is almost the same

If I remember correctly, something similar is in rpc sample in PR opened in rsocket-kotlin now

[Oleg Yukhnevich]

For rsocket client and server is only make sense during connection setup
After that, you have pair of requester and responder on both sides, and API of them is the same

[rocketraman]

I think I see what you mean