export const runtime = 'edge'; // Forțează Edge Runtime pentru această rută
export async function GET(request: Request) {
// Merge excelent: verificare IP, header-uri și răspunsuri rapide
const country = request.headers.get('x-vercel-ip-country') ?? 'RO';
return Response.json({
message: 'Hello from the edge!',
country,
timestamp: Date.now()
});
}Toată lumea a auzit promisiunea Vercel: pune totul pe Edge și ai latență infimă, cold start de câteva milisecunde și utilizatori fericiți pe tot globul. Realitatea din producție e însă mult mai nuanțată, iar dacă schimbi orbește runtime-ul global, o să dai rapid cu capul de tavan.
Am făcut greșeala asta acum un an pe o aplicație de tip SaaS B2B cu vreo 15k utilizatori activi zilnic, migrând aproape toate API routes pe runtime: 'edge'. A durat două zile până când tichetele de suport au început să curgă.
Cold start și iluzia vitezei absolute
Pe Node.js runtime (serverless clasic pe AWS Lambda), un cold start te costă în mod realist între 250ms și 800ms, în funcție de mărimea bundle-ului și de pachetele importate. Pe Edge (V8 isolates), cold start-ul scade la 15-40ms. Pare o victorie uriașă la prima vedere.
Dar apare problema fizicii de rețea. Dacă utilizatorul tău e în Tokyo, Edge function-ul pornește instantaneu în Tokyo. Dacă baza ta de date PostgreSQL stă în eu-central-1 (Frankfurt), funcția din Tokyo va face un roundtrip de 220ms pentru fiecare query la DB. În Node runtime pe Frankfurt, cold start-ul doare o singură dată la câteva minute, dar latența către baza de date e de sub 2ms. Dacă ai 3 query-uri secvențiale într-un endpoint, Edge-ul iese considerabil mai lent.
Ce crapă imediat pe Edge runtime
Edge nu e Node. E un mediu bazat pe V8 isolates (similar cu Cloudflare Workers sau Deno), ceea ce înseamnă că nu ai acces la API-urile native de Node:
- Nu ai
fs,child_processsaunet. - Bibliotecile care depind de C++ bindings native nu funcționează (de exemplu, unele versiuni de
sharpsau pachete de generat PDF-uri). - Driverele clasice de baze de date (precum
pgsau clientul standard de Prisma) crapă instant pentru că nu pot ține conexiuni TCP persistente clasice. Trebuie să treci pe HTTP/WebSocket drivers (Neon Serverless, PlanetScale, Turso) sau Prisma Accelerate. - Mărimea bundle-ului e limitată strict (de regulă 1MB sau 4MB în funcție de plan), așa că un pachet mai gras te scoate din schemă la build time.
Când are sens să schimbi runtime-ul
Trade-off-ul e simplu: Edge e fenomenal dacă nu ai dependențe grele și nu faci query-uri grele de SQL.
Folosește Edge pentru:
middleware.ts(unde verifici JWT-uri stateless, redirecționezi pe bază de geolocație sau rescrii headere);- Proxy-uri simple și agregări de API-uri externe;
- Endpoint-uri de tip streaming cu LLM-uri (OpenAI, Anthropic), unde vrei ca primul token să plece spre client instantaneu;
- Webhook-uri simple care doar pun un mesaj într-un queue (de exemplu Upstash/QStash).
Rămâi pe Node.js pentru:
- Orice rută cu ORM clasic, tranzacții complexe de baze de date sau connection pooling clasic;
- Prelucrare de imagini, video sau generare de rapoarte/facturi în memorie;
- Logica de business masivă care folosește SDK-uri de la terți scrise acum 5 ani fără compatibilitate V8.
Node runtime rămâne opțiunea sigură pentru 80% din aplicațiile web standard. Voi unde ați simțit cel mai mult limitările pe Edge?