Next.js Edge Runtime vs Node.js Runtime (Vercel i Cloudflare): Što pokretati gdje

# Trenutni kontekst#

Ključna fraza "Next.js Edge Runtime vs Node.js Runtime" zapravo se svodi na jednu razmjenu: latencija i globalna distribucija naspram kompatibilnosti i fleksibilnosti compute-a. Next.js ti omogućuje da kod vrtiš ili na Edge runtimeu (Web API-ji, deploy blizu korisnika) ili na Node.js runtimeu (puni Node environment, tipično u jednoj regiji).

U 2026. ova odluka je važnija jer Next.js aplikacije rijetko budu samo stranice. One su auth gateovi, slojevi personalizacije, BFF API-ji, webhook konzumenti, image proxyji i automation triggeri, često povezani s cachiranjem i observabilityjem.

ℹ️ Napomena: Ovaj post pretpostavlja Next.js App Router ili Pages Router na Vercelu ili Cloudflareu. Konkretna ograničenja ovise o provideru i planu, ali principi odlučivanja ostaju isti.

# Brza usporedna tablica#

# Ključna odluka: Što optimiziraš#

Odaberi Edge kada optimiziraš time-to-first-byte globalno i tvoj kod može živjeti unutar Web API-ja. Odaberi Node kada optimiziraš kompatibilnost, širinu integracija i teži server-side rad.

Koristan mentalni model je razdvojiti backend logiku u dva sloja:

Sloj 1: Oblikovanje zahtjeva (Edge-friendly)#

Sve što ima koristi od toga da je blizu korisnika i može se završiti brzo:

• Čitanje cookieja, headera, geolokacije, device hintova
• Validacija session tokena i redirect
• Rewrite ili routing na varijantu
• Fetch iz obližnjeg cachea ili brzog javnog API-ja
• A B eksperimenti ili feature flagovi

Sloj 2: Izvršavanje posla (Node-friendly)#

Ovdje radiš teže ili integracijski zahtjevnije zadatke:

• Upiti u bazu koji traže Node driver ili connection pooling
• Webhook verifikacija i ingest
• Pozivanje provider SDK-ova koji se oslanjaju na Node module
• Manipulacija slikama, generiranje PDF-a, headless browser zadaci
• Background jobovi i queue workeri

Ako Edge zadržiš kao tanak sloj za oblikovanje, a Node kao sloj za izvršenje, dobivaš većinu Edge performansi bez lomljenja kompatibilnosti.

# Realnost providera: Vercel Edge vs Cloudflare Edge#

I Vercel i Cloudflare mogu izvršavati kod na edgeu, ali ergonomija ekosustava se razlikuje.

Vercel#

Vercel je tijesno integriran s Next.js-om. Edge Runtime je praktičan za Next Middleware, Edge Route Handlere i određene server funkcije konfigurirane da rade na edgeu.

Tipičan Vercel obrazac:

• Edge za middleware i lagane API-je
• Node za API rute, server actions i teške zadatke
• Background rad kroz queueove ili cron obrasce, obrađeno u Next.js background jobs, queues, and cron on Vercel

Cloudflare#

Cloudflare Workers su snažna Edge platforma sa zrelim runtimeom i globalnom distribucijom. Cloudflare se često bira kada želiš širu kontrolu na edgeu: custom caching, Workers, KV, Durable Objects, R2.

Tipičan Cloudflare obrazac:

• Edge za velik dio request handlinga i cachiranja
• Node-like workloadovi premješteni u namjenske servise, ili u provider-specifični compute ako je potrebno
• Veći naglasak na edge-native storage i primitive za koordinaciju

💡 Savjet: Ako planiraš pokretati puno logike na edgeu, izbjegni arhitekturu gdje Edge i dalje mora zvati regionalni Node API za svaki request. Dobiješ dodatne network hopove i gubiš smisao edge izvršavanja.

# Okvir za odlučivanje: Praktični model bodovanja#

Kad tim pita "Edge ili Node", nejasni odgovori troše vrijeme. Koristi jednostavan scorecard po endpointu ili featureu.

Korak 1: Klasificiraj request path#

Stavi svaku runtime odluku iza konkretne rute ili funkcije:

• Middleware
• Route handler ili API endpoint
• Server component data fetch
• Image proxy endpoint
• Webhook receiver
• Auth callback

Korak 2: Ocijeni prema pet faktora#

Koristi ovu tablicu kao rubriku za odluku.

Korak 3: Odluči uz default pravilo#

Pravilo koje dobro radi u produkciji:

• Default na Node za svaki endpoint koji dira plaćanja, webhooks ili upise u bazu.
• Default na Edge za svaki endpoint koji radi routing, personalizaciju ili gating.
• Kad nisi siguran, pokreni tanak Edge sloj koji zove Node endpoint samo na cache missovima ili samo za write pathove.

# Ograničenja koja stvarno znače u produkciji#

Timovi često odaberu Edge zbog brzine, pa nalete na ograničenja. Ovo su ona koja redovito uzrokuju prepisivanje.

Kompatibilnost biblioteka i Node API-ji#

Edge runtimeovi tipično ne podržavaju Node built-ine poput fs, net, tls i child_process. Mnogi popularni paketi indirektno ovise o njima.

Česti gotcha momenti:

• Stariji OAuth SDK-ovi koji pretpostavljaju Node request objekte
• DB driveri koji trebaju sockete i pooling
• Biblioteke za obradu slika s native bindingima
• Stackovi za generiranje PDF-a i uredskih dokumenata

Ako biblioteka isporučuje Web-kompatibilan build, može raditi. Ako pretpostavlja Node primitive, planiraj Node.

⚠️ Upozorenje: Mnogi paketi se naizgled instaliraju bez problema, ali padnu u runtimeu kada dotaknu Node-only import path. Dodaj runtime testove u CI za edge-deployane rute, ne samo TypeScript provjere.

Cold start i “warm” izvršavanje#

Cold start ponašanje ovisi o platformi i mijenja se s vremenom. Ipak, arhitektonska istina ostaje:

• Edge je optimiziran za male, brze handlere
• Node funkcije mogu imati veću varijancu cold starta, posebno s velikim bundleovima i teškim dependencyjima

Što napraviti:

• Drži Edge bundleove minimalnima i izbjegavaj ogromne dependency grafove
• Drži Node API handlere malima tako da teške zadatke guraš u background jobove
• Koristi caching da smanjiš origin hitove, vidi Next.js caching strategies: SSR, ISR, and SWR

Streaming i parcijalno renderiranje#

Streaming poboljšava doživljaj performansi. Oba runtimea mogu streamati, ali vrijednost se razlikuje:

• Edge streaming briljira kada su korisnici globalni i možeš rano krenuti slati HTML
• Node streaming briljira kada integriraš Node-only backende, ali možeš platiti regionalnu latenciju

Također pripazi na third-party API-je koji buffere odgovore ili proxyje koji u praksi onemoguće streaming.

Ograničenja observabilityja#

Debugiranje na edgeu je drugačije: logovi su distribuirani, korelacija zahtjeva je teža, a strategije samplinga su važnije.

Ako ne možeš odgovoriti na "zašto se ovaj request drugačije routao" ili "zašto se promijenio bucket eksperimenta", Edge će te operativno boljeti.

Koristi strukturirane logove, correlation ID-je i propagaciju traceova. Operativna osnova je pokrivena u Web app observability guide: logging, metrics, tracing.

# Primjer 1: Autentikacija i session gating#

Auth je klasičan slučaj gdje Edge može puno pomoći, ali samo ako podijeliš odgovornosti.

Što pokretati na Edgeu#

Pokreni gate na edgeu:

• Pročitaj potpisani session cookie ili JWT
• Validiraj potpis koristeći Web Crypto
• Redirectaj na login ako nedostaje ili je nevažeći
• Priloži user claimove u headere za daljnju upotrebu

To smanjuje nepotreban origin rad i poboljšava brzinu redirecta globalno.

export const runtime = "edge";
 
export async function middleware(req: Request) {
  const cookie = req.headers.get("cookie") || "";
  const hasSession = cookie.includes("session=");
  if (!hasSession) return Response.redirect(new URL("/login", req.url));
  return Response.next();
}

Neka bude jednostavno. Nemoj zvati bazu iz middlewarea osim ako si siguran da su latencija i trošak prihvatljivi.

