https://kotlinlang.org logo
#apollo-kotlin
Title
# apollo-kotlin
w

wasyl

06/21/2022, 12:21 PM
Quick question that I haven’t thought out yet but I’m wondering if you have: we’re using Apollo’s cache to keep single source of truth for majority of the data in the app. This works very well, but sometimes we have data that we’d very much like to always have available. We would fetch it when the user logs in and then the app could operate under assumption that observing the query will emit cached value immediately. This works until we update the query and start fetching a new field for example. Now, Apollo can’t emit any value, so it emits
null
and refetches the query. Have you ever thought about some way to do migrations for the cached state of the queries, such that the app can continue working while offline? Such migrations could compute the default values or insert empty/null objects that the query will use for the time being, until it’s refetched
m

mbonnin

06/21/2022, 12:24 PM
I think what we'd want to do there is the cache to return partial results and a list of errors (similar to what a real server would do)
Then the UI can decide to display a default state or if it can't, display an error message
w

wasyl

06/21/2022, 12:25 PM
Having such partial results would imply each field from the query would be nullable, right?
m

mbonnin

06/21/2022, 12:27 PM
Mmmm right
If not it "bubbles" up and you start losing data
We could have an
@optional
directive that is the opposite of
@nonnull
for these cases
blob thinking upside down 1
Another option would be to leverage the
CacheResolver
API. You can technically add code there to "recover" from a cache miss
w

wasyl

06/21/2022, 12:37 PM
I realize any API would have to be carefully thought out, to be convenient to use but not overly complex. Anyway just wanted to throw the idea, I’m not even sure how specific to our use case it is
👍 1
m

mbonnin

06/21/2022, 12:37 PM
Yea, the
CacheResolver
API is complex...
3 Views