Why is Blazor becoming so popular?
Web applications have been developed for approximately 30 years, and during this period both hardware and software technologies have undergone drastic changes. However, the nature of web applications and websites has essentially remained the same: we have a front-end layer exposed to the user and to the world, and a back-end layer, which contains internal data and logic.
This means that building such an application requires at the very least a two-layered technological stack – with 3+ layer stacks being common to take care of databases, services, containers, etc. In the past, the internal complexity of web applications made many developers specialise in a specific layer of the stack. Front-end and back-end development is still an important issue in web development, and the promise of full-stack developers seems to be difficult to accomplish if we (as users or managers) also want all-round proficiency.
Unsurprisingly, independent technologies evolved for both front-end and back-end development, the archetypical example being the divide between Javascript and Java, which only have in common their C-like syntax. Later on, frameworks appeared on the market, but they were mostly containers for other technologies.
The first actual improvement came with Node.js, which allowed the use of a single language both for front and back-end development, as well as for storage (e.g. in the MEAN stack).
A similar breakthrough occurred with Blazor, which provides tools to fully develop and deploy web applications through a .NET interface that can also be installed on Linux and Mac OS. The idea is to let the developer use C# for each application-related need and to use XML and JSON configuration files.
Thus, Blazor lets the C# programmer use their mother tongue both for back and front-end development, and to fully leverage .NET libraries and the .NET underlying environment to build client applications. Moreover, and since it’s interoperable with Javascript, Blazor can be integrated with existing front-end libraries if needed, calling them from C#.
Razor-specific configuration files are used to describe components, which are UI widgets that can be used inside the client and that can interact with back-end logic. Blazor allows writing applications on the server to build UI components, and facilitates interaction in real-time via SignalR, an open-source library whose API allows to invoke functions on the client via server code (with .NET Core running on the server side).
All in all, and due to these features, Blazor is convenient when a web application shares one or more of the following features:
- Apps with high-frequency updates from the server.
- Apps that require notifications.
- Dashboards and monitoring apps (remember this item, as it’s the use case of IoT HMIs!).
- Collaborative apps.
In fact, the SignalR feature underlying Blazor makes it push content instantly on the clients and provides full support for real-time applications.
Moreover, Blazor provides a “hybrid” feature, which can be used with a mix of desktop and mobile native client frameworks. In other words, Hybrid Blazor app is a native client app that avoids the use of WebAssembly to translate and execute served code inside a browser, and instead renders the UI in an embedded Web View control via an interop channel. To get such a result, Blazor can interact with different technologies, such as .NET Multi-platform App UI, WPF (perhaps the most well known) and Windows Forms.
Using Blazor for industry-grade IoT solutions
The features we just mentioned make Blazor suitable to provide support to IoT solutions. First of all, Blazor’s Hybrid feature allows running Razor components natively on the client device. A component is any element that contributes to a web page application and is located to some URI. A single component provides a UI and the corresponding logic needed to describe its dynamic behavior. And as the word “component” suggests, it can be used to compose complex UIs (actually, components are a feature of Razor, a markup syntax for embedding .NET-based code into webpages, with the familiar .cshtml extension).
In other words, within Blazor Hybrid, client UI components don’t run inside a browser, but instead they are rendered into a native client framework. For example, one can use .NET MAUI, the cross-platform that sits on top of the .NET Base Class Library across devices using different operating systems, such as Android, iOS, Mac OS and, of course, Windows. With MAUI, one can render Blazor components into Web View via the BlazorWebView control. This control also works for WPF and Windows Forms, popular frameworks for building apps.
The main outcome of this architecture is that applications built with Blazor Hybrid are native apps that have complete access to all device features through the .NET API layer. Programming with them means having full access to the device’s capabilities.
For example, this can be exploited to integrate Blazor with General-Purpose I/O (GPIO) and Windows compliant controllers. These can interact via Blazor apps, as they are usually able to use functions in peripherals, such as interrupts, signaling, etc. .NET classes used to program drivers can be used to implement IoT applications, e.g. GpioController.
In general, .NET IoT libraries provide the means to access and use devices attached to Common IoT boards (such as the Raspberry Pi) via C#, via Blazor or through an app. The System.Device.Gpio package supports not only GPIO, but also serial ports and other interaction protocols with low-level hardware pins. The Iot.Device.Bindings package provides device bindings to several kinds of devices that are commonly used in IoT, such as displays, GPIO expanders, touch sensors, LED drivers, USB, accelerometers, etc. The Microsoft learn page provides examples and further explanations on this topic.
Another possible and equally interesting integration involves Azure IoT. This is a cloud solution that enables communication with IoT applications, and hence with the devices behind it. Azure IoT provides a reliable and safe communication channel with IoT devices: the cloud-to-device message. The following layers are needed to manage an IoT system with Azure IoT and Blazor:
- An IoT Hub with message routing enabled.
- Azure Function with IoT Hub/EventHub trigger.
- Server-side Blazor web application with API controller integration.
Using Blazor simplifies the handling of business logic and makes it easier to focus on the configuration side, to let those layers talk to each other (for example, to define and configure Azure resources, including the IoT type, to set up the routing, etc.). Therefore, there are several ways in which a Blazor web application can be used inside an IoT infrastructure, based on equipment and needs.
Case study: iTools HMI by SACMI
HMI stands for Human-Machine Interface and refers to applications, usually in the form of dashboards, that are used to connect a human operator with a set of devices. Although this generic definition can refer to standard GUI uses, it’s mainly used to describe a dashboard specifically built to monitor hardware devices or any kind of industrial asset connected to digital sensors that can be accessed by the dashboard.
To achieve this, SACMI iTools HMI provides a complete web application based on the Blazor technology to build up the user interface and to exploit the features we described above, especially the possibility to connect to devices, get and set information to and from such devices, and more.
Since it’s built on a platform-free technology such as Blazor, iTools HMI can run on different operating systems and, of course, inside a docker or from the cloud. The key point is that iTools HMI users need to focus on their business and on their equipment, so the tool has to support them and not to introduce new complexities once it’s deployed. Since the application features built-in drivers for more than 50 devices, it can be configured with no dependencies on other IT assets.
Moreover, since it exposes a web interface to its users, iTools HMI communicates with the user via widgets, animations, etc., making the user experience very easy and intuitive and letting users quickly obtain the monitoring information they require. Of course, being a web application, it can be accessed with different grants, whose administration can be done inside the dashboard itself.
But the actual strength of the product is displayed when creating new projects. Through them, it’s possible to define the widgets and controls needed to monitor and manage IoT devices in a comprehensive way, and always tailored to the user’s operational needs. For example, the following screenshot gives an idea of the IDE that is provided to the program, via Blazor, a complete dashboard fulfilling our needs:
The choice of components and controls can be made between the built-in drivers. Alternatively, and since it is an open framework application, iTools HMI can be easily extended and configured to be tailored around specific use cases and needs.
Conclusion: Why Blazor will be even more important in the future
It is usually said that we live in a connected world. This is true not only because we can communicate with each other, but because we can communicate with devices and devices can communicate between themselves.
While standard web frameworks account just for the communication between the user and a remote application and database, there’s an increasingly pressing need for a web framework that can connect a user with its client devices and also to the type of IoT infrastructure needed for business purposes. As we have seen, Blazor can certainly fulfil these needs and provide the foundation to build IoT-connected web applications, as shown in the iTools HMI case study. The latter is just one of the products that SACMI has released to the market to facilitate the life of people involved in the industries and processes where HMI play an important role.
