I thought I would take some time to talk about some of the special considerations that you have to take when creating and maintaining RIAs for sites that have a national audience. While these can be considered good general practice, at a certain tipping point they become indispensable for the health of your system.

Versioning

As you go through and add features to your application, bundle features into numbered versions. If there is any question about what features you should be seeing during QA, or even if what you are seeing in your QA environment is the very latest, you should be able to immediately pull up the version number from the application and correlate that to a look up table that lists all new features for that version. If you have a feedback area, encourage users to reference that number in any bug reports they submit, so that you always know exactly what code base is being referenced.

Versions can be made available in a number of ways. If your application is JavaScript-centric you can do something as simple as create a variable on the page that holds the version number so you can watch it in Firebug. If your application is AS3-based you can add the version number to the contextual menu you pop up when the user right-clicks.

If you need to make bug fixes or minor enhancements that may not warrant a full new version number, you can create sub-versions.

Cache-bust on new Versions

Cache is a beautiful thing for a national site. You pay a lot of money so that customers across the country can hit edge servers local to them, so that they aren't hitting your origin server, and so that they get content served up quickly.

Cache can also hold onto code past it's freshness date. If you push out a bug fix, cache can delay the fix being seen by whole geographic swaths of users for days. If you update an API but one of the libraries is cached you could be getting broken results anywhere down the chain for days.

To avoid this it's generally a good idea to cache-bust whenever pushing out a new version of an application. This can be as simple as appending a version number to the url pointing to the swf or js file: myapp.swf?ver=2.01

Log Errors

Your application will, obviously, run on the client-side, which is the wild. You have no control over that environment, and you generally can't see errors happening there - and errors will happen. Between loading feeds and graphics and configuration files or video assets, your application will most likely have a lot of moving parts and external dependencies, all of which could fail at one point or another. A user could be running a very old browser, or may have their entire hard-drive full, or a vendor may have deleted the crossdomain.xml that your application needs during a recent upgrade. Your application will run into errors at some point out in the wild.

Yes, you error trap and skillfully use try catches only where appropriate, but at the end of the day at one point or another your application will not be able to access some sort of data that it might need to perform its intended function. At that point you fail gracefully, or move on to the next item in the list, and you should always log.

Running on the client machine is no excuse to not have a server-side error log to track issues and get alerted to potential outages. Call a server-side script to log the error, hit a monitored URL, whatever you need to do to get your error data written to the server-side do it. The benefits are huge, but the two most significant ones are:

• you may be alerted to errors you didn't anticipate or in sections of code that you didn't anticipate, which will allow you to harden up the experience by potentially trapping for those errors


• you will be proactively alerted to outages, hopefully before users alert you to them

Good software design is such a massive topic that I won't attempt to address it here, but I wll make a note to never ever underestimate its value. The more complicated the system, the more you will be glad that your application is made up many small self contained, interchangeable parts. Resist the temptation to compromise on that and you'll have less actual bugs to fix which will free up your time which you will need to manage all of your data sources, put out fires with your infrastructure moving parts, and create new features.

Read more from Tom Barker.