Fast and efficient in-memory rate-limiter. No centralized storage (see below for reasoning).
This rate limiter is designed for AWS Lambda and other serverless computing alternatives, but is usable in any NodeJS project, regardless of whether a framework or vanilla code is used. It works great to prevent most common DOS attacks, but can also be used for simple rate limiting. However accuracy is not guaranteed in the second case (see below).
Uses lru-cache for storage.
How to install?
$ npm install --save lambda-rate-limiter
How to use?
To initialize and check against limit use
const limiter =interval: 60000 // rate limit interval in ms, starts on first requestuniqueTokenPerInterval: 500 // excess causes earliest seen to drop, per instantiation;limiter// define maximum of 10 requests per interval;
USER_TOKEN could be the user ip or login.
Why not using existing similar modules?
Using serverless computing is usually cheap, especially for low volume. You only pay for usage. Adding a centralized rate limiter storage option like Redis adds a significant amount of cost and overhead. This cost increases drastically and the centralized storage eventually becomes the bottleneck when DOS attacks need to be prevented.
This module keeps all limits in-memory, which is much better for DOS prevention. The only downside: Limits are not shared between function instantiations. This means limits can reset arbitrarily when new instances get spawned (e.g. after a deploy) or different instances are used to serve requests. However, cloud providers will usually serve clients with the same instance if possible, since cached data is most likely to reside on these instances. This is great since we can assume that in most cases the instance for a client does not change and hence the rate limit information is not lost.