// app/api/geo-check/route.ts
// Schimbarea runtime-ului în Next.js App Router se face printr-o simplă exportare de variabilă
export const runtime = 'edge';
export async function GET(request: Request) {
const country = request.headers.get('x-vercel-ip-country') || 'RO';
// Răspuns ultra-rapid, sub 20ms, direct din cel mai apropiat punct CDN
return Response.json({
country,
message: "Rulat direct pe Edge isolate, fără cold start persistent."
});
}S-a tot făcut hype pe Edge runtime în Next.js, de zici că Node.js e gata de pensionare și că dacă nu muți totul pe Edge ești depășit. Am trecut și eu prin febra asta la un proiect destul de măricel, cu vreo 12k utilizatori activi zilnic, și m-am lovit cu capul de pragul de sus. Hai să vorbim pe cifre și pe ce doare cu adevărat în producție, fără marketingul de la Vercel.
Câștigul principal când treci pe Edge este viteza de răspuns inițială. Dar prețul plătit în limitări de ecosistem te poate face să regreți decizia destul de repede.
Cold start-ul: Hype vs Realitate
Pe Node runtime (folosind serverless functions pe Vercel sau AWS Lambda), cold start-ul este o realitate dureroasă. Am avut cazuri unde o funcție neapelată de câteva minute avea nevoie de 300ms până la chiar 1.2 secunde ca să se trezească și să răspundă. Pentru un API de checkout, secunda aia în plus înseamnă conversii pierdute.
Pe Edge runtime, povestea se schimbă radical. Pentru că rulează pe V8 isolates (gândește-te la ceva similar cu Cloudflare Workers), cold start-ul scade la sub 15-20ms. Practic, nu există. Codul tău pornește instant și rulează fizic mai aproape de utilizator, pe cel mai apropiat server din CDN.
Sună ideal, nu? Ei bine, aici apar problemele de compatibilitate.
Unde se rupe filmul: Limitările tehnice
Edge nu rulează un mediu Node.js complet. Asta înseamnă că nu ai acces la API-urile native din Node. Vrei să folosești fs ca să citești un fișier local? Nu poți. Ai o librărie mai veche de criptografie care se bazează pe module scrise în C++? N-o să compileze pe Edge.
Cea mai mare durere am avut-o cu conexiunile la baza de date. Dacă folosești un PostgreSQL clasic și vrei să te conectezi direct prin TCP, Edge-ul te lasă baltă pentru că nu are suport nativ pentru socket-uri TCP clasice (deși lucrurile se mai îmbunătățesc cu API-ul connect de la Cloudflare). Ca să funcționeze, a trebuit să trecem prin HTTP-based connection pooling (folosind Neon sau Prisma Accelerate). Asta înseamnă costuri în plus și complexitate adăugată doar ca să putem rula pe Edge.
De asemenea, librării populare precum sharp (folosită pentru procesare de imagini) sau generatoare de PDF-uri pur și simplu nu funcționează acolo.
Când să folosești Edge și când să rămâi pe Node
După ce am mutat jumătate de aplicație pe Edge și apoi am dat rollback la o parte din ea, am ajuns la niște reguli simple:
Rămâi pe Node runtime dacă:
- Aplicația ta face interogări grele direct în baze de date SQL/NoSQL tradiționale fără un proxy HTTP.
- Ai nevoie de librării npm complexe (procesare de fișiere, PDF-uri, criptografie custom).
- Ai un monolită Next.js clasic și nu vrei să rescrii jumătate din integrările externe.
Treci pe Edge runtime dacă:
- Scrii Middleware (aici oricum ești obligat de Next.js să folosești Edge pentru performanță).
- Ai endpoint-uri de API simple, de tip proxy sau webhooks, care doar pasează date mai departe.
- Faci personalizare de conținut bazată pe geolocație sau cookies direct la nivel de request (A/B testing).
În Next.js poți schimba runtime-ul extrem de simplu, per rută sau per pagină, ceea ce este un mare plus. Nu trebuie să fie o decizie de tipul "totul sau nimic".
La final, am lăsat 90% din rutele de API pe Node runtime și am mutat pe Edge doar middleware-ul și două endpoint-uri critice de geolocație unde cold start-ul chiar conta. Am salvat timp, nervi și am păstrat compatibilitatea cu toate librăriile de care aveam nevoie.