0

I am using jQuery, and jQuery Mobile to make a mobile app, if that matters that much.

My question is, is it better practice to perform multiple AJAX calls one way or the other?

For example, having a variable that counts all the ajax calls, and then if that variable maxes out, call the complete function such as:

var count = 0
$.ajax({
    //stuff
}).done({
    count++;
    if(count == 5){
        complete();
    }
});
...

or is it better to run them in a chain like:

$.ajax({
    //stuff
}).done({
    $.ajax({
        //stuff
    }).done({
        $.ajax({
            //stuff
        }).done({
            //do complete stuff
        });
    });
});

The application is that multiple API calls need to be made to gather all the information necessary and then manipulate something afterwards. Is there a difference performance wise and is there a "best practice"?

sharf
  • 2,123
  • 4
  • 24
  • 47

1 Answers1

3

Do what's best for your application. If you have multiple independent sets of data to fetch and you don't rely on data from one set before fetching the other, then by all means request all of them simultaneously. Let the browser worry about throttling them.

Also, don't use your counting method to make sure they all finished. jQuery returns a handy Deferred object with AJAX requests. Untested and simplified, but this should get you started:

$.when (
  $.ajax('/data1'),
  $.ajax('/data2'),
  $.ajax('/data3')
).done(function (data1, data2, data3) {
  console.log(arguments);
});

See also:

Community
  • 1
  • 1
Brad
  • 159,648
  • 54
  • 349
  • 530
  • 1
    beat me to it +1 for $.Deferred – Quince Aug 28 '14 at 20:18
  • I've heard it's better to have one big CSS/JS file rather than breaking them up, due to the limitations of how many files can be loaded at once by your browser. I didn't know if a similar restriction would be applicable here. That doesn't seem to be the case. My application could go either way so it will have to come down to preference then. – sharf Aug 28 '14 at 20:21
  • @sharf That's not the reason people suggest minifying into one. The primary reason for such a suggestion is to cut down on the number of HTTP requests. Each request has overhead with headers and what not, and often requiring a fresh TCP connection for each. If you have the option of returning all of your data in one request, do that then. It's not a matter of preference, it's a matter of what's best for your application. Most folks are going to be hitting nice clean API endpoints and don't have that option. But you could always combine that request server-side. – Brad Aug 28 '14 at 20:23
  • Seems my professor was wrong about that one then. Thanks, I'll accept this as soon as it lets me. – sharf Aug 28 '14 at 20:24
  • @sharf There definitely are limits to what you can load in a browser, but in any reasonable site, it isn't a problem. I definitely have had situations where I load as many as 5,000 resources over HTTP into a single page and it's a non issue (unless I open up my developer tools). – Brad Aug 28 '14 at 20:38
  • I was told that the browser can only make 2 HTTP requests at a time, so if you had 1 large CSS file it would download that and continue to download other things like images instead of clogging it all with separate CSS files. – sharf Aug 28 '14 at 21:05
  • @sharf The browser is capable of making many HTTP requests at the same time, but most browsers will only make two simultaneous requests to the same host. This is generally considered the most efficient method, as the browser won't be hammering the server with requests, and you can take advantage of keep-alive requests where the same TCP connection is reused for subsequent requests. Going forward with SPDY, you get piplining and all that as well. The point is, don't control this yourself. It's up to the browser. Let the browser manage and optimize itself where possible. – Brad Aug 29 '14 at 13:19