// app/api/user-geo/route.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
// Forțăm executarea pe Edge Runtime
export const runtime = 'edge';
export async function GET(request: NextRequest) {
// Preluăm datele de geolocație injectate direct din Web APIs / Edge platform
const country = request.geo?.country || 'RO';
const city = request.geo?.city || 'Bucuresti';
// Web Crypto API este disponibil nativ pe Edge (spre deosebire de crypto din Node)
const uuid = crypto.randomUUID();
return NextResponse.json({
id: uuid,
location: `${city}, ${country}`,
timestamp: Date.now(),
});
}M-am lovit recent de o problemă sensibilă de latență pe o aplicație e-commerce care procesează în jur de 12.000 de utilizatori pe zi. Am zis că e momentul să trec agresiv rutele de API pe Edge runtime ca să scap de latențe. Rezultatul imediat a fost spectaculos la cifre, dar în 24 de ore am realizat că jumătate din pachetele noastre din npm crăpau silentios în producție.
Se vorbește mult despre cât de rapid e Edge-ul, dar puțini explică trade-off-urile reale de arhitectură din spatele deciziei ăsteia.
De la 450ms la 15ms cold start, dar cu ce preț?
Avantajul masiv al Edge runtime-ului e faptul că nu pornește un container greoi de Node.js. Folosește V8 Isolates, la fel ca Cloudflare Workers. Pornirea unei instanțe noi durează literalmente între 5 și 15 milisecunde, comparat cu un Serverless Function clasic de Node pe Vercel sau AWS Lambda care îți ia lejer 350-600ms dacă instanța e rece (cold start).
În plus, codul rulează fizic mai aproape de utilizator, pe servere CDN distribuite global. Dacă ai un user din Cluj și serverul tău principal de Node e în Frankfurt, un endpoint pe Edge răspunde din pop-ul de CDN din București sau Frankfurt fără timpul suplimentar de dus-întors al conexiunii TCP.
Problema apare când realizezi că Edge runtime NU este Node.js. Este un subset restrâns de Web APIs (cum ar fi fetch, Request, Response).
Ce NU merge pe Edge (și de ce te vei enerva)
Dacă vrei să treci o rută pe Edge, pregătește-te să renunți la tot ce depinde de module native de Node:
- Acces la sistemul de fișiere (
fs,path): Nu există fișiere locale. Orice librărie care încearcă să citească ceva din disc va arunca eroare la build time sau runtime. - Conexiuni directe prin TCP la baze de date: Driverele clasice precum
pgpentru PostgreSQL sau driverul nativ de MongoDB presupun un socket TCP persistent pe care V8 Isolates nu îl suportă nativ fără websockets sau HTTP proxies (cum e Prisma Accelerate sau Neon serverless driver). - Criptografie și module C++ bindings: Pachete gen
bcryptnu vor funcționa deloc. Trebuie să treci pejosesau Web Crypto API. - Limita de memorie și execuție: Pe multe platforme ai limite severe (ex: 128MB RAM și timeout de câteva secunde). Nu poți genera PDF-uri, nu poți procesa imagini cu
sharpși nu poți rulat job-uri grele de fundal.
Regula mea de aur în producție
După ce am reconfigurat arhitectura, am ajuns la o separare clară care funcționează impecabil de câteva luni:
- Folosesc Edge pentru: Middleware (redirect-uri de geolocație, AB testing, verificare de token JWT în cookiuri), rute de auth ultra-rapide și API-uri care fac doar proxy către alte microservicii sau servicii headless (Sanity, Stripe webhooks simple).
- Rămân pe Node.js pentru: Orice interacțiune directă și complexă cu baza de date relatională, generare de rapoarte, trimitere de email-uri, procesare de plăți complexe sau manipulare de fișiere.
Nu merită să pierzi trei zile scriind workaround-uri pentru un driver de DB doar ca să câștigi 50ms pe o rută de admin unde oricum intră doi oameni pe zi.
Cum ați abordat voi problema asta în proiectele voastre? Ați rămas pe Node runtime peste tot sau aveți o arhitectură hibridă?