Praktische keuzehulp voor Blazor
Blazor: Server, WebAssembly of Hybride?
Blazor is handig als u weet welk werk op de server blijft, welk werk naar de browser wordt verplaatst en welke URL's als echte HTML-links moeten bestaan.
In deze handleiding wordt de brochureversie overgeslagen. Het richt zich op de afwegingen die teams meestal later verrassen: servergeheugen, liveverbindingen, latentie, payloadgrootte, SEO en meertalige routering.
Vóór de keuze van de rendermodus
Wat Blazor eigenlijk is
Blazor is het componentenframework van Microsoft voor .NET-webapps. Je bouwt de gebruikersinterface op basis van Razor-componenten, schrijft de meeste interactielogica in C# en laat ASP.NET Core die componenten renderen op de server, in WebAssembly of in een native app-shell.
Het is voortgekomen uit oudere ASP.NET-ideeën. Webformulieren probeerden het web achter serverbesturingselementen te verbergen. MVC en Razor Pages hebben HTML-opschoning van verzoek en antwoord gemaakt. Blazor voegt herbruikbare interactieve componenten toe, maar maakt MVC of Razor Pages niet overbodig voor eenvoudige inhoudspagina's en formulieren.
Webformulieren, MVC en Razor Pages hebben verschillende problemen opgelost
Webformulieren waren productief, maar zwaar en stateful. MVC en Razor Pages zorgden voor schonere HTML en eenvoudiger afhandeling van verzoeken. Ze zijn nog steeds goed als een pagina voornamelijk gegevens leest, een formulier plaatst en HTML retourneert.
Componenten houden de UI-logica dicht bij de markup
Een Razor-component kan markeringen, parameters, gebeurtenissen, validatie, geïnjecteerde services en lokale status bevatten. Dat is handig voor dashboards, editors, wizards, rasters en tools waarbij de pagina verandert zonder volledig opnieuw te laden.
Met modern .NET kun je rendermodi combineren
Nieuwere Blazor-apps kunnen statische, door de server weergegeven HTML combineren met interactieve componenten. Dat is belangrijk omdat de ene pagina mogelijk crawlbare inhoud nodig heeft, terwijl een ander deel een live component nodig heeft.
Inhoudsopgave
Begin hier
De handige korte versie
Blazor is niet één architectuur. Het is één componentmodel met verschillende rendermodi. De juiste keuze hangt minder af van de syntaxis en meer van waar de status, latentie, geheugen en doorzoekbare links zich bevinden.
Blazor Server is stateful
Het kan snel aanvoelen bij de eerste keer laden, maar de server houdt circuits onder spanning. Plan het geheugen, maak opnieuw verbinding met het gedrag en schaal uit voordat het verkeer groeit.
WebAssembly betaalt vooraf
Het verwijdert live servercircuits, maar bij het eerste bezoek worden de runtime en app gedownload. Cache, trimmen en pre-rendering zijn belangrijk.
Hybride is een productbeslissing
Gebruik Hybrid wanneer de app echt een desktop- of mobiele shell nodig heeft. Gebruik voor openbare inhoud webweergave en echte URL's.
Blazor Server
Blazor Server houdt het werk levend tussen de klikken door
Blazor Server is geen normale staatloze verzoek-antwoordpagina. Een verbonden browsertabblad krijgt een circuit. De server bewaart de componentstatus en de bereikdiensten voor dat circuit terwijl de gebruiker verbonden is, en vaak gedurende een korte periode voor opnieuw verbinden na het verbreken van de verbinding.
Het geheugen groeit met actieve circuits
Elk aangesloten tabblad heeft een circuit. Componentstatus, bereikservices, validatiestatus en in behandeling zijnd UI-werk kunnen in het geheugen blijven totdat het circuit eindigt. Laadtests moeten actieve gebruikers tellen, niet alleen verzoeken per seconde.
Latency wordt onderdeel van de gebruikersinterface
Een knopklik, invoergebeurtenis of rasterinteractie kan naar de server reizen en terug. Host dicht bij gebruikers en vermijd spraakzame componenten wanneer het publiek over regio's verspreid is.
Voor opschaling is een plan nodig
Voor meerdere app-instanties zijn vaak sticky-sessies, een SignalR-backplane, een Azure SignalR-service of een zorgvuldig statusontwerp nodig. Anders kunnen opnieuw verbindingen worden gemaakt en kunnen onder spanning staande circuits op de verkeerde instantie terechtkomen.
Goede pasvorm: gecontroleerde gebruikers
Blazor Server is het sterkst voor geauthenticeerde tools, beheerdersschermen, dashboards en interne apps waar gebruikers, latentie en hostingcapaciteit bekend zijn.
Blazor WebAssembly
WebAssembly verplaatst de kosten naar de eerste lading
Blazor WebAssembly verwijdert servercircuits, maar niet de kosten. De browser moet de .NET-runtime, assemblages, lokalisatiebronnen en app-middelen downloaden voordat de ervaring snel aanvoelt. Herhaalde bezoeken kunnen goed zijn omdat caching helpt. Eerste bezoeken hebben zorg nodig.
De eerste belasting is de belasting
De browser downloadt de .NET-runtime, app-assemblages, bronnen en statische assets. Trimmen helpt. Compilatie vooraf kan CPU-zwaar werk verbeteren, maar vergroot vaak de downloadgrootte.
Geheimen kunnen niet in de cliënt leven
Een WebAssembly-app draait in de browser van de gebruiker. Behandel het als elke openbare frontend: bewaar geheimen op de server, bescherm API's en ga ervan uit dat clientcode kan worden geïnspecteerd.
SEO heeft weergegeven inhoud nodig
Vertrouw voor openbare artikelen, productpagina's en landingspagina's niet op een lege shell die pas nuttig wordt nadat WebAssembly is gestart. Gebruik server-side rendering, pre-rendering, statische rendering of een afzonderlijk inhoudspad.
Goede pasvorm: offline of client-heavy apps
WebAssembly werkt goed wanneer gebruikers vaak terugkomen, offline gedrag nodig hebben of zwaar client-side werk doen waarbij een server-retour slechter zou zijn.
Hybride en WebView
Hybride is voor apps, niet voor openbare landingspagina's
Blazor Hybrid is handig wanneer een .NET-team componenten wil hergebruiken in een desktop- of mobiele app. Het draait in een native shell via een WebView, zodat het dicht bij lokale bestanden, apparaat-API's en bedrijfsimplementatie kan staan. Het is geen snelkoppeling voor SEO-gerichte websites.
- Gebruik Hybride wanneer u toegang nodig heeft tot lokale bestanden, apparaat-API's, desktopimplementatie of mobiele pakketten.
- Kies niet voor Hybride alleen om webcomponenten te hergebruiken. De native shell voegt update-, opslag-, ondertekenings- en ondersteuningswerk toe.
- Voor SEO en deelbare openbare URL’s is hybride meestal het verkeerde oppervlak.
Meertalige routering
Cultuurbewuste verbindingen moeten echte verbindingen zijn
Een meertalige Blazor-site mag taalnavigatie niet alleen in klikhandlers of JavaScript bouwen nadat de pagina interactief is geworden. Zoekmachines en gebruikers hebben echte ankertags nodig in de initiële HTML, met stabiele href-waarden, canonieke URL's en hreflang-gegevens.
- Gebruik centrale paginalinks en helpers in plaats van met de hand gemaakte strings zoals slash culture slash path.
- Geef taallinks weer als ankertags met href-waarden tijdens de eerste HTML-weergave.
- Houd canonieke URL's, hreflang-URL's en zichtbare taalnavigatie gesynchroniseerd.
- Vermijd het verbergen van belangrijke links achter onclick-handlers, vertraagde JavaScript of alleen interactieve Blazor-status.
Keuzegids
Kies op basis van het knelpunt dat u accepteert
Elke rendermodus verplaatst de druk naar een andere plaats. Kies de druk die u kunt meten, hosten en uitleggen aan het team.
Wanneer de eerste keer wordt geladen en de .NET-backend-integratie het belangrijkst is
Kies Blazor Server voor gecontroleerde, geverifieerde apps waarbij servergeheugen, liveverbindingen en regionale latentie acceptabele bedrijfskosten zijn.
Wanneer het werk en het offline gedrag van de klant er het meest toe doen
Kies WebAssembly wanneer herhaalde bezoeken, caching, offline gebruik of lokaal CPU-werk belangrijker zijn dan de kleinste eerste belasting.
Wanneer het product echt een native app is
Kies voor Hybride als de applicatie thuishoort op desktop of mobiel en meer lokale integratie nodig heeft dan publiek webbereik.
Wanneer de site voornamelijk uit documenten en formulieren bestaat
Klassieke ASP.NET Core MVC- of Razor Pages zijn vaak eenvoudiger voor sites met veel inhoud, openbare documentatie en formulieren met beperkte interactiviteit.
Referentie sectie
Lees deze hierna als je dit echt gaat bouwen
Deze referenties zijn nuttig na de architectuurbeslissing, omdat ze de onderdelen behandelen die een Blazor-pagina betrouwbaar maken in productie: metadata, taallinks, hosting en herbruikbare gebruikersinterface.
Gebruik dit wanneer elke pagina een consistente titel, beschrijving, Open Graph, canonieke en JSON-LD-uitvoer nodig heeft.
SEO-vriendelijke taal-regio-linksGebruik dit wanneer meertalige routering echte doorzoekbare links, stabiele cultuurpaden en correcte hreflang-uitvoer nodig heeft.
Host Blazor op UpCloudGebruik dit wanneer een Blazor Server-app een kleine VPS, Nginx, TLS, systemd, logs, back-ups en herhaalbare implementaties nodig heeft.
TablerForNetGebruik dit wanneer de waarde een beheerdersinterface, gegevenstabellen, formulieren en dashboardschermen is in plaats van een marketingpagina.
BlazorGebruik de Blazor-hub als u de gerelateerde handleidingen op één plek wilt hebben voordat u het volgende implementatiedetail kiest.
Veelgestelde vragen
Waarom kan Blazor Server meer geheugen nodig hebben dan MVC?
MVC kan een verzoek voltooien en de meeste verzoekstatus vrijgeven. Blazor Server houdt een circuit bij voor elk verbonden browsertabblad, zodat de componentstatus en de bereikbare services tussen klikken in leven kunnen blijven.
Kan ik Blazor Server op meerdere app-instanties uitvoeren?
Ja, maar plan het bewust. Live circuits en SignalR-verbindingen hebben stabiele routering nodig, een backplane of beheerde SignalR-service, en een applicatiestatus die overleeft en opnieuw correct verbinding maakt.
Kan Blazor WebAssembly SEO-vriendelijk zijn?
Ja, maar niet door een lege huls te verzenden en te hopen dat de crawler wacht. Openbare pagina's hebben vóór of tijdens de eerste reactie HTML, metadata, canonieke links en gestructureerde gegevens nodig.
Hoe moeten meertalige Blazor-links worden opgebouwd?
Gebruik centrale routedefinities en geef echte ankertags weer voor elke cultuur. Houd zichtbare links, canonieke URL's en hreflang-gegevens op één lijn, zodat gebruikers en crawlers dezelfde taalstructuur zien.