import { NextRequest, NextResponse } from 'next/server';
// Forțăm Next.js să folosească Edge Runtime pe această rută
export const runtime = 'edge';
export async function GET(req: NextRequest) {
// Web APIs standard, fără 'fs' sau 'node:crypto'
const country = req.geo?.country || 'RO';
const authHeader = req.headers.get('authorization');
if (!authHeader) {
return NextResponse.json({ error: 'Neautorizat' }, { status: 401 });
}
return NextResponse.json({
ok: true,
region: country,
serverTime: Date.now(),
});
}Am trecut acum vreo 6 luni prin migrarea asta pe un serviciu cu ~25k utilizatori zilnici. Voiam să scot latența din middleware-ul de auth și din redirecționările de geo-location, așa că am zis să merg pe Edge runtime. Rezultatul? Cold start de sub 30ms, dar mi-am spart capul în 3 librării npm din primele zece minute.
De ce am testat Edge și ce am câștigat la cold start
Treaba e simplă: pe Node.js runtime (pe Vercel sau AWS Lambda), când o funcție e "rece", se inițializează un întreg container Node. Asta înseamnă boot la V8, încărcat bundle-ul tău și analizat node_modules. Am înregistrat des cold start-uri de 600ms - 1.2s pe rute mai grele.
Pe Edge runtime nu ai un Node.js complet. Rulează pe V8 Isolates, la fel ca în Cloudflare Workers. Nu există container greoi de pornit. Am văzut cold start-ul scăzând masiv pe Vercel, de la ~800ms la un interval stabil de 25-40ms. Pentru middleware sau un API scurt de geo-routing, e o diferență de la cer la pământ. Utilizatorul simte instant aplicația.
Zidul de care te lovești: fără Node APIs și librării de ORM
Aici începe distracția și înjurăturile pe Slack. Când treci o rută pe Edge, pierzi accesul la modulele native de Node.js. Fără fs, fără path, fără child_process și cel mai dureros: fără librării C++ native.
Dacă folosești Prisma ORM clasic fără Data Proxy sau fără un driver bazat pe HTTP (cum e Neon sau PlanetScale), aplicația ta va da crash direct la build sau la primul request. Eu am pățit-o cu o librărie mai veche de generat PDF-uri și cu un SDK de plată care folosea dependențe interne de Node. Am pierdut două zile rescriind wrapper-e și căutând alternative edge-compatible.
Când aleg Edge și când rămân pe Node?
Acum am o regulă destul de clară în echipă și nu mai încerc să pun totul pe Edge doar pentru că dă bine în prezentări.
Rămân pe Node Runtime pentru 80% din Route Handler-e. Mai ales pentru cele care fac treabă grea în Baza de Date, prelucrare de imagini, webhook-uri complexe de Stripe sau procesare de fișiere. Latența de cold start o atenuez cu un Caching agresiv sau cu ISR unde se poate.
Folosesc Edge Runtime strict pentru:
- Middleware (verificare JWT, AB testing, GeoIP routing)
- API-uri ultra-simple care doar fac un fetch mai departe către alt microserviciu
- Endpoint-uri de streaming unde am nevoie de Server-Sent Events (SSE) fără overhead-ul de memorie din Node
Edge e un brici foarte ascuțit: taie genial unde e nevoie, dar îți taie și degetele dacă încerci să desfaci conserve cu el. Voi cum ați rezolvat problema cu ORM-urile când ați încercat Edge pe App Router?