Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More
Socket
Sign inDemoInstall
Socket

lambda-rate-limiter

Package Overview
Dependencies
Maintainers
1
Versions
55
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

lambda-rate-limiter

Simple in-memory rate-limit for Node.

  • 2.4.1
  • Source
  • npm
  • Socket score

Version published
Maintainers
1
Created
Source

lambda-rate-limiter

Build Status Test Coverage Greenkeeper badge Dependencies NPM Downloads Semantic-Release Gardener Gitter

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?

Run

$ npm install --save lambda-rate-limiter

How to use?

To initialize and check against limit use

const limiter = require("lambda-rate-limiter")({
  interval: 60000, // rate limit interval in ms, starts on first request
  uniqueTokenPerInterval: 500 // excess causes earliest seen to drop, per instantiation
});

limiter
  .check(10, "USER_TOKEN") // define maximum of 10 requests per interval
  .catch(() => {
    // rate limit exceeded: 429
  })
  .then(() => {
    // ok
  });

where 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.

Keywords

FAQs

Package last updated on 24 Feb 2018

Did you know?

Socket

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install

Related posts

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc