I’ve been using client-side Blazor for a couple of months now on one of my side projects and I’ve become a pretty big fan, because it allows me to write a modern, dynamic web app in C# with minimal JavaScript.  The Blazor docs give a nice synopsis of how this happens here:

1. C# code files and Razor files are compiled into .NET assemblies.
2. The assemblies and the .NET runtime are downloaded to the browser.
3. Blazor uses JavaScript to bootstrap the .NET runtime and configures the runtime to load required assembly references. Document object model (DOM) manipulation and browser API calls are handled by the Blazor runtime via JavaScript interoperability.

With Blazor I’m able to build single-page applications using my preferred language in a natural and enjoyable programming paradigm.

(Disclaimer:  Blazor is still considered an experimental framework by Microsoft, so proceed with caution only if you are brave, daring, and have a penchant for adventure.  You’ve been warned…)

Server-Side Blazor

In late July 2018, the Blazor team shipped release 0.5.0, which introduced server-side Blazor.  Initially I dismissed server-side Blazor, quite content to continue working completely client-side.  But as I saw that it seemed the team was putting quite a bit of emphasis on server-side Blazor and I read about the benefits it promised over client-side Blazor, I became intrigued.

The release notes do a really nice job of explaining what server-side Blazor is and how it works.  In a nutshell, Blazor was designed to be able to be run in a web worker thread separate from the main UI thread, like this:

Server-side Blazor leverages this model and stretches the communication over a network connection, using SignalR to send UI updates, raise events, and invoke JavaScript interop calls between the browser and the server, like this:

The release notes also provide a good breakdown of the benefits and downsides of the server-side model compared to the client-side model.  I’ll highlight just a couple benefits here that I’ve experienced from the get-go:

• Faster app load time:  I received early feedback on my client-side Blazor app that it took a long time to load the app initially (on the order of tens of seconds).  This is understandable, as the framework has to ship the entire app, the .NET runtime, and any dependencies down to the client on load.  After switching over to server-side Blazor, my load time went down to sub-second.
• Much better debugging:  With client-side Blazor there are ways to get basic debugging of the Blazor components working in Chrome developer tools, but it is a far cry from the rich debugging experience that we’re used to in Visual Studio.  I found myself using Debug.WriteLine(..) a lot.  With server-side Blazor, since Blazor component code is running on .NET Core on the server, the Visual Studio debugging tooling just works.
• Feels like client-side Blazor:  Apart from the improved load time and debugging support, server-side Blazor is almost indistinguishable from client-side Blazor to both the developer and the end-user.  As we’ll see in a moment, apart from a couple of small changes at startup, you develop a server-side Blazor app just like a client-side Blazor app: composing Blazor components in exactly the same way regardless of where they will be running.  And the end-user still has a rich, interactive SPA experience.

Now the downsides to server-side Blazor are what you might expect: increased latency on every UI interaction, no offline support, and scalability limited by the number of client connections that SignalR can manage.  It’s too early for me to speak to the scalability concern, but increased latency is mostly imperceptible to the user given a decent internet connection.

Converting a Solution to Server-Side Blazor

Converting a client-side Blazor solution to server-side Blazor is much easier than you might expect and can be done in a matter of minutes.  (In fact, Suchiman has a demo showing how to dynamically switch between client-side and server-side at runtime based on a querystring parameter.)

A server-side Blazor application consists of two projects, typically named {SolutionName}.App and {SolutionName}.Server, both created by the VS tooling when you create a new server-side Blazor application.  I already had a client-side project that I had named ProjectX.Web.  The first step I took was Add > New Project… > ASP.NET Core Web Application on my solution:

After entering my desired name and clicking Next, I selected Blazor (Server-side in ASP.NET Core):

This added two new projects to my solution: ProjectX.App and ProjectX.Server.  Since I already had a ProjectX.Web project representing the client-side piece, I deleted the newly created ProjectX.App project.  I made ProjectX.Server the startup project and added a reference in it to my existing ProjectX.Web.

In my index.html in ProjectX.Web, I replaced this:

<script src="_framework/blazor.webassembly.js" />

With this:

<script src="_framework/blazor.server.js" />

In ProjectX.Server.Startup.cs, there are two places where it was referencing App.Startup; I changed them to use Web.Startup instead.

public void ConfigureServices(IServiceCollection services)
{
    services.AddServerSideBlazor<ProjectX.Web.Startup>();

    // snip...
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    // snip...

    app.UseServerSideBlazor<ProjectX.Web.Startup>();
}

… and that’s all there was to it!  Well, almost…

Gotchas

I ran into a few minor issues that you may or may not encounter, depending on what you’re doing in your application.

1. Blank Screen After App Load

   After making the changes described above, I built and ran my project.  The loading screen displayed as expected, but then it just displayed a blank white screen with no errors logged to the console.

   Following the guidance in this thread, I tried removing the global.json file that was created when I created by client-side project, which pinned the SDK version to 2.1.3xx.  This didn’t help in my case.  I then checked my .NET Core SDK version by running dotnet --info at the VS Developer Command Prompt.  I was running 2.1.500-preview-009335.  I deleted the preview version of the SDK and then my app started loading and running.

2. JS Errors Invoking Blazor Component Methods using .invokeMethod

   With my app running now, I started testing some of the functionality.  I have a couple of controls that invoke methods on my Blazor components via JavaScript that I found were no longer working.  A quick peek at the Chrome dev tools console showed the culprit (thank you, Blazor team, for good error messages!):
   Easy fix: I just changed the couple of spots where I was using .invokeMethod(..) to invoke methods on my Blazor components to .invokeMethodAsync(..), and most of them started working.

3. JSInvokable Methods Not Marked Virtual

   Even after switching to use .invokeMethodAsync(..), I still had a couple of Blazor component methods that were failing to be invoked from my JS.  I found that the difference between the ones that worked and the ones that didn’t was the virtual keyword on the method declaration.  I added virtual to the methods that weren’t executing and they started working.

That said, sitting here a few days later, I tried removing the virtual keyword from those JSInvokable methods again, and they continue to work.  So I’m not sure why this worked in the first place or if I had another change at that time that actually fixed it (I don’t think so).  Your mileage may vary…

Wrapping Up

Switching my solution from client-side to server-side Blazor was a piece of cake, and the benefits were well worth it.  I can now see the reasons for the recent buzz around server-side Blazor.  If I get to the point where I need to support a larger number of concurrent SignalR connections, I’ll start using Azure SignalR Service and route the communication through it, as described in the Blazor 0.6.0 release notes, but for now I’m content to run it through my app service.

---

If you’d like to receive new posts via e-mail, consider joining the newsletter.