kotlinx-rpc
kotlinx-rpc copied to clipboard
Kotlin
Support gRPC
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
hi,Can the client independently support receiving callbacks from the server-side grpc that already exists?
Hey! I wanted to share it this week, but everyone is on vacation, so it'll appear somewhere after holidays now
@Mr3zee is it published to some snapshot or dev repository like Kotlin does?
Nope, it is in grpc-jvm branch It will be available in the dev repo when published
I have seen that the branch has been deleted and the PR closed 👀
@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.
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.
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.
This wouldn't mean that you would remove the .proto generation, right?
Yes, it would be just an option
Yeah, would be great to have them coupled, so there is no need to modify two files and/or run generation for every step. But I try to stay more realistic now, I only got two hands 😅 . Maybe if everything else works perfectly, we will focus on that
I think that drop .proto would be a mistake, even if it's not required on initial stage for someone's project, eventually it could be a large blocker if project got a client which is not written on Kotlin, or even written, but it's third-party and cannot share code.
I love declaring it with Kotlin in a general sense, but our experience with similar bindings for native code (using Djinni) shows, that having an independent binding language, like .proto in case of gRPC, is a great advantage in terms of adoption for different languages. It also helps a lot with validation, diff check unlike having source of truth in Kotlin
So my opinion that lack of .proto support for services for kotlin-grpc would put it to disadvantage at least for some use cases
Hello, do I understand correctly that, for now, KotlinRPC with gRPC only supports JVM projects and cannot be used with Kotlin Multiplatform?
@luca992 the work is planned to start in summer this year, we'll see from there
It would be great if this would somehow be compatible with the new swift GRPC https://www.swift.org/blog/grpc-swift-2/
@Siedlerchr what do you mean by compatible? It all the same protocol, it's compatible by definition
in current dev builds - no. iOS is supported in a branch, and will be released in dev builds some time later
in current dev builds - no. iOS is supported in a branch, and will be released in dev builds some time later
Thank you for the information. I greatly appreciate your work in this direction. I understand that it is difficult to provide an ETA at this time, but do you perhaps have a general idea of when it might be possible to test a development build with iOS support?
A month or so I'd say, but beware it might change significantly in either direction
@Mr3zee what about other platforms? This should already work for Android, right? I tried to view the "public" grpc repo, but didn't have access.
@robertdewilde-dev wdym by "public" repo and no access?
Other* platforms are supported in a dev dev branch, but not published yet
*Apple, Linux, Jvm (no android yet)
The library provides experimental support for the gRPC protocol. The artifacts are published separately in our Space repository. Current latest version:
Trying to open https://public.jetbrains.space/p/krpc/packages/maven/grpc shows that I cannot access it with my email domain
@robertdewilde-dev you don't need to open it, only to add the repo to gradle to consume artifacts