Last Saturday I attended the Codecamp conference in Timisoara and got another opportunity to talk to the local .Net community of my hometown about #Blazor. Before going into a short summary of my presentation I just want to pin point that based on my perception Blazor is getting more and more traction. Six months back I talked about it in the same city and same conference. I had around 12-15 participants in my audience. On Saturday I had around 50. I was excited seeing the room filling up! But let’s go into the key points of my presentation.

Blazor – a fresh perspective

First of all, this was my first Blazor talk after the #MsBuild conference and as many of you might know, a lot of things have changed recently, with key announcements made both during the conference and in the preceding days. After the Build conference it’s clear for me that we can’t talk about Blazor anymore outside .Net 5. Key point here is that there will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more. And this is .Net 5! And Blazor will be a part of it.

That’s why Microsoft also announced that Blazor is not an experimental project anymore. It is now a preview project that is planned to enter global availability at a certain point (probably together with .Net 5). As part of re-shuffling the entire strategy about Blazor there were some new name changes.

Name changes

As we know, Blazor is a single page application framework that allows developers to write full stack application using only C# (of course also HTML and CSS for the UI itself). It supports two hosting models: the client side model and the server side model. Now for the server side model, it was called “Razor Components” till one week before the Build conference. However, since also the client side hosting model entered the preview state it became clear that a lot of confusion could arise. So to simplify things, Razor Components were renamed back to “Server side Blazor”.

I don’t want to enter in more detail about hosting models as I plan to cover this topic in a dedicated blog post. However, the main difference is that within the client side model, actual DLLs are sent over to the browser and the entire application is running from within the browser via WebAssembly. With the server-side hosting model, the app is executed on the server from within an ASP.NET Core app. UI updates, event handling, and JavaScript calls are handled over a SignalR connection.

The important thing is that server side Blazor is already part of the .Net Core 3.0 preview and will, therefore, be available for production use once .Net Core 3.0 enter global availability. That’s why my talk was concentrated on the latter.

The application

This time I felt like I really needed to get my hands dirty and I have decided to create a new Blazor application by myself to use it as a support for the talk (and probably several other upcoming talks). I’m not a gold mine when it comes to ideas for applications so what I have decided to do is kind of a front end for the GitHub API. I imposed myself only two constraints:

1. Rely only on server side Blazor
2. Don’t write any Javascript!

You can find the application code base on GitHub and if you want to check the application out I have deployed it to Azure. For now there are only very basic features there. You can authenticate with your GitHub account and then authorize the app to read information on your behalf. The dashboard is still a “Hello world” heading, but you can view some basic information about the logged in user, you can get a list of repos for the logged in user and also view branches and issues for one selected repo.

The architecture

Blazor seems to be great! There are a lot of demos out there. But in few months server side Blazor will be ready to be use in production. So how do we create a production app? How do e structure folders, components, services and so on? I guess this is one of the biggest points that the community should work out. Since I am also very familiar with Angular, I have thought for around two weeks if anything from the Angular Stayle Guide could be useful in this scenario. In the end it’s a SPA framework! So I went on to adapt some of the Angular architecture principles to Blazor. For now this approach seems to work fairly fine.

One of the key points was to group components into feature folders. As in Angular, I think that going for a feature based folder organization instead of a convention based approach (as we are accustomed with from MVC) has more advantages than disadvantages. First of all it makes code easier to find because you know that all code related to a certain feature will be in the same folder.

Another very useful is in my opinion to separate component code in two different files:

1. A .razor file for the markup
2. A .cs file for the C# code

This can easily be done in Blazor using inheritance. Some might say that this introduces coupling and as we know, coupling is bad. But in this case coupling is good in my opinion, because a component is nothing else than a self-contained chunk of user interface (UI), such as a page, dialog, or form. A component includes HTML markup and the processing logic (C#). So we have a markup language and a programming language that in a certain way belong together. Having them in one file is in my opinion not optimal at all when you go outside demo projects. In real projects a simple data grid could have tens of lines of codes (maybe more). Having the C# code at the end is not very friendly for my taste. So yes, I would say that components contain two fundamental parts so it makes sense to split them in separate files. But these parts also logically belong together. So coupling in this case makes total sense for me.

Besides this I opted to put all my application wide services in a “Core” folder and re-usable components in a “Shared” folder.

I also tried to use the container presentation pattern for the “RepoDetails” component. That is when you have a parent component that is responsible for retrieving data, and presentation components that are only responsible to render that data in the UI.

Routing and dependency injection

During the talk I also demonstrated and explained how routing and dependency injection work in Blazor. Since this article is already fairly long and I however plan to cover these topics in separate blog posts, I won’t dwell too much on them here.

One particular thing to watch out for is service scopes in dependency injection. For now in the client side model it’s easily to imagine that we don’t actually have a real “scoped” service as we know it from MVC. You can still add scoped services, but since the application is running in the browser scoped services will actually behave like singletons.

In server-side Blazor scoped services are scoped to the connection. So the behavior is slightly different. However, please note that according to the Blazor thing some things around dependency injection may be subjected to changes until .Net Core 3.0 enter global availability.

All in all, that’s the summary of my talk. I felt a lot of curiosity out there. Hope to be able to speak soon again about Blazor!

P.S: The mentioned GitHub repo is public. If you want to contribute and work on it as a mean to get familiar with Blazor, get in touch with me. There’s plenty of work to be done and I want to organize a project board and a backlog.