ASP.NET SignalR: More than Just Chat

Related: "ASP.NET Web Development: Get a Glimpse into Your Web Server"

ASP.NET SignalR has been getting plenty of buzz and attention lately in several different circles. Unfortunately, it's often demoed in user groups and online samples as a means of providing chat functionality. Although it's cool to see how easily and efficiently SignalR can be used to whip-up chat applications, I can't help but wonder if a seemingly obsessive focus on chat hasn't sold some of SignalR's strengths quite a bit short. To that end, I've actually been using SignalR to help tackle some really tough problems and have been blown away by how amazing and powerful it has been in letting me address some difficult use cases.

SignalR versus a Data Deployment Application

One of my clients recently came to me to help automate a semi-complex process that they've had in place to manage data modification and deployment needs for their larger e-commerce site. The rough idea of the solution that they've had in place is that their data team modifies product descriptions, keyword text, pricing details, and several different associations in a non-production staging environment.

Within this environment, the data team can validate all changes before they can go live. Updated definitions, associations, and other changes, which weigh in at roughly 40 to 50 million rows worth of data spanning over 60 tables and over 4GB of data, then get pushed out to staging tables in production once the data team's changes have been validated.

To make these changes go live, corresponding product detail tables in the production database are renamed by using sp_rename during non-peak hours. This process effectively makes production tables become 'production_old' tables and corresponding staging tables are spun up to instantly take their place. This provides a means to avoid the kinds of locking and blocking that would occur if these 40 to 50 million rows were first truncated from production tables and then loaded back in.

Related: "Mobile Development Options for .NET Developers"

To tackle the task of automating this push process, I initially thought about using SQL Server Integration Services (SSIS). But as requirements became clearer, I came to realize that SSIS would be a pain to use. For starters, SSIS is incredibly brittle and doesn't suit the need to implement gradual changes where tables and data end up getting staged and deployed into production. Although I initially thought this solution would be used by developers or a reluctant DBA, management determined that a web application that's used directly by the data team would make more sense rather than saddling developers with managing this operation. Although tapping into the SSIS object model from within ASP.NET sites is possible, licensing requirements for SSIS means that we would need to deploy IIS to an existing staging SQL Server or deploy a license of SQL Server to an existing IIS box. Obviously, neither of these options are very appealing.

Ultimately, that left me with several interesting requirements and problems for my web application. Highlights include:

SignalR to the Rescue

In the end, SignalR met all of the needs listed above insanely well. The fact that it's architected to enable multiple clients to effectively be tied to a single point of interaction was the exact solution I needed, as I just needed to put a UI over the top of a back-end workflow manager or engine. Moreover, the fact that SignalR makes it trivial to have your .NET server-side code effectively call or execute JavaScript methods and vice-versa made the mess of keeping perfectly synchronized UIs across browsers very easy.

Ironically, the only problem I had getting everything to work was verifying that I could use SignalR to pull off what I wanted to do and finding examples of non-chat solutions built with SignalR. Happily, I came across SignalR-StockTicker, which is a fantastic demo application that perfectly modeled the idea or notion of multiple clients (browsers) interacting with a single, shared, object or process hosted on a back-end server. Consequently, that demo app, along with the documentation found on "SignalR Client Hubs" and "SignalR JS Client Hubs" helped me get up to speed with obscenely less effort than I would have had to expend otherwise. As such, I think SignalR is a fantastic addition to the ASP.NET family. Not only do I see it having great potential for dashboard applications and other complex solutions, but I also can't wait to use it on some other projects that I'm working on as well. Even if none of those applications are chat-focused.