feat: add function to manually check rate limit#392
Conversation
There was a problem hiding this comment.
Copilot reviewed 2 out of 2 changed files in this pull request and generated no suggestions.
Comments skipped due to low confidence (3)
index.js:285
- The variable timeWindowString is only assigned a value if params.timeWindow is a number. Ensure it is always defined or handle the undefined case properly.
timeWindowString = ms.format(params.timeWindow, true)
index.js:193
- [nitpick] The function name createLimiterArgs is ambiguous. Consider renaming it to generateLimiterArguments for better clarity.
function createLimiterArgs (pluginComponent, globalParams, options) {
index.js:216
- Ensure that the new behavior introduced by the applyRateLimit function is covered by tests.
async function applyRateLimit (pluginComponent, params, req) {
mcollina
left a comment
There was a problem hiding this comment.
Looks good! Finish it up (be careful that CI is failing).
|
Hi @mcollina, after @umakantp has closed their PR #410 because of the "authorship problem", I thought of putting more pressure on myself to finally get this done. I added unit tests, type tests, as well as documentation about the usage of this feature. I also merged the latest commit of At this point, I also would like to appreciate @umakantp again for continuing this PR and putting time and effort into it. Please excuse me if I caused any trouble on your side. |
|
Hi @mcollina If you can please take a look and merge if things are good? |
|
It looks interesting, I'll take a look at this tomorrow |
Eomm
left a comment
There was a problem hiding this comment.
Technically this change is awesome!
A minor suggestion, but LGTM!
gurgunday
left a comment
There was a problem hiding this comment.
Can you run a benchmark using the basic example in the examples folder with autocannon?
https://github.com/fastify/fastify-rate-limit/blob/main/example/example-simple.mjs
|
Hi @gurgunday, sorry for yet anoter late reply... I wasn't sure which kind of benchmarks you'd expect. I still ran two benchmarks with and with @Eomm's suggestion: Machine and Versions
|
|
Looks like this has fallen behind on the priority list? @gurgunday ? |
|
Hey, sorry for the late reply, just to get an idea, can you run the same on |
|
Hey @gurgunday, I ran the benchmark again for TL;DRMy PR has about 2.9% less throughput. Let me know if that is too much regression. I did not check whether there is room for improvement yet. MasterMy PR |
gurgunday
left a comment
There was a problem hiding this comment.
I think 2% is acceptable, we should be able to improve this further with some optimizations but it lgtm currently for this PR
|
Thanks for the PR We should still wait for at least another approval |
Fdawgs
left a comment
There was a problem hiding this comment.
Blocking until I can find time to review, from brief glance the docs could be refined.
Signed-off-by: Frazer Smith <frazer.dev@icloud.com>
Signed-off-by: Frazer Smith <frazer.dev@icloud.com>
Signed-off-by: Frazer Smith <frazer.dev@icloud.com>
Co-authored-by: Manuel Spigolon <behemoth89@gmail.com> Signed-off-by: Frazer Smith <frazer.dev@icloud.com>
Signed-off-by: Manuel Spigolon <behemoth89@gmail.com>
Hey fastify contributors,
Following on from issue #346 and my comment, I finally had some spare time to implement a draft version of my idea as suggested by @mcollina. I realized that any store (child) instance receives all the
optionsprovided tofastify.rateLimitwhen it is constructed, which is why I had to adjust my initial idea and come up with a slightly different solution.I did not provide any documentation or additional tests yet (all existing tests run green tho), because I wanted to ask for your feedback first.
Please let me know what you think and as soon as everything looks good to you, I will finalize my PR with proper docs and tests.
Thanks and cheers
Patrick
How to Use
Checklist
npm run testandnpm run benchmarkand the Code of conduct