Timeline for Web-app filtering information client-side vs server-side?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 16, 2016 at 8:24 | comment | added | l0b0 | @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. | |
| Nov 16, 2016 at 6:21 | comment | added | 4 Leave Cover | 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? | |
| Jul 15, 2014 at 16:20 | vote | accept | fbynite | ||
| Jul 15, 2014 at 16:20 | comment | added | fbynite | 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. | |
| Jul 15, 2014 at 9:33 | history | answered | l0b0 | CC BY-SA 3.0 |