2024-01-02
4560
#node
Philip Obosi
14373
Jan 2, 2024 ⋅ 16 min read

Understanding and implementing rate limiting in Node.js

Philip Obosi Frontend engineer and data visualist 👨🏻‍💻 based in Lagos, Nigeria.

Recent posts:

The different ways to use CSS :has(), with examples

The CSS :has() pseudo-class is a powerful new feature that lets you style parents, siblings, and more – writing cleaner, more dynamic CSS with less JavaScript.

Daniel Schwarz
Oct 24, 2025 ⋅ 7 min read

Kombai AI: The AI agent built for frontend development

Kombai AI converts Figma designs into clean, responsive frontend code. It helps developers build production-ready UIs faster while keeping design accuracy and code quality intact.

Jude Miracle
Oct 23, 2025 ⋅ 7 min read

The Replay (10/22/25): AI-assisted coding, Wasm 3.0, and more

Discover what’s new in The Replay, LogRocket’s newsletter for dev and engineering leaders, in the October 22nd issue.

Matt MacCormack
Oct 22, 2025 ⋅ 29 sec read
Where AI-assisted coding accelerates development — and where it doesn’t

Where AI-assisted coding accelerates development — and where it doesn’t

John Reilly discusses how software development has been changed by the innovations of AI: both the positives and the negatives.

John Reilly
Oct 22, 2025 ⋅ 12 min read
View all posts

11 Replies to "Understanding and implementing rate limiting in Node.js"

  1. 2 of 3 cons of fixed window counter are not fair:
    – “user’s window should start counting from the time of their first request” -> this is easy to implement.
    – “burst traffic towards the end of a window” -> it may be issue, if your service is for one customer. It is unlikely, that all your thousands users would make all requests at once.

  2. Hi,
    It looks like using app.use() would limit the rate to the whole API. How would you go about applying rate limit to only a particular POST request while letting users do unlimited GET requests?

  3. Michal,

    You can do this by applying the middleware to the POST route directly instead of `app.use`

    e.g.

    `app.post(‘/limitedRoute’, customRedisRateLimiter, (req, res, next) => {})`

  4. When the record is null in the Redis store, you create the record, store it and then go to the next middleware. Shouldn’t there be a return statement after the next() instruction to prevent the middleware from executing the rest of the code ?

  5. you should wrap “await redisClient.connect()” in if statement with condition “!redisClient.isReady” or “!redisClient.isOpen” so it doesn’t throw “Socket already opened” error.

  6. this line get time of 24 hours ago from now ‘const windowStartTimestamp = moment().subtract(WINDOW_SIZE_IN_HOURS, ‘hours’).unix();’ and the record in redis already deleted after 24 hours , so how it comes?

  7. I tested the first implementation. I noticed that requestCount is only incremented when you call a different endpoint. But I want the rate to be per request, no matter the endpoints.

Leave a Reply

Would you be interested in joining LogRocket's developer community?

Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.

Sign up now