Support generating kotlin bindings

[tandel-pratik]

Now that https://github.com/protocolbuffers/protobuf/issues/3742 is resolved and the protoc can generate some Kotlin bindings, can we support this in grpc-kotlin as well?

[lowasser]

The intent is that choosing to use gRPC-Kotlin and choosing to use Kotlin protos should be completely independent, and it is -- you can use one or the other, or both.

[tandel-pratik]

My understanding is that grpc-kotlin generates the proto bindings as well for bazel anyway. There's a PR that fails to use the new bindings in bazel for instance: https://github.com/grpc/grpc-kotlin/pull/266

I think this PR should fix it: https://github.com/grpc/grpc-kotlin/pull/271

FWIW, we tried updating rules_proto to use the newer version but the kotlin DSL don't seem to be generated either.

[SanjayVas]

The Kotlin proto generated code effectively just adds a type-safe builder DSL to the Java protos. The current code generated by grpc-kotlin can accept proto messages built using this.

In terms of the Bazel rule implementation, the rule requires the caller to pass in a java_proto_library, meaning it's up to the caller to define a proto library target for each service. What #266 appears to be trying to do is update the examples in this repo to use the Kotlin proto DSL. I don't believe this would have any effect on the API that grpc-koltin exposes. It currently fails in the Bazel path because the Kotlin protos aren't included there. There are currently no Bazel rules for generating Kotlin protos. See https://github.com/bazelbuild/rules_kotlin/issues/546.

[wfhartford]

I'm working on generating some Kotlin to integrate grpc-kotlin more closely with the protobuf generated Kotlin DSL. For every (non-streaming) RPC, I would generate a function like the following:

suspend fun rpcMethodName(
  headers: Metadata = Metadata(),
  builder: RequestMessageKt.Dsl.() -> Unit
): ResponseMessage =
  rpcMethodName(requestMessage(block), headers)

This function allows a client to call the RPC building the request message in a less verbose form:

serviceStub.rpcMethodName {
  fieldOne = valueOne
  fieldTwo = valueTwo
}

Rather than the current syntax:

serviceStub.rpcMethodName(
  requestMessage {
    fieldOne = valueOne
    fieldTwo = valueTwo
  }
)

I've been using functions like this in my projects for quite a while and appreciate the less verbose calls. Would a pull request that introduces these function overloads have a chance of being accepted? These functions introduce a dependency on the protobuf generated Kotlin DSL.

[lowasser]

It is specifically intended that we do not have a dependency from gRPC-Kotlin to Kotlin protos, which is why things are the way they are today.