MobileNativeFoundation
[Feature Request] Ability to add an TTL for Source of truth
I enjoy a lot Store 4 library I actually wrote an article in early 2021. I mentioned a feature I see as an improvement for the library.
Is your feature request related to a problem? Please describe.
Lets consider that following code :
store.stream(StoreRequest.cached(key = _key, refresh = false))
stream function in this situation, searches for first time data from Source Of Truth, given that it is empty, Fetcher is called to grab data from network that will be stored on Source Of Truth.
The next stream function calls will stick on Source Of Truth without having possibility to refresh with new data, we will always deal with data stored for first time.
Describe the solution you'd like
A solution would be to add a TTL for the Source Of Truth. Hence after a specific duration, we invalidate data to refresh with Fetcher, store it again and so on
Additional context A situation this solution could be relevant is case of mobile apps whose API refresh data(generally data we do not mutate) for some routes every X (minutes, hours). It would be interesting to work locally during TTL and be able to refresh juste after its expiration so that API could have less calls from mobile devices.
I think it's a good idea. However, I have another proposal. In my opinion, the ttl should be defined in the ´StoreRequest´, it's the same idea of a fresh or a cached request. If we do that, it's more flexible, you can define the ttl depending on your use case. In the implementation, the ´Store´ could save a ´Map<Key, Date>´ (key and last fetch time) and then when a new flow is created, we use the ttl to define if the fatcher should be invoked or not.
@digitalbuddha it would be nice to have some feedback here. What do you think about the feature? what do you think about the proposed solutions? If you think that it's a good idea, do you have an estimate?
My biggest concern about it is how store will persist the ttls. Currently we don't have our own persistence. I guess we can have a new source of truth type that has the map key/value api. That opens us up to uncertainty around how and for how long the user will store these values.
To be honest I don't think store is the right place for this ttl. I think the underlying source of truth should maintain this logic. For instance if using a room database you can maintain it as an extra column per entity and short circuit when ever you want.
I'm having trouble generalizing this solution but instead want to propose adding a tag to store requests. Tags would be a single field (any type) which then get passed to all source of truth and fetcher delegates. This could then be used as the ttl functionality for you while being used as something like an additional key for others. This way we allow you as the user to control your ttl impl(read issues).
Thoughts?
In my opinion, Store shouldn't persist the TTL. Store is a library that handles different sources and returns a simple response.
But the TTL may not be related to the source itself, it can be related to the request. As you may request fresh data using Store.fresh(key: Key), you could request data after a date or data that was requested before a duration. That's why from my point of view, the TTL should be part of the source. In my opinion, TTL could be not the best name for the attribute, because TTL is appropriated to the source, but I'm not sure if it's appropriated for a request.
The sintaxis could be something like StoreRequest.cached(key = key, maxTime = Duration.minutes(1))
Gave this more thought, we currently have a TTL on an in memory cache but not one on the request/source of truth. I'm open to accepting a PR adding a maxSOTAge to StoreRequest which then hooks into a new delegate in SourceOfTruth
fun ageOf(request:Key) Duration
When `maxSOTAge < fn(ageOf(key)) we skip source of truth.
I won't have time to work on this myself but happy to discuss/accept a pr if someone else wants to take it on