I wanted to get some feedback in regards to requiring proper usage of parallel decomposition (wrapping service method in coroutineScope). Currently for my library its up to the consumers to follow best practices outlined in the structure concurrency blog post.

What do you call "service method" exactly?

The library is for grpc, so code generation creates abstract base implementations of services. "service method" refers to user implementations of those abstract methods.

@marcoferrer Is your library open source? I could help set the context.

@marcoferrer I'm a bit confused (or concerned should I say 😅) regarding the parameter of type

CompletableDeferred

in the snippet in these "Other Concerns". Why is it there? Shouldn't there just be a suspend function with its return type? Also, what is the purpose of this function exactly? Is it meant to take input, perform the request on the remote server via gRPC and return the response, or is it supposed to do something else?

Its a valid point. The original goal was to bridge grpc types with their coroutine based counter parts. With grpc, the service method actually gets a reference to the response callback and its up to the service impl to complete the callback Heres an example of a plain java grpc service https://github.com/grpc/grpc-java/blob/a4859c1e931db7886e2f87f3835286ae1fd10d9a/examples/example-kotlin/src/main/kotlin/io/grpc/examples/helloworld/HelloWorldServer.kt#L68 The reason for marking the method as suspend was so that the service method can be cancelled in the event of a client error / cancellation. Allowing the service method to exit early if its result is no longer needed. Im still considering changing the generated method signature and using the return value explicitly but there are some issues Ill need to address in regards to applying backpressure / flow control when to comes to methods with streaming responses

In abstract words, how is "backpressure / flow control" usually handled in gRPC java?