import { NextRequest, NextResponse } from 'next/server';
import { jwtVerify } from 'jose';
// Specificăm explicit runtime-ul Edge pentru această rută/middleware
export const runtime = 'edge';
const SECRET = new TextEncoder().encode(process.env.JWT_SECRET || 'secret-key-123');
export async function middleware(req: NextRequest) {
const token = req.cookies.get('session_token')?.value;
if (!token) {
return NextResponse.redirect(new URL('/login', req.url));
}
try {
// 'jose' folosește Web Crypto API, compatibil 100% cu Edge Runtime
await jwtVerify(token, SECRET);
return NextResponse.next();
} catch (error) {
return NextResponse.redirect(new URL('/login?error=invalid_session', req.url));
}
}M-am lovit de dilema Edge vs Node runtime acum un an, când încercam să reduc latența la un API de autentificare pentru o platformă cu vreo 15k de utilizatori activi zilnic. Din fișa tehnică, Edge părea glonț: cold start sub 20ms, rulare la cea mai apropiată locație de user, costuri mici. Doar că după prima trecere pe Edge, jumătate din pachetele din node_modules au început să țipe că le lipsesc module native.
Cold start-ul și iluzia vitezei absolute
Pe Node runtime (comportamentul default din Next.js), fiecare rută sau Server Action rulează într-un container sau Lambda clasic. Când aplicația stă degeaba și vine primul request, cold start-ul te costă lejer între 300ms și 800ms, mai ales dacă ai importat jumătate de npm în fișier.
Pe Edge runtime, povestea e diferită. Nu ai un mediu Node.js integral, ci un V8 Isolate (similar cu ce e în browser sau Cloudflare Workers). Asta înseamnă că instanțierea e aproape instantanee: am scăzut cold start-ul de la 450ms la sub 15ms pe un middleware de geolocație. Când userul intră pe site, decizia de redirect sau verificare de token JWT se întâmplă fără întreruperi sesizabile.
Câștigul real nu e doar viteza brută de execuție, ci faptul că primul request al unui utilizator nu mai pare blocat în trafic.
Ce se rupe când treci pe Edge
Totul e frumos până când încerci să folosești o librărie veche sau un ORM tradițional. V8 Isolate nu are acces la procesele Node.js de sistem și nici la binare compiled native C++.
Asta înseamnă câteva limitări clare:
- Nu ai modulul
fs,child_processsaupathdin Node. - Pachete populare precum
jsonwebtoken(care depinde direct de modululcryptovechi din Node) vor da crash la build. Trebuie să folosești alternative cajosebazate pe Web Crypto API. - Conexiunile tradiționale de TCP la baze de date (PostgreSQL sau MySQL clasic fără HTTP proxy) nu funcționează direct pe Edge fără un driver specializat.
Am pățit-o pe un proiect unde foloseam Prisma conectat la un Postgres găzduit clasic. Când am pus export const runtime = 'edge', rutele au crăpat instant la build pentru că engine-ul Rust din Prisma nu putea rula pe V8 Isolate. A trebuit fie să trecem pe Prisma Accelerate și HTTP drivers, fie să lăsăm rutele de date grele pe Node.
Când merită să comuți pe Edge?
Nu merită să treci toată aplicația pe Edge doar pentru că dă bine în benchmark-uri sintetice. Eu aplic regula asta simplă pe proiectele mele:
Treci pe Edge runtime când:
- Scrii Next.js
middleware.ts(verificări de sesiuni, A/B testing, geo-redirects). - Ai API-uri simple care procesează JWT-uri sau folosesc baze de date HTTP-ready (Upstash Redis, Turso, PlanetScale).
- Faci proxy la request-uri către alte microservicii și vrei latență minimă.
Rămâi pe Node runtime când:
- Ai SSR masiv cu interogări SQL complexe prin conexiuni TCP directe.
- Generezi PDF-uri, procesezi imagini cu
sharpsau faci operațiuni pe fișiere pe disc. - Folosești SDK-uri terțe vechi care nu au fost rescrise folosind Fetch API / Web Standards.
Concluzie
Edge runtime nu înlocuiește Node.js, ci îl completează unde contează latența rețelei. Dacă ai nevoie de decizii rapide la marginea rețelei înainte de aducerea datelor, Edge e excelent. Dacă ai de mutat muntele de date dintr-un SQL clasic, Node runtime rămâne varianta sigură.
Voi pe unde v-ați lovit de limitările din Edge în Next.js?