I can't stop talking about how quickly AJAX and its capabilities are developing. In my last blog post, I talked about how you can store huge (in the order of MB) amounts of persistent storage on the client side with Dojo Storage. In a webmonkey article I wrote a while back (pre-AJAX), I explored the high level of GUI control that can be achieved with JavaScript's Event Model.
With all these capabilities that AJAX has made available to us, it makes me wonder, where are we headed in the grand scheme of things? I mean, how will it affect the architecture of web applications?
Figure 1: Web Application Architecture without AJAX
The above figure shows us how life is without AJAX. JavaScript's role is minor -- it's mainly used to improve the look and feel of web pages. The heart of the application (i.e. the main control logic) lies on the server side, as this is where the application has unbridled access to all its resources. Any time an action is performed that requires access to data on the server side, an entire HTTP request/response cycle occurs.
AJAX opens up a lot of doors for us. Because we can communicate with the server via JavaScript (specifically the XMLHTTPRequest object), web application architecture can radically change.
Figure 2: Possible Web Application Architecture with AJAX
We see a fundamental change in JavaScript's role. It now encompasses the control and business logic (event handlers and custom objects), and the page building component (functions that make use of the JavaScript DOM) . The server script's role has been drastically reduced. On an initial page load (represented by the dotted "HTTP req/resp" arrow), the server sends a template HTML page, along with the source code. It's important to note that this is a blank template -- it contains empty HTML tags (it's not the template loader's responsibility to populate the HTML page).
In this model, the JavaScript does all the work. Whenever it needs data from the server, it makes a request to the database server (e.g. a stored procedure call) via an XML HTTP Request (XHR). The job of the security manager is to ensure that the JavaScript has the appropriate permissions; if it does, the request is passed on to the database.
The dotted lines in figure 2 indicate that a full HTTP request / response cycle is only done once per template load; there may be several XHR request / response cycles that occur within one template. Even an e-commerce website may only need a handful of templates: one for the registration process, one for account setup, and one for general website use.
Off the top of my head, I can think of many advantages and disadvantages to this client-side script-centric approach. However, I will hold off on discussing them, for now (I think I'll sleep on it). Nevertheless, your feedback is appreciated, as always!