// Cum setezi runtime-ul în Next.js pentru o rută specifică
export const runtime = 'edge';
export async function GET(request: Request) {
// Edge are acces la Web APIs standard
const { searchParams } = new URL(request.url);
const userId = searchParams.get('id');
// ATENȚIE: Nu poți folosi librării de Node native aici (ex: fs.readFileSync)
return new Response(JSON.stringify({
message: "Hello from the Edge!",
userId
}), {
status: 200,
headers: { 'content-type': 'application/json' }
});
}Să fim serioși, când Vercel a început să promoveze Edge Runtime, toți am vrut să mutăm totul acolo. Promisiunea de „zero cold starts” sună ca un vis devenit realitate pentru oricine s-a luptat cu latențele din serverless. Am făcut și eu trecerea asta la un proiect cu vreo 12.000 de utilizatori activi și mi-am luat un mare perete în față.
Azi vreau să vorbim pe șleau despre ce merge, ce crapă spectaculos și cum să alegi runtime-ul fără să-ți strici weekend-ul reparând bug-uri de producție.
De ce am vrut Edge și ce am câștigat
Pe Node.js clasic (pe infrastructura serverless de la Vercel sau AWS Lambda), cold start-ul ne sărea uneori de 1.5 - 2 secunde. Dacă o funcție nu mai fusese apelată de 15 minute, primul utilizator care intra pe pagină plătea taxa de așteptare.
Când am trecut rutele de API pe Edge, cold start-ul a scăzut sub 50ms. Practic, a dispărut. Edge runtime rulează pe instanțe extrem de ușoare (V8 isolates), similare cu cele din Cloudflare Workers. Nu încarcă un întreg sistem de operare virtualizat, ci doar contextul de execuție JS. Pentru API-uri simple de geolocație sau verificări rapide de token-uri, este absolut genial.
Compromisul dureros: Edge nu este Node.js
Aici m-am ars cel mai tare. Edge runtime nu are acces la API-urile native de Node.js. Uită de fs, path sau de librării npm care folosesc module scrise în C++.
Dacă ai în proiect o librărie mai veche de criptare (cum ar fi bcrypt cel clasic) sau ceva care generează PDF-uri, build-ul de Next.js o să crape imediat ce setezi runtime-ul pe edge. Trebuie să cauți alternative compatibile cu Web APIs (de exemplu, bcrypt-ts sau Web Crypto API).
Coșmarul conexiunilor la baza de date
Cea mai mare palmă am luat-o când am încercat să conectez rutele de Edge la o bază de date PostgreSQL clasică. Pe Node runtime, trântești un pool de conexiuni prin pg sau Prisma și totul funcționează direct prin TCP.
Pe Edge, nu poți deschide conexiuni TCP brute direct din cod (deși lucrurile se mai îmbunătățesc recent cu unele drivere noi). A trebuit fie să folosesc un HTTP proxy pentru baza de date (cum e Prisma Accelerate sau Neon serverless driver), fie să accept că interogările devin mai lente din cauza overhead-ului de HTTP. Practic, am salvat 200ms la cold start ca să pierd 300ms la fiecare query de bază de date. O afacere extrem de proastă.
Când să schimbi și ce să folosești
Regula mea de aur acum este simplă:
- Folosește Edge pentru: Middleware (unde redirecționezi userul pe baza locației), verificări rapide de JWT-uri, A/B testing sau rute de API care doar pasează un request către un alt serviciu extern (ex. Stripe webhooks).
- Rămâi pe Node.js pentru: Tot ce înseamnă CRUD clasic pe baza de date, generare de fișiere, trimis email-uri sau procesări grele de date.
Nu merită să complici arhitectura doar ca să bifezi o tehnologie nouă pe hârtie. Voi ce bătăi de cap ați avut cu limitele din Edge runtime în Next.js?