Što pokretati na Nodeu#

Pokreni teške provjere na Nodeu:

• Dohvati korisnika iz baze
• Provjeri role, stanje pretplate i feature entitlemente
• Rotiraj refresh tokene
• Zovi provider SDK-ove koji zahtijevaju Node

Dobra podjela je: Edge radi “je li korisnik vjerojatno autentificiran”, Node radi “smije li korisnik napraviti ovaj upis”.

🎯 Ključna poruka: Koristi Edge da rano zaustaviš neautentificirani promet. Koristi Node za autoritativne provjere i stateful operacije.

# Primjer 2: Personalizacija i A B testiranje#

Personalizacija je područje gdje edge izvršavanje donosi veliku vrijednost jer utječe na first paint.

Edge obrazac: routing varijanti#

Na edgeu:

• Pročitaj geo, jezik, uređaj ili cookie za bucket
• Rewriteaj na varijantnu rutu
• Cachiraj varijante odvojeno po stabilnom ključu

Jednostavan cookie-based bucketing može se odraditi u potpunosti na edgeu s determinističkim hashiranjem, pa cachiranje po bucketu.

Node obrazac: dubinska personalizacija#

Koristi Node kada personalizacija zahtijeva:

• Više poziva bazi
• Složene algoritme preporuka
• Skupa spajanja (joins) ili težak compute
• Osjetljivu logiku koju ne želiš replicirati preko mnogih POP-ova

Ako moraš raditi dubinsku personalizaciju, razmisli o hibridu:

• Edge brzo odabere grubi segment
• Node asinkrono generira finalni personalizirani payload i cachira ga

To drži P95 latenciju pod kontrolom kod ponovnih posjeta.

# Primjer 3: Image proxy i optimizacija#

Image proxy endpointi djeluju jednostavno, ali brzo postanu skupi i ograničeni.

Edge-friendly image proxy#

Edge je odličan za:

• Verifikaciju potpisa zahtjeva
• Normalizaciju query parametara
• Enforceanje allowlista
• Redirect na CDN ili optimiziranu varijantu

Time smanjuješ abuse. Image proxy endpointi su česta meta za bandwidth i cache-bypass napade.

export const runtime = "edge";
 
export async function GET(req: Request) {
  const url = new URL(req.url);
  const src = url.searchParams.get("src") || "";
  if (!src.startsWith("https://images.example.com/")) {
    return new Response("forbidden", { status: 403 });
  }
  return Response.redirect(src, 302);
}

Node-friendly manipulacija slika#

Koristi Node kada trebaš:

• Resize, transkodiranje, konverziju formata s native bibliotekama
• Složeno watermarkanje
• EXIF obradu
• Ne-trivijalne caching pipelineove

Čak i tada, razmisli o offloadu na specijalizirane image CDN-ove. Najbrža optimizacija slika je često “nemoj vrtjeti vlastiti image CPU”.

⚠️ Upozorenje: Ako manipuliraš slikama u serverless Node funkcijama, brzo možeš udariti u memory ceiling. Velike slike plus paralelni requestovi mogu naglo podići memoriju i uzrokovati throttling.

# Primjer 4: Webhookovi (Payments, CRM, Email provideri)#

Webhookovi su najčešće mjesto gdje timovi slučajno odaberu Edge i požale.

Zašto webhookovi po defaultu pripadaju Nodeu#

Webhook handling često treba:

• Pristup raw bodyju i signature verification s provider SDK-ovima
• Idempotency ključeve spremljene u bazu
• Retryje, dead-lettering i queueing
• Dulje izvršavanje za downstream pozive

Također treba konzistentno ponašanje i jak observability. Node je sigurnija baza.

Robustan webhook pristup:

1. 1
   Verificiraj i prihvati brzo
2. 2
   Spremi event uz idempotency
3. 3
   Stavi u queue za obradu
4. 4
   Odmah potvrdi (ack)

Taj queue i worker pristup je detaljno opisan u Next.js background jobs, queues, and cron on Vercel.

Kada Edge ipak može pomoći#

Edge može stajati ispred Nodea da:

• Rate-limitira abusive IP-ove
• Rano odbaci očito nevaljane zahtjeve
• Routa prema najbližem regionalnom ingestion endpointu

