// app/api/geo-check/route.ts
import { NextResponse } from 'next/server';
// Forțează Edge Runtime pentru această rută specifică
export const runtime = 'edge';
export async function GET(request: Request) {
// Citim header-ele injectate de Edge Network
const country = request.headers.get('x-vercel-ip-country') || 'RO';
const city = request.headers.get('x-vercel-ip-city') || 'Bucuresti';
return NextResponse.json({
status: 'ok',
runtime: 'edge',
location: { country, city }
});
}Am trecut recent un proiect de Next.js cu vreo 12.000 de utilizatori zilnici de pe Node.js runtime pe Edge pentru câteva API routes și middleware, crezând că am găsit soluția magică pentru latență. M-am lovit de zid imediat ce am vrut să fac un query banal de Postgres. Dacă vrei să știi exact unde merită schimbarea și unde pierzi timpul degeaba, am adunat mai jos câteva concluzii trase direct din producție, nu din documentația roz.
Cold start-ul și iluzia vitezei absolute
Edge runtime rulează pe V8 Isolates (similar cu Cloudflare Workers), ceea ce înseamnă că nu pornește un proces întreg de Node.js la fiecare cold start. Pe serverless clasic, unde folosești Node runtime pe Vercel sau AWS Lambda, un cold start te costă lejer între 400ms și 1.5 secunde dacă ai pachete grele în build (cum ar fi AWS SDK sau manipulări complexe de date).
Pe Edge, cold start-ul scade drastic, de obicei sub 15-20ms, pentru că instanțele sunt deja calde la nivel global, aproape de utilizator. Sună impecabil pe hârtie, dar viteza asta vine cu un preț uriaș pe partea de compatibilitate.
Ce NU merge pe Edge (și ce te va face să înjuri)
Cea mai mare capcană este compatibilitatea cu pachetele din npm. Edge runtime NU este Node.js. Nu ai API-uri native de sistem: uită de fs, child_process sau net.
Am pățit-o direct cu driverul clasic de PostgreSQL (pg). Când am trecut ruta pe runtime = 'edge', build-ul a crăpat instant. Ca să legi Edge la o bază de date relatională, ești obligat să folosești HTTP proxies sau drivere modificate peste WebSockets (gen Neon, PlanetScale sau Prisma Data Proxy).
Trade-off-ul e clar:
- Edge e excelent pentru: middleware, geo-routing, A/B testing, verificare de token-uri JWT (folosind
jose, pentru căjsonwebtokentrage dependențe native din Node) și modificat header-e din zbor. - Edge e nasol pentru: procesare de imagini, generat PDF-uri, ORM-uri grele sau computație intensivă. Ai limite severe de CPU execution time (de obicei 30ms-50ms pe Vercel Pro).
Când schimbi runtime-ul și cum prioritizezi
Nu trece tot app-ul pe Edge doar pentru că e la modă. În Next.js App Router, poți seta runtime-ul per route handler sau per pagină, ceea ce e super flexibil.
Regula mea după câteva proiecte trecute prin asta:
- Middleware: Întotdeauna Edge. Acolo vrei latență minimă înainte să atingi oricare altă rută.
- Rute de Auth / Geo / Redirects: Edge. Răspunsul se dă instant din cel mai apropiat PoP (Point of Presence).
- CRUD clasic, rapoarte, DB queries grele: Rămâi pe Node.js runtime. Nu merită bătaia de cap să schimbi driverele de DB și să rescrii bucăți din app doar ca să economisești 200ms de cold start o dată la câteva ore.
Nu vă complicați arhitectura fără motiv. Lăsați Node runtime-ul să-și facă treaba unde aveți nevoie de tot ecosistemul npm, și folosiți Edge ca pe o sabie de precizie la marginea rețelei. Voi de ce bătăi de cap v-ați lovit când ați încercat să treceți rute complexe pe Edge?