// app/api/geo-check/route.ts
import { NextResponse } from 'next/server';
// Forțăm rularea pe Edge Runtime pentru cold-start instant (<20ms)
export const runtime = 'edge';
export async function GET(request: Request) {
// Header furnizat de CDN/Vercel la Edge
const country = request.headers.get('x-vercel-ip-country') || 'RO';
const city = request.headers.get('x-vercel-ip-city') || 'Unknown';
// Puteți folosi doar Web APIs standard (fetch, Response, headers)
return NextResponse.json({
status: 'ok',
location: { country, city },
timestamp: Date.now(),
});
}Anul trecut am lucrat la refacerea unui serviciu de e-commerce cu vreo 15k vizitatori unici pe zi. Toată lumea pe Twitter lăuda Edge Runtime în Next.js — latență zero, cold start instant, rulare aproape de client. Așa că am zis să fiu deștept și am schimbat export const runtime = 'edge' pe aproape toate Route Handler-ele din App Router. În două ore eram pe Slack căutând de ce nu mai mergea checkout-ul.
Nu mă înțelege greșit, Edge Runtime e fabulos când înțelegi exact ce este și ce restricții are. Dar dacă treci de la Node.js la Edge crezând că e doar un Node mai rapid, o să ai o surpriză neplăcută.
Cold start și latență: unde câștigă Edge cu adevărat
Principala diferență stă în modul de execuție. Node.js runtime pornește un container sau un proces separat Node. Când serverul e 'rece' (fără trafic o perioadă), primul request plătește o taxă: cold start-ul. La Node.js, pe serverless (gen Vercel sau AWS Lambda), cold start-ul poate fi lejer între 250ms și 1.2 secunde, în funcție de cât de mare e bundle-ul tău și câte pachete ai în node_modules.
Edge Runtime folosește V8 Isolates (aceeași tehnologie ca din Cloudflare Workers). Nu pornește un mediu Node întreg, ci doar creează un context izolat în browser-like engine. Câștigul? Cold start sub 15-20ms.
Am mutat o rută de Geo-Pricing pe Edge și am văzut scăderea TTFB-ului de la 320ms la 42ms pentru utilizatorii din Asia. Pentru că ruta rula fizic la un POP (Point of Presence) din Singapore, mai aproape de ei, fără să mai facă round-trip până în regiunea principală AWS din Frankfurt.
Zidul de care te lovești: Ce NU merge pe Edge
Aici apar înjurăturile la 11 noaptea. Edge Runtime NU este Node.js. Este un subset redus de Web APIs (gen fetch, TransformStream, Request, Response).
Dacă în codul tău sau în pachetele tale din node_modules ai vreun import de genul:
fs(file system)child_processnetsautls- Anumite pachete de
cryptovechi
...proiectul va crăpa la build sau direct în runtime. Am pierdut vreo 3 ore încercând să fac un SDK vechi de plăți să meargă pe Edge, doar ca să-mi dau seama că folosea un modul nativ C++ pentru semnarea tranzacțiilor.
Iar dacă folosești Prisma ORM clasic fără un HTTP proxy (cum e Prisma Accelerate sau Neon serverless driver), conexiunile de TCP directe la PostgreSQL vor eșua lamentabil pe Edge.
Regula mea simplă: Când folosești Edge și când rămâi pe Node
După mai multe teste, am ajuns la o regulă internă destul de clară pe care o aplicăm pe toate proiectele:
Folosește Edge doar pentru:
- Middleware (unde oricum ești obligat de Next.js să folosești Edge)
- Rutare geografică sau A/B testing simplu bazat pe cookiere
- Pre-render / Auth token check rapid înainte de redirect
- API-uri ultra-simple care doar apelează un alt API extern prin HTTP
fetch
Rămâi pe Node.js runtime pentru:
- Oricare Server Action sau API Route care vorbește direct cu baza de date prin SQL/ORM clasic
- Generare de PDF-uri, manipulare de imagini (Sharp), parsare de fișiere
- Integrare cu SDK-uri legacy sau librării mari care depind de pachete native Node
Schimbarea de runtime nu e o soluție magică pentru cod scris prost. Dacă API-ul tău face 5 query-uri lente în DB, Edge nu te va salva. Voi ce experiență aveți cu Edge pe proiectele din producție? Ați lăsat totul pe Node sau ați împărțit rutele?