// Configurare simplă pentru a activa Edge Runtime într-o rută de API
export const runtime = 'edge';
export default async function handler(req) {
const { searchParams } = new URL(req.url);
const name = searchParams.get('name') || 'World';
return new Response(
JSON.stringify({ message: `Salut, ${name} de pe Edge!` }),
{
status: 200,
headers: { 'content-type': 'application/json' },
}
);
}M-am lovit recent de o dilemă pe un proiect unde aveam nevoie de latență minimă pentru utilizatorii din Asia, deși serverul principal era în Frankfurt. Am început să mă joc cu Edge Runtime în Next.js și mi-am dat seama repede că nu e totul lapte și miere. Dacă nu ești atent, te trezești că pui runtime: 'edge' și jumătate din dependințele tale din npm crapă instant.
Diferența care contează la factură și viteză
Node.js runtime e bătrânul clasic. Ai tot ecosistemul la dispoziție, poți să scrii fișiere, să folosești librării grele de criptografie sau să generezi PDF-uri. Problema? Cold start-ul. Pe Vercel sau AWS Lambda, dacă funcția ta n-a mai fost apelată de 5 minute, durează și 2-3 secunde până se trezește la viață. La un proiect cu 8k useri activi, am observat că sesiunile noi aveau un delay vizibil la prima încărcare, ceea ce e frustrant.
Edge Runtime e altă mâncare de pește. Nu e un Node.js complet, ci un subset bazat pe motorul V8, similar cu ce se întâmplă în Cloudflare Workers. Partea mișto: pornește instant (sub 10ms) și rulează fizic aproape de user. Am reușit să reduc timpul de răspuns pentru un API de personalizare a conținutului de la 450ms la sub 60ms doar prin mutarea pe Edge.
Unde apar problemele (Trade-offs)
Am pățit-o cu jsonwebtoken. Voiam să verific un token pe Edge și surpriză: librăria standard folosește module native de Node care nu există în Edge. A trebuit să trec pe jose, care e mult mai light și compatibilă.
Iată ce pierzi pe Edge:
- Nu ai acces la
fs(file system). Uită de citit fișiere locale în timpul execuției. - Limită de memorie mult mai mică. Dacă în Node poți să tragi 512MB sau 1GB lejer, pe Edge ești limitat drastic (adesea sub 128MB).
- Nu poți folosi
eval()sau alte funcții dinamice care încalcă politicile de securitate V8.
Un alt aspect e conexiunea la baza de date. Dacă baza ta e în US-East și tu rulezi codul pe Edge în Singapore, latența dintre funcția Edge și DB o să anuleze orice câștig de viteză. Am învățat asta pe pielea mea: Edge e util doar dacă ai o bază de date distribuită (gen Upstash sau Neon cu read replicas) sau dacă API-ul tău nu depinde de DB.
Când să faci switch-ul?
Eu folosesc regula asta simplă: dacă ruta mea de API doar face un proxy către alt serviciu, verifică un header sau face un redirect, merge direct pe Edge. Dacă am nevoie de logică complexă, procesare de imagini sau librării legacy care „țipă” după Node, rămân pe Node.
Pe un proiect recent de e-commerce, am mutat doar middleware-ul și rutele de autentificare pe Edge. Am economisit cam 20% la costurile de compute și am scăpat de plângerile clienților legate de „site-ul care se agață la login”.
Node runtime rămâne regele pentru „heavy lifting”, dar Edge e viitorul pentru tot ce înseamnă interfață rapidă și logică de rutare. Voi ați încercat să mutați tot stack-ul pe Edge sau v-ați blocat în limitările de librării?