eduardweb.
Next.jsIntermediar#performance#nextjs#serverless#edge-runtime

Edge vs Node runtime în Next.js: Când merită bătaia de cap și când te frigi

De Mihai Popescu, 1 iul. 2026 · 12 vizualizări · 3 like-uri

Postat 1 iul. 2026
typescript
// app/api/geo/route.ts
export const runtime = 'edge';

export async function GET(request: Request) {
  // Citim datele de geo-locație oferite direct de header-ele platformei
  const country = request.headers.get('x-vercel-ip-country') || 'RO';
  const city = request.headers.get('x-vercel-ip-city') || 'București';

  return new Response(
    JSON.stringify({
      message: `Salut! Te salutăm din ${city}, ${country}!`,
      timestamp: Date.now()
    }),
    {
      status: 200,
      headers: { 'content-type': 'application/json' }
    }
  );
}

Să fim sinceri: când Vercel a început să promoveze Edge Runtime, toți am crezut că am scăpat definitiv de coșmarul cold start-urilor din serverless-ul clasic. Am trecut și eu prin entuziasmul ăsta la un proiect cu vreo 15.000 de utilizatori activi, unde un cold start de 1.8 secunde pe o rută de Node ne strica tot flow-ul de onboarding. Realitatea din producție însă m-a lovit destul de repede peste degete.

Nu tot ce zboară se mănâncă, iar Edge nu este un înlocuitor universal pentru Node.js.

Unde strălucește Edge și numerele din spate

Edge rulează pe V8 isolates (la fel ca Cloudflare Workers), nu în containere Node.js complete. Asta înseamnă că boot-ul se întâmplă aproape instantaneu.

La proiectul de care ziceam, după ce am mutat rutele de autentificare pe Edge, timpul de răspuns inițial a scăzut de la 1.8 secunde la sub 50 de milisecunde. Zero cold start sesizabil. Utilizatorul dădea click și primea token-ul instant, indiferent dacă serverul fusese inactiv de trei ore sau de trei secunde.

Edge este genial pentru chestii simple:

  • Verificat și decodat un token JWT în middleware.
  • Citit din cookie-uri și redirecționat userul în funcție de geolocație.
  • Apeluri HTTP simple către un API extern (de exemplu, trimis un webhook în Stripe).

De ce te lovești cu capul de prag (Trade-offs)

Dar libertatea asta vine cu un preț uriaș. Edge runtime nu este Node.js. Nu ai acces la modulele native de Node. Vrei să folosești fs ca să citești un fișier local? Nu poți. Vrei să folosești o librărie mai veche de criptografie care se bazează pe chestii interne din Node? Eroare la build.

Cea mai mare durere am avut-o însă cu bazele de date. Dacă folosești un ORM clasic precum Prisma peste o conexiune TCP tradițională (Postgres/MySQL), ai încurcat-o. Edge nu suportă conexiuni TCP directe out-of-the-box (deși lucrurile se mai îmbunătățesc cu drivere noi sau proxy-uri gen Prisma Accelerate).

Trebuie să folosești conexiuni prin HTTP/WebSockets sau să rămâi pe Node runtime. Am pierdut două zile încercând să fac un query simplu să meargă pe Edge doar ca să realizez că overhead-ul de a trece printr-un pool-er HTTP extern anula tot câștigul de performanță obținut din eliminarea cold start-ului.

Cum schimbi runtime-ul

E ridicol de simplu să schimbi runtime-ul în Next.js, dar ai grijă la importuri. Adaugi doar o linie în fișierul de rută sau în layout/page.

Înainte de a face asta în producție, rulează un build local (npm run build). Next.js îți va arăta imediat la compilare dacă ai importat module sau pachete npm care folosesc API-uri de Node incompatibile cu sandbox-ul V8.

Node runtime rămâne sfânt pentru 90% din rutele voastre care fac interogări grele în baze de date SQL sau procesare de imagini. Folosește Edge doar ca pe un instrument chirurgical, acolo unde latența la primul request chiar distruge experiența utilizatorului.

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

Doar membrii comunității pot lăsa comentarii.