AspNetCoreRateLimit
AspNetCoreRateLimit copied to clipboard
stefanprodan
Support decorative style limit declaration
Hey! This is an amazing project!
Can you, please, evaluate supporting declaring limits using decorative attributes? This would align with other decorations pattern of asp.net (such as routes or authorization) and would give a very maintainable approach at declaring limits.
Thank you!
Any progress on this?
I second that. This feature would be much appreciated.
I tried to implement this some time ago (https://github.com/stefanprodan/AspNetCoreRateLimit/tree/feature/inline_attributes), but I couldn't easily make it work, it needed too much refactoring, maybe some breaking changes - so I abandoned it.
In the same time, I'm not sure of the actual value of this feature - having to re-deploy the code to change the limits doesn't sound so "maintainable".
Too bad, but I understand. Thanks for the effort 👍
I personally don't need to update this real-time for my solution, I would just favor something like this:
[HttpThrottle(["1m", "5m"], [2, 100])]
over a long list of appsettings policies. The HttpThrottle being the pseudo code here of course.
Anyway, great project and I think I'll manage without it haha.
Cheers!
In the same time, I'm not sure of the actual value of this feature - having to re-deploy the code to change the limits doesn't sound so "maintainable".
I think both types of configuration are very valid. I see how changing the configuration on the fly without redeploying could be valuable. However, having all the endpoint configurations at the Controller level is much easier to read and maintain at the code level. Redeploying is very easy in a modern CI/CD scenario, unless you need to do it a lot, which is not always the case.
Would like very much to see this feature. Looking at the code, I understand your concern about needing a major refactor. On the other hand, all the code is already there, the attribute is the same as the middleware, but with the rules passed to them directly and per endpoint.
Another way of implementing this is creating plain attributes, which do nothing. And use reflection to get all the endpoints configured this way. Then just pass it as the configuration class.
Yes, this is worse than implementing the code directly in an action filter attribute, yet it does the job as good as the current implementation, while not requiring too much effort. And if you configure it once per app life, we don't care about reflection being slow here.
I am most likely will be going with this approach for my scenario, can do a PR here if it works.