ASP.NET Core Blazor Basic Concepts and Hosting Models Selection (Server vs WebAssembly)
Blazor
🔗Blazor is a framework developed by Microsoft for building modern web applications. The biggest advantage is that developers can directly use C# to create dynamic, interactive web applications. Blazor executes C# programs on the client side using WebAssembly (a technology that allows back-end code to run in the browser in a similar way to JavaScript) to achieve high-performance application development.
The above introduction alone should be enough to make back-end developers who usually use C# interested in learning. After actually learning it, I feel that if you already have a certain C# language foundation, the learning curve can be said to be very smooth. I highly recommend it if developers who want to try to learn the full-end or are not familiar with the front-end can try using the Blazor framework as a basis.
Blazor WebAssembly vs. Blazor Server
🔗Blazor provides two hosting models options. It was quite hard to learn at first. Let me explain the differences between of both.
Blazor Server
🔗When entering the website, the front-end will connect to the back-end server through SignalR (a C# package that implements WebSocket two-way communication function), and the data is mainly provided by the back-end.
Several benefits are:
- Initial loading speed is faster than WebAssembly mode.
- Compared to WebAssembly's static website, the Server model retains the functionality of the API.
Limitations:
- Because SignalR is used to transmit information, the website cannot be used if the network is unstable or disconnected midway (if the connection is only momentary, the browser will automatically reconnect).
- Users need to be connected to continue operating the website. The number of connection pools has an upper limit based on the hardware. This means that there may be problems when a large number of users are connected at the same time!?
The official website also recommends using Azure SignalR Service. This service allows Blazor Server applications to be scaled up to a large number of parallel SignalR connections.
It seems that if it is used to build large-scale projects, it may be a costly choice😅.
Blazor WebAssembly
🔗It can be seen that the entire architecture is executed directly on the client side. When the user connects, the independent Blazor WebAssembly application will be loaded, and subsequent operations do not require interaction with the back-end server.
Several benefits are:
- It is independent. You can think of it as downloading an application directly. Subsequent use has nothing to do with the server. If it is disconnected, it can still be used normally.
- Since there is nothing to do with the backend server, basically after the user enters the webpage, they can fully utilize the client resources instead of relying on the server resources.
- It is a static website and is easy to deploy.
Limitations:
- The client needs to support WebAssembly (will become more and more common).
- Because the entire code is loaded on the user side, the web page will take a long time to load for the first time.
- Same as above, since the code sent to the client cannot be protected, please carefully consider the code content during implementation.
How to choose Hosting Models
🔗Comparing the two models, in fact, each has its own advantages and disadvantages, and the disadvantages can also be solved in other ways. For example: the problem that Blazor Server cannot be used if it cannot be connected can be changed to hide the reconnect message that will pop up if it is disconnected and if Blazor WASM takes a long time to load for the first time, you can also use loading effects to solve it.
Personally, I think that if the project is a back-end management system, the number of users is predictable, and the database needs to be operated, Blazor Server is a good choice. If the project is a small website that simply displays information, you can choose Blazor WASM.
Blazor Hybrid
🔗Or if you want to get the best of both, you can choose the Blazor WASM Hybrid mode of ASP.NET Core Hosted. In short, WASM is used as the front end, and the back end uses .NET Core to provide API operations. It solves the problems of Blazor Server requiring continuous connection, WASM preloading time if the website is too large and security problem with all codes need to be sent to the client.
Hybrid mode can be built using different .NET native application architectures including .NET MAUI, WPF and Windows Forms. I chose to use the .NET Core API to build it. The way to build this kind of Blazor WASM Hosted is very simple. Just choose to build the Blazor WebAssembly project through Visual Studio. In the framework selection screen, check ASP.NET Core Hosted and create it.
The project structure is as follows:
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
🔗Blazor is a brand new framework with high flexibility and efficiency. It is very suitable for developers who originally used C# language. They know the pain points of back-end engineers who are not familiar with the front-end. After personal use, they can build a front-end and back-end application for simple applications in a short time. If you want to get in touch with the front-end or full-end, it is recommended to get started with Blazor.
Reference
Alvin
Software engineer, interested in financial knowledge, health concepts, psychology, independent travel, and system design.
Related Posts
Discussion (0)
No comments yet.