De Host en Blazor
Inleiding
In ASP .NET Core wordt een host geactiveerd bij het opstarten van een applicatie. De host zet net zoals het stokstaartje in de uitgelichte afbeelding dingen klaar die nodig zijn voor het doen draaien van de applicatie (in het geval van het stokstaartje wordt een bos wortels klaargezet voor de giraffe zodat de giraffe daarmee zijn dingen kan doen). In deze post zullen we de host nader bekijken.
Een host zorgt o.a. voor het “optuigen” van “services” waarbij de service binnen de applicatie beschikbaar is voor gebruik.
Een host is weer wat anders dan een hosting model en ik hoop dat na het lezen van deze post ook de verwarring is weggenomen over wat een host is en wat een hosting model is.
Hosting modellen
In deze post hebben we het gehad over hosting modellen. De strekking van de post is dat een web server in het geval van een web applicatie altijd wel iets zal moeten doen. Het hangt van de hosting model af wat en hoeveel de web server moet doen.
Zo zal een web server veel meer moeten doen bij een “Blazor server”-applicatie terwijl de web server het wat rustiger aan kan doen bij een “Blazor Web Assembly”-applicatie omdat bij een “Blazor Web Assembly”-applicatie veel werk uit handen wordt genomen door de Web Assembly programmatuur in de browser.
de Host
De term host zien we ook regelmatig voorbij komen, maar wat is dat dan? Een host schijnt toch weer wat anders te zijn dan een “hosting model” ofschoon het woord host in beide termen voorkomt.
Een host wordt geactiveerd met het opstarten van een applicatie waarbij de host dingen klaargezet die nodig zijn voor het doen draaien van de applicatie. Zo heeft Microsoft ook een host voor haar .NET applicaties en sinds ASP .NET Core 3.x heeft Microsoft haar “Generic Host”.
De Generic Host wordt dan ook voor alle .NET Core applicaties gebruikt, maar de inspanningen van de generic host zullen per applicatie verschillen. Zo zal het voor elke applicatie wenselijk zijn dat voorzieningen worden getroffen voor:
- het doen instellen van een “content root” directory
- het kunnen vastleggen van configuratiegegevens welke nodig zijn voor de applicatie
- logging
- het registreren van “services” die beschikbaar moeten zijn binnen de applicatie
- dependency injection
Maar onderstaande voorzieningen zullen voor bijvoorbeeld een “Worker Role”-applicatie niet nodig zijn, maar wel weer voor een web applicatie:
- voorzieningen voor de Kestrel web server
- voorzieningen voor de IIS web server
We bekijken voor een viertal applicatie types het “opstartmechaniek” zodat we enigszins kunnen herleiden wat een host doet.
Blazor Server
We zien dat het opstartmechaniek begint met een methode Main in Program.cs waarbij als host uiteindelijk een .CreateDefaultBuilder()-methode wordt aangeroepen met ergens een startup-object en ergens in dat startup-object wordt datgene wat nodig is verder opgetuigd.
MVC
Het opstartmechaniek bij een MVC .NET Core applicatie is identiek aan die van een “Blazor server”-applicatie. Ook hier zien we een methode Main in Program.cs met een .CreateDefaultBuilder()-methode zijnde de host en een startup-object.
Worker Role
Het zelfde verhaal bij een “Worker Role”-applicatie. Ook daar zien we een methode Main in Program.cs met een .CreateDefaultBuilder()-methode als zijnde de host.
We gaan nu wel wat verschillen zien bij die .CreateDefaultBuilder()-methode. De host gebruikt nu een worker-object voor het verder doen optuigen van de dingen die nodig zijn.
Blazor Web Assembly
Bij “Blazor Web Assembly”-applicatie zien we meer afwijkingen. We zien dat bij een “Blazor Web Assembly”-applicatie de nadruk ligt op het optuigen van een HttpClient-service dat binnen de applicatie gebruikt kan worden voor het doen aanroepen van Web APIs. Verder zien we dat de host een app “root component” optuigt zijnde iets wat specifiek nodig is voor een “Blazor Web Assembly”-applicatie.
Deze afwijkende opstart valt te verklaren uit het feit dat bij een “Blazor Web Assembly”-applicatie veel in de browser zelf wordt gedaan waardoor een web server en allerlei andere zaken niet opgetuigd hoeven te worden.
Slot
In deze post hebben we het opstartmechaniek bekeken van een “Blazor Server”-applicatie, een “ASP .NET Core MVC”-applicatie”, een “Worker Role”-applicatie en een “Blazor Web Assembly”-applicatie.
In alle vier de gevallen zijn er grote overeenkomsten voor wat betreft het opstarten van de applicatie met een host. De host zet dingen klaar die nodig zijn voor het doen draaien van de applicatie. Elke .NET Core applicatie heeft weer zijn eigen behoeftes waardoor datgene wat de host moet klaarzetten ook weer per applicatie zal verschillen.
Alle verschillen ten spijt, bij elke .NET Core applicatie wordt uitgegaan van het kunnen optuigen van “services” door een host. In deze post zullen we in detail ingaan op een ASP .NET Core hosted Blazor WebAssembly App en we komen daar een host tegen die ervoor zorgt dat dingen als “services” beschikbaar komen voor andere onderdelen binnen de applicatie waarbij die andere onderdelen naar goeddunken gebruik mogen maken van de “service”.
Hopelijk ben je met deze posting weer wat wijzer geworden en ik hoop je weer terug te zien in één van mijn volgende blog posts. Wil je weten wat ik nog meer over Blazor heb geschreven? Hit the Blazor button…