gRPC Kotlin is a protoc plugin for generating native Kotlin bindings using coroutine primitives for gRPC services.
- Why?
- Quick start
- gRPC Context propagation
- Exception handling
- Maven configuration
- Gradle configuration
- Examples
- RPC method type reference
The asynchronous nature of bidirectional streaming rpc calls in gRPC makes them a bit hard to implement
and read. Getting your head around the StreamObserver<T>'s can be a bit tricky at times. Specially
with the method argument being the response observer and the return value being the request observer, it all
feels a bit backwards to what a plain old synchronous version of the handler would look like.
In situations where you'd want to coordinate several request and response messages in one call, you'll and up having to manage some tricky state and synchronization between the observers. There are reactive bindings for gRPC which make this easier. But I think we can do better!
Enter Kotlin Coroutines! By generating native Kotlin stubs that allows us to use suspend functions and
Channel, we can write our handler and client code in an idiomatic and easy to read Kotlin style.
Note: This has been tested with gRPC 1.25.0, protobuf 3.10.0, kotlin 1.3.61 and coroutines 1.3.3.
Add a gRPC service definition to your project
greeter.proto
syntax = "proto3";
package org.example.greeter;
option java_package = "org.example.greeter";
option java_multiple_files = true;
message GreetRequest {
string greeting = 1;
}
message GreetReply {
string reply = 1;
}
service Greeter {
rpc Greet (GreetRequest) returns (GreetReply);
rpc GreetServerStream (GreetRequest) returns (stream GreetReply);
rpc GreetClientStream (stream GreetRequest) returns (GreetReply);
rpc GreetBidirectional (stream GreetRequest) returns (stream GreetReply);
}Run the protoc plugin to get the generated code, see build tool configuration
After compilation, you'll find the generated Kotlin code in the same package as the generated Java
code. A service base class named GreeterImplBase and a file with extension functions for the
client stub named GreeterStubExt.kt. Both the service base class and client stub extensions will
use suspend and Channel<T> instead of the typical StreamObserver<T> interfaces.
All functions have the suspend modifier so they can call into any suspending code, including the
core coroutine primitives like delay and async.
All the server streaming calls return a ReceiveChannel<TReply> and can easily be implemented using
produce<TReply>.
All client streaming calls receive an argument of ReceiveChannel<TRequest> where they can receive()
messages from the caller.
Here's an example server that demonstrates how each type of endpoint is implemented.
import kotlinx.coroutines.*
import kotlinx.coroutines.channels.ReceiveChannel
import kotlinx.coroutines.channels.produce
import java.util.concurrent.Executors.newFixedThreadPool
class GreeterImpl : GreeterImplBase(
coroutineContext = newFixedThreadPool(4).asCoroutineDispatcher()
) {
// unary rpc
override suspend fun greet(request: GreetRequest): GreetReply {
return GreetReply.newBuilder()
.setReply("Hello " + request.greeting)
.build()
}
// server streaming rpc
override fun greetServerStream(request: GreetRequest) = produce<GreetReply> {
send(GreetReply.newBuilder()
.setReply("Hello ${request.greeting}!")
.build())
send(GreetReply.newBuilder()
.setReply("Greetings ${request.greeting}!")
.build())
}
// client streaming rpc
override suspend fun greetClientStream(requestChannel: ReceiveChannel<GreetRequest>): GreetReply {
val greetings = mutableListOf<String>()
for (request in requestChannel) {
greetings.add(request.greeting)
}
return GreetReply.newBuilder()
.setReply("Hi to all of $greetings!")
.build()
}
// bidirectional rpc
override fun greetBidirectional(requestChannel: ReceiveChannel<GreetRequest>) = produce<GreetReply> {
var count = 0
for (request in requestChannel) {
val n = count++
launch {
delay(1000)
send(GreetReply.newBuilder()
.setReply("Yo #$n ${request.greeting}")
.build())
}
}
}
}Extensions functions for the original Java stubs are generated that use suspend functions, Deferred<TReply>
and SendChannel<TRequest>.
import io.grpc.ManagedChannelBuilder
import kotlinx.coroutines.delay
import kotlinx.coroutines.launch
import kotlinx.coroutines.runBlocking
fun main(args: Array<String>) {
val localhost = ManagedChannelBuilder.forAddress("localhost", 8080)
.usePlaintext()
.build()
val greeter = GreeterGrpc.newStub(localhost)
runBlocking {
// === Unary call =============================================================================
val unaryResponse = greeter.greet(req("Alice"))
println("unary reply = ${unaryResponse.reply}")
// === Server streaming call ==================================================================
val serverResponses = greeter.greetServerStream(req("Bob"))
for (serverResponse in serverResponses) {
println("server response = ${serverResponse.reply}")
}
// === Client streaming call ==================================================================
val manyToOneCall = greeter.greetClientStream()
manyToOneCall.send(req("Caroline"))
manyToOneCall.send(req("David"))
manyToOneCall.close()
val oneReply = manyToOneCall.await()
println("single reply = ${oneReply.reply}")
// === Bidirectional call =====================================================================
val bidiCall = greeter.greetBidirectional()
launch {
var n = 0
for (greetReply in bidiCall) {
println("r$n = ${greetReply.reply}")
n++
}
println("no more replies")
}
delay(200)
bidiCall.send(req("Eve"))
delay(200)
bidiCall.send(req("Fred"))
delay(200)
bidiCall.send(req("Gina"))
bidiCall.close()
}
}gRPC has a thread-local Context which is used to carry scoped values across API boundaries. With Kotlin coroutines
possibly being dispatched on multiple threads, the thread-local nature of Context needs some special care. This is
solved by two details in the generated Kotlin code.
First, all the generated service *ImplBase classes implement CoroutineScope. This allows you to use any of
the top level coroutine primitives such as launch, async and produce in your service implementation while still
keeping them within the context of your service code. The actual CoroutineContext that is used can be set through the
base class constructor, but defaults to Dispatchers.default.
abstract class MyServiceImplBase(
coroutineContext: CoroutineContext = Dispatchers.Default
)Second, in the getter for CoroutineScope.coroutineContext, an additional context key is added to the
CoroutineContext that manages the gRPC Context attach() and detach() calls when dispatching coroutine
continuations. This will ensure that the the gRPC context is always propagated across different coroutine boundaries,
and eliminates the need to manually carry it across in user code.
Here's a simple example that makes calls to other services concurrently and expects an authenticated user to be present
in the gRPC Context. The two accesses to the context key may execute on different threads in the CoroutineContext but
the accesses work as expected.
val authenticatedUser = Context.key<User>("authenticatedUser")
override suspend fun greet(request: GreetRequest): GreetReply {
val motd = async { messageOfTheDay.getMessage() }
val weatherReport = async { weather.getWeatherReport(authenticatedUser.get().location) }
val reply = buildString {
append("Hello ${authenticatedUser.get().fullName}")
append("---")
append("Today's weather report: ${weatherReport.await()}")
append("---")
append(motd.await())
}
return GreetReply.newBuilder()
.setReply(reply)
.build()
}For another example of gRPC Context usage, see the code in ContextBasedGreeterTest
Thanks to wfhartford for contributing!
The generated server code follows the standard exception propagation for Kotlin coroutines as described
in the Exception handling documentation. This means that it's safe to throw exceptions from within
the server implementation code. These will propagate up the coroutine scope and be translated to
responseObserver.onError(Throwable) calls. The preferred way to respond with a status code is to
throw a StatusException.
Note that you should not call close(Throwable) or close() from within the ProducerScope<T>
blocks you get from produce as the producer will automatically be closed when all sub-contexts are
closed (or if an exception is thrown).
Add the grpc-kotlin-gen plugin to your protobuf-maven-plugin configuration (see compile-custom goal)
<properties>
<kotlin.version>1.3.61</kotlin.version>
<kotlinx-coroutines.version>1.3.3</kotlinx-coroutines.version>
<grpc.version>1.25.0</grpc.version>
<protobuf.version>3.10.0</protobuf.version>
<grpc-kotlin.version>0.1.4</grpc-kotlin.version>
</properties>
<dependencies>
<dependency>
<groupId>org.jetbrains.kotlin</groupId>
<artifactId>kotlin-stdlib</artifactId>
<version>${kotlin.version}</version>
</dependency>
<dependency>
<groupId>org.jetbrains.kotlinx</groupId>
<artifactId>kotlinx-coroutines-core</artifactId>
<version>${kotlinx-coroutines.version}</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-netty</artifactId>
<version>${grpc.version}</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-protobuf</artifactId>
<version>${grpc.version}</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-stub</artifactId>
<version>${grpc.version}</version>
</dependency>
</dependencies>
<build>
<extensions>
<extension>
<groupId>kr.motd.maven</groupId>
<artifactId>os-maven-plugin</artifactId>
<version>1.5.0.Final</version>
</extension>
</extensions>
<plugins>
<plugin>
<groupId>org.xolstice.maven.plugins</groupId>
<artifactId>protobuf-maven-plugin</artifactId>
<version>0.6.1</version>
<configuration>
<protocArtifact>com.google.protobuf:protoc:${protobuf.version}:exe:${os.detected.classifier}</protocArtifact>
</configuration>
<executions>
<execution>
<goals><goal>compile</goal></goals>
</execution>
<execution>
<id>grpc-java</id>
<goals><goal>compile-custom</goal></goals>
<configuration>
<pluginId>grpc-java</pluginId>
<pluginArtifact>io.grpc:protoc-gen-grpc-java:${grpc.version}:exe:${os.detected.classifier}</pluginArtifact>
</configuration>
</execution>
<execution>
<id>grpc-kotlin</id>
<goals><goal>compile-custom</goal></goals>
<configuration>
<pluginId>grpc-kotlin</pluginId>
<pluginArtifact>io.rouz:grpc-kotlin-gen:${grpc-kotlin.version}:exe:${os.detected.classifier}</pluginArtifact>
</configuration>
</execution>
</executions>
</plugin>
<!-- make sure to add the generated source directories to the kotlin-maven-plugin -->
<plugin>
<artifactId>kotlin-maven-plugin</artifactId>
<groupId>org.jetbrains.kotlin</groupId>
<version>${kotlin.version}</version>
<executions>
<execution>
<id>compile</id>
<goals><goal>compile</goal></goals>
<configuration>
<sourceDirs>
<sourceDir>${project.basedir}/src/main/kotlin</sourceDir>
<sourceDir>${project.basedir}/target/generated-sources/protobuf/grpc-kotlin</sourceDir>
<sourceDir>${project.basedir}/target/generated-sources/protobuf/grpc-java</sourceDir>
<sourceDir>${project.basedir}/target/generated-sources/protobuf/java</sourceDir>
</sourceDirs>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>Add the grpc-kotlin-gen plugin to the plugins section of protobuf-gradle-plugin
def protobufVersion = '3.10.0'
def grpcVersion = '1.25.0'
def grpcKotlinVersion = '0.1.4'
protobuf {
protoc {
// The artifact spec for the Protobuf Compiler
artifact = "com.google.protobuf:protoc:${protobufVersion}"
}
plugins {
grpc {
artifact = "io.grpc:protoc-gen-grpc-java:${grpcVersion}"
}
grpckotlin {
artifact = "io.rouz:grpc-kotlin-gen:${grpcKotlinVersion}"
}
}
generateProtoTasks {
all()*.plugins {
grpc {}
grpckotlin {}
}
}
}Add the kotlin dependencies
def kotlinVersion = '1.3.61'
def kotlinCoroutinesVersion = '1.3.3'
dependencies {
compile "org.jetbrains.kotlin:kotlin-stdlib:$kotlinVersion"
compile "org.jetbrains.kotlinx:kotlinx-coroutines-core:$kotlinCoroutinesVersion"
}This is a list of example gRPC services and clients written using this project
rpc Greet (GreetRequest) returns (GreetReply);
A suspendable function which returns a single message.
override suspend fun greet(request: GreetRequest): GreetReply {
// return GreetReply message
}Suspendable call returning a single message.
val response: GreetReply = stub.greet( /* GreetRequest */ )
rpc GreetClientStream (stream GreetRequest) returns (GreetReply);
A suspendable function which returns a single message, and receives messages from a ReceiveChannel<T>.
override suspend fun greetClientStream(requestChannel: ReceiveChannel<GreetRequest>): GreetReply {
// receive request messages
val firstRequest = requestChannel.receive()
// or iterate all request messages
for (request in requestChannel) {
// ...
}
// return GreetReply message
}Using send() and close() on SendChannel<T>.
val call: ManyToOneCall<GreetRequest, GreetReply> = stub.greetClientStream()
call.send( /* GreetRequest */ )
call.send( /* GreetRequest */ )
call.close() // don't forget to close the send channel
val responseMessage = call.await()
rpc GreetServerStream (GreetRequest) returns (stream GreetReply);
Using produce and send() to send a stream of messages.
override fun greetServerStream(request: GreetRequest) = produce<GreetReply> {
send( /* GreetReply message */ )
send( /* GreetReply message */ )
// ...
}Note that close() or close(Throwable) should not be used, see Exception handling.
In kotlinx-coroutines-core:1.0.0 produce is marked with @ExperimentalCoroutinesApi. In order
to use it, mark your server class with @UseExperimental(ExperimentalCoroutinesApi::class) and
add the -Xuse-experimental=kotlin.Experimental compiler flag.
Using receive() on ReceiveChannel<T> or iterating with a for loop.
val responses: ReceiveChannel<GreetReply> = stub.greetServerStream( /* GreetRequest */ )
// await individual responses
val responseMessage = serverResponses.receive()
// or iterate all responses
for (responseMessage in responses) {
// ...
}
rpc GreetBidirectional (stream GreetRequest) returns (stream GreetReply);
Using produce and send() to send a stream of messages. Receiving messages from a ReceiveChannel<T>.
override fun greetBidirectional(requestChannel: ReceiveChannel<GreetRequest>) = produce<GreetReply> {
// receive request messages
val firstRequest = requestChannel.receive()
send( /* GreetReply message */ )
val more = requestChannel.receive()
send( /* GreetReply message */ )
// ...
}Note that close() or close(Throwable) should not be used, see Exception handling.
In kotlinx-coroutines-core:1.0.0 produce is marked with @ExperimentalCoroutinesApi. In order
to use it, mark your server class with @UseExperimental(ExperimentalCoroutinesApi::class) and
add the -Xuse-experimental=kotlin.Experimental compiler flag.
Using both a SendChannel<T> and a ReceiveChannel<T> to interact with the call.
val call: ManyToManyCall<GreetRequest, GreetReply> = stub.greetBidirectional()
launch {
for (responseMessage in call) {
log.info(responseMessage)
}
log.info("no more replies")
}
call.send( /* GreetRequest */ )
call.send( /* GreetRequest */ )
call.close() // don't forget to close the send channel