Blazor Server Released

Net Core 3 released on the 23rd of last month supports Blazor Server. In other words, Blazor Server is ready for production.

I don’t think that I’m being too dramatic to declare this a major milestone! This is Microsoft throwing the full weight of .Net into the mobile/web ecosystem, with arguably the most sophisticated software library around. What’s really monumental about this release however is Microsoft’s embrace of community supported Open Source that’s cross-platform, runs on Windows, macOS and Linux!

Now, I don’t think Microsoft has suddenly changed from the ruthless commercial entity that took on the mighty IBM in the eighties and subsequently left a trail of crushed competitors – OS/2, Netscape, Novell, Borland, Lotus, just to name few. No, this is Microsoft doing what they’ve always been good at. If you can’t beat them nor buy them – I’m sure Microsoft has tried in the past to buy Google – then emulate them. So this is just naked commercial reality.

So what is Blazor Server? The best way to understand a new technology is to try it out. Github has a blazor-start app that has everything needed for a Blazor Server AIS app, plus a svelte clock to demonstrate how C# and JavaScript can happily co-exist. Putting aside the scaffolding code, the application can be narrowed down to four folders:

• Pages. Blazor uses what’s called Razor Components for its pages. The app has three pages, Login.razor, Index.razor and AddressBook.razor in addition to a shared Header.razor component. This should be familiar to anyone who’s worked with a JavaScript framework or ASP.Net pages – nothing to see here.
• Services. Injectable class instances – again this should be familiar.
• E1. Helper classes for AIS.
• Features. The app use BlazorState for state management and the Features folder structure is taken directly from its Tutorial.

So what’s the big deal? Just another way to develop a web app using C#.

The difference becomes clear once you Fire it up!

The back-end is Steltix’s demo system with DEMO user and password.

Once logged in, open up the Network tab on the DevTools/Inspect window and clear it before entering for example ‘warehouse’ in the search bar to get some data.

Unlike a typical SPA, the data was delivered without registering any network activity.

And the Source tab shows a rather trivial main.js of 600 odd lines (154kb) that’s mostly code to draw the clock in the left bottom corner.

The guts of the app, the c# code is sitting on the back-end and interacts with the browser through framework/blazor.server.js. The browser only receives the data it needs with all the AIS logic hidden from it. In practice this means that the AIS server can be protected behind a firewall while the Blazor server is public, servicing AIS apps.

In addition to securing the AIS server, I can see numerous other benefits with this architecture compared to traditional SPA’s.

• The app only receives data as needed which should improve performance.
• The back-end can be scaled to suit the app. Generally, traditional SPA’s are considered scalable because each user contributes resources with their own device meaning the back-end is the potential bottleneck. This logic however doesn’t necessarily apply to an AIS app because the user base is typically known and the back-end can be scaled accordingly.
• Logging at the back-end improves monitoring and trouble-shooting.
• Commonly used data can be shared and cached in the back-end.

In addition, despite all the clever stuff you can do in JavaScript, a compiled C# runtime within the structure of .Net Core is arguably a better long term transactional solution and should outperform comparable JavaScript solution. JavaScript however still has its place in the browser, as demonstrated by the svelte clock and it can happily co-exist with C# in a Blazer app and continue to do its magic.