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
Support decorative style limit declaration #19
Comments
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: Anyway, great project and I think I'll manage without it haha. Cheers! |
I think both types of configuration are very valid. I see how changing the configuration on the fly without redeploying could be valuable. Would like very much to see this feature. |
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. |
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!
The text was updated successfully, but these errors were encountered: