I build a bank… and it crashed.

If you were at Codestock this past weekend, you might have seen me talking about a certain demo I wrote to show off the awesomeness of SignalR, Twilio, and Wijmo. In fact, you can still check it out: http://callcenter.apphb.com Didn’t see the demo? That’s fine, but shame on you. Bank of Griff was meant to represent a theoretical call center. By using Twilio, “customers” could dial into the system and interact with the few options that I had available. All this information would be stored in real time, and pushed out to clients that were actively looking at the Bank of Griff dashboard. I learned several lessons during this demo, and a lot of them were mistakes that I made due to time constraints and not adequately thinking about what I was doing. Issue #1: Constant DOM Rewriting Is (REALLY) Bad This is one I really should have seen coming. There are two grids on the page: one for the incoming calls, and another for what users are doing on the system. I thought it was a great idea to just send all the raw data to the clients every five seconds. This worked fine during testing with two or three clients, but I started to see issues when scaling to 150+ clients. Oh, and a “client” was a person who called into the system. What was happening? Every five seconds, I was sending a full dump of the grid data to the webpage. If I have 5 columns and 500 rows of data, that’s 2500 table elements that have to be destroyed and rewritten. Then do that every 5 seconds. Oops! What should I have done? First, there is a place for a method to retrieve all data. It should only be used with first time connections, and possible resyncs. Second, I should have only been sending deltas (changes). If I’m adding 1 row, I don’t need to resend the entire grid. If I want to change a row, I only need to send the change information. It’s just “easier” to resend the entire data package. Issue #2: Bad Dashboard Design When I first approached the idea of dashboards, it was purely from a technologist point of view. I wanted to build an experience where I could demonstrate real time web applications, but I didn’t put enough thought into the physical look of the dashboard. My buddy, Devin Rader, turned me on to a book called Information Dashboard Design: The Effective Visual Communication of Data . After flipping through it for a few minutes, I immediately discovered I wasn’t using the tools effectively. I’ll write more about this later What Went Right #1: Wijmo Wijmo is just an awesome tool. The charting and grid controls worked as well as I would have liked them to work, even when I totally abused them. For v2 of the Bank of Griff dashboard, I’m going to take advantage of our native KnockoutJS support. This will definitely clean up the code, and improve the process of updating the screen. What Went Right #2: Twilio You call in. Request gets sent to my app. The app sends a response. Rinse and repeat. I love Twilio. What Went Right #3: SignalR If you’re writing tons of jQuery AJAX calls, you’ll want to look at SignalR as a replacement. Not only do you get great integration for client to server communications, but you’ll get the added support of the server being able to push data down to your clients. What’s Next Now that v1 is done and in the bag, it’s time to build v2 of the Bank of Griff app. I’d like to spend the next several blog posts rebuilding the application and implementing changes that I’ve picked up along the way. Kevin Griffin keving@componentone.com @1kevgriff