// Cum forțezi runtime-ul în Next.js (App Router)
export const runtime = 'edge'; // sau 'nodejs' (default)
export async function GET(request: Request) {
// Atenție: Aici nu poți folosi librării de Node.js
// Doar Web Standard APIs (fetch, Response, etc.)
return new Response(JSON.stringify({ message: "Salut de pe Edge!" }), {
status: 200,
headers: { 'content-type': 'application/json' }
});
}Am tot văzut confuzia asta pe Slack și prin comunități în ultima vreme: „Dacă pun totul pe Edge în Next.js, aplicația o să zboare, nu?”. Răspunsul scurt e: depinde ce ai băgat în package.json și cât de mult te bazezi pe ecosistemul clasic de Node.js.
Recent, am lucrat la un proiect de e-commerce unde cold start-urile ne omorau pe regiunea US-East. Avem un API de checkout care pleca de la 800ms - 1.2s cold start pe Node.js (Vercel Lambdas standard). Clienții simțeau lag-ul ăla nesimțit la prima interacțiune. Am zis să trecem totul pe Edge Runtime. Rezultatul? Cold start-ul a scăzut la sub 50ms, dar ne-am lovit de un zid de care nu ne-am dat seama din prima.
Diferența de mindset între Edge și Node
Node.js runtime e practic tot ce știi: ai acces la tot setul de API-uri (fs, child_process, crypto nativ). E robust, dar e „greu”. Când cererea ajunge la o lambda de Node, containerul trebuie să se trezească, să încarce tot runtime-ul, și abia apoi rulează codul tău. De aici și secundele alea pierdute.
Edge Runtime e o cu totul altă bestie. E bazat pe motorul V8 (ca în Chrome), deci nu ai un OS întreg în spate. E ultra-light. Dar, și aici e buba, nu ai acces la API-urile de Node. Vrei să citești un fișier de pe disc cu fs? Nu poți. Vrei să folosești o librărie veche de criptografie care se bazează pe module native din C++? Mult noroc, nu o să meargă.
Unde m-am fript: Conexiunea la baza de date
Asta e cea mai mare capcană. Majoritatea driverelor de SQL (Postgres, MySQL) folosesc TCP sockets sub capotă. Edge Runtime, fiind bazat pe Web APIs, suportă în principal HTTP/Fetch. Dacă încerci să folosești un client de Prisma clasic pe Edge, o să primești o eroare lungă cât o zi de post pentru că Prisma are nevoie de motoare de query care nu rulează în V8 izolat.
Am rezolvat-o folosind un proxy de baza de date (ca Prisma Accelerate sau HTTP tunnel-ul de la Neon), dar asta a adăugat o latență extra care a cam anulat beneficiul de viteză inițial. Am economisit 30% la build time și cold start, dar am pierdut pe partea de execuție a query-urilor complexe.
Când să alegi Edge fără să regreți
Edge e imbatabil pentru Middleware. Dacă ai nevoie de redirecționări bazate pe geolocație, A/B testing sau verificări de autentificare rapide prin JWT, Edge e rege. Se execută „la marginea” rețelei, cel mai aproape de user.
Totuși, pentru rutele de API care fac heavy lifting — procesare de imagini (Sharp nu merge pe Edge!), generare de PDF-uri sau integrări cu SDK-uri de payment care încă se bazează pe Node internals — rămâi pe Node runtime.
Un alt aspect e limita de memorie. Pe Edge ai de obicei un buget mult mai mic (128MB sau 512MB pe unele platforme). La proiectul menționat, am încercat să procesăm un JSON masiv de vreo 40MB și Edge-ul a crăpat instant cu un Out of Memory, în timp ce Node-ul l-a „înghițit” fără probleme, chiar dacă mai lent.
Concluzia mea după 10+ ani de dev
Nu te arunca la Edge doar pentru că e „cool” sau pentru că scrie pe site-ul Vercel că e viitorul. Folosește Edge pentru logică mică, de rutare și securitate, și păstrează Node pentru tot ce înseamnă business logic complex și interacțiune cu DB-ul, cel puțin până când driverele de database-over-http devin standardul de aur.
Voi ce experiențe ați avut cu Edge? V-ați lovit de limitările de librării sau ați reușit să mutați tot stack-ul pe V8?