[discussion] using feathers-vuex as a client-side incremental cache

One of the wonderful things about feathers-vuex is that it loads back-end data, keeps them in browser’s memory (vuex states), and updates them via socketio when needed. This makes it a handy tool to do client-side cache so that we don’t need to waste band-width to request the same data again and again.

Here I want to discuss what we should do to make it easier to turn feathers-vuex into an out-of-box client-side incremental cache.

Previously I use raw client-side feathers services to cache data, and use feathers-reactive and vue-rx to let vue components be able to subscribe these data from the client-side feathers services. This approach requires considerable knowledge of rxJS, and not all team members feel comfortable with it.

Another possibility is to use the newly developed feathers-offline-realtime and feathers-offline-publications. Pros: they provide out-of-box data-replica and syncing between client and server, and furthermore, allow easy configuration and optimization of event filtering on the the server side. Cons: 1) they are designed to sync the whole back-end service data or a subset of the data with a given query, so they do not support incremental cache (i.e. querying and caching some records at first, and then run new find\get methods to add more records into the cache later); 2) Still need to write some rxJS code to glue feathers data and vue components.

I have discussed similar topic with @eddyystop on the feathers-offline-realtime project (https://github.com/feathersjs/feathers-authentication-management/issues/8#issuecomment-313148338). Later I realized the realtime strategy, by its nature, is for replication of a given service over a given query, not for incremental caching.

I think feathers-vuex is currently the best way to fulfill a full-functional client-side incremental cache for applications using feathers and vue. It naturally allows incrementally adding new records into the store, and since it uses vuex, no need for rxJS subscriptions.

Based on what we already have, I propose several new APIs for the service module, which can make the caching process easier:

1. a new option in the params object for the get action, which makes the get firstly look for the given id in the vuex state (similar to the get gettter). If the item exists, bypass the remote request and just return the item in the vuex state with a resolved promise; if not, request the item from remote server normally, cache it in the vuex store, and return it (similar to the original get action).

2. a new option in the params object for the update and patch actions, which enables optimistic mutation, i.e., mutating the data in the vuex state first, letting the back-end do the same mutation, and in case of back-end error, restoring the old data to the vuex state. Currently we can write some code to use the copy object to do this job, but it would be nice to include this in the offical API.

3. (not necessary) some volume-control strategies to prevent the unlimited growing of the cache in the vuex store. It would be wonderful to provide some API to let user determine the maximum size of the keyedById object of a certain service module, and use LRU or random strategy to expire some old records in the module when it grows too big. Or we can have an expiration time for all the records in the service module.

What do you guys think of it?

[marshallswain]

This has been released in feathers-vuex@1.2.0

[beeplin]

I have been thinking of the fall-through find for a long time, and then realised that in most cases people just do not need such an intelligent find. When we do get we always are not sure if the item wanted has been cached by a previous find or not; on the contrary when we do find we are probably aware of whether we want to find in cache or from server.

So in my opinion this is not a very commonly required feature, and we can try to dig it further in the future.