Blazor can run your client logic on the server. Client UI events are sent back to the server using SignalR - a real-time messaging framework. Once execution completes, the required UI changes are sent to the client and merged into the DOM.

Blazor Server overview

Some history

What ended up coming out of the initial effort by Microsoft to run .NET code in the browser was some seriously good patterns utilising some forward thinking client/server communication mechanisms.

Because of the sheer work involved with getting Blazor WebAssembly to market Blazor Server allowed Microsoft to deliver all the amazing work, almost immediately. This was only achievable because of the decoupled architecture that enables separation of the application execution from the actual rendering process.

What is really comforting is the goal to utilise the same component based approach with C# and Razor syntax which will mean little or no change for developers once WebAssembly is production ready, with all the smarts changing in the hosting layers. This really is unparalleled with any other Web Application Framework enabling development now and reuse later once more capabilities emerge.

As of ASP.Net core 3.0, Blazor Server is production ready

Cool!

How it works

A typical interaction between a web browser and a web server consists of a series of HTTP requests and responses. On startup of a Blazor Server app, this remains the same with a typical ASP.NET core request / response pipeline with middleware and services being configured the same as a standard .NET core web app.

But as soon as the initial payload is received by the client, let's assume a web browser, as opposed to only HTTP, a websocket will open a persistent bi-directional connection where multiple messages being sent back and forth. This also means the server can send (push) messages to the client at any time. Blazor Server is built on SignalR, which is built on websockets among other things.

The combination of these technologies allow Blazor Server to push UI changes down to the client without the client requesting those changes.

Blazor server apps run your components on the server, on top of .Net core.
  • An ASP.NET Core application hosts Blazor on the server-side.
  • A server round-trip is required to handle most of events, including user actions.
  • The open-source library ASP.NET Core SignalR handles two-way connection between the browser and the server.
  • There is no C# code running on the client side.

Eventing  

Events that then happen in the browser are sent to the server and handled by your components which then render.

  • Blazor keeps track of any changes that are made to the UI using a sophisticated diffing algorithm.
  • Any changes are then sent back down to the browser and applied to the DOM
  • Blazor server apps use a very thin client that can run great on low bandwidth devices and in older browsers.

Client

On the client, the blazor.server.js script establishes the SignalR connection with the server. The script is served to the client-side app from an embedded resource in the ASP.NET Core shared framework. The client-side app is responsible for persisting and restoring app state as required by sending and receiving binary messages between the browser and the server.

Caveats / Considerations

  • Higher latency usually exists. Every user interaction involves a network hop.
  • There's no offline support. If the client connection fails, the app stops working.
  • Scalability is challenging for apps with many users. The server must manage multiple client connections and handle client state.
  • An ASP.NET Core server is required to serve the app. Serverless deployment scenarios aren't possible (for example, serving the app from a CDN).

Benefits

  • Download size is significantly smaller than a Blazor WebAssembly app, and the app loads much faster.
  • .Net code runs on a full .Net core runtime.
  • Can simplify architecture by eliminating the need to stand up additional apis and endpoints.
  • All code stays on the server so as the app grows, the application size doesn’t increase.
  • Blazor code executing on the server has the flexibility to do anything you would normally do on the server, such as connecting directly to a database.
  • The app takes full advantage of server capabilities, including use of any .NET Core compatible APIs.
  • .NET Core on the server is used to run the app, so existing .NET tooling, such as debugging, works as expected.
  • Thin clients are supported. For example, Blazor Server apps work with browsers that don't support WebAssembly and on resource-constrained devices.
  • The app's .NET/C# code base, including the app's component code, isn't served to clients.

Conclusion

It's important to remember that either the Blazor WebAssembly or Blazor Server hosting models are based on ASP.NET Razor syntax that mixes HTML code, C# code and specific Blazor tags to create dynamic web-pages. Both hosting modes rely on the same razor syntax.

What happens internally to render the page and handles updates with a Blazor Server app is completely different. However, these differences also offer opportunities to solve problems in interesting ways.

It will be down to the domain and the specific application requirements to determine the best fit or even a combination of hosting models and approaches. with the advent of microservices, also comes patterns such as microfrontends. With so much capability at our fingertips, we are likely to see some amazing solutions emerge utilisng all that Blazor has to offer.

Stay tuned as we continue to explore Blazor in more detail and discover ways to mix both hosting models in future posts.

References

ASP.NET Core Blazor hosting models
Understand Blazor WebAssembly and Blazor Server hosting models.
assemblysoft/AssemblySoft.WonkaBuild
Web client for consuming AssemblySoft.DevOps task library - assemblysoft/AssemblySoft.WonkaBuild