import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
// Activăm explicit rularea pe Edge la nivel de rută
export const runtime = 'edge';
export function GET(request: NextRequest) {
// Pe Edge avem acces nativ la header-ele geografice oferite de CDN
const country = request.geo?.country || 'RO';
const city = request.geo?.city || 'București';
return NextResponse.json({
message: 'Salutare de pe Edge!',
location: `${city}, ${country}`
});
}Am tot văzut hype-ul ăsta cu Edge runtime în Next.js și cum promite Vercel că rezolvă toate problemele de latență din lume. Am trecut un API cu 15.000 de request-uri pe zi de pe Node pe Edge ca să văd dacă merită cu adevărat. Vă spun direct ce am pățit, ce s-a rupt în producție și unde am simțit o îmbunătățire reală.
Diferența reală și de ce contează cold start-ul
Node runtime pornește un mediu complet în spate. Chiar și pe serverless, când vine un request după o perioadă de inactivitate, durează până se trezește containerul. La proiectul nostru, cold start-ul pe Node (pe AWS Lambda în spatele Vercel) era undeva pe la 1.5 secunde. Pentru un endpoint de căutare rapidă, latența asta e moartea conversiilor.
Edge runtime folosește V8 isolates, adică aceeași tehnologie din spatele Google Chrome sau Cloudflare Workers. Nu mai ai un sistem de operare întreg în spate. Rezultatul? Cold start-ul a scăzut de la 1.5 secunde la sub 40 de milisecunde. Practic, utilizatorul nu mai simte nicio agățare, iar serverul răspunde instantaneu. În plus, costurile de rulare scad drastic pentru că resursele alocate sunt minime.
Unde se rupe filmul: Limitări de care m-am lovit
Sună perfect, nu? Ei bine, aici vine acel trade-off sincer despre care nu prea se vorbește în materialele de marketing. Când treci pe Edge, renunți la aproape tot ecosistemul Node.js.
Nu ai acces la modulul fs (file system), la path sau la alte chestii de bază. Am vrut să folosesc o librărie clasică de manipulare a imaginilor și am primit un ecran plin de erori la build. Orice librărie npm care are dependențe native de C++ sau folosește API-uri de Node nesprijinite va crăpa instantaneu.
Altă problemă majoră: conexiunea la baza de date. Dacă folosești un PostgreSQL clasic pe o conexiune TCP standard, nu o poți folosi direct în Edge runtime. A trebuit să trecem pe driverul HTTP de la Neon și să folosim un WebSocket connection pooler. Ne-a luat vreo două zile de debugging doar ca să facem interogările simple să meargă fără să blocăm baza de date la spike-uri de trafic.
Când să folosești Edge și când să rămâi pe Node
Regula mea de deget după experiența asta e destul de simplă și clară:
Folosește Edge pentru:
- Middleware (redirecționări rapide, verificări de sesiuni, A/B testing).
- API-uri simple care doar apelează alte API-uri externe (proxy-uri).
- Geolocation și personalizare de conținut în funcție de IP-ul utilizatorului.
Rămâi pe Node pentru:
- Logica de business complexă care necesită librării grele (criptografie complexă, generare de PDF-uri, procesare video/imagini).
- Conexiuni directe la baze de date tradiționale unde nu ai un proxy HTTP/WebSocket.
- Rute unde cold start-ul de 1.5 secunde nu afectează critic experiența (de exemplu, un webhook de la Stripe).
Edge runtime e o unealtă fantastică dacă înțelegi că nu e un înlocuitor universal pentru Node. Noi am lăsat pe Edge doar middleware-ul și endpoint-ul de autocomplete, iar restul aplicației rulează fericită pe Node standard.
Voi ce experiențe ați avut cu Edge în Next.js? V-ați lovit de limitările de conexiune la baze de date sau a mers totul din prima?