Surely most of you remember the Norton Commander application where similar (sometimes the same) data is displayed in separate decoupled views.
I'm building a web application that follows the same principle. The amount of data is too big to be fetched/displayed entirely on the page, and potentially overlapping subsets of data need to be displayed in separate views.
My architecture looks like this:
┌──────── EventBus ────────┐ │ │ │ │ StorageService │ │ ╱ ╲ │ PresenterLeft┤ ├PresenterRight ╱ ╲ ╲ ╱ ╱ ╲ ViewLeft ModelLeft ModelRight ViewRight
The application creates both presenters and passes them the instance of EventBus and StorageService. The presenters, in their turn, create their respective models and views. The StorageService is passed down to models. The communication between presenters is done via the EventBus.
In this scenario the left side has no awareness of the right side, yet models should possess the same information without a need to do a double round trip to the server.
To achieve this I use the StorageService. Models implement the model.fetch()
method which asks the storage for data. If the same data was previously requested, the storage will simply return it acting like an in-memory cache.
Here comes the actual question. In the above context, how to design a data structure for a network-wise efficient storage service for the following use case:
- Left model requests
GET /files?limit=100
- Right model requests
GET /files?limit=110
(but actually I only need the last 10)
My attempted approach was:
- store the requests made by models
- for every additional request, do my best to figure out the request diff
- do the diff request (e.g.
GET /files?offset=100&limit=10
) - store the fetched items under
{"files": {"id1": item1, ..., "id110": item110}}
Unfortunately the above steps don't help, because there's no relation between the url and the ids. When a model requests the next set of values, I never know if they are actually in the in-memory cache.
Of course, I could use the per-url in-memory caching strategy, but then I would have duplicate entries in the cache, which is something I'd like to avoid.
What are your thoughts? I feel like I'm reinventing the wheel here. Is there a better/simpler/commonly-accepted method? Perhaps my architecture is flawed...