Introducing IoT, new .NET 6 features, SignalR and Blazor

Let’s now have a short overview of what is IoT, what are the new features of .NET 6, what is SignalR, and what is Blazor. So IoT stands for internet of things. Internet of things represents a collection of any embedded smart devices that can connect to internet. These devices can be bespoke, special-purpose devices, such as smart meters, smart home solutions, things like Amazon Alexa, Google Home, and so on.

Or they can also be general-use, single-board computers, such as Raspberry Pi, Fitlet, and there are plenty of other devices. Those devices normally run either Windows or Linux, and you can deploy any software on them that you would normally be able to deploy on any standard computer.

The only thing you need to look out for is the compilation target because the standard desktop PCs normally run on AMD-based CPU architecture while single-board computers don’t always do that. Some of them run on ARM-based architecture while others do run an AMD-based architecture. But with .NET, it doesn’t matter because you can set compilation target to either of those.

Internet of things is used where computers weren’t used traditionally. Smart meter is an example of that. Somebody used to come to your house and take meter readings. But now if you connect a smart meter to your utilities, the utility provider will be receiving the data from it automatically via either internet or mobile network.

Smart TVs are another example of internet of things. These days, television sets have same capabilities as only computers used to have a couple of decades ago. Internet of things devices can be placed into cars as well. Tesla is an example of a brand of cars that uses internet of things quite heavily. But there are many other applications.

Smart IoT devices can be placed anywhere to take any kind of metrics. All you have to do is just connect them to the internet and connect specialized sensors to them. In this video, we’ll have a look at two examples of IoT devices. As I mentioned already, the main purpose of IoT is to make traditional technologies smart. Let’s now overview what’s new in .NET 6.

.NET 6 has better performance than its predecessor .NET 5. It has simplified application entry point. Prior to .NET 6, you had to write a class called Program and there had to be a static method called Main. That was the entry point of the application. You don’t have to be as verbose anymore. You still have a file called Program.cs, but you no longer have to have a class inside that file. And you no longer have to have a method inside it.

The platform will be able to figure out automatically that this is the entry point of your application. You can now have global “using” statements. If you are using any system libraries in your code, you no longer have to have “using” statements in those files. Those are now referenced implicitly. But if you are relying on any third-party libraries or any custom-made spaces, all you have to do is just prepend “globa”l before the “using” keyword. That will allow you to reference all of them in a single place in your application.

So you don’t have to have duplicate “using” statements in every single file where you need to use that namespace. Unless, of course, there are objects of the same name that exist in separate namespaces, then you have to use “using” statements explicitly. As well as making the entry points of the applications less verbose and significantly simplifying the use of namespaces, there are now also less verbose namespace definitions.

Traditionally, when you defined namespaces in C#, you have to then put the brackets in and enclose any objects that belongs to that namespace inside those brackets. You don’t have to do it anymore. Now, all you have to do is just write your namespace and complete that line with the semicolon. The compiler will now know that anything below that line of code belongs to that particular namespace.

There are also finely scoped namespaces. So in .NET 6 and C# 10, you can now have multiple namespaces inside of the same file. If you need to define multiple objects in the same file and you need to have those multiple objects under different scopes, this feature will help you to do this. And now there are also some notable reference types which are enabled by default when you are using .NET 6 template.

Prior to .NET 6, strings and things like classes, any reference types were nullable by default. That sometimes created confusion. For example, int or bool data types were not nullable by default. But string, which is just another primitive data type, was. Enabling this feature for strings and reference data types and forcing you to write specific nullable references of those will help you to minimize the amount of errors.

It will help you to prevent things like unexpected null reference exceptions in your code. But you can always switch this feature off and write your code exactly in the same way as you did in .NET 5 or any prior version of it. There are some more features of .NET 6, but those are, in my opinion, are the main ones that you should worry about.

Let’s now have a look at what is SignalR. It’s a library which is an integral part of ASP.NET Core. So whenever you are using ASP.NET Core, you don’t have to reference SignalR explicitly as a NuGet package. It will be part of ASP.NET CORE, and this is because this package is so popular.

What SignalR is, essentially, is a mechanism that enables persistent real-time, two-way communication between the server and the client. What that means is that whenever client connects to the server, a persistent connection is established. Now, while this connection is alive, both client and the server can send messages to each other. You can get the server to initiate the message and send it to the client or you can have a client send a message to the server.

You no longer have to rely on the request-response model which is traditional to HTTP. But it’s not SignalR itself that enables this functionality. SignalR is nothing more than an abstraction layer on top of either WebSockets, server-sent events, or long poling protocols, WebSockets is the default communication mechanism. Essentially, it’s a different protocol.

Although it is related to HTTP, if you are to use pure WebSocket, you would prepend your URL with WS rather than HTTP. Likewise, if you are using TLS and SSL, you will write WSS instead of HTTPS. WebSocket is a mechanism of establishing a persistent connection between the client and the server. But writing the WebSocket code is quite tricky, because you have to write code to disassemble objects into raw bytes and then reassemble those objects on the other end.

SignalR significantly simplifies this. Server-sent events is just another protocol that SignalR can use. It’s a fallback protocol. So if the client or the server can’t use WebSockets, it will fall back to server-side events. This is when the client occasionally sends HTTP requests such as server, and then server submits some events from its end back to the client.

Another fallback protocol is long polling. Long polling relies on pure HTTP, and it’s not as efficient as either WebSockets or server-sent events. What happens is that your HTTP client will submit a synchronous request to the server and that request will wait for the data to be available. So it will be using more bandwidth than WebSockets. But long polling is supported by pretty much any system.

In SignalR, you can either specify any of those protocols explicitly on either client or the server. Or if you don’t specify them, then this is the fallback order. If it can’t use WebSockets, then server-sent events. And if it can’t use server-sent events, then long polling. SignalR as a library is designed to be easy to learn by developers.

Writing SignalR code is almost as easy as writing two separate classes inside of the same .NET project. The server endpoints are represented by just standard C# methods. On the client side, endpoints are nothing more than main event handlers. You will appreciate how easy it is to write code by using SignalR.

And the best thing about it is that regardless of which protocol you use with it, your code implementation will be identical. As a developer, you don’t have to worry about how things work under the hood. Signal is suitable to be used for any real-time applications. It’s heavily used inside of real-time chats, geographic tracking systems, live status updates, IoT, and anything else that requires real-time updates from the server.

It’s also used by Blazor Server as its communication mechanism to facilitate asynchronous communication between the browser and the server. But when you are writing Blazor Server, you don’t have to configure SignalR. The project templates will do it for you. Now, let’s have a look at Blazor WebAssembly.

Blazor WebAssembly is a mechanism that allows to run .NET code in browsers. The code gets compiled into WebAssembly, which is a standard that all major browser manufacturers support. It allows C# elements such as fields, proposition methods to be bound to HTML. It works similar to how angular works in JavaScript. But instead of using JavaScript, you will be using C#.

You can perform real-time updates of document object model or even manipulate document object model, as we will see some examples of in the video. It can interoperate with JavaScript on the page. You can have functions in JavaScript to call methods in your WebAssembly. But likewise, your C# code can have methods that will call JavaScript on the page.

And you can either replace JavaScript completely or work alongside it. In this video, we’ll be using any JavaScript at all. All client-side code that we will write will be in Blazor. And this completes the overview of what we will be doing in this video. Let’s now go ahead and set up our environment.