import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
// Specificăm explicit runtime-ul pentru această rută
export const runtime = 'edge';
export async function GET(request: NextRequest) {
const country = request.geo?.country || 'RO';
const ip = request.ip || '127.0.0.1';
// Edge e excelent pentru logică rapidă bazată pe headers/geo
if (country === 'US') {
return NextResponse.json({ message: 'Redirected to US region', ip });
}
return NextResponse.json({
status: 'ok',
country,
runtime: 'edge-v8'
});
}Toată lumea laudă Edge runtime pentru că scapă de cold start, dar mutarea unui API route sau Server Component pe Edge nu e întotdeauna un upgrade gratuit. Am făcut greșeala asta acum un an la o aplicație cu vreo 12.000 de utilizatori activi zilnic și am pierdut două zile depanând module care pur și simplu nu existau în mediul V8 isolates.
Diferența de latență și cold start
Node runtime pornește un container complet sau o mașină virtuală serverless. Asta înseamnă că dacă endpoint-ul tău n-a fost apelat recent, un cold start pe Node îți ia lejer 250ms până la 600ms, mai ales dacă ai un bundle voluminos cu biblioteci grele încărcate în memorie.
Pe Edge, codul rulează în lightweight isolates (similar cu Cloudflare Workers sau V8 engine pur). Cold start-ul scade instant sub 20-30ms, adesea insesizabil pentru utilizator. În plus, codul rulează în data center-ul cel mai apropiat de user, nu într-o singură regiune fixă gen fra1 sau iad1.
Dacă ai un endpoint care doar citește un JWT, validează un cookie sau returnează un răspuns dintr-un KV store, Edge e imbatabil.
Unde te lovești cu capul de pereți
Problema e că Edge runtime nu este Node.js. Nu ai acces la majoritatea API-urilor native: fs, child_process, net, tls sau buffer-uri clasice în unele implementări vechi.
Am pățit de exemplu să vreau să generez un PDF pe Edge cu o bibliotecă populară de npm. Nicio șansă: biblioteca depindea intern de stream din Node și canvas. Totul a crăpat la build time cu erori criptice despre module native lipsă.
La fel și cu bazele de date clasice:
- Dacă folosești Prisma sau TypeORM cu conexiune TCP directă către un Postgres găzduit în Frankfurt, un Edge handler executat dintr-un PoP din Tokyo nu te ajută deloc. Ba chiar adaugă latență la connection pooling.
- Ca să meargă decent pe Edge, ai nevoie de HTTP-based database drivers (gen Neon serverless, PlanetScale, Turso) sau connection poolers de tip Prisma Accelerate.
Mai e și limita de memorie și execuție: pe Edge ai limite stricte de CPU time (adesea 50ms per request pe planurile standard), așa că orice transformare grea de date sau parsare JSON gigant îți va da un 504 Gateway Timeout rapid.
Regula mea practică: când alegi Edge vs Node
Nu optimiza prematur. După mai multe proiecte trecute prin ambele variante, am rămas la o împărțire simplă:
- Merită Edge: Auth middleware, geo-routing / feature flags, proxy-uri către API-uri externe (de exemplu streaming de răspunsuri LLM de la OpenAI) și cache invalidation.
- Rămâi pe Node: Procesare de fișiere/imagini, conexiuni directe de DB fără pooling HTTP, exporturi de rapoarte sau orice librărie npm mai veche care nu respectă Web Standards (Fetch API, Web Streams).
Edge câștigă când e folosit ca bouncer sau gateway la marginea rețelei, în timp ce Node rămâne calul de bătaie pentru business logic serios. Voi ce ați mutat pe Edge și v-a părut rău după primul deploy?