Is your feature request related to a problem? Please describe.
When interacting with an external API that has a rate limiter implemented, it is important to have a matching rate limiter so that requests aren't unintentionally triggering that rate limit.
Describe the solution you'd like
rate limiting algorithms.
Describe alternatives you've considered
Some of these algorithms exist under external repositories
but the ideal would be for a common interface and location for these algorithms
I requested the creation of a common interface in #43003 but I put the cart before the horse.
As with any request, the initial goal is to determine which, if any of these are worth implementing, and in what form.
The text was updated successfully, but these errors were encountered:
There are a lot of different features you may or may not want in a rate limiter. Features come with tradeoffs like dependencies or memory usage etc. The x/time/rate limiter is hardly a panacea. Features one might want are:
Fairness (or arbitrary queuing behavior)
Different burst behavior (getting an error or truncating to the burst size can be very painful, a "debt" concept can be good)
My feeling is that this proposal would carry more weight if:
(A) It proposed a uniform interface.
(B) Explained why this interface should be centralized as opposed to just another library.
As part of the examination of x/time/rate that I did for 43003, I moved several things around to learn about it, and created an interface that could be a starting point. Looking back at it, I believe that my original suggestion was OK, but could be better. I also see several things that could be improved in general, but would go in the opposite direction norms wise.
as such I have two options as starting points, The first
Is effectively a slimmed down version of the current implementation, and really only differs in what it removes from my original messing around in that it removes the helpers.
The second is a much more radical change to the way Reservation works, but which I think cleans up the interfaces. I suggest this only because it is an x package, and the creation of a Limiter interface would be a backwards incompatible change requiring renaming of the current Limiter to TokenBucketLimiter anyway.