Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need a way to adapt gRPC context with Reactor Context for Reactor generated stubs #330

Open
svametcalf opened this issue Aug 7, 2024 · 0 comments

Comments

@svametcalf
Copy link

First of all, thank you for the very nice library. These stubs really simplify the implementation of gRPC in the Spring ecosystem.

We are using the Reactor gRPC stub generator, along with spring-grpc and Spring Boot and are running into impedance mismatches between the gRPC context and Reactor context. Because Spring uses the Reactor context for a bunch of cross-cutting concerns, such as transaction management, authn / authz, and tracing, we have found a need to provide an adapter between both context storage mechanisms.

This adapter would need to be called on every server (and maybe every client call?), in order to propagate the context values upstream.

Tricky Bits

The tricky bit is that there is not a way to enumerate all of the values in a gRPC context, so it would not be possible to have a generic adapter that transparently converts between the two values.

Instead, we need to provide a user-defined mechanism to convert between the two context values, so that users of this library can do the conversion that makes sense for their use-case.

Options for design

To add this feature, we will need a way for users to register this context adapter with the generated Reactor stubs. For this, I see a couple options:

  1. ServiceLoader: Users could provide an implementation of this adapter interface that could be registered and loaded using Java's ServiceLoader mechanism
  2. Code generation: Add another overrideable method to the generated stubs that would allow for customization of this context adapter
  3. Some combination of the two

I am happy to work on a PR that would be a proof of concept of this feature, but wanted to lay my thoughts out in case someone had any suggestions on where the best approach might be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant