Support gRPC

[Mr3zee]

Describe the solution you'd like
Full KMP support for gRPC protocol via kotlinx.rpc

This is a huge topic, so the support will be rolled out gradually, I'll keep this issue updated for the news

[honzamalousek]

Any update or estimation when gRPC will be supported? :)

[Mr3zee]

Hi! No exacts timings, but it is in the development

[Joehzd]

hi,Can the client independently support receiving callbacks from the server-side grpc that already exists?

[Mr3zee]

@Joehzd I don't see any reasons why not

[AnwarShahriar]

Any estimate on when we might see an alpha?

[Mr3zee]

Hey! I wanted to share it this week, but everyone is on vacation, so it'll appear somewhere after holidays now

[JavierSegoviaCordoba]

@Mr3zee is it published to some snapshot or dev repository like Kotlin does?

[Mr3zee]

Nope, it is in grpc-jvm branch
It will be available in the dev repo when published

[JavierSegoviaCordoba]

I have seen that the branch has been deleted and the PR closed 👀

[Mr3zee]

@JavierSegoviaCordoba, yes, thanks for noticing. I'm preparing release infra for gRPC

Releases will be published from the grpc-release branch and dev branch will now be just grpc instead of grpc-jvm. I'll post more news after first dev release.

[Mr3zee]

Update on the matter:
With 0.5.0 release, we've added dev versions of gRPC available to try out:
https://kotlin.github.io/kotlinx-rpc/grpc-configuration.html

The plan is somewhat along these lines (NOT by priority):

• Main goal is KMP support, however it would work internally.
• Probably over time we will move from Java protoc generation and replace it with ours for the sake of easier maintenance and implementation. We'll see how it goes
• All (or almost all) features of gRPC are on track (streams, extensions, etc)
• Compiler plugin support in IDE (additional codegen, QoL inspections, etc)
• Easier project setup
• No .proto services (aka Kotlin-first). No sure about this one, but we do have it in mind.
• Ktor Plugin

No ETAs, but dev build will be updated probably more frequently than the main lib, and sometime when we are satisfied with its stability - we'll merge it into the main

Please, post and questions and feedback. Is it bad, poor UX, or maybe you like something there, or have any ideas - we'll try to make it better, and any changes can take place, so that the resulting lib is easy and nice to use.

[JavierSegoviaCordoba]

No .proto services (aka Kotlin-first). No sure about this one, but we do have it in mind.

This wouldn't mean that you would remove the .proto generation, right?

In an ideal world, I want to have proto files and codegen everything in all stacks with a compiler plugin in FIR as Dataframe does now. Even if it is KMP, it is possible KMP is not used on another stack so having the schemas as the source of truth like GraphQL or SqlDelight does is really nice.