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

Design #248

Open
aiodintsov opened this issue Oct 30, 2024 · 0 comments
Open

Design #248

aiodintsov opened this issue Oct 30, 2024 · 0 comments

Comments

@aiodintsov
Copy link

When it says:

We're more interested in the design itself than in some intelligent and tricky rate-limiting algorithm...

Does it mean "design of the rule configuration classes" or "design of the implementation (such as efficient rule-matching against endpoints and context data and concurrent and safe rule execution"

That is how important it is choose and provide rule configuration classes, since a large part of usability of such library is an approach to configuring the rate limit rules, which also greatly depends on a way application is configured which may use xml, json, yaml, ini, custom configuration file and a range of other techniques which may become quite sophisticated really quickly, while still being irrelevant to the implementation; at the same time rule combinations are tightly coupled to rules configuration and definition approach.

Is there a suggestion on a specific rule definition / rule definition discovery format?

I.e. when defining WebApi endpoints (most natural use case for .NET / C# library) defining them with AOP attributes on the WebApi methods would probably be the easiest to use while offering either static or runtime discovery of the rules. However it also says that there is no need to add ASP.NET project, meaning that it should be configurable without it.

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

No branches or pull requests

1 participant