Blazor of glory

Who doesn't like Single Page Applications (SPAs)?

They are fast and efficient. Unlike other server based models like MVC, not every request is refreshing the whole page, offering much richer user experience.

Generally, backend developers write server-side RESTful APIs in language of their own choice (in my case C#) and front-end developers use JavaScript based frameworks to request data, manipulate DOM and route to different views.

When things work efficiently, one ignores the apparent challenge in it. As in this architecture there was always a disconnect between client and server side skills. To successfully deliver a Single Page Application, experienced C# developers have to be retrained in an entire new client side language or we need separate front-end development resources. Things in these JS frameworks are volatile too. Angular(2) was not a newer version of AngularJS but something totally different. Moreover, code written in one framework is not reusable in other. Debugging is mostly in browser and at runtime. And the list goes on and on.

What if we could just use typesafe, object oriented and stable language like C# for client side development too? 

Life would be much better. Isn't it?

Well, we can.

Enter Blazor.

“Blazor is Single Page Application framework that lets you write C# on browser side.”

And this is possible, thanks to 

• WebAssembly and SignalR

WebAssembly

WebAssembly is an enhancement in new browsers which allows bytecode to run inside JavaScript runtime sandbox. 

Essentially, write a Blazor app in C# and deploy it to, let’s say, Azure Storage as static website. Upon request everything including dependencies and assemblies will be served to the browser. This type of app is called Blazor WebAssembly, works great if you are building something like games, because of its near native speed and offline availability. 

Note that Blazor WebAssembly is in preview and not ready for production use at the moment.

All good, but not all apps are static. Web applications, mostly, connect to the databases and go back and forth to the server to post and get data. They also do heavy calculations. These tasks can’t be left for the browser alone.

So, we still need code on the server that performs all server “things” and if server could just update the browser in real-time and asynchronously. We'll get our SPA. 

Turns out Microsoft had already something in their arsenal for this.

SignalR

Six years ago (2013) Microsoft released a library comprised of server and client side JavaScript components, that allows server to send notification to the clients, without any request from them. So, in a web site values get updated in real time without pressing any button and whole page is also not refreshed. For example, on pizza delivery website order status updates without user’s interaction to the page.

This was made possible through use of WebSocket, which is “an HTML5 API that enables bi-directional communication between the browser and server”

In a SignalR application, we create a hub, that enables you to call methods on connected clients from the server. (Read more about SignalR Hubs here.)

Blazor Server app uses this SingalR Hub for real time updates on browser.

I know this is a new way of thinking about web applications. As in WebAssembly, we are reliant on the browser capabilities, in Blazor Server model, application performance and even execution is solely dependant upon SignalR. Scalling SignalR connections effieciently is a big question mark.

Atleast, this can be taken care of by Azure SignalR Service. 

“The Azure SignalR Service is essentially a logical transport layer between application server and clients”

Diagram: Microsoft Documentation

Why Blazor?

Now we are settled, either we choose WebAssembly or Server approach, C# can not only be used as a client side language, but like any other browser based language it can also interact with other JavaScript code. Further we get

• (As discussed previously) utilisation of existing C# skills for full stack development, cheaper to resource projects with more productive teams
• Consistency in code base
• Interaction with JavaScript, means existing client side liberaries can still be used
• Independance from many different JavaScript frameworks and replacing it with an object oriented, memory safe and backward compatible language like C#
• Easy to debug and test
• Smaller learning curve than other JavaScript frameworks
• Availability of Microsoft tools like Visual Studio and in those tools features like intellisense 

Talking about Visual Studio, in VS2019, there’s Blazor Server template, let’s investigate this.

1. Create New Project
2. Select Blazor App

3. Select Blazor Server App

Startup.cs

In ConfigurationServices there are new MvcServiceCollection extension methods now. We see AddRazorPages here, this is because Blazor runs on Razor pages. All these pages have code block, which is essentially C# code dealing with html above.

This is Counter razor page. @page declaration at top defines its route.

And simply onclick event on button is calling IncrementCount method written in C#. 

We can see this working when we run and go to counter page.

In Configure method of Startup class we got instruction to app to use routing, which will be handled in App.razor page.

Also in UseEndPoints extension method, Blazor specific SignalR is mapped (which is crucial for SingalR two way connection for a Blazor app)

Summary

This was a brief intro to Blazor. Please do have a look, what else is new in .NET Core 3? We discussed Blazor, what and why? in this article. I would recommend to use Visual Studio Blazor Server Template and play around with it. Run the app and in DevTools see how browser caches the resources. Not now but perhaps soon Blazor could be a blazing technology.

Keep an eye on my GitHub, I’ll soon be publishing some sample apps in Blazor there.

...

Originally Posted on https://ahsanshares.wordpress.com/2019/11/27/blazor-of-glory/