Coloquent
Coloquent copied to clipboard
DavidDuwaer
Caching and polling support
In the projects tab of this repository there is something about caching and polling support. I will need this functionality so I will develop.
I had a doubt, in the activity you do not specify what to do with the filters. For example, calling the route http: //api.example/users will result in the response being cached.
But what if a new request is made later to the same endpoint but with some filter, for example http: //api.example/users?filter[a]=aaa, or even some sort, what should be the behavior? Will filtering and sorting be done offline based on cached data or will a new request be made?
Ah nice 🙂, you're touching on a core aspect immediately.
The answer is: both.
Say we have this cached users data, and a query with filter[a]=aaa is performed, then this query is answered twice: first with the result from the cache, and then with the result from the server. We never know if on the server side the data has changed, so we will never only fulfill a query from the cache; it will always be the conjunction of cache response first and backend response after.
One use case you can also imagine, is that if a query filter[a]=aaa is subscribed, and another query deletes a user with a=aaa, that the corresponding record can be deleted from cache immediately. Deletes like that should then trigger the re-evaluation of all "subscription" queries, so that they automatically and immediately re-emit a result calculated from the changed cache. Similar for creation and update queries.
Good!
And which storage engine do you recommend using? WEB Sql, localStorage or something else?
I have no recommendation there, but we'd be free to choose and on the safe side if we write a wrapper for the storage that has a non-blocking (Promise based) API.
Probably you already thought of this but I'm just putting it out here for clarity's sake, that writes are always persisted to persistent storage as they happen, but reading from persistence storage should only happen on startup, loading all data in an in-memory storage layer. The queries then all read only from the in-memory storage tier. This so that references entities/models from different queries have to eachother could stay intact. Anyway, that would be if our "cache" becomes a single, normalized graph of mutable models/entities, in which for every unique (model class, model ID) there is only one instanceof the corresponding model, but maybe it's a bit of a moonshot for a first iteration, and just caching per-query will be useful enough. I'll leave that design choice up to you.
One other point, does your use case require a persistent storage? Because it could potentially be easier for a first iteration to depend only on in-memory storage, allowing you to focus on the core problems.
I need to store the data somewhere in the browser because my use case is to build an offline application (including POST, PUT and DELETE requests, which should be stored in a processing queue until a connection is made).
I already have it implemented in a company internal http library, but now I'm migrating to Coloquent because it has a much better interface.
I could just internally develop and couple the code together with coloquent without having to change the plugin at all, but as you have a project to implement this functionality I decided to try developing it via pull request.
Maybe I can develop only the in-memory cache part in coloquent and leave the rest internally in my internal application.
By all means; if you already have the persistence in code somewhere then there's no reason to leave it out here. I'm looking forward to see your PR!