Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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:


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.


share|improve this question
"Well, then," Jesus said, "give to Server what belongs to Server, and give to the Client what belongs to the Client." – Hackerman Jan 22 '14 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 '14 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 '14 at 18:43

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.

share|improve this answer
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 '14 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 '14 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 '14 at 19:23
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 '14 at 19:28

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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