A summary of some fundamental Blazor ideas, including the benefits and drawbacks of WebAssembly and server models.

Blazor

Microsoft created the Blazor framework to facilitate the development of contemporary web applications. The primary benefit lies in the fact that developers can utilize C# to directly create dynamic and interactive web applications. To achieve high-performance application development, Blazor uses WebAssembly, a technology that lets back-end code run in the browser similarly to JavaScript, to execute C# programs on the client side.

The introduction given above ought to be sufficient to pique the curiosity of back-end developers who typically work with C#. After actually learning it, I believe the learning curve is fairly easy to navigate if you have some prior knowledge of the C# language. If developers are unfamiliar with the front-end and would like to try learning the full-end, I strongly suggest that they use the Blazor framework as a foundation.

Blazor WebAssembly vs. Blazor Server

Blazor offers two choices for hosting models. Learning was challenging at first. Allow me to clarify the distinctions between the two.

When a user visits the website, the front end uses SignalR, a C# package that implements the WebSocket two-way communication function, to connect to the back end server. The back end provides the majority of the data.

A few advantages are:

  • Compared to WebAssembly mode, the initial loading speed is faster.
  • In contrast to WebAssembly’s static website, the API’s functionality is retained in the Server model.

Limitations:

  • The website cannot be accessed if the network is unstable or breaks midway because SignalR is used to transmit information (if the connection is only momentary, the browser will automatically reconnect).
  • For the website to continue to function, users must be connected. There is a maximum number of connection pools determined by the hardware. This implies that issues could arise if numerous users attempt to connect at once!?

Blazor WebAssembly

As can be observed, the client side handles every aspect of the architecture directly. The standalone Blazor WebAssembly application loads upon user connection, and further operations don’t need communication with the back-end server.

A few advantages are:

  • It is self-sufficient. Consider it as if you were directly downloading an application. The server is unaffected by further use. It is still functional even if disconnected.
  • After the user accesses the webpage, they can fully utilize the client resources rather than depending on the server resources because there is no interaction with the backend server.
  • It is simple to set up and is a static webpage.

Limitations:

  • The client must enable WebAssembly, which is becoming more and more popular.
  • The first time you load the web page, it will take a while because the entire code is loaded on the user’s side.
  • Similar to the previous example, please take great care when implementing the code because it cannot be protected once it is sent to the client.

How to choose Hosting Models

When comparing the two models, it can be seen that each has pros and cons of its own, with the drawbacks potentially being resolved in different ways. For instance, you can use loading effects to fix issues where Blazor Server won’t work if it can’t connect, and you can adjust the reconnect message that appears when it does. If Blazor WASM isn’t loading quickly the first time, you can also use loading effects to fix the issue.

In my opinion, Blazor Server is a good option if the project involves a back-end management system, the user base is predictable, and the database needs to be maintained. Blazor WASM is a good option if the project is just a small informational website.

Blazor Hybrid

Alternatively, you can select the ASP.NET Core Hosted Blazor WASM Hybrid mode to get the best of both worlds. To put it briefly, the back end uses.NET Core to perform API operations, while the front end is WASM. It resolves issues with Blazor Server’s need for a constant connection, WASM’s need to preload pages if a website is too big, and security issues with all codes needing to be forwarded to the client.

Several.NET native application architectures, such as.NET MAUI, WPF, and Windows Forms, can be used to create hybrid applications. I decided to construct it using the.NET Core API. This type of Blazor WASM Hosted is very easy to construct. Simply decide to use Visual Studio to build the Blazor WebAssembly project. Select ASP.NET Core Hosted from the framework selection screen and create it.

The following is the project’s structure:

BlazorApp1.Client is part of WebAssembly and is mainly responsible for front-end screen display.
BlazorApp1.Server is part of the back-end Web API. Its implementation is consistent with ASP.NET Web API, and the controller controls the API.
BlazorApp1.Shared is the object storage location for use by Client and Server.

Conclusion

A completely new framework with great efficiency and flexibility is called Blazor. It is ideal for developers who have experience with the C# language. They are aware of the difficulties faced by back-end engineers who lack front-end experience. They can quickly create a front-end and back-end application for basic applications after using it for personal use. Blazor is a good place to start if you want to communicate with the front-end or full-end.

Leave a comment

Your email address will not be published.