Rate limit

import { rateLimit } from "@vxnsin/inkan";

app.register(rateLimit({ max: 120 })); // 120 a minute, per client

At most max requests per client per window. The one after gets a 429 problem, rate-limited, with retry-after, and every answer says how many are left in x-ratelimit-limit and x-ratelimit-remaining. It is a shared plugin: registered on the app it counts every route, inside a plugin only that plugin's routes.

app.register((auth) => {
  auth.register(rateLimit({ max: 5 }));      // five login attempts a minute
  auth.post("/login", { body: Login }, login);
});

OptionsCopy Anchor Link

| store | this process's memory | a Store the processes share: one atomic increment per request | | prefix | "rate-limit:" | what the store's keys start with; give two limits that share a store their own |

Without a store the counts live in memory, in each process: with workers, each worker counts for itself. With one, every process and every server counts together:

import { redisStore } from "@inkanjs/redis";

const store = redisStore(redis);
app.register(rateLimit({ max: 120, store }));
app.register((auth) => {
  auth.register(rateLimit({ max: 5, store, prefix: "login:" }));
  auth.post("/login", { body: Login }, login);
});

Windows are fixed: they start at multiples of window since the epoch, and each request is one increment, which keeps the TTL the first one gave its key. A store that fails fails the request with a 500, rather than letting it through uncounted.