There should be created a sample for a Chat like a...

# kotlinx-rpc

[Dumitru Preguza]

There should be created a sample for a Chat like app made on kRPC.
I want to be sure that the pattern would be something like this:

Interface ChatService {
   sendMessage(Message): Unit
   receivedMessages(): Flow<Message> //infinite pulling of messages?
}

[Dumitru Preguza]

I don't want to use Websockets directly, since kRPC is an abstraction over websockets anyway

[Alexander Sysoev]

I think each chat implementation should decide for itself, giving the particular project requirements and goals, how to use our library. I don't see a problem with your approach just from these 4 lines, but it doesn't mean it will suit everyone. Some tutorial may indeed be added later, but we have other priorities now

[Javier]

Probably you can adapt any gRPC chat app tutorial to this library

[Dumitru Preguza]

Of course the chat implementation will differ for everyone

I just did not find this sample for “Infinite receive/send new payload from server” like ws do, which is a more broader topic, this sample could fix arising questions like: is a flow enough or there should be a while loop on the client etc

[Dumitru Preguza]

Well, the kPRC is closer to Kotlin types than gRPC, it’s a little different, however I already did some research

[Javier]

kRPC has already a branch to support gRPC. I don't think this is a "type" problem, but a "concept" problem, and both are "the same".

[Dumitru Preguza]

gRPC operates over HTTP/2 while kRPC is over websockets, it already should have a bit different implementation for streaming purposes

[Dumitru Preguza]

I don't care about gRPC, the support for gRPC is added for people who need it. The idea is the same "Remote Procedure Call", but the transport layer is different etc.

[Alexander Sysoev]

arising questions like: is a flow enough or there should be a while loop on the client etc

Flow by definition is a streaming

[Alexander Sysoev]

gRPC operates over HTTP/2 while kRPC is over websockets, it already should have a bit different implementation for streaming purposes

They both use flows

[Alexander Sysoev]

the transport layer is different etc.

And the idea of an abstract transport is that it doesn't matter what is under the hood - streaming is a streaming

[Dumitru Preguza]

Maybe Kotlin Flows is not what I need, something like a queue is more suitable, I need to push messages from the server to the client. Or a Publish/Subscriber behaviour. Anyway that’s why I asked for samples

[Alexander Sysoev]

Flows exactly suit the case
For more precise approaches we have this proposal https://github.com/Kotlin/kotlinx-rpc/issues/403

[Dumitru Preguza]

I’m watching your video interview that was posted not long ago, I did not know that only you work on the project @Alexander Sysoev

[Alexander Sysoev]

Yep, was so (we did the podcast in February), and since July an intern joined us to work on amongst other things - native support for grpc (and he has some great results already)

[Dumitru Preguza]

I like what you guys do for KMP developers, other things like gRPC I personally do not need at the moment

[Alexander Sysoev]

gRPC will work for KMP too btw 🌚

[Dumitru Preguza]

But I don’t want to deal with protobuff, serialisation, codegen

[Javier]

IMO gRPC with codegen is about not dealing with anything, everything is generated, you only need to write the schema and implement the server part, models and client is totally generated. And the base class/interface with the correct types depending if you are doing one shot or streaming operations is generated too, so basically you only need to think about how to cache that

[Javier]

Not sure how kRPC implementation in KMP will look like, but I don’t think it would need serialization and if it does as the models are generated you don’t need to care about that.

[Dumitru Preguza]

Is generated two times, one for server and once for client?
I think there are more things to deal with, I tried kRPC I think it’s cleaner. I don’t have anything against gRPC but I don’t use it

[Javier]

Depending on the configuration. As kRPC will be its own gRPC implementation to be KMP, probably @Alexander Sysoev can reply you about if it is possible to generate everything at the same time or having configurations to generate all in an independent way.

Usually you want to generate the server in the module A, and the client in the module B.

For example, in an Android application, the production code only care about the client.

[Alexander Sysoev]

The cool think about what we already achieved in KMP gRPC - there are no generated client/servers - only services with @Grpc annotation. So they we feel very simmilar to how kRPC looks now.

[Alexander Sysoev]

But a bit too early for this, we have some working prototypes, and polishing them now

[Javier]

You mean no generation like ksp, right? But I guess there is some FIR or IR generation, no?

[Alexander Sysoev]

There are too modes: proto and proto-less, both just produce services, (the first generates them, the second is written by a user) and then IR plugin does the rest

[Javier]

The proto one generates the services in FIR?

[Javier]

Or it is an independent Gradle task or whatever that generates the files in the build directory?

[Javier]

If it is the second, it should be interesting copying the dataframe approach so passing the schema to a Kotlin object or whatever and get the public API generated in FIR

[Alexander Sysoev]

The proto one generates the services in FIR?

Not for now. Currently it is a protoc plugin (so regular grpc in java dx)
We are thinking of FIR based approach, but a couple of things need to change in IDE and in compiler before that

Or it is an independent Gradle task or whatever that generates the files in the build directory?

yes

If it is the second, it should be interesting copying the dataframe approach so passing the schema to a Kotlin object or whatever and get the public API generated in FIR

Not sure if this can work, though, tbh I have no idea how this dataframe magic works 😅
But I'm talking to people with experience in plugins, to get a better understanding

[Alexander Sysoev]

For FIR approach - you can vote https://youtrack.jetbrains.com/issue/KTIJ-21163, maybe it will speed up things

[Javier]

AFAIK, currently FIR is limited to read Kotlin code, so the dataframe hack is annotating something in Kotlin and passing a file path with the CSV as paran to that annotation, so it is able to generate everything with FIR.

Something like:

@Schema(“some/path”)
class Foo

Then on FIR, it generates all needed, IR does the rest.

[Alexander Sysoev]

currently FIR is limited to read Kotlin code

Actually no, it can modify too, though with restrictions

the dataframe hack is annotating something in Kotlin and passing a file path with the CSV as paran to that annotation

Ohhh, hm, interesting, I'm wondering how they handle incremental compilation there

[Javier]

I was meaning that FIR cannot do anything if there isn’t something annotated, I mean, it cannot read a random file and react to it if you are not annotating some Kotlin code so FIR can act

[Alexander Sysoev]

Oh, yes, sorry, didn't get you there
Yes, that is true

[Javier]

In any case, it looks like the same issue, so probably you can create a common plugin to be shared between any jetbrains project, at the end is reading a file/schema and generate Kotlin code

[Alexander Sysoev]

Yes, that's what I'm researching right now

[Dumitru Preguza]

I like to have my RPC interfaces in the shared KMP module (like a contract), the implementation on server module, and the client just uses this interface from shared module

shared --- service
server --- serviceImpl: service[shared]
client --- service[shared]

no protobuff, no schemas, no code gen, you own your contracts, you own your code, I like simple things

[Dumitru Preguza]

Maybe later I would like something to generate and export / import my services to schemas, to use them on other services written on Golang or something else, but I don't have this requirement right now

[Alexander Sysoev]

no protobuff, no schemas, no code gen, you own your contracts, you own your code, I like simple things

Still possible with gRPC 😄
But I'm getting ahead of myself, I'll showcase it when it's out