A non-reactive flavor for GRPC?

[preslavrachev]

Is there an option to implement GRPC services without the need to explicitly rely on reactive Mutiny constructs? I am aware of the fact that one can make an RPC method blocking by simply adding the @Blocking annotation. However, what would be the use of Unis in that case?

@Override
@Blocking
public Uni<HelloReply> sayHelloBlocking(HelloRequest request) {
    // Do something blocking before returning the Uni
    // Then what? Simply, wrap the result in an Uni? What for?
}

Don't get me wrong, I am pretty much aware that down at the core, everything in Quarkus follows the reactive pattern. However, in this case, requiring the reader of the code to be mixing reactive and blocking concepts only makes the code more difficult to comprehend. The REST extension is handling that part elegantly, allowing for both flavors to be used interchangeably.

Could an approach like this eventually get added to the GRPC part too? Or, am I missing a crucial difference here?

[quarkus-bot[bot]]

/cc @alesj (grpc), @cescoffier (grpc)

[cescoffier]

You should be able to use the plain gRPC base interface. You will see that it's relatively close to what you have.

Pure-blocking was considered at some point but not implemented.