Ajax seminar

A new architecture

I see two different architectures of Ajax applications: one has the Ajax mindset as a foundation, the other sees Ajax as a possibility to simplify and improve the existing architecture.

This is a schematic view of a current web application architecture. The Controllers/Actions/JSP-layer is thicker because, from a client side programmer’s point of view, it’s where a lot of the code is. The HTML+CSS bit is on the server side because that’s where it’s created, nothing really happens on the client side.

An architecture with Ajax as a foundation. The client and server are independet of each other, nothing but data (in the form of XML or JSON) is sent between them. There are layers on the client side dealing with communication, event handling and such, and the Controllers/Actions-layer on the server side is now simpler, being mostly a facade/data translation layer to the business logic.

The alternative Ajax architecture, doing the old things in parallell with the new. Pages are still rendered by the server, but they also contain dynamic components. For example, instead of having separate pages for a multi-part wizard, you could have one page with all the parts, hiding and showing the parts as the user progresses through the wizard. This way you would simplify for yourself by not having to think about the state, and simplify for the user, who could jump back and forth in the wizard without having to wait for the next part to be rendered by the server.

Communication

Even though you could use whichever format you want for communicating between the server and client, there are three realistic options:

• the server is a generic web service talking SOAP or similar
• the server sends data in your own XML-format or JSON
• you use a framework to send RPC

Most of you will go with rolling your own communications format in XML, some may pick up an RPC-framework like DWR, and very few with the generic web service option, it’s just not worth it.

JSON as an alternative to XML

If you are asked to define a format for a chunk of data, what is your first thought? XML. There’s nothing wrong with that, but depending on the situation, you may not need XML:s descriptional approach. Sometimes you just want to send data. If the producer and consumer both know about the data that is sent, there is no need to describe it, but with XML description is not an option.

JSON, JavaScript Object Notation is a textual representation of JavaScript data structures. No logic, just the data structure parts: strings, numbers, lists, and objects/maps. And it’s got serialisers for all possible languages and environments.

The thing with JSON is that it removes the need to parse the data you get from the server, it’s already in JavaScript. Just run it through eval() and you’re done. If your client is not JavaScript (for example a Flash-application which uses ActionScript, not quite JavaScript since it lacks eval()), there are deserialisers available too.

Just stop and think for a second. How much time do you spend writing code that parses XML into your own data structures? I think the answer is »a lot«. And its no fun either. JSON is simpler to create than XML and simpler to parse.

Of course, there are XML dialects which does the same thing, WDDX for example, and RPC is in most cases XML which is translated to method calls on both sides. JSON:s advantage over these is that if your client is JavaScript, JSON is super-simple to parse, since you don’t have to parse.

On the other hand, good XML is simple to read for a human, and XML can be transformed with XSL to other formats, which can be handy sometimes.

Some notes on performance

There are two aspects of performance in JavaScript: runtime performance and loading.

JavaScript isn’t that fast, don’t try to sort or transform big data sets, it will freeze the browser. It can also be slow to create big and complex DOM structures, the best way to do it is to create the structure separately from the page’s DOM and add it in one go, that way the browser only has to re-render the page once, not once for every added node.

If you have lots of code it can take a while before the page is ready to use, but this is usually not a problem, a couple of hundred K is nothing compared to a few images. Some frameworks come in a compressed version, with all whitespace and comments removed, to save space. This is nice in a way, but a waste of time. All modern browsers support gzip-compression, and gzip will compress your code much more than removing whitespace will. Use mod_gzip if you are running off Apache, or some other compression mechanism if you are using another web server. It’s easy to write a compression filter for a servlet container, do it. The magic is that the browser will tell the server if it supports compression, so you won’t shut out those that can’t handle it.

Pages: 1 2 3