0

I'm building a report for an end user. They would like to see a list of all widgets... but then also like to see widgets with missing attributes, like missing names, or missing size.

So i was thinking of creating one method that returns json data containing all widgets... and then using javascript to let them filter the data for missing data, instead of requerying the database.

Ultimately, they need to be able to save all "reports" (filtered versions of data) inside a csv file.

These are the two options I'm mulling over:

Design 1

Create 3 separate methods in my controller/model like:

get_all_data()
get_records_with_missing_names()
get_records_with_missing_size()

And then when these methods are called, I would display the data on screen and give them a button to save to csv file.

Design 2

Create one method called get_all_data() and then somehow, give them tools in the view to filter the json data using tables etc... and then letting them save subsets of the data.
The reality is, in order to display all data, I still need to massage the data, and therefore, I know which records are missing attributes. So i'd rather not create separate methods by each filter.

I'm not sure how I would do that just yet but at this point, i would like to know some pros/cons of each method.

Thanks.

3
  • 7
    "Well, then," Jesus said, "give to Server what belongs to Server, and give to the Client what belongs to the Client."
    – Hackerman
    Jan 22, 2014 at 18:30
  • @RobertRozas What does that even mean? lol. Sorry... i don't understand what you're getting at. You can do it both ways.
    – dot
    Jan 22, 2014 at 18:35
  • How many data are we talking, because if you are returning all the data on a json and the data returned is about 100-1000 the performance of your point of view is good....for more data it's not that good, unless you are a turtle xD
    – Hackerman
    Jan 22, 2014 at 18:43

1 Answer 1

0

Assuming your using Angular.JS, jQuery or similar, I would recommend loading all the data from the server at once, then writing controllers that are able to filter between the different types of lists.

This solution allows for the least amount of load on your server and makes the client do most of the work. This along with the idea of having an application whose lag depends on the local machines filtering (local processing = fast) is much better that having an application that can lag due to network instabilities (network = slow).

That being said, if it is a massive amount of data (> 1 million records), migrating the logic from the client to the server may become reasonable. At this point the local processing may/can take longer that it would be to request the data from the server.

4
  • yeah... that's what i was thinking too. I'm going to be using jquery. We're talking about 200,000 records or so as the upper limit and 1000 as lower limit
    – dot
    Jan 22, 2014 at 19:14
  • That is getting toward the cap for client processing. What I would recommend is mocking up a client side example and try some performance testing to determine if you should perform the logic on the server or not. Personally, I prefer to use client side logic and just have my servers respond with data-chunks. But in the end, the decision is yours.
    – bign8
    Jan 22, 2014 at 19:20
  • That's what i'm talking about...and if you use the right stored procedures to produce a decent pagination, your app should works like a charm
    – Hackerman
    Jan 22, 2014 at 19:23
  • 3
    Yes Robert, but you are still subject to network (which for 200,000 records could be a bit) lag by off-loading all your processing to a server. Both cases work, it is just a developer's preference which one he/she chooses.
    – bign8
    Jan 22, 2014 at 19:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.