Hosting Models

Learn the different hosting models and their pros and cons in the Blazor framework.

Blazor has two different hosting models. The first hosting model that Microsoft released is the Blazor Server model. In this hosting model, the web app is executed on the server. The second hosting model that Microsoft released, and the topic of this course, is the Blazor WebAssembly model. In this hosting model, the web app is executed on the browser.

Each hosting model has its own advantages and disadvantages. However, they both use the same underlying architecture. Therefore, it is possible to write and test our code independent of the hosting model. The major differences between the two hosting models concern latency, security, data access, and offline support.

Blazor Server

As we just mentioned, the Blazor Server hosting model was the first hosting model released by Microsoft. It was released as part of the .NET Core 3 release in September 2019. The following diagram illustrates the Blazor Server hosting model:

Press + to interact
Blazor Server model
Blazor Server model

In this hosting model, the web app is executed on the server and only updates to the UI are sent to the client's browser. The browser is treated as a thin client and all of the processing occurs on the server. When using Blazor Server, UI updates, event handling, and JavaScript calls are all handled over an ASP.NET Core SignalR connection.

Note: SignalR is a software library that allows the web server to push real-time notifications to the browser. Blazor Server uses it to send UI updates to the browser.

Advantages of Blazor Server

There are a few advantages of using Blazor Server vs. using Blazor WebAssembly. However, the key advantage is that everything happens on the server. Since the web app runs on the server, it has access to everything on the server. As a result, security and data access are simplified. Also, since everything happens on the server, the assemblies (DLLs) that contain the web app's code remain on the server.

Another advantage of using Blazer Server is that it can run on thin clients and older browsers, such as Internet Explorer, that do not support WebAssembly.

Finally, the initial load time for the first use of a web app that is using Blazor Server can be much less than that of a web app that is using Blazor WebAssembly because there are fewer files to download.

Disadvantages of Blazor Server

The Blazor Server hosting model has a number of disadvantages vs. Blazor WebAssembly due to the fact that the browser must maintain a constant connection to the server. Since there is no offline support, every single user interaction requires a network roundtrip. As a result of all of these roundtrips, Blazor Server web apps have higher latency than Blazor WebAssembly web apps and can feel sluggish.

Tip: Latency is the time between the UI action and the time when the UI is updated.

Another disadvantage of using Blazor Sever is that it relies on SignalR for every single UI update. Microsoft's support for SignalR has been improving, but it can be challenging to scale.

Finally, a Blazor Server web app must be served from an ASP.NET Core server.

Blazor WebAssembly

The Blazor WebAssembly hosting model is the most recent hosting model released by Microsoft. Blazor WebAssembly 3.2.0 was released in May 2020. Blazor WebAssembly in .NET 5 was released as part of the .NET 5.0 release in November 2020 and it is not a long-term support (LTS) release. But this course will be using Blazor WebAssembly in .NET 7 for all of the projects. The following diagram illustrates the Blazor WebAssembly hosting model:

Press + to interact
Blazor WebAssembly model
Blazor WebAssembly model

In this hosting model, the web app is executed on the browser. In order for both the web app and the .NET runtime to run on the browser, the browser must support WebAssembly. WebAssembly is a web standard supported by all modern browsers, including mobile browsers. While Blazor WebAssembly itself does not require a server, the web app may require one for data access and authentication.

In the past, the only way to run C# code on the browser was to use a plugin, such as Silverlight. Silverlight was a free browser plugin provided by Microsoft. It was very popular until Apple decided to disallow the use of a browser plugin on iOS. As a result of Apple's decision, Silverlight was abandoned by Microsoft. Blazor does not rely on plugins or recompiling the code into other languages. Instead, it is based on open web standards and is supported by all modern browsers, including mobile browsers.

Advantages of Blazor WebAssembly

Blazor WebAssembly has many advantages. First of all, since it runs on the browser, it relies on client resources instead of server resources. Therefore, unlike Blazor Server, there is no latency due to each UI interaction requiring a roundtrip to the server.

Blazor WebAssembly can be used to create a Progressive Web App (PWA). A PWA is a web app that looks and feels like a native application. They provide offline functionality, background activity, native API layers, and push notifications. They can even be listed in the various app stores. By configuring our Blazor WebAssembly app as a PWA, our app can reach anyone, anywhere, on any device with a single code base.

Finally, a Blazor WebAssembly web app does not rely on an ASP.NET Core server. In fact, it is possible to deploy a Blazor WebAssembly web app without a server.

Disadvantages of Blazor WebAssembly

To be fair, there are some disadvantages to using Blazor WebAssembly that should be considered. For starters, when using Blazor WebAssembly, the .NET runtime, the dotnet.wasm file, and our assemblies all need to be downloaded to the browser for our web app to work. Therefore, a Blazor WebAssembly application usually takes longer to initially load than a Blazor Server application. However, there are strategies, such as deferring the loading of some of the assemblies until they are needed, designed to speed up the load time of the application.

When debugging a Blazor Server application, we can use the standard .NET debugger. However, to debug a Blazor WebAssembly application, we need to use the browser's debugger. To enable the browser's debugger, we need to launch the browser with remote debugging enabled and then use “Alt+Shift+D” to initiate a proxy component that sits between the browser and the editor. Unfortunately, due to the complexities concerning debugging on the browser, there are certain scenarios, such as hitting breakpoints before the debug proxy is running and breaking on unhandled exceptions, that the debugger currently can't handle. Microsoft is actively working on improving the debugging experience.

Another disadvantage of Blazor WebAssembly web apps is that they are only as powerful as the browser that they run on. Therefore, thin clients are not supported. Blazor WebAssembly can only run on a browser that supports WebAssembly. Luckily, due to a significant amount of coordination between the World Wide Web Consortium (W3C) and engineers from Apple, Google, Microsoft, and Mozilla, all modern browsers support WebAssembly.

The Blazor framework provides two different hosting models, Blazor Server and Blazor WebAssembly. A Blazor Server web app runs on the server and uses SignalR to serve the HTML to the browser. Conversely, a Blazor WebAssembly web app runs directly in the browser. They each have their advantages and disadvantages. However, if we want to create responsive, native-like web apps that can work offline, we need to use Blazor WebAssembly.