Overload ServerBuilder.addService to take a Supplier of the service definition
- 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
Assessment
This issue has not been assessed yet.