// app/api/fast-proxy/route.ts
export const runtime = 'edge'; // Așa forțezi Edge în Next.js
export async function GET(request: Request) {
// Perfect pentru Edge: doar un fetch rapid către un API extern
const res = await fetch('https://api.external-service.com/data', {
next: { revalidate: 60 }
});
const data = await res.json();
return Response.json({ data, source: 'edge-runtime' });
}Am trecut acum ceva timp un proiect cu vreo 12.000 de utilizatori activi pe Edge runtime în Next.js. Speram să scap definitiv de cold start-urile alea enervante din serverless-ul clasic. Pe hârtie, totul arăta perfect: latență de câteva milisecunde și execuție direct la user în bătătură. În realitate, m-am lovit de niște limitări tehnice dure care m-au făcut să dau rollback la Node runtime pe jumătate din rute în mai puțin de o săptămână.
Iluzia performanței absolute pe Edge
Edge runtime rulează pe V8 isolate-uri (similar cu ce folosește Cloudflare Workers), nu pe un mediu Node.js complet. Asta înseamnă că nu ai overhead-ul de pornire al unei mașini virtuale sau al unui container Docker. Cold start-ul scade practic de la 1.5 - 2 secunde (pe un Node runtime clasic în AWS Lambda sau Vercel) la aproape zero (sub 50ms).
Dacă ai un landing page dinamic sau o rută de API care doar citește din Redis și formatează un JSON, Edge e genial. Am redus timpul de răspuns de la 450ms la 80ms pentru un endpoint de configurare globală. Dar fericirea s-a terminat rapid când am vrut să fac operațiuni normale de backend.
Unde se rupe filmul și apar limitările
Marea problemă cu Edge este că e un mediu extrem de steril. Nu ai acces la API-urile native de Node.js. Vrei modulul fs ca să citești un fișier local sau să generezi un PDF? Nu se poate. Vrei process.env în modurile clasice sau biblioteci de criptare mai vechi? Mult noroc.
Cel mai tare m-am fript cu conexiunile la baza de date. Majoritatea driverelor de PostgreSQL sau MySQL folosesc socket-uri TCP native (modulul net din Node), care pur și simplu nu există în Edge. Ca să te conectezi la baza de date dintr-o funcție Edge, trebuie să folosești fie un HTTP tunnel (cum are Prisma Data Platform sau Neon serverless driver), fie să schimbi complet driverul cu unul compatibil WebSockets.
Când am văzut că interogarea mea simplă adaugă 200ms de latență doar pentru că trece prin HTTP proxy-ul bazei de date, am realizat că am rezolvat cold start-ul, dar am stricat timpul total de execuție. În plus, ai o limită de dimensiune a bundle-ului (adesea 1MB - 4MB după compresie). Dacă tragi trei librării mari din npm în ruta aia, build-ul o să crape direct.
Ghidul meu simplu de decizie
După ce am pierdut câteva nopți bune încercând să fac workaround-uri inutile, am stabilit o regulă simplă pentru proiectele noastre:
- Rămâi pe Node Runtime (implicit) pentru tot ce înseamnă scriere/citire din DB clasic, generare de PDF-uri, procesare de imagini sau integrări cu SDK-uri mari (Stripe, Firebase Admin etc.). Da, ai cold start uneori, dar măcar codul funcționează predictibil și stabil.
- Treci pe Edge Runtime doar pentru middleware (unde oricum e obligatoriu în Next.js), rute simple de redirecționare, geolocație (citirea headerelor de țară) sau proxy-uri ultra-rapide către alte microservicii care se ocupă de greul din spate.
Tranziția nu e "totul sau nimic". Next.js îți permite să setezi runtime-ul per pagină sau per API route. Folosește asta în avantajul tău și nu optimiza prematur doar pentru că sună bine în specificații.