Description
Is there an existing issue that is already proposing this?
- I have searched the existing issues
Is your feature request related to a problem? Please describe it
We would like to be able to throttle based on quota from requests instead of 1 per request.
For example:
- Lets say we have an API that gets a
events: string[]
as part of request body. - If rate limit is
100 events/min
and we did 1st API call with99
events - Then,
- If we did 2nd API call with
2
events then it would throw rate-limit - If we did 2nd API call with
1
events then it would allow it
- If we did 2nd API call with
Describe the solution you'd like
In a similar way to the generateKey
that can be overloaded, to have another method getQuota
that decide the quantity that is being consumed, which by default would be 1
(i.e. 1 per API call)
Teachability, documentation, adoption, migration strategy
Since the default value would be 1
, users will not have to change anything from their side.
Users that would like to implement quota based throttling would need to implement the getQuota
inside the ThrottlerGuard
and return the quota used in a single API request.
What is the motivation / use case for changing the behavior?
We would like to implement rate limit by events - similar to what AWS does for SNS (docs):
The messages per second quota is based on the number of messages published to an Amazon SNS region, combining Publish and PublishBatch API requests