AJAX application architecture and JavaScript scalability

1/26/2010

It looks like I have invested myself in the right technology, since developing AJAX applications is growing a very hot field. I have done some searches in google on this keyword, and there is not much comprehensive material on this topic, so decided to contribute some of my experiences from developing AJAX apps.

First, let's define what I mean when I refer to AJAX app: Ajax Application, is a web page, that only loads once for the session of its use, and other interaction, rendering happens behind the scene via AJAX calls.

The main objective when architecting AJAX apps is to design a framework that will be easy to work with, perform well, and highly scalable: can be used to develop something to the level of google documents for example.

The main challenge in this pursuit becomes catering to very un-level filed of used browser create interesting challenges. This is well understood by those who have developed cross-browser XHTML/CSS, less by those who have been writing server-side business logic for a specific platform. To sum it up, the browser have many performance limitations, when developing business logic in JavaScript, and the common denominator becomes quite small.

Currently, there are many JavaScript frameworks available, however some are more suited for developing "FULL" AJAX applications, than others.

Design proposition:
1. Ajax application should initially only load JavaScript code which is shared by all future code: since we want to have a framework that can scale, we don't want our code base grow with our business logic.

2. For simplification and mainstreaming purposes, all AJAX calls should use a single protocol JSON wrapper.

3. Javascript will be always separated from the presentation layer, adding interaction through the DOM selectors.

4. If possible, there should be a one to one relation between user action, and AJAX request: user action (click) should not result into 5 ajax calls.

5. Creating presentation markup (HTML) should be limited in the UI: creating table views from JSON in the UI for example can be quite costly on several fronts: growing our code base, and computation cost.

This is all for the intro... in the next post I will start with examples.