Blazor Server vs WebAssembly vs Auto: vad ska du välja för en affärsapplikation?

Varje Blazor-projekt börjar med samma beslut, och det är lätt att göra fel: ska applikationen köras på servern eller i webbläsaren? Väljer du fel köper du större servrar ett år senare, eftersom varje användare håller minne, eller förklarar för användarna varför den första laddningen tar så lång tid.

Det korta svaret: sedan .NET 8 väljer du inte längre ett läge för hela applikationen, utan för varje sida. För de flesta affärsapplikationer är rätt mix enkel: vanlig rendering på servern för publika sidor, Interactive Server för interna skärmar och WebAssembly bara där det tydligt lönar sig.

De fyra lägena med enkla ord

Läge	Var koden körs	Vad användaren får
Statisk rendering på servern	På servern, en gång per anrop	En vanlig snabb HTML-sida, formulär fungerar, men utan levande interaktivitet
Interactive Server	På servern, via en ständig anslutning	Omedelbar start, varje klick går till servern och tillbaka
Interactive WebAssembly	I användarens webbläsare	En större första nedladdning, sedan körs allt lokalt, även offline
Interactive Auto	Först på servern, sedan i webbläsaren	Startar som Server och byter vid senare besök, när filerna har laddats ner, till WebAssembly

Jämfört efter det som spelar roll för verksamheten

	Interactive Server	WebAssembly
Första laddning	Snabb	Långsammare första gången, sedan från cachen
Hundratals användare samtidigt	Inga problem	Inga problem
Tiotusentals samtidigt	Kräver planering: minne per användare, fler servrar eller Azure SignalR Service	Belastar servern knappt
Svag eller instabil anslutning	Varje klick väntar på nätverket, och ett avbrott betyder återanslutning	Körs lokalt, bara dataanrop väntar
Arbete offline	Inte möjligt	Möjligt
Kod och affärsregler	Stannar på servern	Laddas ner till webbläsaren, så inget hemligt får finnas i dem
Åtkomst till databas och tjänster	Direkt	Bara via ett API
Serverkostnad	Växer med antalet användare som arbetar samtidigt	Främst kostnaden för API:et

Den viktigaste skillnaden är inte hastigheten, utan var koden lever. Med Interactive Server anropar skärmen dina tjänster och databasen direkt, och ingenting lämnar servern. Med WebAssembly är applikationen i webbläsaren i praktiken en publik klient: allt den vet kan en nyfiken användare se, och all data måste komma via ett API som kontrollerar behörigheter.

Det riktiga svaret: per sida

I en Blazor Web App bestämmer varje sida eller komponent sitt eget läge. Applikationen förbereds en gång, i Program.cs, för båda interaktiva lägena:

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

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

Därefter avgör en rad på sidan:

@page "/orders"
@rendermode InteractiveServer

@page "/field/inspection"
@rendermode InteractiveWebAssembly

En sida utan @rendermode renderas statiskt på servern, precis vad en publik sida eller ett enkelt formulär behöver. Komponenter som körs i WebAssembly ligger i ett separat klientprojekt, som mallen Blazor Web App skapar åt dig.

En typisk mix för en affärsapplikation

• Publika sidor, inloggning, enkla formulär: statisk rendering på servern. Snabbt, bra för Google, utan ständig anslutning.
• Interna skärmar, administration, rapporter: Interactive Server. Direkt åtkomst till tjänster, ingenting lämnar servern, och för några hundra anställda är serverbelastningen måttlig.
• Skärmar för arbete i fält eller på svaga anslutningar: WebAssembly. Det extra API:et lönar sig bara där anslutningen verkligen är ett problem.

För en typisk intern applikation betyder det att de flesta skärmar använder Interactive Server, och WebAssembly är undantaget, inte standardvalet.

Fällorna

• Auto ser ut som det bästa av två världar, men kostar mest. Samma komponent måste fungera både på servern och i webbläsaren, så den kan inte anropa tjänster direkt och behöver ett API för allt. Välj Auto när du verkligen behöver båda, inte som ett säkert standardval.
• Interactive Server håller tillstånd per användare. Varje öppen flik håller minne på servern tills användaren går. Komponenter som laddar enorma listor i minnet multiplicerar det med varje användare. Hur du håller det under kontroll visar artikeln om långsamma Blazor-applikationer.
• Med WebAssembly är webbläsaren inte din. Anslutningssträngar, API-nycklar och prisregler får inte finnas i klientprojektet, och varje API-anrop måste kontrollera behörigheterna på servern igen. Hela listan finns i checklistan för säkerhet i Blazor.
• Förrendering laddar data två gånger om du inte hanterar det: en gång på servern för den första HTML-koden och igen när sidan blir interaktiv. I .NET 10 löser attributet [PersistentState] det.

Fem frågor innan du bestämmer dig

1. Hur många användare arbetar samtidigt, och var finns de: på kontoret eller i fält?
2. Hur bra är deras anslutning, och behöver de arbeta offline?
3. Behöver skärmen direkt åtkomst till tjänster och databas, eller har du redan ett API?
4. Finns det något i skärmens logik som användarna inte får se?
5. Måste sidan gå att hitta på Google?

För de flesta interna skärmar leder svaren till Interactive Server, för publika sidor till statisk rendering. WebAssembly vinner där anslutningen eller arbete offline avgör.

Om du fortfarande funderar på om du ska bygga i Blazor alls, läs Har Blazor en framtid 2026? och Blazor vs React för affärsapplikationer. En kort översikt över vilket läge som passar vilken skärm finns också på sidan Blazor.

Så arbetar vi

ProCoding är en .NET-studio från Split i Kroatien, och vi har levererat Blazor till produktion sedan 2020. Vi hjälper dig att välja läge per skärm innan den första kodraden skrivs, och rättar till applikationer där valet visade sig vara fel. Första steget är ett kostnadsfritt samtal på 30 minuter.

Källor

• 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