Rate Limiting

Begrenze, wie oft ein einzelner Leser den Assistenten, den Proxy des API-Playgrounds und die serverseitige Suche aufrufen kann. Das ist standardmäßig aktiv, und die Zählung liegt im Speicher, bei Upstash oder bei Cloudflare.

Die Server-Routen, die ein Leser aufrufen kann, kosten dich bei jedem Aufruf etwas: Der Assistent verbraucht Modell-Tokens, der Proxy des API-Playgrounds leitet Anfragen an deine API weiter, und die Mixedbread-Suche führt eine kostenpflichtige Abfrage aus. Blume begrenzt, wie oft ein einzelner Leser jede dieser Routen aufrufen kann. Erkannt wird er an seiner IP-Adresse. Überschreitet ein Leser das Limit, erhält er 429 Too Many Requests mit einem Retry-After-Header, und der Assistent bittet ihn, es in ein paar Minuten erneut zu versuchen.

Rate Limiting ist standardmäßig aktiv, mit 30 Anfragen pro Leser und Route alle 10 Minuten. Das ist hoch genug, dass ein Mensch nie daran stößt, und niedrig genug, um ein Skript zu stoppen. Es spielt nur bei einem Server-Build eine Rolle, denn eine statische Seite hat keine Server-Routen, die begrenzt werden müssten.

import { defineConfig } from "blume";
import { upstash } from "blume/ratelimit";

export default defineConfig({
  rateLimit: upstash({ requests: 30, window: 600 }), // window in seconds
});

Jede Route zählt für sich. Eine intensive Playground-Sitzung verbraucht also nicht die Fragen, die der Leser dem Assistenten stellen kann.

Wo die Zählung liegt

Speicher

memory() braucht keine Einrichtung. Auf einem Server, der als einzelner Prozess läuft, etwa mit deployment: node(), ist die Zählung exakt. Vercel, Netlify und Cloudflare betreiben viele kurzlebige Instanzen, von denen jede ihre eigene Zählung führt. Dort bremst es also einen plötzlichen Ansturm von Anfragen eines einzelnen Lesers, setzt das Limit aber nicht exakt durch. Für ein exaktes Limit auf diesen Hosts nutzt du einen der gemeinsamen Stores weiter unten.

import { memory } from "blume/ratelimit";

rateLimit: memory({ requests: 60, window: 600 }),

Upstash

upstash() speichert die Zählung in Upstash Redis, das alle Instanzen gemeinsam nutzen. Erstelle eine Datenbank (auf Vercel fügst du Upstash über den Marketplace hinzu) und setze dann ihren REST-Endpunkt und ihr Token als UPSTASH_REDIS_REST_URL und UPSTASH_REDIS_REST_TOKEN. Blume spricht direkt mit der REST-API von Upstash, du musst also nichts installieren. Solange nicht beide gesetzt sind, zählen die Routen im Speicher, und blume build gibt eine Warnung aus.

import { upstash } from "blume/ratelimit";

rateLimit: upstash(),

Cloudflare

cloudflare() zählt mit Workers Rate Limiting und ist für Seiten gedacht, die mit deployment: cloudflare() deployt werden. Blume deklariert das Binding beim Build in der Konfiguration des Workers, du musst also nichts einrichten. Cloudflare zählt pro Standort und erlaubt nur ein Zeitfenster von 10 oder 60 Sekunden. Deshalb liegen die Standardwerte hier bei 10 Anfragen pro 60 Sekunden.

import { cloudflare } from "blume/deploy";
import { cloudflare as cloudflareRateLimit } from "blume/ratelimit";

export default defineConfig({
  deployment: cloudflare(),
  rateLimit: cloudflareRateLimit({ requests: 10, window: 60 }),
});

Der Namespace des Bindings wird aus dem Namen des Workers abgeleitet, sodass sich zwei Seiten in einem Account keine Zählung teilen. Mit namespaceId legst du ihn selbst fest.

Deaktivieren

Setze rateLimit: false, um jede Anfrage durchzulassen, zum Beispiel wenn die Firewall deines Hosts diese Routen bereits begrenzt. Eine Anfrage, deren Adresse der Host nicht ermitteln kann, wird immer durchgelassen. Dasselbe gilt für eine Anfrage, die ein gemeinsamer Store nicht zählen kann. Der Fehler wird dann geloggt, und ein Ausfall des Stores sperrt nie Leser aus.

Kombiniere Rate Limiting beim Assistenten mit einer Bot-Prüfung, um Skripte zu stoppen, die ihre Anfragen auf viele Adressen verteilen.