Imagine a page with an autocomplete textbox on it, to get Customer.
I am wondering what sort of limit for record size makes sense in this day and age regarding whether all the customers should be pulled down on page load, vs. using ajax to dynamically query them as the user types.
For example, if it were every customer in the entire system and you have 10,000 customers, pulling down 10,000 key/value pairs (name, customerId) is quite a lot just to do an autocomplete.
However within most systems I am working on there are more ambiguous cases, whereby you might be getting Employees for a particular store, and there are 20, 30, 40, employees etc. at which point using ajax to send the first 2 characters of your autocomplete onwards as they type might be unnecessary overhead versus the trivial task of just grabbing all 20 keyvaluepairs (and doing client-size autocomplete).
I am not really sure where to draw the line. Pulling 20 records in at once creates a faster, more responsive UI, both because there are no waits for ajax calls and because it's unnecessary to add the standard autocomplete delay in (the delay that prevents hammering the server with 30 requests when typing each letter in a name like Fitzgerald McFistyCuffs by waiting until you're done typing before sending the ajax request). It's also much faster to write the code in a system which just has page after page of generic CRUD forms/tables/submit buttons because you don't have to wire up ajax, implement server side paging, etc.
But what about 30, or 40, etc.?
Likewise, with grids of data, we can pull in 20 complete records (not just keyvaluepair) rather than implement ajax pagination, but at what point does it become prohibitive?
I think it's purely a question of bandwidth, rather than UI lag or memory, so what's a reasonable amount of data to send to a webpage upon loading? Is there a 'rule of thumb'?