-
Notifications
You must be signed in to change notification settings - Fork 926
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
Add documentation for preprocessors #6051
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new interface looks promising. 👍 👍 👍
I also understand that the decorator chain is mutable so that different decorators can be added in the preprocessor. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍👍
|
||
## Implementing `HttpPreprocessor` and `RpcPreprocessor` | ||
|
||
<type://HttpPreprocessor> and <type://RpcPreprocessor> expose a <type://PartialClientRequestContext>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can understand what Partial
means, but it might be ambiguous for normal users.
What do you think of prefixing Pre
to imply it is used in *Preprocessor
?
<type://HttpPreprocessor> and <type://RpcPreprocessor> expose a <type://PartialClientRequestContext>. | |
<type://HttpPreprocessor> and <type://RpcPreprocessor> expose a <type://PreClientRequestContext>. |
+-----------+ +-----------------+ +-----------------+ +-----------------+ +----------+ +-----------+ | ||
``` | ||
|
||
Note that unlike decorators, <typeplural://HttpPreprocessor> are not executed for RPC-based clients. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Motivation: This PR introduces the notion of `Preprocessor`s and allows users to configure these to clients as options. The second part of this PR will introduce a way for users to solely create a client based on `Preprocessor`s. The eventual POC can be found here: https://github.com/jrhee17/armeria/pull/36/files Eventually this extension point will also make it easier/clearer for users to use xDS with existing Armeria APIs. The full capability/limitations/design of `Preprocessors` are better described in the following PR: #6051 Modifications: - Introduced `Preprocessor` and `PreClient` APIs - Added `ClientPreprocessors` and `ClientPreprocessorsBuilder` to allow users to easily add `Preprocessor`s to clients as options - Modified `DefaultWebClient`, `DefaultTHttpClient`, and `ArmeriaClientCall` to use `Preprocessor`s - In order to allow users a way to overwrite the chosen `EndpointGroup`, the `EndpointGroup` is now specified when creating a `ClientRequestContext` instead of at initialization time. - Modified `ClientUtil` methods to pass an additional `req` field which signifies the original request for type-safety. Result: - Users can specify `Preprocessor`s when creating a client. <!-- Visit this URL to learn more about how to write a pull request description: https://armeria.dev/community/developer-guide#how-to-write-pull-request-description -->
Notes