// next.config.js sau direct în pagină/rută
// Specificăm runtime-ul pentru o rută de API
export const runtime = 'edge';
export default async function handler(req) {
// Aici nu poți folosi fs.readFileSync
// Dar ai acces la Web standard APIs (fetch, Response, etc.)
return new Response(
JSON.stringify({ message: 'Salut din Edge!' }),
{ status: 200, headers: { 'content-type': 'application/json' } }
);
}Am observat că multă lume activează runtime: 'edge' în Next.js doar pentru că sună a tehnologie nouă și rapidă, fără să înțeleagă ce pierd la schimb. Am avut cazul unui proiect de e-commerce unde am făcut switch-ul ăsta impulsiv și m-am trezit cu 50 de erori de tipul 'Module not found' la build. Node.js runtime e mediul clasic, greoi, dar complet. Edge runtime e o versiune extrem de light, bazată pe V8 isolates (ca în Cloudflare Workers), care pornește instant dar vine cu niște restricții de te dor ochii.
Diferența reală de cold start
Pe Node runtime, mai ales dacă rulezi pe serverless (Vercel, AWS Lambda), cold start-ul e inamicul numărul unu. La un proiect cu vreo 15 dependințe mai serioase, am măsurat un cold start de aproximativ 650ms. Pentru un API care trebuie să răspundă repede, e enorm. Utilizatorul simte lag-ul ăla când dă click pe un buton după 10 minute de inactivitate.
În schimb, pe Edge runtime, cold start-ul este practic inexistent sau sub 10ms. V8 isolates nu pornesc o mașină virtuală întreagă ca Node, ci doar contextul de execuție. E genial pentru middleware-uri, autentificare sau geo-routing, unde ai nevoie de răspuns instant indiferent de unde vine userul.
Unde se rupe filmul: Librăriile
Aici e partea unde am pierdut eu vreo două zile de debugging. Dacă proiectul tău folosește librării de generat PDF-uri (ca jspdf), manipulare de imagini (ca sharp) sau orice depinde de API-uri native de Node (cum e fs sau child_process), Edge runtime o să-ți dea eroare. Nu există sistem de fișiere pe Edge. Nu poți să scrii /tmp/file.txt.
Chiar și conexiunile la baza de date sunt problematice. Majoritatea driverelor de SQL folosesc TCP, iar Edge runtime suportă în general doar HTTP. Dacă folosești Prisma, ai nevoie de un Data Proxy ca să poți interoga baza de date de pe Edge. Am economisit poate 200ms la cold start, dar am adăugat 50ms latență prin proxy-ul de baza de date. Trade-off-ul e real și nu e întotdeauna în favoarea ta.
Când să schimbi și când să stai cuminte
Regula mea de aur după 10 ani de experiență: rămâi pe Node runtime default până când ai o problemă reală de latență pe care o poți atribui cold start-ului. Dacă ai un dashboard administrativ unde intră 3 oameni pe zi, nu te ajută cu nimic Edge. Din contră, te limitează la ce librării poți folosi pentru exporturi de date.
Schimbă pe Edge doar dacă:
- Ai nevoie de Middleware (unde oricum ești forțat).
- Construiești un API care va fi apelat de mii de ori pe secundă din locații geografice diferite.
- Logica ta e simplă: procesare de string-uri, validare de JWT-uri sau transformări simple de JSON.
La un proiect recent cu 8k useri activi, am mutat doar rutele de autentificare pe Edge. Am câștigat o viteză de răspuns vizibilă la login, dar am păstrat restul logicii complexe de business pe Node pentru că aveam nevoie de librării de procesare care pur și simplu nu rulează în V8 simplu.
Concluzia e simplă: Edge e pentru viteză brută și logică subțire, Node e pentru când ai treabă serioasă de făcut cu fișiere și baze de date clasice. Voi ce ați ales să sacrificați pentru un cold start mai mic?