Ali sama webhook logika i dalje treba raditi na Nodeu.

# Caching i dohvat podataka: Edge nije čarobni metak#

Edge poboljšava brzinu odlučivanja, ali caching poboljšava brzinu toga da uopće ne radiš posao. Za većinu aplikacija, odluke o cachiranju dominiraju odlukama o runtimeu.

Praktične smjernice:

• Koristi Edge da postaviš cache ključeve i routaš requestove
• Koristi Node za cache missove koji zahtijevaju teška backend čitanja ili upise
• Pobrinite se da je cache ponašanje eksplicitno i testirano, posebno preko varijanti

Ako miješaš SSR, ISR i client caching, koristi konzistentnu strategiju. Najčešći failure mode je pogrešno cachiranje personaliziranih stranica. Vidi Next.js caching strategies: SSR, ISR, and SWR za obrasce koji drže pod opterećenjem.

# Kako implementirati odabir runtimea u Next.js-u bez iznenađenja#

Glavni cilj je izbjeći runtime drift, gdje se kod slučajno premjesti na Edge ili Node zbog refaktora.

Učini runtime eksplicitnim po ruti#

Koristi eksplicitne runtime deklaracije gdje je podržano:

export const runtime = "nodejs";
export async function POST(req: Request) {
  return Response.json({ ok: true });
}

I za edge rute:

export const runtime = "edge";
export async function GET() {
  return new Response("ok");
}

Drži shared logiku runtime-safe#

Kreiraj dva seta utilsa:

• lib/edge/* koji koristi samo Web API-je i fetch
• lib/node/* koji može koristiti Node API-je, SDK-ove i DB drivere

To sprječava slučajne importe. Najčešći build break je importanje Node-only helpera u Edge rutu.

Testiraj kritične tokove u uvjetima sličnim produkciji#

Local dev može sakriti razlike runtimea. Dodaj testove koji se izvršavaju protiv deployanih preview environmenta:

• Auth redirect putanje
• Webhook signature verification
• Image proxy allowliste
• Stabilnost experiment bucketinga

Također dodaj observability hookove rano. Debugiranje edge produkcijskih problema bez correlation ID-jeva je skupo. Za praktičan setup slijedi Web app observability guide: logging, metrics, tracing.

💡 Savjet: Dodaj x-runtime response header iz svake rute kako bi potvrdio što se stvarno izvršilo. Sprječava tjedne nagađanja tijekom istraga performansi.

# Završna matrica odluke: Use-caseovi mapirani na najbolji runtime#

Koristi ovo kao default mapiranje, pa overrideaj kada te ograničenja prisile.

# Ključne poruke#

• Koristi Edge za oblikovanje zahtjeva: auth gateove, routing, odluke o personalizaciji, cache ključeve i bot filtering.
• Koristi Node za izvršavanje posla: webhooks, upise u bazu, integracije s provider SDK-ovima, težak compute i background obradu.
• Drži Edge bundleove malima i isključivo na Web API-jima da izbjegneš runtime failureove zbog Node-only dependencija.
• Caching tretiraj kao first-class dizajnerski izbor, jer cache hit rate često znači više od odabira runtimea. Koristi ove Next.js caching strategije kao bazu.
• Izgradi observability za oba runtimea od prvog dana, sa strukturiranim logovima i correlation ID-jevima, vođeno našim logging, metrics, tracing playbookom.
• Za webhooks i asinkrone workflowove preferiraj Node plus queueove, prateći naš vodič za Next.js jobove i cron.

# Zaključak#

Odabir između Edge i Node u Next.js-u nije o tome da proglasiš pobjednika. Najbolje arhitekture koriste Edge kao brzu globalnu kontrolnu ravninu i Node kao kompatibilnu izvršnu ravninu za stateful i integracijski zahtjevan rad.

Ako želiš pomoć oko mapiranja ruta na pravi runtime, zatezanja cachiranja i postavljanja pouzdane obrade webhookova i jobova, Samioda može pregledati tvoju Next.js arhitekturu i isporučiti promjene s mjerljivim poboljšanjima latencije i pouzdanosti. Javi se i predložit ćemo runtime i deployment plan prilagođen tvom prometu, regijama i integracijama.