Rough sketch (draft 3) limiter extension and middleware #12700
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…missed a form of gRPC interceptor. For both client and server gRPC cases in the middleware extension API, introduce a method to obtain a stats handler. ClientStatsHandler() and ServerStatsHandler() methods will be added, returning (grpc.StatsHandler, error). In limitermiddleware, add support for the two new methods. Implement the StatsHandler interface with empty methods for now. The type is named stats.Handler, package documented https://pkg.go.dev/google.golang.org/[email protected]/stats#Handler
bogdandrutu
reviewed
Mar 22, 2025
Comment on lines
+27
to
+28
| // ClientStatsHandler returns a gRPC stats handler for client-side operations. | ||
| ClientStatsHandler() (stats.Handler, error) |
There was a problem hiding this comment.
Not sure if this should be part of the GRPCClient or different GRPCStatsClient?
Comment on lines
+20
to
+21
| // Key identifies the type of weight being limited | ||
| Key string |
There was a problem hiding this comment.
Should we use an enum here instead?
| // | ||
| // On success, it returns a ReleaseFunc that should be called | ||
| // when the resources are no longer needed. | ||
| Acquire(ctx context.Context, weights []Weight) (ReleaseFunc, error) |
There was a problem hiding this comment.
Not sure I understand the need of a slice of weights vs just one.
Comment on lines
+27
to
+28
| // ServerStatsHandler returns a gRPC stats handler for server-side operations. | ||
| ServerStatsHandler() (stats.Handler, error) |
There was a problem hiding this comment.
Same question as for client, not sure if this should be here or a separate interface. Idea is that in general you either have implementations for the 2 interceptors or for the stats handler.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
After prior drafts, summarized in #12603, with feedback from @bogdandrutu and @axw, I explored adding limiters via middleware structured as two separate configuration and two separate extensions.
This draft includes only the outline of 6 (six!) new modules, which piece together to support a variety of limiter and interceptor behaviors. While I am concerned about the scope of this (#9591, #7441), this appears to be a good direction:
There are implied changes here as well as TODOs:
Link to tracking issue
Part of #9591 #7441 #12603
Testing
NONE: for discussion
Documentation
NONE: TODO