grpc / grpc/grpc-java

Overload ServerBuilder.addService to take a Supplier of the service definition

Open
#1,576 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Java
Stars
12.1k
Forks
4k
Avg merge
2d 17h
Merged PRs (30d)
37

Description

In general, servers want to instantiate a new method handler for each call to avoid polluted state. We'd like this to be handled by the framework, rather than asking application developers to remember it. The current API essentially pushes the responsibility to the application:
- The `Server` is a singleton since it has a long-lived lifecycle
- `ServerBuilder.addService(ServerServiceDefinition service)` requires that the `service` be instantiated at startup
- `FooServiceGrpc.bindService(FooService serviceImpl)` also requires that the `serviceImpl` be instantiated. Thus, the `FooService` has to be a singleton with respect to the server lifecycle. That is, your implementation of the generated service stub has to be a singleton. So the app developer has to worry about the scope of the dependency chain from there down.

I propose overloading the generated code to take a `Supplier` of some sort: `FooServiceGrpc.bindService(Supplier serviceImplSupplier)`. This would let me pass a Guice `Provider::get` to the `bindService` method and get whatever Guice scoping I want on method calls. This lets me handle proper scoping in my own framework code rather than in every implementation of a stub.

Almost as good would be pushing the thunk-ness back a layer to `ServerBuilder.addService(Supplier serviceSupplier)`, but I suspect that is harder to implement.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.