eduardweb.
Next.jsIntermediar#nodejs#performance#nextjs#serverless#edge

Edge vs Node runtime în Next.js: când merită și unde te lovești de pereți

De Ioana Marinescu, 17 aug. 2026 · 1 vizualizări · 2 like-uri

Postat acum 6 ore
typescript
// app/api/fast-search/route.ts
import { NextRequest, NextResponse } from 'next/server';

// Specificăm runtime-ul explicit la nivel de fișier
export const runtime = 'edge';

export async function GET(req: NextRequest) {
  const query = req.nextUrl.searchParams.get('q') || '';
  
  // Web Crypto nativ funcționează perfect pe Edge
  const hash = await crypto.subtle.digest(
    'SHA-256',
    new TextEncoder().encode(query)
  );

  return NextResponse.json({
    query,
    edgePoP: req.headers.get('x-vercel-ip-country') ?? 'local',
    timestamp: Date.now()
  });
}

Am migrat acum câteva luni un API route din Next.js de pe Node pe Edge runtime pentru un endpoint de autocomplete accesat de vreo 12.000 de utilizatori zilnic. Cold start-ul a scăzut instant de la ~450ms la sub 25ms, dar tranziția a venit la pachet cu câteva bătăi de cap pe care documentația oficială le cam bagă sub preș.

Dacă ești indecis între nodejs și edge în route.ts sau page.tsx, diferența nu e doar de performanță, ci de ecosistem.

Cold start și latență: de ce e Edge atât de rapid

Node runtime pornește un container (sau o funcție serverless clasică pe AWS Lambda). Asta înseamnă inițializare de mediu complet Node.js, parsing de dependențe grele și un cold start vizibil, de obicei între 200ms și 800ms dacă ai un bundle generos.

Edge runtime rulează pe V8 isolates (la fel ca în Cloudflare Workers). Nu ai sistem de operare în spate, nu ai un proces greoi de inițializat. Cold start-ul e practic insesizabil: sub 15-30ms. În plus, codul rulează în locația geografică cea mai apropiată de utilizator (Point of Presence), nu într-o singură regiune din Frankfurt sau US-East.

Dar viteza asta vine cu un cost uriaș de compatibilitate.

Unde te lovești de pereți cu Edge

Edge runtime NU este Node.js. Este un subset strict de Web APIs (fetch, Request, Response, TransformStream, crypto nativ).

  1. Fără module native Node: Uită de fs, path, child_process sau net. Dacă o librărie din node_modules are un require('fs') ascuns printr-un utilitar, build-ul îți va crăpa.
  2. ORM-urile clasice: Dacă folosești Prisma fără driver adapters sau direct pe conexiune TCP clasică de PostgreSQL, nu va merge pe Edge. Ai nevoie de serverless database drivers (Neon, PlanetScale, Supabase over HTTP) sau Prisma Data Proxy.
  3. Dimensiunea bundle-ului: Pe Edge ai o limită strictă de dimensiune (pe Vercel, de exemplu, e 1MB sau 4MB în funcție de plan). Dacă tragi librării masive de manipulare imagini sau PDF-uri, ai atins limita imediat.

Cum împarți logica în mod practic

Nu trebuie să treci toată aplicația pe un singur runtime. Next.js îți permite să setezi runtime-ul per fișier (route segment config):

  • Alege Edge pentru: Middleware (verificare token JWT simplu, redirect-uri geografice, A/B testing), endpoint-uri de streaming cu OpenAI/LLMs, proxy-uri rapide sau endpoint-uri mici de căutare cu răspunsuri din Redis/Upstash.
  • Rămâi pe Node pentru: SSR-ul principal al paginilor dacă ai query-uri complexe de DB, operațiuni cu sharp pentru procesare foto, generare de fișiere Excel/PDF, webhook-uri de la Stripe (unde vrei verificări criptografice complexe și conexiuni sigure directe la DB).

Trade-off-ul e simplu: Edge îți dă latență minimă, dar îți limitează uneltele. Node îți dă tot npm-ul la dispoziție, cu penalizarea de rigoare pe cold start.

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

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