Blazor Client Side (WASM) or Server Side

[DotNetDublin]

We need to decide whether to implement the application using Blazor Client Side (WASM) or Server Side.

https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-models?view=aspnetcore-5.0

Given the below requirement and the potential for a large amount of users I'm leaning towards Blazor Client Side.

The IT department is already busy and would therefore prefer if the solution was delivered via a Cloud hosting solution that was scalable without the need for further development

[harperjohn]

I agree that a WASM target is a good thing for a few reasons (It is a "Blazor" strong point, SPAs are getting so popular/useful, etc)

However, at the moment I think that WASM is hard to debug.

And having the both Server and WASM options for as long as possible is nice...

Blazor train shows how to develop both Server and WASM simultaneously, And this article also does a great job discussing it! (I think he makes all of his examples support both)
https://www.codeproject.com/Articles/5299017/Building-a-Blazor-WASM-and-Server-All-In-One-Solut

[jonhilt]

The ability to build the application then host it in different ways does seem to be one of Blazor's unique strengths at this point, so it could make make sense to go down the 'both' route.

I guess the only caveat there would be if it ends up costing more effort (to maintain this hybrid approach) than the benefit of having that flexibility.

The hybrid approach generally works without too much overhead but occasionally you end up having to implement things twice, simply because WASM/Server behave differently.

Perhaps an initial spike is in order (testing out the approach, using the resources mentioned by @harperjohn).

[DotNetDublin]

Thanks @harperjohn and @jonhilt.

Certainly one for us to ponder over in the coming days and I must re-watch that Blazor Train episode.

[harperjohn]

It seems that MudBlazor easily supports both Server and WASM...

And if you go to https://mudblazor.com/ you can see a button in the upper right corner that allows for the dynamic switching between Server and WASM

Note - If you download the Mudblazor source - There is a "server" project in the solution that is the MudBlazor website! So you can run it locally and we can see how they built their "dual" app.

[DotNetDublin]

What a world we live in when you can just clone a software repository and be able to see such great code. That's what they'll say about TimeKeeper one day! 😃

I see they have amongst others the below projects

• MudBlazor.Docs
• MudBlazor.Docs.Client
• MudBlazor.Docs.Server

You won't believe I worked this out so quickly however MudBlazor.Docs.Client is the WASM project, MudBlazor.Docs.Server is the server side project and MudBlazor.Docs is the project that is shared between Docs.Client and Docs.Server.

MudBlazor.Docs contains all the pages and components

In MainLayout.razor I note the below code.

@if (Wasm)
{
	<MudTooltip Text="Switch to Blazor server-side">
		<MudIconButton Icon="@Icons.Material.Filled.Computer" Color="Color.Inherit" OnClick="@((e) => SwitchToServer())" />
	</MudTooltip>
}
else
{
	<MudTooltip Text="Switch to Blazor wasm">
		<MudIconButton Icon="@Icons.Material.Filled.Dns" Color="Color.Inherit" OnClick="@((e) => SwitchToWasm())" />
	</MudTooltip>
}

In MainLayout.razor.cs I note the below code.

private void SwitchToServer()
{
	NavigationManager.NavigateTo(NavigationManager.Uri.Replace("wasm/", string.Empty), forceLoad: true);
}

private void SwitchToWasm()
{
	NavigationManager.NavigateTo(NavigationManager.Uri.Replace(
		NavigationManager.BaseUri,
		NavigationManager.BaseUri + "wasm/" + NavigationManager.ToBaseRelativePath(NavigationManager.BaseUri))
		, forceLoad: true);
}

private bool Wasm => NavigationManager.Uri.Contains("wasm");

As Larry David would say pretty, pretty, pretty, pretty, pretty, good!

[DotNetDublin]

Overall I think we are edging towards an agreement to at least try and provide a hybrid Client and Server application.

If for whatever reason it starts to become too onerous we will drop back to only Client in the first instance.

One thing we do need to be aware of is that having a server side version will impact the Azure hosting options. See issue #12 however as I type this I realise that could actually be another advantage as we'll gain experience of hosting both a client and server Blazor application in Azure.

[DotNetDublin]

One thing we do need to be aware of is that having a server side version will impact the Azure hosting options. See issue #12 however as I type this I realise that could actually be another advantage as we'll gain experience of hosting both a client and server Blazor application in Azure.

I realise now when I said "as we'll gain experience of hosting both a client and server Blazor application in Azure." that's not correct as in terms of hosting it will be a single combined app rather than separate client and server Blazor apps.

One of the advantages of client Blazor apps is that you can host as a static site which I think in Azure means you can choose a cheaper option but I don't think we need to worry about that too much in our scenario.

[harperjohn]

Yes it feels like thee general situations:

Blazor Server - Needs a "constant" server connection. Period.
Blazor WASM - Does some/a lot of processing on the client, but still needs a server or "azure functions" for some (usually regular/periodic if not nearly "constant") external processing/data/resources. Even if the server "need" is pretty "constant" I believe that this can still be a "low server load" and a lower cost than Blazor server.
Blazor WASM - As a pure "static" site, that can be hosted less expensively at Azure, and (I am pretty sure) at any "regular" hosting service. Hugo has a lot of this "space" covered, but to "interactivity" to Hugo, JavaScript is needed, and in some/small cases this is fine, but I can see a segment of sites that would be mostly "static", but that could really benefit from C# functionality. This is definitely a "tool" that I want in my "belt".

[ripteqdavid]

If we do go down the dual hosting scenario, it might be worth building a WebAPI layer directly in the server soluition so that we can share:

• Service layer
• Security management and authentication
• WebAPI layer could be useful for a mobile app down the track
• Learn from the setup/implementation experience

This should reduce the maintenance overhead going forward (it will still be greater with 2 hosting models)

[jonhilt]

Agreed. If we're going to have a Blazor WASM frontend then the only way it can really interact with the backend is via Web API.

As it is, this doesn't need to be too complicated to set up. Here's one example I put together (primarily for demonstrating prerendering but it's the same basic architecture).

https://github.com/jonhilt/blazor-wasm-net5-example

The Server project exposes an API controller (in this case for the weather sample demo thingy).

https://github.com/jonhilt/blazor-wasm-net5-example/blob/master/Server/Controllers/WeatherForecastController.cs

The WASM UI then makes an HTTP call to this endpoint to fetch data:

https://github.com/jonhilt/blazor-wasm-net5-example/blob/master/Client/Data/WeatherForecastService.cs

Whereas the Blazor Server part of the project can just bypass the controller and fetch the data more directly:

https://github.com/jonhilt/blazor-wasm-net5-example/blob/master/Server/Data/WeatherForecastService.cs

If that makes sense.

[ripteqdavid]

Perfect!

Only thing we'll need to add is authentication and authorization (which I went through on another project today). Unfortunately I can't share the GitHub code (Enterprise project), however I might add documentation as it had a few tricks.

[jonhilt]

Sounds good @ripteqdavid :-)

[harperjohn]

@ripteqdavid and @jonhilt I agree! And really like the "Server API" for shared/common server processing. As time/experience goes by I am really seeing the benefit of keeping the server/wasm options as synced/interchangeable as possible.