My current project is part of a highly linked architecture, with individual systems each owning certain pieces of data, and exposing them RESTfully. Both our web services and our user interface take advantage of this linkage, storing links to the resources in other systems rather than storing a copy of the data, and presenting composite views by fetching the current state of those resources.

For example, my system might be responsible for a yearbook of people (I'm not using our real data and relationships here, of course). People are owned by another system, and perhaps have contact information (email addresses, phone numbers, twitter handles, etc). That contact information might be stored in another system that has details about the phone number or email address.

In order to present a view in my user interface, I then have to fetch my own data and follow the links in order to present the appropriate details from these other systems. I could cache certain parts of this information but likely want to retrieve the newest details.

In some of my pages, I have a reasonably small number of lookups to do this kind of data enrichment. In other pages, I am presenting a lot more information and end up with an explosion of data as I get a list, expand each element, expand each of those, and so on. I have experimented with providing a service which does this aggregation and returns all the data needed by the view in a single response. However, I am not sure whether this is the cleanest way to provide this.

Can anyone suggest some strategies for determining when I should directly use AJAX requests to fetch this data? At what point should I switch from individual requests to providing aggregated services to build the data? Or is there some other technique I could apply?


I think how many Ajax requests you should perform and when they should be done really depends on your UI. What I would think of first is what is the most important information related to the data I'm loading. For example, if it's a person, I'd say his first name, last name, birthday date are what I want to display (or the kind of information you can find in Wikipedia's right side frame for displaying personal information). I think you have to display critical information as fast as possible however it's up to you (or your client) to determine what is critical and what is not.

You can then use Ajax requests to load more detailed information (addresses ? phone numbers ? twitter handles) that at first is not available or/and hidden to the user, for example in a "tab" that is not selected. The selected tab by default being the one with the main information. You have two ways to do it then:

  • Load when the page is ready, that is when it has shown up to the user. It is loaded while the user looks at the main information.
  • Load when the user clicks on the tab. The user will have to wait a little bit (could be very fast and nearly unknown to the user).

Either way, adopt consistency and always make sure to show the famous "loading icon" when the data is not yet available. The second choice may not be great, but it could be useful for Ajax requests that take some time, return a lot of data and more than anything else need a complex widget to be displayed. You also avoid unnecessary Ajax calls.

How many Ajax requests you perform (service aggregation as you wrote means to me you aggregate data server-side) is less important in my opinion than the total time it takes to get the data you need. If you display the information faster with one huge request, go for it, if not, stay with several small requests/responses. You should set yourself a goal in terms of loading the page as fast as possible and try to attain it.

Anyway, you will have to experiment and see what gives the user the best experience. I know it's not a great advice, but that's what I'd try to do.

  • If the 'extra' person data can be got from the database at the same time as the basic information with little or no overhead then you should get it. The overhead of making a separate AJAX call and extra database call is an unnecessary load on your server(s). If the extra data is going to have a large overhead and is not going to be viewed on a regular basis then I would get it in a separate on-demand AJAX call. You have to look at both the frequency that this extra data will be viewed and at the cost of pulling this data all at once and then make your decision. – James Culshaw Jul 25 '16 at 13:28

I've found that developers familiar with ASP .NET Web forms and code-behind simply replace their code-behind with javasctipt and Ajax. They tend to put an Ajax onclick behind the smallest of user controls, which is effectively a server control event handler.

You have to understand what the consequences of making an Ajax call are. For example, if the call is going to result in a call to some WCF/EJB and onto a datastore then that call will span 4 processor boundaries (browser, Web Svr, App Layer, DB). These calls are expensive in terms of the latency involved in preparing the call and marshaling data.

Ajax promotes fine grained remote processing which is actually an anti-pattern according to Martin Fowlers Service Facade. Like anything, Ajax is fine in moderation and in the right place. I don't think that place is in commercial software.

  • 1
    I think that AJAX has its place in commercial software. The overuse of AJAX though I agree doesn't have a place. – James Culshaw Jul 25 '16 at 13:23

The answer is "it depends".

  • Are your ajax requests handled concurrently, or are they serialized? Serialization can occur client-side (logic or browser connection limits), or server-side (e.g. PHP serializes requests if you use sessions, to prevent concurrency issues with session data).
  • What's your typical case and worst case for roundtrip time to the server?

I've known situations where the typical roundtrip time was one second. In that sort of situation you must aggregate requests if they would otherwise become serialized, because each request takes 1 second even if your server responds in 1 millisecond. On the other hand, if the requests are highly concurrent, who cares?


Currently I'm working on an application that uses the ExtJS framework and there is AJAX everywhere. Launching a module of the application and loading a report causes up to 30 AJAX requests.

Once you get used to the idea that AJAX is a normal part of your software development, you just stop counting. AJAX is nothing that has to be limited or avoided.

Just make sure you don't get race conditions when processing the output of one AJAX call depends on the output on the other.


Its too much when it becomes a hindrance to usability, performance, maintenance, or development.

  • 4
    Those 4 are trade-offs. Everything is a hindrance to at least one of those 4 – Raynos Dec 8 '11 at 2:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.