ASP.NET Core Blazor Hosting Models

ASP.NET Core Blazor Hosting Models A blazer is a web framework that is application-based within a browser. Designed to run server-side in NET runtime (Blazer WebAssembly) or ASP.NET Core (Blazer Server). Regardless of the hosting model, the application and component models are identical.   Table of Content 1. Blazor WebAssembly 2. Blazor Server 3. Comparison with server-rendered UI 4. Circuits 5. Conclusion Blazor WebAssembly The primary Blazor hosting model is running client-side within the browser on WebAssembly. Blazor application is dependencies, and the .NET runtime is downloaded to the browser. The application runs directly on the browser UI thread. Updates the UI and event handling happen within the same process. The application is assets are deployed as static files on an internet server or service capable of serving static content to the client. Figure: Blazor WebAssembly application When a Blazor WebAssembly application is created for deployment without a backend ASP.NET Core application to provide its files, the application is called a standalone Blazer WebAssembly application. When an app is created for deployment with a backend app to provide its files, the app is called a hosted Blazer WebAssembly application. The hosted Blazer application client application typically interacts with a backend server application on the network using Web API calls or SignalR. Blazor.Webaswebel.JS script framework and handles provided by: Download .NET runtime, application, and application dependencies. Start runtime to run the application. The Blazor WebAssembly hosting model offers several advantages: There are no .NET server-side dependencies. Once the application is downloaded to the client it is fully functional. Client resources and capabilities are absolutely leverage. The work server is offloaded to the client. ASP.NET core web server isn't needed to host the application. Serverless deployment scenarios are possible, like serving an application from a Content Delivery Network (CDN). Read More: How To Create A Shared Library In .net Core? The Blazer WebAssembly Hosting model has the following limitations: The Blazer WebAssembly Hosting model has the following limitations: Requires enabled client hardware and software (for example, web-based support). The download size is large and apps take longer to load. .NET runtime and tooling support are less mature as an example, there are limitations in .NET standard support and debugging. To create a Blazor WebAssembly application, see tooling for ASP.NET Core Blazor. The Hosted Blazor app supports docker containers. Docker Support in Visual Studio, right-click on the project of the hosted Blazor WebAssembly solution and select Add> Docker Support. Blazor Server With the Blazor Server Hosting model, the application is run on the server from the ASP.NET core application. Figure: Blazor Server Hosting model ASP.NET refers to the application's Startup class for adding a core application: Server-side services. Application of request handling pipeline. On the client, the blazor.server.js script establishes a SignalR reference to the server. The script is delivered to the client-side application from a source embedded within the ASP.NET Core Shared Framework. The client-side application is responsible for maintaining and restoring the application state as required. The Blazor server hosting model offers several advantages: The download size is considerably smaller than the Blazor WebAssembly app, and also the app loads much faster. The application takes full benefit of server capabilities, together with the use of any .NET Core compatible API. The .NET core on the server is used to run the application, so it exists. NET tooling, like debugging, works as expected. The .NET/C # code base of the application, including its component code, is not provided to the client. The Blazor Server Hosting model has the following limitations: Higher latency usually exists. Each user interaction includes network hop. No offline support. If the client connection fails, the application stops working. Scalability is difficult for applications with multiple users. The server should manage multiple client connections and manage client state. An ASP.NET Core server is required to serve the application. Circumstances of serverless deployment aren't possible, like serving an application from a content delivery network (CDN). Are You Looking for Dedicated ASP.Net Core Developer ? Your Search ends here. See here The Blazer Server application model supports docker containers. For Docker support in Visual Studio, right-click on the project in Visual Studio and choose Add Docker Support. Comparison with server-rendered UI One way to understand Blazor Server apps is to understand however it differs from traditional models for rendering UI in ASP.NET Core apps using Razor views or Razor Pages. Both models use the Razor language to explain HTML content for rendering, but they differ significantly in however mark-up is rendered. When a razor page or view is rendered, each line of razor code releases HTML in text form. After rendering, the server disposes of the page or view instance, includes any state that was manufactured. When a second request for a page occurs, for instance when server validation fails and a validation summary is displayed: The whole page is rendered in HTML text again. The page is been sent to the client. The Blazer app is made up of reusable elements of UI called components. The component contains C# code, mark-up, and other components. When the component is rendered, Blazer produces a graph of similar content components such as HTML or XML Document Object Model (DOM). This graph includes the component state contained in the properties and fields. Evaluates the blazer component graph for binary representation of mark-up. The binary format can be: Converts to HTML text (during prerendering). Used to effectively update mark-up during regular rendering. Circuits A Blazor Server application is built on top of the ASP.NET Core SignalR. Each client interacts with the server over one or more SignalR connections known as circuits. A circuit is the abstraction of a Blazor over SignalR connections that can withstand temporary network interruptions. When the Blazer client sees that the SignalR connection is disconnected, it attempts to reconnect to the server using the new SignalR connection. Each browser screen (browser tab or iframe) is connected to the Blazor Server app used in the SignalR connection. This is yet another important difference compared to typical server-rendered applications. In a server-rendered application, opening the same application in multiple browser screens does not usually translate into additional resource demand on the server. In the Blazor Server application, every browser screen requires a separate circuit and separate instances of component state to be operated by the server. Conclusion In this article, we have learned about ASP.NET Core Blazor Hosting Models. If you want to serve a large number of users and do not have secret code running, use WASM. It also provides offline support. Use Blazor Server if you need to load the first page quickly or if you have sensitive code that you do not want to send to the browser.