Next.js real-time značajke: WebSockets vs SSE vs Supabase Realtime (kada što koristiti)

# Trenutačni landscape za Next.js real time u 2026.#

"Next.js real time" obično znači jednu od četiri potrebe proizvoda: chat, live nadzorne ploče, obavijesti ili suradničko uređivanje. Svaka od njih ima različite zahtjeve za latenciju, fan-out, redoslijed, garancije isporuke i sigurnost.

Sam Next.js ne nudi jedan ugrađeni real-time transport. Vi birate transport i onda ga uklapate u ograničenja Next.js-a: serverless timeoute, ograničenja edge runtimea, limite konekcija te način na koji rješavate auth i isporuku u više regija.

ℹ️ Napomena: Ova usporedba fokusira se na tri praktična izbora koji se danas koriste u produkciji: WebSockets, Server-Sent Events (SSE) i Supabase Realtime. WebRTC može biti relevantan za audio i video, ali to je druga problematika.

Ako niste sigurni na koji runtime deployate, krenite ovdje: Next.js Edge Runtime vs Node.js Runtime na Vercelu i Cloudflareu. Odabir runtimea izravno utječe na to jesu li dugotrajne konekcije uopće moguće.

# Brza usporedna tablica#

# Što zapravo znači u real-time sustavima#

Odabir protokola nije prva odluka. Prva odluka je model interakcije.

Kriteriji odluke koji mijenjaju ishod#

🎯 Ključna poruka: Najbolje "Next.js real time" rješenje je ono koje odgovara vašem modelu interakcije i ograničenjima hostinga, a ne ono s najnižom latencijom na papiru.

# Opcija 1: WebSockets u Next.js-u#

WebSockets pruža trajnu, dvosmjernu konekciju. To ga čini idealnim za interaktivna opterećenja: chat, presence, suradničke kursore i sve gdje klijent ne samo da prima updateove nego i često šalje male eventove.

Realnost hostinga: gdje WebSockets zapravo živi#

Ako deployate Next.js na serverless funkcije, u pravilu ne biste trebali hostati WebSocket servere unutar svoje Next.js aplikacije. Serverless je dizajniran za kratkotrajne requestove, a ne dugotrajne konekcije. Čak i kad tehnički možete otvoriti socket, nailazite na praktične probleme: cold startovi, limiti konekcija, timeoute i bez garancije da će ista instanca kasnije opet rukovati istim klijentom.

U praksi, WebSockets za Next.js aplikacije obično živi na jednom od ovih mjesta:

Minimalni primjer WebSocket servera#

Držite WebSocket server odvojeno od Next.js-a ako ste na serverlessu. Ovaj primjer koristi ws na Nodeu.

// server.js
import http from "http";
import { WebSocketServer } from "ws";
 
const server = http.createServer();
const wss = new WebSocketServer({ server });
 
wss.on("connection", (socket) => {
  socket.on("message", (raw) => {
    const msg = raw.toString();
    wss.clients.forEach((client) => client.send(msg));
  });
});
 
server.listen(8080);

Ovo je namjerno jednostavno. Produkcijska verzija treba autentikaciju, rutiranje po sobama, validaciju poruka i rate limiting.

Skaliranje WebSocketa: skriveni posao#

Jedan WebSocket proces radi dok ne prestane raditi. Najčešća prekretnica je kad vam treba horizontalno skaliranje. Tada vam treba zajednički pub-sub sloj kako bi klijenti spojeni na različite instance i dalje dobivali iste eventove.

Tipična arhitektura:

• WebSocket nodeovi rukuju konekcijama.
• Pub-sub sustav radi fan-out eventova: Redis PubSub, Redis Streams, NATS, Kafka ili managed ekvivalenti.
• Zajednički store drži presence i članstvo u sobama, ili implementirate consistent hashing.

Zašto je to važno: chat može biti 1 poruka u sekundi po aktivnom korisniku, ali presence i typing često multipliciraju volumen eventova. Team chat s 5.000 istovremenih korisnika lako generira desetke tisuća malih eventova u minuti kad uključite typing, read receipts, presence i retryjeve.

Auth za WebSockets u Next.js-u#

Najsigurniji pattern je izdati kratkotrajni token iz Next.js-a preko HTTPS-a, pa ga validirati tijekom WebSocket handshaka. Koristite istog providera kojeg koristite za web sesije.

Ako trebate praktičan pregled auth opcija u Next.js-u, uključujući Supabase i druge česte opcije, koristite: Vodič za autentikaciju u Next.js-u: NextAuth vs Clerk vs Supabase.

⚠️ Upozorenje: Nemojte vjerovati "roomId" ili "userId" koje klijent šalje kroz WebSocket poruke. Svaku poruku tretirajte kao API request: validirajte auth, autorizirajte pristup sobi i provodite rate limite.

# Opcija 2: Server-Sent Events (SSE) u Next.js-u#

SSE koristi standardan HTTP response koji ostaje otvoren i streama eventove. Klijent prima eventove, ali ne može slati eventove natrag na istoj konekciji. To čini SSE odličnim za "push-only" potrebe: nadzorne ploče, feedove obavijesti, napredak poslova i streaming logova.

Zašto SSE često pobjeđuje za dashboarde i obavijesti#

SSE je jednostavan:

• Radi preko HTTP-a i prijateljski je prema proxyjima.
• Automatski reconnect je ugrađen u browser EventSource API.
• Jednosmjernost smanjuje kompleksnost i površinu za zloupotrebu.

Za mnoge proizvode, dashboardi su read-heavy. Ako imate 10.000 gledatelja dashboarda i samo nekolicinu writera, SSE je često jeftiniji i lakši od WebSocketa jer serveri ne moraju pratiti dvosmjerno stanje.

SSE caveati važni u produkciji#

SSE je i dalje dugotrajna konekcija. To znači da vaša hosting platforma mora pouzdano podržavati streaming responseove. Neka serverless okruženja bufferaju response, što razbija real-time streaming. Morate testirati na ciljnoj platformi.

Ako deployate na edge runtimes, provjerite podršku za streaming i timeoute. Implikacije runtimea pokrivene su ovdje: Next.js Edge Runtime vs Node.js Runtime na Vercelu i Cloudflareu.

Primjer SSE route handlera u Next.js-u#

Ovaj primjer prikazuje osnovni SSE endpoint. Ne uključuje pravi izvor eventova, ali demonstrira ispravne headere i periodične heartbeatove.

// app/api/events/route.js
export async function GET() {
  const encoder = new TextEncoder();
 
  const stream = new ReadableStream({
    start(controller) {
      const send = (event, data) => {
        controller.enqueue(encoder.encode(`event: ${event}\n`));
        controller.enqueue(encoder.encode(`data: ${data}\n\n`));
      };
 
      send("connected", "ok");
 
      const interval = setInterval(() => {
        send("heartbeat", String(Date.now()));
      }, 15000);
 
      // No clean shutdown shown here for brevity
    },
  });
 
  return new Response(stream, {
    headers: {
      "Content-Type": "text/event-stream",
      "Cache-Control": "no-cache, no-transform",
      Connection: "keep-alive",
    },
  });
}

Client strana:

const es = new EventSource("/api/events");
es.addEventListener("heartbeat", (e) => console.log(e.data));

Skaliranje SSE-a#

SSE se dobro skalira za broadcast tip updateova, ali i dalje vam treba izvor eventova koji može raditi fan-out. Uobičajeni patterni:

• Pollajte bazu i streamajte delta promjene klijentima.
• Konzumirajte iz queuea ili pub-suba i streamajte povezanim klijentima.
• Koristite managed pub-sub i nakačite SSE kao mehanizam isporuke.

SSE postaje nezgrapan kad trebate visokofrekventne upstream poruke od klijenata. Možete kombinirati SSE plus obične HTTPS POST requestove za akcije klijenta, ali tada WebSockets može biti jednostavniji.

💡 Savjet: Za dashboarde smanjite volumen eventova slanjem agregiranih updateova svakih 250 do 1000 milisekundi, a ne po promjeni svakog retka. Korisnici doživljavaju "real time" kao bilo što ispod ~1 sekunde za većinu poslovnih dashboarda, a vi značajno štedite compute i bandwidth.

# Opcija 3: Supabase Realtime s Next.js-om#

Supabase Realtime vam daje dvije glavne real-time mogućnosti:

1. 1
   Postgres change feeds za insert, update, delete eventove.
2. 2
   Realtime channels za broadcast poruka, presence i sinkronizaciju stanja.

Velika prednost za Next.js je hosting: dugotrajna WebSocket konekcija je između browsera i Supabasea, a ne između browsera i vašeg Next.js deploya. To izbjegava najveću operativnu bol WebSocketa na serverless platformama.

Gdje Supabase Realtime najbolje sjeda#

Supabase Realtime je snažan izbor kada:

• Vaš source of truth je Postgres.
• Želite "database-driven" real-time updateove bez izgradnje pub-sub sloja.
• Trebate auth integriran s permissions u bazi preko Row Level Security.
• Želite brzo isporučiti i prihvaćate određenu povezanost s vendorom.

Posebno je učinkovit za interne alate, SaaS admin panele i proizvode u ranoj fazi gdje je time-to-market važniji od custom arhitekture skaliranja.

Primjer pretplate na Supabase Realtime#

Ovaj primjer se pretplaćuje na Postgres promjene za tablicu. Imajte na umu autorizaciju: RLS politike i dalje vrijede.

// subscribe.js
import { createClient } from "@supabase/supabase-js";
 
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY
);
 
const channel = supabase
  .channel("orders-feed")
  .on(
    "postgres_changes",
    { event: "*", schema: "public", table: "orders" },
    (payload) => console.log(payload)
  )
  .subscribe();

Za chat-like značajke, kanali su često bolji izbor od sirovih feedova promjena iz baze, jer chat treba validaciju poruka, provjere pristupa po sobama i ponekad transformacije poruka.

Auth i autorizacija sa Supabase Realtime#

Prava prednost Supabasea je konzistentan auth kroz:

• rukovanje sesijom u client SDK-u
• JWT claims
• Postgres Row Level Security politike

Ipak, autorizaciju morate pažljivo dizajnirati. Česta greška je pretplatiti se na široke feedove promjena tablica i filtrirati na klijentu. Ispravan pristup je provoditi pristup na razini baze pomoću RLS-a i query patterna koji scopeaju podatke po tenant-u i po korisniku.

Ako trebate usporediti auth pristupe u Next.js-u prije nego se odlučite za Supabase, koristite: Vodič za autentikaciju u Next.js-u: NextAuth vs Clerk vs Supabase.

Trošak i razmatranja skaliranja#

Trošak Supabase Realtime-a obično nije prvi trošak na koji naletite. Veći driveri su:

• broj povezanih klijenata
• stopa poruka i veličina payloada
• opterećenje baze uzrokovano writeovima i triggerima
• egress bandwidth

Ako vaš proizvod postane event-heavy, morate mjeriti i budžetirati na temelju stvarne upotrebe. Primjerice, presence updateovi svake 2 sekunde za 5.000 korisnika su 2.500 updateova u sekundi ako naivno modelirate presence. Čak i ako je svaki update malen, plaćate bandwidth i obradu.

# Trade-offovi po značajkama koji odlučuju pobjednika#

Ovdje većina timova donosi stvarnu odluku: hosting, skalabilnost, auth i trošak nisu apstraktni — postaju day-two problemi.

Ograničenja hostinga#

Ako ne možete pokretati dugotrajne konekcije u svom Next.js okruženju, WebSockets i SSE unutar Next.js-a nisu dobar start. To vas gura prema managed real-timeu ili zasebnom real-time servisu.

Skalabilnost i fan-out#

Autentikacija i kontrola pristupa#

Model troška i česta iznenađenja#

# Kriteriji odluke po use caseu#

Ovaj dio mapira potrebe proizvoda na konkretan izbor. Ovo nisu teorijske preporuke; odražavaju česte produkcijske pattern-e i failure modeove.

Chat aplikacije#

Chat je dvosmjeran. Trebate slanje poruka, potvrde isporuke, typing indikatore, presence, read receipts i workflowe moderacije.

Ako vam je Next.js aplikacija na serverless hostingu, chat gotovo uvijek završi kao zaseban real-time servis. Supabase je dobra opcija ako vam data model odgovara Postgresu i prihvaćate managed ograničenja.

Live nadzorne ploče#

Dashboardi su uglavnom server → klijent. Koriste jednostavne broadcast updateove i otporan reconnect.

Za dashboarde obično dobivate bolji ROI smanjenjem volumena eventova nego brušenjem latencije. Prava metrika je percipirana svježina za korisnika, ne odabir protokola.

Obavijesti#

Obavijesti su često bursty i ne trebaju strogi redoslijed. Također često trebaju offline podršku, što upućuje na queueove i perzistenciju.

Čest pattern je: perzistirati obavijesti u DB, streamati nove u real timeu, a pri reconnectu dohvatiti propuštene preko Last-Event-ID ili timestampa.

Suradničko uređivanje#

Suradnja je najteža. Trebate kontrolu konkurentnosti i rješavanje konflikata, a ne samo transport.

⚠️ Upozorenje: Suradničko uređivanje propada kad timovi to tretiraju kao "real-time messaging". Treba vam data model za merge i konflikte. Bez CRDT-a ili OT-a korisnici će si prepisivati sadržaj čak i ako je transport savršen.

# Observability: kako održati Next.js real time stabilnim#

Real-time sustavi su osjetljivi na male probleme: reconnect oluje, amplifikaciju poruka i tihe diskonekcije. Ako ne mjerite, problem ćete vidjeti tek kad se korisnici požale.

Pratite barem ove metrike:

Instrumentirajte i server i klijent. Client-side logovi su često jedini način da razumijete ponašanje mobilnih mreža.

Praktičan baseline za logove, metrike i tracing je ovdje: Vodič za observability web aplikacija: logging, metrics, tracing.

💡 Savjet: Dodajte jedinstveni eventId svakom eventu i spremite zadnji obrađeni eventId u memoriji. Time sprječavate dvostruku primjenu updateova nakon reconnecta, što je jedan od najčešćih real-time bugova u produkciji.

# Naša praktična preporuka#

Ako vam je cilj brzo isporučiti "Next.js real time" značajke uz minimalan DevOps, Supabase Realtime je teško nadmašiti, posebno za Postgres-backed dashboarde i chat u ranoj fazi. Dobivate managed WebSockets, integrirani auth i database-driven eventing bez izgradnje pub-sub sloja.

Ako trebate duboku kontrolu, predvidljivo skaliranje pod teškim dvosmjernim prometom ili gradite suradnju na velikoj skali, s vremenom ćete prerasti jednostavne setupove. WebSockets sa namjenskim realtime servisom i pravim pub-sub backboneom postaje dugoročna arhitektura.

Ako je vaš use case uglavnom broadcast updateova, SSE je najjednostavniji i često najpouzdaniji. Također ga je lakše osigurati i nadzirati jer je server jedini writer u streamu.

# Ključne poruke#

• Birajte prema modelu interakcije: dvosmjerne potrebe upućuju na WebSockets ili Supabase channels, a feedovi samo za broadcast često odgovaraju SSE-u.
• Ne hostajte WebSockets unutar serverless Next.js route handlera u produkciji; pokrenite zaseban realtime servis ili koristite managed providera.
• Koristite Supabase Realtime kad vam je Postgres source of truth i želite bržu isporuku uz integrirani auth i RLS.
• Za dashboarde prvo optimizirajte učestalost eventova i agregaciju; korisnicima rijetko trebaju per-row updateovi brži od 1 sekunde.
• Uložite u observability rano: pratite istovremene konekcije, reconnect stopu, stopu poruka i lag isporuke kako biste spriječili tihe kvarove.

# Zaključak#

WebSockets, SSE i Supabase Realtime mogu svi pokretati Next.js real time značajke, ali rješavaju različite probleme proizvoda i dolaze s različitim operativnim troškovima. Odaberite najjednostavniju opciju koja odgovara vašem modelu interakcije i ograničenjima hostinga, a zatim dodajte dijelove koji nedostaju: autorizaciju, replay i idempotentnost te observability.

Ako želite pomoć pri odabiru prave arhitekture ili implementaciji produkcijski spremnog realtime sloja u Next.js-u, kontaktirajte Samioda i pregledat ćemo vaš use case, hosting setup i ciljeve skaliranja, pa predložiti plan implementacije koji možete pouzdano isporučiti.