// app/api/github-stars/route.ts
// Schimbarea runtime-ului se face extrem de simplu prin segment config
export const runtime = 'edge';
export async function GET() {
const res = await fetch('https://api.github.com/repos/vercel/next.js');
const data = await res.json();
return Response.json({
stars: data.stargazers_count,
message: "Rulat rapid pe Edge runtime!"
});
}Ne batem toți cu pumnul în piept că vrem aplicații rapide, dar de multe ori activăm Edge runtime în Next.js doar pentru că sună cool în prezentările de marketing. Am trecut prin asta pe un proiect cu 12.000 de utilizatori activi lunar și am învățat pe pielea mea că Edge nu este o soluție magică pentru orice scenariu. Hai să vedem concret când te ajută și unde se rupe filmul.
Ce înseamnă, de fapt, diferența asta?
Node.js runtime e clasicul server cu care am crescut toți. Are tot ce-i trebuie, rulează pe o mașină virtuală completă, dar pornește greu în medii serverless. Dacă ai un endpoint care nu a mai fost apelat de zece minute, te lovești de un cold start de 1-2 secunde, mai ales dacă ai proiectul plin de dependințe grele.
Edge runtime rulează pe V8 isolates (cum sunt și Cloudflare Workers). Nu are tot API-ul de Node, dar pornește instant, de obicei în sub 40 de milisecunde.
Sună ideal, nu? Dar aici apare un mare trade-off: economisești timp la cold start, dar pierzi accesul la modulele native de Node.js.
Unde s-a rupt filmul la noi (Problema cu npm)
La proiectul de care vă spuneam, am zis să fim moderni și am setat runtime-ul global pe edge. Primul build local a trecut, dar în producție s-a declanșat iadul.
Foloseam o librărie mai veche pentru generat PDF-uri și pachetul standard de jsonwebtoken. Ambele s-au spart instantaneu la build pentru că aveau nevoie de module native precum crypto sau fs, care pur și simplu nu există în Edge runtime.
Am pierdut o zi întreagă rescriind sistemul de autentificare ca să folosim jose în loc de jsonwebtoken și mutând generarea de PDF-uri înapoi pe un endpoint separat, rulat pe Node.js standard.
Un alt caz unde am pățit-o a fost conexiunea la baza de date. Dacă ai un Postgres clasic și încerci să te conectezi la el din Edge, o să ai surprize neplăcute. Driverele tradiționale folosesc socket-uri TCP pe care Edge nu le suportă direct fără wrapper-uri HTTP sau proxy-uri de tip Prisma Data Proxy.
Când să folosești Edge și când să rămâi pe Node
După câteva luni de optimizări și dureri de cap, mi-am făcut o regulă simplă de care mă țin acum la orice proiect nou.
Folosește Edge doar pentru:
- Middleware-uri rapide: redirecționări, geolocație, teste A/B.
- API-uri extrem de simple, de tip proxy, care doar pasează datele mai departe.
- Pagini statice unde ai nevoie de o personalizare minimă la nivel de header-e.
Rămâi pe Node.js pentru:
- Tot ce atinge o bază de date relațională clasică.
- Generare de PDF-uri, imagini sau manipulare de fișiere.
- Criptare complexă sau integrări cu SDK-uri vechi de la terți.
La final, am reușit să aducem cold start-ul pe rutele critice de la 1.4 secunde la doar 50ms, dar prețul plătit în refactoring a fost destul de piperat.
Voi ce runtime folosiți implicit în Next.js? V-ați lovit de limitările de pe Edge până acum?