Im using apollo-kotlin in a middleware application to talk to some other services.
One of these services has a huge schema where I am interested in different entities. I would like to be able to control the expiration per entity type and with that
being able to refresh the data in the cache independently of the APIs use. I would also like to be able to clear the cache programmatically.
How well does these requirements fit with apollo-kotlin today? It seems I have to create a separate client and cache for each of my entities and that doesnt
feel like the correct way to do this. Is my use cases too complicated for the normalized cache?
This is not possible at the moment although it has been requested before. You can follow this issue for a related (albeit not exactly similar) question.
clear the cache programmatically
You can clear the whole cache as a whole with apolloStore.clearAll(). For manual per-entry eviction, you can follow this issue.
control the expiration per entity type
Back to this, would you like the expiration to be “client-controlled” or should the rules be updatable by the backend?
being able to refresh the data in the cache independently of the APIs use
I’m not sure I follow that part. GraphQL is typically only one API. Or do you mean depending the object type?
Overall, having separate caches is most likely not what we’re aiming for because that would remove some of the de-duplication and single source of truth that’s interesting in the normalized cache. Do you mind telling us a bit more about your use case? More caching APIs is the next item on the ROADMAP so we could make sure it is supported correctly.
Back to this, would you like the expiration to be “client-controlled” or should the rules be updatable by the backend?
This expiration should be client controlled the way Im thinking.
being able to refresh the data in the cache independently of the APIs use
I’m not sure I follow that part. GraphQL is typically only one API. Or do you mean depending the object type?
Overall, having separate caches is most likely not what we’re aiming for because that would remove some of the de-duplication and single source of truth that’s interesting in the normalized cache. Do you mind telling us a bit more about your use case? More caching APIs is the next item on the ROADMAP so we could make sure it is supported correctly.
Yes, depending on the object type. I dont really wany different cache instances if it can be avoided but rather flexibilty based on the type im querying. The single source of truth is important.
The normalized cache mode allows for retrieving data as well as returning the cached value (FetchPolicy.CacheAndNetwork). Im thinking it would be nice to also have the possibility of having some kind of timed “refresh” of the cached values so that the cache is always up-to-date. Im asking about this because I cannot use the async nature of apollo in my application without rewriting a lot of code.
Edit: I need to control this in my client as I have no control over the API im talking to. However I have requirements on how the up-to-date my data has to be so it is acceptable to say “refresh cache every 2 hours” or something like that. I hope im making sense here
!