import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
import { jwtVerify } from 'jose'; // jsonwebtoken clasic CRAPĂ pe Edge!
export const runtime = 'edge'; // Forțăm V8 Isolate
export async function GET(request: NextRequest) {
const token = request.headers.get('authorization')?.split(' ')[1];
if (!token) {
return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
}
try {
const secret = new TextEncoder().encode(process.env.JWT_SECRET);
const { payload } = await jwtVerify(token, secret);
return NextResponse.json({ user: payload.sub, region: request.geo?.city ?? 'unknown' });
} catch (err) {
return NextResponse.json({ error: 'Invalid token' }, { status: 403 });
}
}M-am lovit recent de o problemă supărătoare de latență pe un proiect cu vreo 12.000 de utilizatori activi zilnic. Aveam rute de checkout și verificare de sesiuni unde cold start-ul pe serverless (Node.js pe Vercel) ajungea la 450-600ms, iar utilizatorii simțeau lag-ul instant. Am decis să mutăm rutele problematice pe Edge runtime, iar rezultatele au fost spectaculoase, deși au venit cu destule dureri de cap.
Cold start: 450ms vs 15ms
Marea diferență nu vine din viteza de procesare a CPU-ului, ci din modul în care este bootat codul. Node runtime pornește un container întreg de serverless, încarcă tot mediul de executare Node și abia apoi rulează handler-ul tău. Când nu ai trafic constant pe o rută, primul request după o pauză te penalizează masiv.
Edge runtime folosește V8 Isolates (aceeași tehnologie din spatele Cloudflare Workers). Nu ai un proces complet de Node.js, ci doar un context izolat de JavaScript care pornește în mai puțin de 15 milisecunde. Pe proiectul nostru, timpul mediu de răspuns pe rutele de middleware și geo-location a scăzut de la 520ms la doar 28ms pentru cererile de tip cold start.
De ce o să-ți blestemi zilele (Limitările Edge)
Totul sună excelent până când încerci să imporți librăriile tale obișnuite. V8 Isolates nu este Node.js. Asta înseamnă că nu ai acces la module native precum fs, path, net sau child_process.
Am pățit-o direct cu pachetul jsonwebtoken. Codul clasic folosește module interne din Node pentru semnare asimetrică și crapă la build în secundul în care pui export const runtime = 'edge'. Am fost obligați să rescriem logica folosind Web Crypto API via librăria jose.
A doua problemă mare este conexiunea la baze de date. Dacă folosești Prisma în mod tradițional, nu poți deschide conexiuni TCP directe către PostgreSQL dintr-un V8 Isolate fără un HTTP proxy (cum ar fi Prisma Data Proxy sau Neon serverless driver). Dacă ai o bază de date SQL clasică găzduită pe un VPS, Edge-ul îți va complica viața enorm.
Când schimbi și când rămâi pe Node
După câteva săptămâni de teste pe producție, regula mea e destul de simplă:
Folosește Edge runtime pentru:
- Middleware (A/B testing, redirectări pe bază de țară, verificare token-uri JWT)
- Rute simple de API care fac doar un proxy/transformare scurtă către un alt microserviciu
- Personalizare de conținut dinamic cu latență minimă
Rămâi pe Node runtime pentru:
- Rute complexe care generează PDF-uri, procesează imagini sau folosesc buffer-e mari
- Interacțiuni directe prin TCP cu baze de date SQL/NoSQL fără WebSocket/HTTP adapters
- Cod care depinde de pachete npm vechi ce nu au fost refăcute pentru Web APIs
Concluzie
Edge runtime nu este un înlocuitor direct pentru Node.js, ci o unealtă specializată pentru latență minimă la marginea rețelei. Am economisit peste 300ms pe TTFB în zonele critice, dar prețul a fost refactorizarea a 20% din codul de autentificare.
Voi ce experiențe aveți cu Edge în Next.js? Ați mutat rute complete de API sau ați rămas doar la nivel de middleware?