Blazor Server versus Blazor WebAssembly

in Software development, IT strategyBy Pedro Borges, Software Engineer

Introduction

One of the first decisions we need to make when creating a Blazor project, besides choosing a project name, is to select the Blazor hosting model we want to use. Microsoft provides two different hosting models, Blazor Server and Blazor WebAssembly, and depending on the purpose of the application one could be better than the other.

In this article, we will explore the definitions of both hosting models, explain the pros and cons of each, and reach a conclusion on when to use them.

Blazor Server

The Blazor Server, like the name suggests, is the server-side hosting model, meaning, that the application will run and execute server-side. Very little will be loaded to the client browser, and the server will handle all the events and UI updates.

To handle the communications between the client and server, Blazor Server uses the open-source library SignalR.

SignalR works by pushing server-side content instantly to the client-side. To handle all the communications, SignalR supports an array of transports techniques:

WebSockets
Server-Sent Events
Long Polling

From these three, SignalR will choose the best transport method depending on the server and client capabilities, and in case one fails, automatically fall back to another transport mechanism.

For more information about SignalR, the source code is available on Github: https://github.com/dotnet/AspNetCore/tree/master/src/SignalR

SignalR is the bridge that connects the client-side with the server-side in the Blazor Server architecture.

The next image shows a simple architecture diagram of Blazor Server:

Interpreting the above:

A change happens in the browser.
It is communicated to the server via SignalR.
The server does all the work and sends a response to the client.

This process translates to the main functional loop of Blazor Server.

In one hand, we can detail some of the Blazor Server benefits:

Faster load times - because the core of the application will run server-side, it will only load the essentials to the client;
Developers can use all the .Net tools, such as debugging and .Net Core APIs;
The application code isn’t revealed to the client - everything besides the essentials stays on the server;
Broader client support - because the workload is on the server, Blazor Server will work on a browser that doesn’t support WebAssembly (IE 11, for example).

On the other hand, Blazor Server has some disadvantages:

No offline support - every interaction requires a constant connection to the server if the connection fails the app stops working;
Scalability problems - the server must manage multiple connections at the same time, therefore is more server intensive;
It is limited to be hosted on an ASP.NET Core server - no serverless possibility, like hosting from a CDN.

Blazor WebAssembly

Blazor WebAssembly is the new addition to the Blazor family, being released after Blazor Server (Blazor Server - September 2019; Blazor WebAssembly - May 2020). And it is the opposite of his brother. While the Blazor Server executes almost everything at the server-side, Blazor WebAssembly does the opposite. The application will run entirely on the client-side.

This client-side approach is possible because all the necessary components to run the application will be downloaded to the browser on the first load, this way the application will be able to run without establishing new connections to the server.

In detail, the app will be executed on the WebAssembly UI thread of the client browser, hence the Blazor WebAssembly name. All the vents and UI updates will occur in this thread process, and the app will be executed in the client browser. The image below shows this, where if need, it will only connect to a server via API, following the same paradigm as React.

Having the workload on the client-side has its advantages, namely:

Offline support - since the app is fully downloaded on the client-side, it can work even if the connection to the server is lost. This key aspect translates to no server-side dependency;
Less workload on the servers - the client will do all the work after the initial download;
Serverless deployment is a possibility with this approach.

However, there are also some drawbacks:

Longer initial load time - everything is downloaded in the beginning causing the app to take longer to load;
Only works on browsers with WebAssembly support - for example, doesn’t work on IE 11;
Has limitations on some .Net tools, like debugging and .Net standard support;
Requires APIs to access resources and establish a backend connection.

Server vs WebAssembly

Now back to the original question, which hosting model should we choose when creating a Blazor application? And the truth is, it depends, and it will always depend on the purpose of the application that we are creating. One is not directly better than the other, where both serve different purposes.

In case you are looking for a simple application to run inside a warehouse where you know the internet connection is bad? Then Blazor WebAssembly is the choice for you because it works even without a server connection.

Need a back-office application to manage your business in real-time? Then Blazor Server is the answer because it will require a constant connection to the backend to get real-time updates.

To help you decide on which hosting model to use, we summarize everything in the following table:

Conclusion

Through Blazor, Microsoft offers an array of options and opportunities when creating applications. Choosing a client-side or server-side hosting model will always depend on the end-goal of the application that you are building.

In case you need support deciding or clarifying the way for of the architecture design or model to follow for of your application, here at Hexis, we help you decide which is the best choice for you and your applications!