-
Notifications
You must be signed in to change notification settings - Fork 61
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 a way to use Throttler multiple times #1369
Comments
I think this could be manageable with a new API and mixin guard. Essentially something like |
Ability to set multiple rate limits with custom time intervals. Flexible storage options including Redis, in-memory, and MongoDB. BREAKING CHANGE: Multiple rate limits, Storage options "fix nestjs#1369","fix nestjs#1221"
This is a bit of something that I've wanted to do for a while and inspired by [this pr][pr]. With the new appraoch, we're now able to let users define scales at which they would like the throttling to work over, and let it work for any number of configuratins, from a single 10 requests in 5 seconds to scales of months, or milliseconds BREAKING CHANGES: It's worth noting there are quite a few breaking changes in this which will be reflected in the changelog as well, but better to have multiple mentions in my opinion * ttl is now in milliseconds, not seconds, but there are time helper exposed to ease the migration to that * the module options is now either an array or an object with a `throttlers` array property * `@Throttle()` now takes in an object instead of two parameters, to allow for setting multiple throttle contexts at once in a more readable manner * `@ThrottleSkip()` now takes in an object with string boolean to say which throttler should be skipped pr: #1522 ref: #1369 ref: #1522
This is a bit of something that I've wanted to do for a while and inspired by [this pr][pr]. With the new appraoch, we're now able to let users define scales at which they would like the throttling to work over, and let it work for any number of configuratins, from a single 10 requests in 5 seconds to scales of months, or milliseconds BREAKING CHANGES: It's worth noting there are quite a few breaking changes in this which will be reflected in the changelog as well, but better to have multiple mentions in my opinion * ttl is now in milliseconds, not seconds, but there are time helper exposed to ease the migration to that * the module options is now either an array or an object with a `throttlers` array property * `@Throttle()` now takes in an object instead of two parameters, to allow for setting multiple throttle contexts at once in a more readable manner * `@ThrottleSkip()` now takes in an object with string boolean to say which throttler should be skipped pr: #1522 ref: #1369 ref: #1522
This is a bit of something that I've wanted to do for a while and inspired by [this pr][pr]. With the new appraoch, we're now able to let users define scales at which they would like the throttling to work over, and let it work for any number of configuratins, from a single 10 requests in 5 seconds to scales of months, or milliseconds BREAKING CHANGES: It's worth noting there are quite a few breaking changes in this which will be reflected in the changelog as well, but better to have multiple mentions in my opinion * ttl is now in milliseconds, not seconds, but there are time helper exposed to ease the migration to that * the module options is now either an array or an object with a `throttlers` array property * `@Throttle()` now takes in an object instead of two parameters, to allow for setting multiple throttle contexts at once in a more readable manner * `@ThrottleSkip()` now takes in an object with string boolean to say which throttler should be skipped pr: #1522 ref: #1369 ref: #1522
This is a bit of something that I've wanted to do for a while and inspired by [this pr][pr]. With the new appraoch, we're now able to let users define scales at which they would like the throttling to work over, and let it work for any number of configuratins, from a single 10 requests in 5 seconds to scales of months, or milliseconds BREAKING CHANGES: It's worth noting there are quite a few breaking changes in this which will be reflected in the changelog as well, but better to have multiple mentions in my opinion * ttl is now in milliseconds, not seconds, but there are time helper exposed to ease the migration to that * the module options is now either an array or an object with a `throttlers` array property * `@Throttle()` now takes in an object instead of two parameters, to allow for setting multiple throttle contexts at once in a more readable manner * `@ThrottleSkip()` now takes in an object with string boolean to say which throttler should be skipped pr: #1522 ref: #1369 ref: #1522
This is a bit of something that I've wanted to do for a while and inspired by [this pr][pr]. With the new appraoch, we're now able to let users define scales at which they would like the throttling to work over, and let it work for any number of configuratins, from a single 10 requests in 5 seconds to scales of months, or milliseconds BREAKING CHANGES: It's worth noting there are quite a few breaking changes in this which will be reflected in the changelog as well, but better to have multiple mentions in my opinion * ttl is now in milliseconds, not seconds, but there are time helper exposed to ease the migration to that * the module options is now either an array or an object with a `throttlers` array property * `@Throttle()` now takes in an object instead of two parameters, to allow for setting multiple throttle contexts at once in a more readable manner * `@ThrottleSkip()` now takes in an object with string boolean to say which throttler should be skipped pr: #1522 ref: #1369 ref: #1522
This is a bit of something that I've wanted to do for a while and inspired by [this pr][pr]. With the new appraoch, we're now able to let users define scales at which they would like the throttling to work over, and let it work for any number of configuratins, from a single 10 requests in 5 seconds to scales of months, or milliseconds BREAKING CHANGES: It's worth noting there are quite a few breaking changes in this which will be reflected in the changelog as well, but better to have multiple mentions in my opinion * ttl is now in milliseconds, not seconds, but there are time helper exposed to ease the migration to that * the module options is now either an array or an object with a `throttlers` array property * `@Throttle()` now takes in an object instead of two parameters, to allow for setting multiple throttle contexts at once in a more readable manner * `@ThrottleSkip()` now takes in an object with string boolean to say which throttler should be skipped pr: #1522 ref: #1369 ref: #1522
This is a bit of something that I've wanted to do for a while and inspired by [this pr][pr]. With the new appraoch, we're now able to let users define scales at which they would like the throttling to work over, and let it work for any number of configuratins, from a single 10 requests in 5 seconds to scales of months, or milliseconds BREAKING CHANGES: It's worth noting there are quite a few breaking changes in this which will be reflected in the changelog as well, but better to have multiple mentions in my opinion * ttl is now in milliseconds, not seconds, but there are time helper exposed to ease the migration to that * the module options is now either an array or an object with a `throttlers` array property * `@Throttle()` now takes in an object instead of two parameters, to allow for setting multiple throttle contexts at once in a more readable manner * `@ThrottleSkip()` now takes in an object with string boolean to say which throttler should be skipped pr: #1522 ref: #1369 ref: #1522
This is a bit of something that I've wanted to do for a while and inspired by [this pr][pr]. With the new appraoch, we're now able to let users define scales at which they would like the throttling to work over, and let it work for any number of configuratins, from a single 10 requests in 5 seconds to scales of months, or milliseconds BREAKING CHANGES: It's worth noting there are quite a few breaking changes in this which will be reflected in the changelog as well, but better to have multiple mentions in my opinion * ttl is now in milliseconds, not seconds, but there are time helper exposed to ease the migration to that * the module options is now either an array or an object with a `throttlers` array property * `@Throttle()` now takes in an object instead of two parameters, to allow for setting multiple throttle contexts at once in a more readable manner * `@ThrottleSkip()` now takes in an object with string boolean to say which throttler should be skipped pr: #1522 ref: #1369 ref: #1522
This is a bit of something that I've wanted to do for a while and inspired by [this pr][pr]. With the new appraoch, we're now able to let users define scales at which they would like the throttling to work over, and let it work for any number of configuratins, from a single 10 requests in 5 seconds to scales of months, or milliseconds BREAKING CHANGES: It's worth noting there are quite a few breaking changes in this which will be reflected in the changelog as well, but better to have multiple mentions in my opinion * ttl is now in milliseconds, not seconds, but there are time helper exposed to ease the migration to that * the module options is now either an array or an object with a `throttlers` array property * `@Throttle()` now takes in an object instead of two parameters, to allow for setting multiple throttle contexts at once in a more readable manner * `@ThrottleSkip()` now takes in an object with string boolean to say which throttler should be skipped pr: #1522 ref: #1369 ref: #1522
This is a bit of something that I've wanted to do for a while and inspired by [this pr][pr]. With the new appraoch, we're now able to let users define scales at which they would like the throttling to work over, and let it work for any number of configuratins, from a single 10 requests in 5 seconds to scales of months, or milliseconds BREAKING CHANGES: It's worth noting there are quite a few breaking changes in this which will be reflected in the changelog as well, but better to have multiple mentions in my opinion * ttl is now in milliseconds, not seconds, but there are time helper exposed to ease the migration to that * the module options is now either an array or an object with a `throttlers` array property * `@Throttle()` now takes in an object instead of two parameters, to allow for setting multiple throttle contexts at once in a more readable manner * `@ThrottleSkip()` now takes in an object with string boolean to say which throttler should be skipped pr: #1522 ref: #1369 ref: #1522
This is a bit of something that I've wanted to do for a while and inspired by [this pr][pr]. With the new appraoch, we're now able to let users define scales at which they would like the throttling to work over, and let it work for any number of configuratins, from a single 10 requests in 5 seconds to scales of months, or milliseconds BREAKING CHANGES: It's worth noting there are quite a few breaking changes in this which will be reflected in the changelog as well, but better to have multiple mentions in my opinion * ttl is now in milliseconds, not seconds, but there are time helper exposed to ease the migration to that * the module options is now either an array or an object with a `throttlers` array property * `@Throttle()` now takes in an object instead of two parameters, to allow for setting multiple throttle contexts at once in a more readable manner * `@ThrottleSkip()` now takes in an object with string boolean to say which throttler should be skipped pr: #1522 ref: #1369 ref: #1522
Is there an existing issue that is already proposing this?
Is your feature request related to a problem? Please describe it
The problem is I can't use two Throttler decorators.
Describe the solution you'd like
I want to make something like:
With this, is possible to make a business rule:
Teachability, documentation, adoption, migration strategy
It's a pretty good way to use this library.
What is the motivation / use case for changing the behavior?
It's the necessity to Rate Limiting on micro-time (seconds) and macro-time (days).
The text was updated successfully, but these errors were encountered: