Blazor Server vs WebAssembly vs Auto: što odabrati za poslovnu aplikaciju?

Svaki Blazor projekt počinje istom odlukom, a nju je lako promašiti: treba li aplikacija raditi na serveru ili u pregledniku? Odaberete li krivo, za godinu dana kupujete veće servere jer svaki korisnik drži memoriju, ili korisnicima objašnjavate zašto prvo učitavanje traje tako dugo.

Kratki odgovor: od .NET-a 8 više se ne bira jedan način rada za cijelu aplikaciju, nego za svaku stranicu. Za većinu poslovnih aplikacija prava kombinacija je jednostavna: obično serversko iscrtavanje za javne stranice, Interactive Server za interne ekrane, a WebAssembly samo tamo gdje se jasno isplati.

Četiri načina rada ljudskim jezikom

Način	Gdje se kod izvršava	Što korisnik dobiva
Statično serversko iscrtavanje	Na serveru, jednom po zahtjevu	Običnu brzu HTML stranicu, forme rade, ali bez žive interaktivnosti
Interactive Server	Na serveru, uz stalnu vezu	Trenutan početak, svaki klik ide do servera i natrag
Interactive WebAssembly	U korisnikovom pregledniku	Veće prvo preuzimanje, a zatim sve radi lokalno, čak i bez interneta
Interactive Auto	Prvo na serveru, zatim u pregledniku	Počinje kao Server, a pri idućim posjetama, kad su datoteke preuzete, prelazi na WebAssembly

Usporedba po onome što je važno firmi

	Interactive Server	WebAssembly
Prvo učitavanje	Brzo	Sporije prvi put, zatim iz predmemorije
Stotine korisnika istovremeno	Nema problema	Nema problema
Desetci tisuća istovremeno	Traži planiranje: memorija po korisniku, više servera ili Azure SignalR Service	Server gotovo ne osjeti
Slaba ili nestabilna veza	Svaki klik čeka mrežu, a prekid znači ponovno spajanje	Radi lokalno, čekaju samo pozivi za podatke
Rad bez interneta	Nije moguć	Moguć
Kod i poslovna pravila	Ostaju na serveru	Preuzimaju se u preglednik, pa u njima ne smije biti ništa tajno
Pristup bazi i servisima	Izravno	Samo preko API-ja
Trošak servera	Raste s brojem korisnika koji rade u isto vrijeme	Uglavnom trošak API-ja

Ključna razlika nije brzina, nego gdje kod živi. Kod Interactive Servera ekran izravno poziva vaše servise i bazu, a ništa ne izlazi sa servera. Kod WebAssemblyja aplikacija u pregledniku u biti je javni klijent: sve što ona zna, znatiželjan korisnik može vidjeti, a svaki podatak mora doći preko API-ja koji provjerava ovlasti.

Pravi odgovor: po stranici

U Blazor Web App aplikaciji svaka stranica ili komponenta sama određuje svoj način rada. Aplikacija se jednom, u Program.cs, pripremi za oba interaktivna načina:

builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents()
    .AddInteractiveWebAssemblyComponents();

app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode()
    .AddInteractiveWebAssemblyRenderMode()
    .AddAdditionalAssemblies(typeof(Client._Imports).Assembly);

Nakon toga odlučuje jedan redak na stranici:

@page "/orders"
@rendermode InteractiveServer

@page "/field/inspection"
@rendermode InteractiveWebAssembly

Stranica bez @rendermode iscrtava se statično na serveru, a to je upravo ono što treba javnoj stranici ili jednostavnoj formi. Komponente koje rade u WebAssemblyju žive u zasebnom client projektu, koji predložak Blazor Web App izradi za vas.

Tipična kombinacija za poslovnu aplikaciju

• Javne stranice, prijava, jednostavne forme: statično serversko iscrtavanje. Brzo, dobro za Google, bez stalne veze.
• Interni ekrani, administracija, izvještaji: Interactive Server. Izravan pristup servisima, ništa ne izlazi sa servera, a za nekoliko stotina zaposlenika opterećenje servera je skromno.
• Ekrani za rad na terenu ili na slabim vezama: WebAssembly. Dodatni API isplati se samo tamo gdje je veza stvarno problem.

Za tipičnu internu aplikaciju to znači da većina ekrana koristi Interactive Server, a WebAssembly je iznimka, a ne zadani izbor.

Zamke

• Auto izgleda kao najbolje od oba svijeta, ali najviše košta. Ista komponenta mora raditi na serveru i u pregledniku, pa ne može izravno zvati servise i za sve treba API. Birajte ga kad vam stvarno treba oboje, a ne kao siguran zadani izbor.
• Interactive Server čuva stanje po korisniku. Svaka otvorena kartica drži memoriju na serveru dok korisnik ne ode. Komponente koje u memoriju učitavaju ogromne popise to množe sa svakim korisnikom. Kako to držati pod kontrolom, pokazuje članak o sporim Blazor aplikacijama.
• Kod WebAssemblyja preglednik nije vaš. Connection stringovi, API ključevi i pravila za cijene ne smiju biti u client projektu, a svaki API poziv mora ponovno provjeriti ovlasti na serveru. Cijelu listu donosi članak o sigurnosti Blazor aplikacije.
• Predrenderiranje učitava podatke dvaput ako to ne riješite: jednom na serveru za prvi HTML i ponovno kad stranica postane interaktivna. U .NET-u 10 to rješava atribut [PersistentState].

Pet pitanja prije odluke

1. Koliko će korisnika raditi istovremeno i gdje su: u uredu ili na terenu?
2. Kakva im je veza i moraju li raditi bez interneta?
3. Treba li ekranu izravan pristup servisima i bazi ili već imate API?
4. Ima li u logici ekrana nešto što korisnici ne smiju vidjeti?
5. Mora li se stranica naći na Googleu?

Za većinu internih ekrana odgovori vode prema Interactive Serveru, a za javne stranice prema statičnom iscrtavanju. WebAssembly pobjeđuje tamo gdje odlučuju veza ili rad bez interneta.

Ako još odlučujete hoćete li uopće raditi u Blazoru, pogledajte Je li Blazor još relevantan 2026.? i Blazor vs React za poslovne aplikacije. Kratki pregled koji način rada odgovara kojem ekranu nalazi se i na stranici Blazor.

Kako mi radimo

ProCoding je .NET studio iz Splita i Blazor isporučujemo u produkciju od 2020. Pomažemo vam odabrati način rada za svaki ekran prije prvog retka koda i popravljamo aplikacije u kojima se izbor pokazao pogrešnim. Prvi korak je besplatan razgovor od 30 minuta.

Izvori

• ASP.NET Core Blazor render modes, Microsoft Learn
• ASP.NET Core Blazor hosting models, Microsoft Learn
• Prerendered state persistence, Microsoft Learn
• Azure SignalR Service, Microsoft Learn