// app/api/geo/route.ts
export const runtime = 'edge'; // Activăm Edge runtime pentru această rută
export async function GET(request: Request) {
// Header specific Vercel pentru geolocație
const country = request.headers.get('x-vercel-ip-country') || 'RO';
return Response.json({
country,
message: "Cold start redus la zero direct de la Edge"
});
}Am tot văzut discuții pe grupuri despre când naiba ar trebui să treci o rută de API sau o pagină din Next.js pe Edge Runtime. Mulți dau click pe opțiunea aia crezând că e un fel de cheat code pentru performanță gratuită, dar realitatea te lovește rapid în producție. Hai să vedem unde merită efortul și unde îți prinzi urechile în erori ciudate de build.
Edge runtime: Ce este de capul lui?
Edge runtime rulează pe V8 isolates (gândește-te la tehnologia din spatele Cloudflare Workers). Nu ai un mediu Node.js complet în spate. Asta înseamnă că este incredibil de rapid și are un cold start practic inexistent (sub 10ms, adesea chiar zero).
Am avut un proiect anul trecut, un SaaS cu vreo 12k de useri activi, unde făceam geo-routing și personalizarea paginii de landing în funcție de țară. Pe Node runtime, aveam un delay vizibil când redirectam userii. Am mutat middleware-ul și rutele de localizare pe Edge. Rezultatul? Am scăzut LCP-ul (Largest Contentful Paint) cu aproape 350ms pentru userii din afara Europei.
Dar vine cu un mare minus: nu ai API-urile native din Node.js. Uită de fs, child_process sau pachete criptografice vechi. Dacă o librărie de care depinzi folosește ceva nativ din C++ sau module interne de Node, build-ul tău în Vercel va crăpa instant.
Node.js runtime: Dinozaurul pe care ne bazăm
Node.js este runtime-ul clasic. Vine la pachet cu toată compatibilitatea din lume. Vrei să folosești bcrypt pentru hashing de parole sau să generezi PDF-uri grele în spate? Node e singura ta șansă reală.
Trade-off-ul major este cold start-ul. Pe serverless (Vercel, AWS Lambda), dacă funcția ta nu a mai fost apelată de ceva timp și bundle-ul tău e măricel, primul user va aștepta între 1.5 și 3 secunde doar ca să se trezească containerul. Am pățit asta la o platformă de cursuri online unde rutele de analiză aveau cold start de 2 secunde după câteva ore de inactivitate.
Marea problemă: Conexiunile la baza de date
Aici se rupe filmul pentru mulți care trec pe Edge. Driverele tradiționale de baze de date (cum e clasicul pg pentru PostgreSQL) folosesc TCP sockets sub capotă. Edge runtime nu suportă TCP clasic în mod nativ direct din cutie, ci are nevoie de conexiuni HTTP sau WebSockets.
Dacă încerci să conectezi o bază de date clasică direct dintr-o rută de Edge folosind Prisma fără niciun workaround, o să ai o surpriză neplăcută. Ca să funcționeze pe Edge, trebuie să folosești soluții ca Prisma Accelerate, Neon Serverless Driver sau PlanetScale, care știu să comunice prin protocoale web.
Cum alegi de fapt?
Regula mea de aur e simplă și o aplic la orice proiect nou:
- Folosește Edge pentru: middleware-uri, API-uri simple de redirecționare, rute de webhook care doar trimit un mesaj mai departe, sau când folosești baze de date globale cu API HTTP (cum e DynamoDB sau Firebase).
- Rămâi pe Node pentru: query-uri complexe în baze de date relaționale clasice, manipulare de imagini (Sharp), generare de PDF-uri sau când folosești librării npm mari unde nu vrei să stai să depanezi de ce nu au suport de V8.
Voi cum ați gestionat cold start-urile pe Node în Next.js? Ați trecut complet pe Edge sau ați preferat să optimizați bundle-ul?