[gRPC] Is it a goal to support bidirectional streaming?

[drub0y]

Is it a goal of the gRPC transport to support bidirectional streaming? The current limitation of building gRPC clients on top of the ktor HTTP client itself is that it uses the platform specific abstractions for HTTP and, well, I think we all know that iOS hamstrings streaming with URLSession. So, if the kotlinx-rpc gRPC transport is going to just build on ktor HTTP only (vs say ktor Sockets), then we're going to be just as limited in terms of capabilities.

Of course, if you were going to implement full HTTP[/2] support on top of ktor Sockets, I doubt it would be just for this gRPC transport and you'd most likely transition ktor HTTP off the platform specific abstractions onto your full HTTP[/2] implementation, right? 😄 Therefore, I'm pretty sure it's safe to assume that there will not be bidirectional streaming support, but I figured I'd ask.

FWIW, this leaves us in a place where we either bail on gRPC and go in on WebSockets (trying to avoid that) or we end wrapping grpc-swift on top of SwiftNIO. It just feels crazy to have to do that when we're all in on KMP.

[Mr3zee]

I'm sorry, I'm not sure what you mean. gRPC implementation doesn't use Ktor at all, and already supports bidi streaming

[drub0y]

Ah, well, that's an answer... so, thank you! 🙏🏻

FWIW, we do not see anything in the docs that explains what layers the gRPC transport builds on and since the kRPC very explicitly calls out that it's built on ktor and even the gRPC server side mentions ktor server I don't think it was too much of a stretch for ppl to think perhaps the client might be built on ktor as well.

We're going to clone and dig in to educate ourselves, but if there's a quick answer you can give as to what the library is using at a high level to do the HTTP/2 communication (or even just a link to some code) that would be highly appreciated.

[Jozott00]

The library utilizes platform-specific official gRPC libraries internally. On the JVM, it uses grpc-java, while on native platforms, it utilizes the grpc-core library, which is the low-level library used by other implementations, such as C++ and Python.

[drub0y]

Thanks @Jozott00, I just got everything cloned and dug into NativeManagedChannel and found it referencing libkgrpc which looks like it's maybe a small shim over libgrpc. That sound about right?

[Jozott00]

Yes, thats right 👍

[drub0y]

Thanks so much, that gives a lot of confidence in the runtime and we'll just expect a bit of a bumpy ride on the dev experience as ya'll get it dialed in. 😄

[Mr3zee]

@drub0y this first link you shared (https://kotlin.github.io/kotlinx-rpc/krpc-ktor.html) is kRPC doc, not gRPC (these are two separate protocols)

[Mr3zee]

I guess we have a naming confusion here, let me clear it up:

• kotlinx-rpc - library with all rpc related stuff
• kRPC - RPC protocol built by us for Kotlin.
• gRPC - another protocol, unrelated to kRPC.

gRPC and kRPC reuse the same compiler plugin and Gradle plugin for simplicity (think of it like JSON and CBOR sharing serializers in kotlinx.serialization), but use different implementations for actual communication.

We are workshopping better namings