I have a Flex-based client app which "talks" to the back-end through BlazeDS. In one of my use cases there will be a so called "Photo Wall" view, which will present a number of the most recent photos, submitted from people and for locations the user is following (Facebook-like).
The thing is, the data in this photo wall has to be filtered by "All", meaning no filter, "Friends", meaning friends that the user is following, and "Locations", meaning locations the user is following.
The following three approaches are buzzing my head
If I get data from the server only once (when the ALL filter is selected by default), I will store it locally, and the next time a user clicks on a filter, this local collection will be filtered locally. The problem is that I can't predict how many of all recent photos are coming from friends, and how many from locations, thus I may end up with a page that shows only one photo, where a minimum of 5 photos should always be present. I clearly don't want to deal with partial fetching and stuff like that.
The other way is making two separate requests to the server initially, one to get a collection of recent photos from friends, and one for locations. Thus I will make sure I have the bare minimum of photos for the filtered pages. When data arrives, the client will merge those two collections, sort by date, and voila there is the "ALL" collection (of course, repeating photos will have to be pruned while merging)
Third, making this same thing down at the server level, by making two separate queries and then merging them.
This is a common situation, I know, but still, i have to deal with it somehow. In general, please suggest good server-agnostic strategies for data fetching.
In my opinion the best way is to think about your application in terms of data driven design. You definitely should have 3 queries to get all photos, friends photos and location photos with corresponding paging. From the client-server interaction point of view it is not so expensive to pass the same domain object with image description twice or triple. Just keeping in mind AMF is compact binary format. And you can rely on browser cache for images or even can cache bitmap data on a client side if needed.
From the server point of view you'll have 3 service methods with 3 queries to DB. And there is no need to combine ALL images on a server using two other queries. Getting all records from DB will be much more cheaper than two queries with additional criteria and then combining them in Java code.
And finally it will make you application more simple and testable (both on client and server side).
So finally 3 independent queries and 3 service methods on a server side to get lists by client.