// app/api/fast-route/route.ts
export const runtime = 'edge'; // Activează Edge runtime pentru această rută
export async function GET(request: Request) {
// Fetch-ul nativ funcționează perfect pe Edge
const res = await fetch('https://api.github.com/repos/vercel/next.js');
const data = await res.json();
return Response.json({ stars: data.stargazers_count });
}Toată lumea vorbește despre Edge runtime în Next.js de parcă e soluția universală la orice problemă de performanță. Am căzut și eu în capcana asta acum un an, când am vrut să optimizez un API pentru o aplicație cu vreo 12.000 de utilizatori activi. Realitatea e că Edge e genial, dar doar dacă înțelegi exact ce pierzi când renunți la Node.
Dacă ai trecut vreodată de la un cold start de 1.5 secunde pe serverless Node la sub 20ms pe Edge, senzația e incredibilă. Dar drumul până acolo e plin de erori de compilare.
Ce este, de fapt, Edge runtime?
Spre deosebire de Node.js, care rulează într-un container complet, Edge folosește V8 isolates (la fel ca în Cloudflare Workers). Practic, e un mediu de execuție mult mai simplu, lipsit de overhead-ul unui sistem de operare întreg.
De aici vine și viteza. Codul tău pornește aproape instantaneu și rulează fizic mai aproape de utilizator, în cel mai apropiat punct de prezență (PoP) al providerului de cloud.
Unde se rupe filmul: Limitări de care m-am lovit
Sună perfect pe hârtie, dar în practică te lovești repede de pereți. Cel mai mare șoc pe care l-am avut a fost cu conexiunile la baza de date.
Pe Edge nu ai acces la API-urile native de Node.js, cum ar fi net sau dns. Asta înseamnă că driverele clasice de baze de date (cum ar fi cel de PostgreSQL sau MySQL) pur și simplu nu funcționează direct pentru că nu pot deschide socket-uri TCP clasice. Am vrut să folosesc Prisma direct pe Edge și am primit o listă kilometrică de erori. Soluția? A trebuit să trecem pe conexiuni prin HTTP (cum e Neon serverless driver) sau să folosim un connection pooler extern ca Prisma Accelerate.
Uite o listă rapidă cu ce NU ai în Edge:
- Fără
fs(nu poți citi fișiere de pe disc). - Fără
process.envcomplet (ai doar o versiune limitată). - Limitare drastică la dimensiunea bundle-ului (de obicei 1MB - 4MB, depinde de provider). Dacă ai librării mari de procesare de imagini sau PDF-uri, ai pierdut din start.
Cold start: Node vs Edge
La proiectul menționat, aveam câteva rute pe Node.js care făceau cold start în aproximativ 800ms pe Vercel (Hobby/Pro tier). După ce am rescris logica și am mutat acele endpoint-uri pe Edge, cold start-ul a scăzut la sub 15ms. Utilizatorii au simțit imediat diferența la prima interacțiune.
Totuși, am păstrat rutele de raportare și generare de PDF-uri pe Node runtime. Acolo aveam nevoie de librării mari și de timp de execuție mai lung de 30 de secunde, lucru interzis pe Edge (unde limita de timeout e adesea de câteva secunde sau chiar milisecunde de timp de CPU efectiv).
Cum faci switch-ul în Next.js
Configurarea e extrem de simplă. Trebuie doar să exporți o constantă în fișierul tău de rută sau pagină. Ai exemplul de cod atașat mai jos.
Concluzia mea
Trade-off-ul e destul de clar din punctul meu de vedere. Edge runtime câștigă detașat pentru API-uri simple, autentificare, middleware și rute de redirecționare unde latența contează enorm. În schimb, dacă ai nevoie de conexiuni directe la baze de date clasice, manipulare de fișiere sau librării npm grele, rămâi pe Node. Nu te chinui să forțezi Edge acolo unde nu se potrivește.
Voi ce folosiți cel mai des în producție? Ați avut probleme cu librăriile externe când ați încercat să treceți pe Edge?