![]() This main server project (the BFF) contains the startup logic, registers the services, and configures also the SignalR hub. The CRM we are building is separated into modules, but in the end, all modules get referenced from one single project (for the server part, there is of course another project for the client application). If you’re using multiple hubs just for organization within the same project then I’d recommend using a partial class with more methods. So, I started to look for an easier solution and found a recommendation from David Fowler (the creator of SignalR): The code looked quite complex, and I didn’t want to replicate it because it would require a lot of testing and would be hard to maintain in the long term. Because with SignalR the messages are sent as text messages, and SignalR maps them to the hub methods and passes the correct parameters and converts them to the right type. I looked at the SignalR source code, and it turned out that I would have to replicate a lot of things that SignalR is already doing. It gets even more complicated if we want to support all SignalR features like filters, streaming, and authentication. This solution would require a lot of reflection magic to find the right method, pass the parameters with the correct types, and handle the return values. My first idea was to create a single hub with a single method that parses the messages and calls the methods of the modules. Some people asked about this on GitHub too and you can find more insights from the product team here, here, and here. Connections are made directly to a single hub, rather than a single connection being used to share access to multiple hubs. In ASP.NET Core SignalR, the connection model has been simplified. The Compare SignalR and SignalR Core page has this information: Why is it not possible to share one connection between hubs you ask? Well, this was supported in SignalR but isn’t supported anymore in SignalR Core. That’s why we want that multiple modules can share the same WebSocket connection. It’s a big difference if each user has only 1 or, for example, 5 concurrent WebSocket connections. Let’s say we have a maximum of 1.000 concurrent users per day. For example, Azure SignalR Service is paid per unit and one unit can have 1.000 concurrent connections. Holding many active WebSocket connections can get expensive on the server-side. This can lead to many concurrent WebSocket connections. But there can be multiple modules on one page, and they can subscribe to updates from different hubs. The first logical thought was that each module can provide its own hub that can be used by the client application. SignalR is structured in so-called hubs and each hub is using its own WebSocket connection. One requirement is that modules can send real-time updates from the backend to the client using SignalR. ![]() Each module can consist of a frontend part that will be executed in the Blazor client application and a backend part that runs as part of the ASP.NET Core backend-for-frontend (BFF). Therefore we developed a small base framework that allows different teams to build independent modules. There are multiple teams inside Söderberg & Partners that will contribute to the CRM system. NET and build a new frontend with Blazor for their existing ASP.NET Core micro-service backend. They made the strategic decision to use full-stack. Over the last months, I worked together with the engineers of our customer Söderberg & Partners to build the foundation for their new CRM system. The source code with samples is available on GitHub. The following graphic provides an overview of how it works: The partial classes get then generated using a C# Source Generator. ![]() But instead of putting everything in one project, SignalR modules can live in separate projects or NuGet packages. The concept is based on the idea of organizing multiple hub methods in partial classes within the same project. In this article, I describe an approach how to build SignalR modules with a shared connection using a C# Source Generator. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |