Dave Johnson

There are a multitude of ways to get data to and from the client in an AJaX application.

A recent article by Jon Tiresn [1] outlines what he feels are the three most useful methods of returning data to AJaX client applications and makes a point of dismissing the idea of sticking to standards and other theoretical dogmas. I highly recommend reading the article but will mention the three methods he discusses which are:

1) simple return
2) snippit return
3) behaviour return

and I will add what I feel is an important fourth:

4) XML return

I added the last one because it is a very important tool in the AJaX toolbox since XML data can be transformed on the client very quickly using XSL-T thus reducing server load, enabling the inherent use of app server data caching and adhering to standard design principles. You can even do various tricks to reduce the size of your XML data so that you are actually transferring very little data.

All of these four options are good if used in the proper situation. I generally agree with Jon that there should not be any of this generic interface (SOAP, SOA, WS-*) type malarky in AJaX applications. There may be some special cases where one might put high value on being able to re-purpose AJaX data and thus make the client and server very loosely coupled but for the most part AJaX services will not be available to the general public and exist primarily to support the user interface.

Furthermore, due to the constraints that JavaScript places on AJaX applications in terms of latency and usability, one has to engineer both the client and sever interfaces for the best performance possible; this often includes performing time consuming operations on the server rather than the client and returning ready to process JavaScript snippets or behaviours as opposed to raw data / XML. This is not interoperable or standards based (yet) but pays huge dividends in terms of application usability.

That being said there may be instances where you are dealing with the same data in both internal and external applications and it might be helpful to be more standards based. Another strong case for being standards based arises from situations where you are building AJaX based components for use by the development community in web applications. These type of developer components should be easily integrated into internal systems and thus can benefit from being standards based - that is why there are standards in the first place after all.

In the end one has to ask several questions to determine what method to use. Some of the important questions to ask about the application would be

• is the data going to be used for several interfaces or systems inside or outside of your company (SOA type situations)
• is the application a one off (Google Suggest)
• how important is application latency
• how important is browser compatibility
• how much traffic and server load is expected
• how much client processing can be done without compromising latency goals
• how important is it to be standards based
• how difficult will it be for a new developer to extend / debug the application
• how much raw data is being transferred between the server and client
• how much formatted (HTML or JavaScript) data is being transferred

and so on (its late and I am tired:)). One thing is certain - the lines that define a traditional MVC architecture can get very blurry when dealing with AJaX.

What are other metrics that people have found useful when considering data access in an AJaX application?

[1] Designs for Remote Calles in AJaX

Del.icio.us

This entry was posted on Wednesday, August 24th, 2005 at 11:10 am and is filed under Web2.0, AJAX, JavaScript, XML, XSLT. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.