Web-app filtering information client-side vs server-side?

Question

I have a web-app that provides data (that is updated on an interval) for intranet users, who are able to filter information by location.

I was having a discussion with a co-worker about whether that filtering should take place on the client vs server side. The amount of information isn't large, but the users are typically interested in a certain location.

My question..Is it preferable to let the database filter the data and send the results to the client, or return all data back to the client and then sort by location? If it's not clear cut, when would you choose on method over the other?

Answer 1

Some client side filtering issues:

1. Cache invalidation. Server side filtering will always operate on up-to-date data, while client caches will have to be updated when data changes. This may be very complex depending on which correctness guarantees you want to have. The future developer will curse this solution. If it doesn't work properly the customers will curse this solution.
2. Query language. Your server already supports SQL out of the box (assumed because of the "sql" tag), and it is very different from JSON + JavaScript, the most obvious candidate for a client side querying solution. There might be a sufficiently generic client side data structure + querying solution out there that you can slap it onto the web site with barely any effort, but the alternative is invariably going to result in more (and more complex) code than using server side querying. The future developer will curse this solution.
3. Code change propagation. Many web sites have fallen into a trap with client side code where a refresh of the page does not download the latest code. Users then will likely not be able to query until they clear the browser cache. The customers will curse this solution.
4. Network transfer size. You may have a small database right now, but transferring all of it to every client on a regular basis is going to be quite slow and costly in the long run. The sysadmin will curse this solution. Any customers on slow connections will curse this solution.
5. CPU/battery use. JavaScript uses more CPU (and therefore battery) than plain text. And no, you will not have the resources to optimise the code. Customers with laptops and slow machines will curse this solution.

If your database really is small, and you create a server side filtering solution which is anywhere near sane, the filter round-trip time should be in the low milliseconds. This is fast enough that nobody will notice, and you avoid a whole lot of extra complexity and possible grief.