import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";
// Configurare limiter pentru Edge / Cloudflare Workers
const ratelimit = new Ratelimit({
redis: Redis.fromEnv(),
limiter: Ratelimit.slidingWindow(10, "10 s"), // max 10 req pe secunda
});
export async function middleware(request: Request) {
const ip = request.headers.get("x-forwarded-for") ?? "127.0.0.1";
const { success, limit, reset, remaining } = await ratelimit.limit(ip);
if (!success) {
return new Response("Te-ai grăbit! Prea multe request-uri.", {
status: 429,
headers: {
"X-RateLimit-Limit": limit.toString(),
"X-RateLimit-Remaining": remaining.toString(),
"X-RateLimit-Reset": reset.toString(),
},
});
}
}Am văzut prea des API-uri puse la pământ de un script amărât de scraping sau de vreun client web care a uitat un loop infinit în frontend. Rate limiting-ul nu e opțional, dar mulți sar direct la soluții complexe fără să înțeleagă unde trebuie pus filtrul.
Hai să trecem prin cele trei abordări pe care le-am tot folosit în ultimii ani, cu bune și rele.
1. Nginx: Prima linie de apărare
Dacă vrei doar să oprești atacurile brute-force sau roboții agresivi înainte ca request-urile să atingă codul tău de Node, Go sau Python, Nginx e regele absolut. Totul se întâmplă la nivel de infrastructură, extrem de rapid și cu consum minim de resurse.
La un proiect cu vreo 15k useri activi pe zi, aveam probleme mari cu boții care scanau rutele de login. Am configurat o zonă de limit_req în Nginx, limitând la 5 request-uri pe secundă per IP pe rutele sensibile. Încărcarea pe serverele de aplicație a scăzut cu 40% instant, pentru că request-urile malițioase nici nu mai ajungeau la Node.js.
- Trade-off: E excelent pentru throttling global pe IP, dar e rigid. Dacă vrei reguli dinamice (de exemplu, limite diferite pentru useri free vs. premium), Nginx devine un coșmar de configurat și întreținut. Nginx nu știe cine e logat în baza ta de date fără să facă el însuși un request suplimentar.
2. Redis self-hosted: Control total în aplicație
Când ai nevoie de logică de business (userul X are voie 100 de request-uri pe oră, iar userul premium are 5000), muți logica în cod și folosești Redis. Redis este în memorie, deci e incredibil de rapid — sub 1ms latență dacă este în aceeași rețea cu API-ul tău.
De obicei folosesc algoritmul Sliding Window Counter implementat printr-un script Lua în Redis. Asta previne acele „race conditions” care apar când un user trimite 10 request-uri concurente în exact aceeasi milisecundă.
- Trade-off: Trebuie să administrezi tu instanța de Redis. Dacă pică Redis, îți pică și rate limiter-ul (sau trebuie să ai fallback pe "allow all", ceea ce e riscant). Plus costurile de infrastructură și mentenanța unui cluster dacă proiectul crește.
3. Upstash Ratelimit: Alternativa pentru serverless
Dacă rulezi pe Vercel, Netlify sau AWS Lambda, nu vrei să ții conexiuni TCP deschise permanent către un Redis clasic. Aici intervine Upstash, un Redis serverless accesibil prin HTTP.
Am folosit SDK-ul lor (@upstash/ratelimit) la un API de inteligență artificială unde taxam utilizatorii per token consumat. Integrarea a durat literalmente 10 minute și am scăpat de grija scalării bazei de date de limitare.
- Trade-off: Plătești la numărul de request-uri. Dacă ai un atac masiv de tip DDoS, te poate costa o avere comparativ cu o regulă simplă în Nginx. De asemenea, fiind un API extern, adaugi o latență de 10-25ms la fiecare verificare, în funcție de regiune.
Cum alegeți? Nginx pentru securitate brută la intrare, Redis pentru aplicații clasice monolit sau microservicii cu logică custom, iar Upstash pentru arhitecturi serverless și edge. Voi ce folosiți în producție?