4

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?

7

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.

  • All great points. I'm currently handling the filtering on the server, mostly for issue 1. Issues 2-5 are seem to be solid reasons to keep filtering on the server as well. Thanks. – fbynite Jul 15 '14 at 16:20
  • I have a suggestion, user will query the data at a point of time. Your website can check for updates (e.g. last_updated_date or row count or any pattern that suits your DB design) then display a div section saying there are updates available to the records. Then it is up to user to decide whether to run the latest query or not. Also if the div section is displaying, stop querying database for latest records. This might actually reduce more bandwidth to DB. What do you think? – 4 Leave Cover Nov 16 '16 at 6:21
  • @4LeaveCover that should probably be another question, but: From a user perspective I suspect they will be annoyed that your interface doesn't refresh the data seamlessly. This can be done relatively easily with event-driven architectures using for example socket.io. The client establishes a permanent connection using web sockets (modern browsers support it) and is sent every new piece of data as it arrives. – l0b0 Nov 16 '16 at 8:24

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.