29 November 2006
The Challenges of Developing an Ajax Application
I do not think anyone prefers the old style click->reload style applications over newer Web 2.0 applications. Think back to the first time you saw Google Maps: was your first though closer to “Cool!” or “Mapquest’s UI is so much better?” There was an initial wave of resistance to developing applications with this technology, with three primary reasons being a certain lack of understanding of the benefits Ajax afforded, a lack of knowledge about the particulars of JavaScript necessary to make Ajax happen, or resistance to having to develop each Ajax feature twice: once for JavaScript-enabled users and once for those who disable it.
The Ajax phenomenon swept the web nearly three years ago and development is in a different place today. Any programmer worth a quid at least understands Ajax as a concept and should be capable of taking Prototype’s easy to use libraries and deliver a rudimentary Ajax application. But just as a beginning Visual Basic developer does not understand the subtleties of Windows in the way an expert does, this rudimentary knowledge is only the beginning.
Of particular concern is how to properly layer your application. Most developers are familiar with three-tiered applications: the data tier, the logic tier and the presentation tier. However, each tier is comprised of one or more layers. In an Ajax application, the logic tier will likely have a minimum of three layers: state management, server-side logic and client-side logic. The separation between server and client logic is perhaps the most important to grasp. Certain things must still happen on the server: data validation, authentication, many web services, database I/O, etc. Even though JavaScript is fully capable of performing validation, JavaScript itself must be considered unsafe input. The JavaScript validation would, in effect, have to be validated. Furthermore, nothing has addressed the fact that some users still keep JavaScript disabled. Many applications just choose to turn there back to these users and they’re not necessarily wrong. Just as some applications require Windows XP and will not run on Windows 98, JavaScript can simply be a requirement. Other times though, a requirement of the program is that it will work on mobile devices or in situations where JavaScript is not at option. So any code that does anything should remain on the server side, but should be compartmentalized to make it accessible to JavaScript.
It’s still not that simple, though. Functions can’t be spitting out raw XML, as they will often call each other. Which means any function to be used in Ajax will require an access wrapper. And very quickly, you have all your Ajax calls exposed as actions in your MVC. And you’ve moved for the first time beyond a beginning Ajax developer.
Soon you will realize that while validation is well and good, you somehow must access data from JavaScript. It’s easy enough, to be sure, for your server code include a data pool in some format in the initial presentation. But sometimes, live data is simply required. So you diligently build your runSql action that returns a resultset in XML. Or, you’ve built a runSql action which accepts SELECT * FROM user_history WHERE '1'='1'. Or DELETE FROM Users. Do you see the problem? Ajax development must be treated like a firewall: it disables everything by default and punctures tiny holes in its outermost layer to exchange requests. But again, this functionality must be on the server side.
This is not to say your Ajax application will have no JavaScript. It will — it will fire requests on onKeyDown events, onFocus, onClick and every message a normal desktop application would have to respond to. But within those methods, it will do little more than package the client state for input to your server-side application and massage the server’s response back into the client state. But even in Ajax applications, JavaScript should be considered user data and any attempt to treat it as anything but that will do nothing more than add layer upon layer of complexity to the application as a whole.