Oct 26, 2020

Welcome to Architect Tips with a tip so that you can get your team to move faster, deliver quality, and run your system with confidence!

We will talk about the architecture of Blazor and some of the key differences if you are running a Blazor application. Before we do that, you might wanna check out Azure DevOps Podcast; for .NET developers who are shipping software with Microsoft platform technologies; go to www.azuredevops.show.

Blazor is a different architecture; it is a new architecture. Blazor runs on top of .NET Core, and the server-side has been out for several months now. WebAssembly just came out in May, and people are still trying to figure that out. Many applications are being developed already with the Blazor server-side model. I want you to understand the key differences in that model from regular web applications so that you can be successful. What is important to understand is that Blazor runs on top of ASP.NET Core. So, startup, the middleware, all that stuff running it in Azure will be the same. It will run in process, but the Razor components are a different programming model in the UI and are different from your ASP.NET MVC controllers or web API controllers, and it is a stateful programming model. When a Razor component essentially paints a screen, that class will be in memory; it will be on the call stack in memory for the entire time that your user has that screen open in their browser. What happens is when you have that first request to your URL, your web server is going to return a JavaScript file. That JavaScript contains the Blazor client, and it is scanned, so you do not need to mess with that. The client will subscribe to a built-in SignalR connection run by your web application, automatically Blazor publishes a SignalR hub, and every bit of communication between the browser and the server is going to go across that SignalR hub. If you are hosting it in Azure, you will want to use the Azure SignalR service because it is scalable and will take that processing power off your web instance.

However, it is important to understand what happens and that Razor component class is going to be on the call stack and is going to be alive in memory, that instance of the class, the entire time that screen is on the page, no matter how many times things are clicked, no matter how many times maybe a section of the page is swapped out, that is going to be on the call stack.

Now, if you do a navigate URL to another top-level page, well, then it will go out of memory and be cleaned up. That is how Blazor server-side works. Every session, every user’s screen, and what a user is doing is resident in memory on your web server, and the changes to the screen are messaged through that SignalR hub with binary messages. So, what is important is the latency in the network connection. If you have really bad latency, then your users are going to see slowness. For instance, if you have 100-millisecond latency, you may need 10 round trips to the server, which is not unheard of, these messages are really small, but if it is 100 milliseconds of latency with each one, well, that is one second. So you have to keep that in mind, that is the architecture.

Let's now go over some of the settings. When you are publishing to Azure, you will want to make sure that you choose 64 bit because you will be using up more memory. Every one of your agents, every one of your users, keeps that memory on the server and their session, everything they do, and all of the memory keep those objects on the webserver. You will be using more memory as a trade-off for that phenomenally fast development model.

You can crank out applications so quickly it is so much more productive than JavaScript and the JavaScript ecosystem. Now, you will want to turn on web sockets. Off by default, you turn on web sockets. We do rely on SignalR in the custom built-in SignalR hub. If you leave that off, SignalR is going to fall back to long polling, which will send a lot of requests to IIS. You will be able to see that in application insights that your application is not doing anything, but you are getting a ton of requests; it is a tip-off that maybe you do not have web sockets.

You can also press F12 in the browser tools and make sure that you’re connected to your WSS protocol for the web socket. You also want to have ARR Affinity because we keep around in-memory objects for user sessions; you want to make sure that essentially you are turning on sticky sessions. 

The first request comes in, a user will be assigned by the load balancer to one of your web instances, and that user will use that web server instance the whole time they have that tab open for that session. 

They may be assigned to a different one if they close the browser tab and come back and essentially recreate everything from scratch, but you’ll be on one web instance.

Also, you want to learn how Blazor server-side interacts with the browser because all of the data, everything to show on the screen, is going to be coming through binary messages on a SignalR circuit, and then that JavaScript client, that is the Blazor JavaScript client that’s running in the browser is going to take that information and append children to the dom in the browser. 

You can inspect all the different frames coming that are coming just by looking at the performance tab in the Chrome developer tools. It is really important that you understand how many frames are necessary per page because if you have a ton, it will make for a slow page. So, you want to use that as a point of optimization.

You will also want to look at how many round trips your application is making to the server. You can go to the network tab in the tools, and you can click on the web socket connection, and you can see all these different binary messages. If you select one, you can see what it is doing at every stage, every message that’s called a round trip. We can see the OnRender completed right here, and I have zoomed in on the bottom. 

You will want to inspect that and understand what your message is doing with these binary messages. Now, the Canary version of Edge, the Chromium version of Edge, has some enhancements that are being worked on in the developer tools to show a visualizer of these binary messages so that you can sniff the wire and you can see exactly what is coming through. Right now, it is not very helpful to see the current views other than it came through and how big these are, but the tooling is coming so that we can see exactly what is in these messages because that will be important.

When you are running an Azure, you want to have a minimum of two web instances. Because it uses sticky sessions, and if something happens to that web instance, you want the web browser to immediately be able to take all of the connected sessions and move them to another instance of the webserver. 

With the auto-reconnect behavior that Blazor has in the JavaScript client, that can happen automatically for you as long as you have that second web server that those users can be assigned to.

I hope that helps and if you are starting a Blazor project, let us help you avoid those pitfalls. Clear Measure is a software architecture company that really wants to help your development team move fast and deliver quality and run your systems with confidence so that you can get more done internally within your team and deliver world-class results. Thank you very much, and that was another Architect Tip.