Hi! I’m considering using KRPC for a project, but ...

# kotlinx-rpc

[Rafael Diaz]

Hi! I’m considering using KRPC for a project, but I do have a few questions.

1) Are there any examples of using KRPC without Ktor, ideally via HTTP transport instead of web socket?

I guess the question below is not as important, since I can test it out myself once I do the above. But just in case:

2) My backend is JVM Kotlin, with a Compose Multiplatform frontend. Since KRPC has us declare a shared interface along with a client and server implemention, would I able to use KRPC despite the backend being JVM and the frontend KMP?

As a follow up, I was thinking of using virtual threads-based system for the backend, and coroutines-based for the CMP frontend. Would this be doable?

[Rafael Diaz]

Also one more question. Currently Android is not listed as a supported target.

Does that mean Android cannot use KRPC even if its a Kotlin Multiplatform/Compose Multiplatform project? Or is it only for Android-specific non-KMP that cannot use it?

[andylamax]

I am curious how the http transport is expected to behave, especially in scenarios where the erver will be streaming some responses

Does it establish a connection then send an SSE back to the client?

[neworldlt]

2) would I able to use KRPC despite the backend being JVM and the frontend KMP?

Yes, it is possible. I have working solution using separate KMP module where I put all shared declarations common sourceSet. I am not sure if it is recommended way, because I never find a documentation. I used org.jetbrains.kotlinx:kotlinx-rpc-core dep, but despite it having all annotations, compiler plugin still requires client or server, so I put them both.

I am also curious, how RPC could work with HTTP?

[Alexander Sysoev]

1) Are there any examples of using KRPC without Ktor, ideally via HTTP transport instead of web socket?

Not officially

2) would I able to use KRPC despite the backend being JVM and the frontend KMP?

Already answered above, but yes

Currently Android is not listed as a supported target.

It is Jvm, so it is supported y definition, same as you can run any jvm-built library on android. Though I guess people are confused a lot, I'll update docs to state this explicitly

[Alexander Sysoev]

I am curious how the http transport is expected to behave, especially in scenarios where the erver will be streaming some responses

Does it establish a connection then send an SSE back to the client?

@andylamax I would imagine:
• Client streaming/Unary calls - just HTTP requests
• Server streaming - SSE
Would it work with current transport model? I don't know

[Alexander Sysoev]

I used org.jetbrains.kotlinx:kotlinx-rpc-core dep, but despite it having all annotations, compiler plugin still requires client or server, so I put them both.

@neworldlt hmmmmmm, can you give me an example of a compiler error?

[S.]

regarding different transport options: SSE is just a higher level api for http streaming.
grpc typically also leverages http2 which uses multiplexing so many streams can share a single TCP connection

[S.]

but it sounds like krpc's grpc implementation will use websockets as well, just with the grpc protocol?

[S.]

tbh websockets are the reason why I'm not using krpc in my applications. it's an absolute pain to deal with, especially since it's fully internal (e.g. you don't even know when it closed)

[Alexander Sysoev]

but it sounds like krpc's grpc implementation will use websockets as well, just with the grpc protocol?

no, grpc uses platforms grpc runtime libraries. In other words - on jvm under the hood is io:grpc, on native libgrpc, etc. So it is http2

[S.]

ohh I see

[Alexander Sysoev]

(e.g. you don't even know when it closed)

You do, there is session exposed

[Alexander Sysoev]

oh, only on the server*

[S.]

yeah, client would need this more than the server I think 😅

[Alexander Sysoev]

yeahhh, I'll think about that

[S.]

for end devices websockets are just generally annoying but afaik the transport layer is abstracted from the protocol, I definitely want to look into that some time

[neworldlt]

I can agree, websockets on browsers makes annoying hard to solve problems like authentification properly. On some random day I thought, maybe webRTC could be better suited for transport?

[S.]

I never worked with it but the "unreliable" nature of UDP might not be the best fit for a general purpose RPC