Skip to content
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

Closed
1 task done
ghost opened this issue Feb 22, 2023 · 1 comment · Fixed by #1565
Closed
1 task done

Add a way to use Throttler multiple times #1369

ghost opened this issue Feb 22, 2023 · 1 comment · Fixed by #1565

Comments

@ghost
Copy link

ghost commented Feb 22, 2023

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

The problem is I can't use two Throttler decorators.

Describe the solution you'd like

I want to make something like:

    @UseGuards(ThrottlerGuard)
    @Throttle(10,60)
    @Throttle(1000, 86400)
    @Post("/teste")

With this, is possible to make a business rule:

  • Ten request per minute
  • One thousand request per day

Teachability, documentation, adoption, migration strategy

image

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).

@jmcdo29
Copy link
Member

jmcdo29 commented Feb 22, 2023

I think this could be manageable with a new API and mixin guard. Essentially something like ThrottlerGuard('macro') where macro is essentially just a label. That same label would then be added to the @Throttle() decorator as we overhaul that to be @Throttle({ ttl, limit, label? }) and the guard implementation itself uses the reflector plus the label (if it exists) to get specific metadata based on label + metadata key for that labeled guard. This way, it could be used multiple times over for multiple rate limits that need to be adhered to.

Ganesha2552 added a commit to Ganesha2552/throttler that referenced this issue Jun 16, 2023
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"
@Ganesha2552 Ganesha2552 mentioned this issue Jun 16, 2023
12 tasks
jmcdo29 added a commit that referenced this issue Jul 6, 2023
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
jmcdo29 added a commit that referenced this issue Jul 6, 2023
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
@jmcdo29 jmcdo29 mentioned this issue Jul 6, 2023
12 tasks
jmcdo29 added a commit that referenced this issue Jul 6, 2023
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
jmcdo29 added a commit that referenced this issue Jul 6, 2023
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
@jmcdo29 jmcdo29 linked a pull request Jul 6, 2023 that will close this issue
12 tasks
jmcdo29 added a commit that referenced this issue Jul 7, 2023
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
jmcdo29 added a commit that referenced this issue Jul 7, 2023
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
jmcdo29 added a commit that referenced this issue Jul 7, 2023
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
jmcdo29 added a commit that referenced this issue Sep 4, 2023
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
jmcdo29 added a commit that referenced this issue Sep 4, 2023
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
jmcdo29 added a commit that referenced this issue Sep 4, 2023
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
jmcdo29 added a commit that referenced this issue Sep 4, 2023
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant