What sort of data limit would make sense for pulling down all data vs autocomplete/pagination via ajax?

Question

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'?

Answer 1

As you write in your question;
This is a question of profiling, assuming assumptions about the environment that your system run at, assuming assumptions about how the user interacts etc.

Anyway, you'll find some tipping point in your research such as X records (given network conditions, application protocol, browser assumptions, serialized object size, the average size of a single record etc).

It's a good solution for now and for your current use case apparently. However, my suggestion for you is to implement it as simple as possible - and providing a limited plan B option in case that some of your assumptions prove wrong. (For instance, in case of an error send the naive page with the simple ajax code - make sure you log such an event and keep track of it).

In case that your assumptions become unrealistic to your system after some time (limited bandwidth clients start using it, you don't have X records per store but 1000X records now etc), you should make the effort here for a long standing solution, instead of the previous one (as it assumes a very narrow view of the system).

Good luck.