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

[Feature Request] server-side "wrapper" interceptors #591

Open
cbatson opened this issue Dec 3, 2022 · 3 comments
Open

[Feature Request] server-side "wrapper" interceptors #591

cbatson opened this issue Dec 3, 2022 · 3 comments

Comments

@cbatson
Copy link

cbatson commented Dec 3, 2022

Hello, I'd like to see something like Interceptors on the server side, but more akin to the UnaryInterceptor of gRPC-Web. This is something I have appreciated from other server frameworks. This style of interceptor would "wrap" around the service call, which yields the existing functionality of Interceptors (such as vetoing a request) and more. Such "wrapping" interceptors would be able to manipulate both the incoming request as well as the outgoing response.

There are several interesting use cases for this. One such use case would be instrumenting all service calls in a uniform way.

Interceptor 1
|   Interceptor 2
|   |   Interceptor 3
|   |   |   service call
|   |   Interceptor 3
|   Interceptor 2
Interceptor 1
@mraleph
Copy link
Member

mraleph commented Dec 12, 2022

I think it makes sense to deprecate current interceptor functionality and align client and server interceptor APIs. Feel free to contribute PR with the implementation.

@cbatson
Copy link
Author

cbatson commented Dec 18, 2022

Note to self, consider addressing #546 when implementing this.

@Levi-Lesches
Copy link

A server-side interceptor could possibly add CORS headers to a response, fixing #611

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

No branches or pull requests

3 participants