Home / Thoughts, sketches, dev cases

SignalR clients

How I advanced myself in 4 technologies in 2 months

Friday, January 26, 2024




For the past 5 years I have been a backend developer. I appreciate slick design and thoughtful usability of the software products, however even more I like to implement "under-the-hood" functionality that breathes actual life into them. My knowledge of frontend technologies was limited by ASP.NET MVC, html, css/bootstrap and javascript/jquery.

Recently I got an interesting task to investigate message exchange technology called SignalR for potential implementation in a product that our company is developing. SignalR implementation consists of backend thing called "hub" and frontend clients that basically can be of any type — web, mobile or desktop. So to advance my investigation and to update my frontend knowledge I decided to implement several different simple clients to observe their interoperability in regard of SignalR messaging for different users on different clients. I started with very simple console client and finally ended up with 2 web clients, which were built on React and Blazor, and one desktop, which was WPF.

Yet another time I glad to myself that I have Pluralsight subscription. Thanks to this great educational platform with thousands of courses, I've made myself familiar with those frameworks in a matter of days. Of course there were things to invesigate separately, especially regarding Azure Entra Id (former Azure Ad) authentication/authorization, but finally all of these were solved.

So what can I say at the end of this experiment?

Both React and Blazor had been originated by IT giants Facebook and Microsoft as internal projects and later on came out as full-featured frameworks for frontend web development. I got basically no difficulties implementing simple application on both of them, tailoring it to my needs, which is connecting to the SignalR hub and implementing Entra Id auth. Both React and Blazor have things called components where custom logic is implelented to solve particular task; those components are used in html markup along with standard tags.

One noticable difference for me is that React components, being implemented in modern javascript modular approach, requires declaring export entities for each module. Also interesting that html rendering part usually is specified as return statement from a function, with all code logic specified in function body. Whereas Blazor proposes much like familiar for a c# developer approach with Razor frontend markup and code-behind supplemental files, where logic is implemented (and yes, some small code snippets can be added right in the .razor file as well). Under the hood markup files and their respective cobe-behind files are translated into partial c# classes and thus the whole structure of an application for me personbally becomes more familiar.

Really cool feature of the Blazor is that by design it can be used to use 3 different kind of UI engine for the developed apps: server-rendered, webassembly client-rendered and progressive web apps (PWA). Server-rendered UI allows to have no limits in regard of db connections or credential management in the app, providing SignalR-connected clients with DOM updates in their browsers; webassembly client-rendered UI makes the app true SPA with backend used for initial startup and, as possible extension, API calls; and PWAs are kind of webassembly apps wrapped into OS-specific envelope that makes it fully-featured standalone installable app that can work offline.

Development of desktop WPF application gave me whole lot of new experience. First of all, ObservableCollection class, INotifyPropertyChange interface and c# events — the things which by nature are not really needed on the backend. However, to provide consistent UI that contains many different visual elements, the way how WPF framework utilizes those features is really impressive. Secondly, synchronization context and Dispatcher — writing async code for desktop app, I've got experience of how the app crashes just because the code tries to update UI from backend thread. And finally, the XAML markup language, which is used in WPF as well as in more modern UI technologies like WinUI and MAUI, is really impressive kind of "Bootstrap on steroids" :)

Although in this project I used Entra Id authentication/authorization and each of my application was registered in Azure, actually I run all of them locally. React client app was developed using Visual Studio Code, all other — in Visual Studio. According to business task there were two REST APIs — external which serves ordinary business requests and internal, which processes long-running tasks. When some external request needs to launch a long-running task, external API calls internal API where such tasks are served. When the task execution passes particular stage that needs to be messaged to the calling user, SignalR hub sends a message to a user with Azure SignalR service which is the only service that runs in the cloud.

So final setup for this PoC solution consisted of cloud SignalR service, 2 APIs and 4 clients — React, Blazor, WPF desktop and windows console. The idea is to run long-running tasks on the background and notify clients when the task passes particular stage. Those tasks are fibonacci sequence (disabled as not that many numbers can be generated for int32, I kept it just to play with UI), positive and negative numbers generation, once per 5 seconds.

And here goes my SignalR clients zoo :)

SignalR clients zoo

© All Rights Reserved. Designed by HTML Codex