:tada: We've released the first gRPC KMP dev versi...

# kotlinx-rpc

[Alexander Sysoev]

🎉 We've released the first gRPC KMP dev version with kotlinx.rpc 0.11.0-grpc-185!
TL;DR:
• Most gRPC core features are now available on JVM, Android, and native targets
• KMP Protobuf implementation included
• This is a dev release — APIs are not yet stable
• A stabilization roadmap and plans for the main release are coming soon
• For a smooth developer experience, the KEFS plugin is currently required. More details are available in the documentation.
Try it out now K
• Get Started with gRPC
• Release notes

[S.]

Looks amazing, can't wait to try it out.
I have one question though, is the grpc connection still based on a websocket?

[Alexander Sysoev]

No, gRPC uses HTTP/2
We didn't reinvent the whole thing here. Instead, we created an easy-to-use out-of-the-box wrapper for platform implementations of gRPC. So on JVM/Android it is grpc-java, on K/Native it is grpc-core. We only generate code and wire it up to the platforms' protocol implementation

[S.]

I see, that makes sense, thanks.
that was my main problem with krpc before, websockets can be difficult to deal with, especially for frontend apps

[Vivek Modi]

Hey Alexander, thanks for the update! Just to confirm, does this support the Web target yet, or is that planned for the future?

[S.]

I suppose not yet https://kotlin.github.io/kotlinx-rpc/grpc-limitations.html#platform-support

[Vivek Modi]

Thanks Dominik.

[Alexander Sysoev]

Web target is a bit of a hassle with gRPC. They have a separate protocol for, it needs transcoding, it has streaming limitations, and some other issues. So we decided to ship it later. It is on the table

[phldavies]

Is/will it be possible to use the kotlin-multiplatform or grpc-kotlin-multiplatform protoc plugins independently from kotlinx-rpc?

[Alexander Sysoev]

@phldavies we are in discussions about that with the libraries team. If it is not hard for you, I'd ask you to file an issue on GH with a small description of why you'd like that

[Javier]

gRPC implementation does not use a compiler plugin, right?

[Alexander Sysoev]

It does
We have diagnostics and some generated code with the compiler plugin, that's why KEFS is a requirement

[Alexander Sysoev]

https://kotlin.github.io/kotlinx-rpc/grpc-codegen.html#grpc-what-compiler-plugin-adds

[gpopides]

is the library drop in replacement to https://github.com/grpc/grpc-kotlin (assuming stable) for the JVM?

I will try to use it in our services to see the behaviour

[Alexander Sysoev]

Intended to be, yes
Though, there is no full feature parity for now, we are working towards it

[Alexander Sysoev]

Let me know on any issues you may face!

[Callum Parton (ctparton)]

Amazing work 🚀

[gpopides]

i started looking into it and noticed that (also in the docs) the generated functions are PascalCased. Is this configurable? Ideally we would generate the files and implement the new interface with the same methods

[Alexander Sysoev]

@gpopides not configurable now, we did the same as grpc-java. We are thinking of adding a configuration for naming.
Do you only need to preserve method names? What about service/message/field names?

[gpopides]

to be honest its not a big problem, its just the generated files "violate" kotlin standards too :

here intellij complains for it for example.

Regarding message name, same. Grpc kotlin generates them as request while rpc kotlin generates them as message Its a minor renaming which im okay with doing

[Uli Bubenheimer]

The new grpc release looks exciting for many reasons. Love the native kotlinx.serialization support, eliminating triple marshalling concerns (proto wire format-Java-Kotlin proto translations-Kotlin business objects).