// app/api/geo/route.ts
export const runtime = 'edge'; // Forțează rularea pe Edge
export async function GET(request: Request) {
// Header-ul ăsta e injectat direct la nivel de CDN
const country = request.headers.get('x-vercel-ip-country') || 'RO';
return new Response(JSON.stringify({ country, edge: true }), {
headers: { 'content-type': 'application/json' },
});
}Am trecut recent un serviciu de geolocație de pe Node.js pe Edge runtime în Next.js și am scăzut cold start-ul de la 350ms la aproape zero. Sună ca o victorie rapidă, dar tranziția m-a costat vreo două nopți pierdute cu biblioteci de npm care pur și simplu au refuzat să ruleze. Dacă vrei să știi când merită să faci switch-ul și unde o să te lovești direct de zid, hai să le luăm la rând.
Iluzia de viteză și cifrele reale
Edge runtime rulează pe V8 izolate (cum are Cloudflare Workers), nu pe un mediu Node.js complet. Asta înseamnă că nu încarcă tot runtime-ul de Node la fiecare pornire la rece.
La un proiect cu vreo 12.000 de utilizatori activi pe zi, aveam niște API routes în Next.js care făceau doar un mic query și returnau un JSON personalizat în funcție de țară. Pe Node.js (pe Vercel, în regiunea fra1), cold start-ul ne ducea uneori în 400ms dacă funcția nu mai fusese apelată recent. După ce am mutat ruta pe Edge, cold start-ul a scăzut la sub 20ms. Practic instantaneu.
Dar aici intervine compromisul de care te lovești repede. Edge e genial pentru chestii ultra-rapide: redirecționări bazate de geo-IP, headers rescrise, sau mici validări de token-uri JWT.
Unde se rupe filmul și de ce o să înjuri
Dacă ai impresia că poți să muți tot proiectul pe Edge cu un simplu config, te înșeli amarnic. Edge runtime nu are acces la API-urile native de Node.js.
Ai nevoie de fs ca să citești un fișier local? Nu funcționează. Folosești o librărie veche de criptografie care se bazează pe module interne de Node? O să îți dea eroare la build.
Cea mai mare durere de cap am avut-o cu baza de date. Majoritatea driverelor tradiționale de PostgreSQL (cum e pg) folosesc TCP sockets. În Edge runtime nu ai suport de TCP direct out-of-the-box. Dacă vrei să te conectezi la baza de date din Edge, trebuie să folosești un HTTP Connection Pooler (cum are Prisma Data Platform sau Neon Serverless Driver) sau o bază de date HTTP-native ca Upstash. Dacă ai deja infrastructura clasică pe AWS RDS, mutarea pe Edge o să-ți complice viața inutil.
Când să rămâi pe Node.js și cum decizi
Regula mea e destul de simplă acum, după ce m-am ars cu câteva deploy-uri eșuate.
Rămâi pe Node runtime dacă:
- Faci procesare de imagini, PDF-uri sau orice operațiune CPU-heavy. Edge-ul are limite stricte de timp de rulare (de obicei 50ms de CPU execution time pe request).
- Ai nevoie de librării mari din npm care nu sunt compatibile cu mediile Web Workers.
- Te conectezi direct la o bază de date SQL clasică fără un proxy HTTP.
Treci pe Edge runtime doar dacă ai rute de API critice pentru latență (cum ar fi auth checks, geolocație sau dynamic personalization la nivel de CDN) și poți rezolva totul cu fetch-uri HTTP rapide.
Până la urmă, Edge nu e un înlocuitor pentru Node, ci o unealtă de optimizare fină. Voi ați încercat să mutați rute complexe pe Edge în producție? Ce librării v-au dat cele mai mari bătăi de cap?