🧩 Feature Request
Background
When migrating from net.devh:grpc-server-spring-boot-starter to spring-grpc, one of the missing features is support for request-scoped Spring beans within a gRPC call.
In net.devh, this was provided via @Scope("grpcRequest") that activated a new scope for the duration of each gRPC call, allowing developers to inject @Scope("grpcRequest") beans that are created once per RPC and destroyed when the call completes.
A typical use case: injecting a per-request context object (e.g. authenticated principal, request metadata, tracing state) into multiple downstream components without passing it explicitly through method arguments.
Question
Is there a plan to support a similar mechanism in spring-grpc?
Possible approaches we can think of is a built-in @Scope("grpcRequest") / @RpcScope backed by a ServerInterceptor that manages the scope lifecycle per call.
If there are no plans, any guidance on the recommended approach for per-request state management in spring-grpc would be appreciated — ideally documented (e.g. in the reference docs or as a wiki entry) so that teams can implement their own solution without waiting for a potential future addition to the starter.
Context
|
|
spring-grpc version |
1.0.2 |
| Migrating from |
net.devh:grpc-server-spring-boot-starter:3.1.0.RELEASE |
🧩 Feature Request
Background
When migrating from
net.devh:grpc-server-spring-boot-startertospring-grpc, one of the missing features is support for request-scoped Spring beans within a gRPC call.In
net.devh, this was provided via@Scope("grpcRequest")that activated a new scope for the duration of each gRPC call, allowing developers to inject@Scope("grpcRequest")beans that are created once per RPC and destroyed when the call completes.A typical use case: injecting a per-request context object (e.g. authenticated principal, request metadata, tracing state) into multiple downstream components without passing it explicitly through method arguments.
Question
Is there a plan to support a similar mechanism in
spring-grpc?Possible approaches we can think of is a built-in
@Scope("grpcRequest")/@RpcScopebacked by aServerInterceptorthat manages the scope lifecycle per call.If there are no plans, any guidance on the recommended approach for per-request state management in
spring-grpcwould be appreciated — ideally documented (e.g. in the reference docs or as a wiki entry) so that teams can implement their own solution without waiting for a potential future addition to the starter.Context
spring-grpcversion1.0.2net.devh:grpc-server-spring-boot-starter:3.1.0.RELEASE