In my previous posts, here and here, I discussed my objective to create a custom dashboard solution in order to meet a number of requirements as well as a method for creating that solution using a traditional Web Services approach. In this approach, the client is wholly responsible for requesting all of its updates from the server whenever it needs them (typically on a set timer). In this post, I’ll create the same dashboard but use a different technology, SignalR, for performing the data communications. Much of the solution will be the same or similar to the previous solution, however the back-end is fundamentally different.
With the SignalR approach, rather than the client being responsible for requesting data updates from the server, the server maintains a connection with the client and pushes them to the client on an “as needed” basis. This basis can be timed (such as sending an update once every 5 minutes) or it can be triggered (such as sending an update whenever data changes.) In this example, we’ll be using the timed approach for parity with the previous solution. As an extra benefit to the SignalR solution, when multiple clients are connected to the same dashboard, they will all display the exact same data and refresh at the exact same time (as they are not maintaining their own individual update timers. The following diagram gives a quick illustration of the data communications between the clients, web server, and database server:
In my previous post, I discussed my objective to create a custom dashboard solution in order to meet a number of requirements. In the process of researching how I would create the solution, I made multiple choices pertaining to the technology and design which would be used to create the dashboard. I chose to implement both a traditional communications model utilizing web services where the client is responsible for requesting data refreshes as well as the SignalR communications model where the server pushes updates to the client.
To recap, I made the following design decisions for the application:
- Use a custom developed application instead of an off-the-shelf product
- Use web-based technologies within the Microsoft ecosystem
I just recently finished a series of custom development projects which required me to revisit the programming world from which I once came. Programming is something I started doing when I was very young and have always enjoyed. While I’ve done plenty of scripting, Powershell, and T-SQL in recent years, my current job roles have had little need for true programming skills until recently. And wow, things have changed! In this series of posts, I’ll be going through my process for choosing a technology and developing a custom dashboard solution as well as some of the lessons I learned along the way. Here in Part 1, I plan to cover my goals for the dashboard as well as how I chose the platform I did. In Part 2, I’ll cover the more traditional of the two methods I explored and in Part 3, I’ll cover a SignalR solution.
Whenever learning or refreshing skills, it always helps to have a goal. In this case, my objective was to create a dashboard solution with the following objectives:
- Display near real-time data from a OLTP SQL Server data source
- Be aesthetically pleasing as it will be viewed on multiple large screen displays 24/7
- Refresh gracefully with no user interaction or display interruption while refreshing