Express middleware for IP-based rate limiting with flexible configuration options and multiple storage backends
Overall
score
96%
{
"context": "Evaluates whether the solution relies on express-rate-limit's default MemoryStore to enforce the windowed limit without reinventing counters. Also checks that reset and shutdown hooks use the library's own helpers so the store can be cleaned up cleanly.",
"type": "weighted_checklist",
"checklist": [
{
"name": "rateLimit middleware",
"description": "Configures express-rate-limit's rateLimit middleware on GET /api/message with the provided windowMs and limit options.",
"max_score": 20
},
{
"name": "Default MemoryStore",
"description": "Leaves the store option unset so the limiter uses the built-in MemoryStore and its initialization (no custom store implementation).",
"max_score": 20
},
{
"name": "Reset via helper",
"description": "POST /admin/reset invokes the limiter's resetKey (or equivalent store.resetKey) with the supplied clientId instead of manual counter mutation.",
"max_score": 20
},
{
"name": "No manual counters",
"description": "Request counting relies solely on express-rate-limit hooks (rateLimit, getKey/resetKey) with no parallel custom tracking or side-channel throttling.",
"max_score": 10
},
{
"name": "Timer cleanup",
"description": "shutdown() calls the limiter store's shutdown/stopInterval hook to clear MemoryStore timers and can be invoked safely multiple times.",
"max_score": 15
},
{
"name": "Window reset timing",
"description": "Relies on MemoryStore's automatic window resets (via windowMs and internal timers) rather than manual setTimeout logic for resetting counters.",
"max_score": 15
}
]
}Install with Tessl CLI
npx tessl i tessl/npm-express-rate-limitevals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
scenario-6
scenario-7
scenario-8
scenario-9
scenario-10