Is there a way to make a query load from the cache, then perform a network request, then continue to...

# apollo-kotlin

[Nick]

Is there a way to make a query load from the cache, then perform a network request, then continue to monitor the cache for changes?

[mbonnin]

I don't think so. The main reason is that CacheAndNetwork emits 2 items so it's not included in the possible FetchPolicy

[mbonnin]

You can use a combination of

fetchPolicy(CacheOnly).refetchPolicy(NetworkFirst)

But that will trigger a network request on each watched item

[mbonnin]

What I'd do is use a CacheOnly watcher and run a NetworkOnly query out of the band to update the watcher if needed

[Nick]

perf, thanks!

[Nick]

Is there any good documentation anywhere about what refetch is?

[mbonnin]

I'm writing it as we speak 😅

[mbonnin]

Haven't reached the "refetch" part yet though

[mbonnin]

refetch is what happens when a cache change has been seen by a watcher

[Nick]

heh. I don’t understand why one would set a refetch policy of network when the cache is updated. I clearly don’t understand anything about it. Don’t worry about explaining it now, i just wanna learn about it.

[mbonnin]

TBH, I'm not sure why would anyone use anything else than CacheOnly on refetchPolicy()

[mbonnin]

It's been there forever. Let me see if I can dig some insight about why it's there

[Nick]

ok 👍

[Nick]

would performing a query in the onStart be the best spot you think?

apollo.query(ProjectMediaNotesQuery(projectId))
            .fetchPolicy(FetchPolicy.CacheOnly)
            .watch()
            .onStart {
                apollo.query(ProjectMediaNotesQuery(projectId))
                    .fetchPolicy(FetchPolicy.NetworkOnly)
                    .execute()
            }

[mbonnin]

That will block your first item until the network reequest has executed so I think this is the same as a NetworkFirst watcher

[Nick]

ahh ok

[mbonnin]

I think you need to launch {} somehow, not sure you can do this 100% using suspend

[mbonnin]

Wait, why don't you do things sequentially?

// Get from the cache
apollo.query(myQuery).fetchPolicy(CacheOnly).execute()
// Update from network and watch
apollo.query(myQuery).fetchPolicy(NetworkFirst).watch().collect {
}

[Nick]

ohhh yeahh! perfect.

[mbonnin]

That could be wrapped in one big Flow if needed:

fun <D : Query.Data> ApolloQueryCall<D>.watchCacheAndNetwork(): Flow<ApolloResponse<D>> {
  return flow {
    try {
      emit(copy().fetchPolicy(FetchPolicy.CacheOnly).execute())
    } catch (e: ApolloException) {
    }

    copy().fetchPolicy(FetchPolicy.NetworkOnly).watch().collect { 
      emit(it)
    }
  }
}

[Nick]

heh thats nearly what I was cooking up:

fun <T : Query.Data> Query<T>.autoUpdate(client: ApolloClient) = client.query(this)
        .fetchPolicy(FetchPolicy.NetworkFirst)
        .watch()
        .onStart {
            emit(client.query(this@autoUpdate).fetchPolicy(FetchPolicy.CacheOnly).execute())
        }

[Nick]

oh but if there’s nothing in the cache it’ll throw an exception huh

[mbonnin]

Not in my "Flow" version above. The initial exception is ignored

[Nick]

ok

[mbonnin]

Because the contract is that watchers never throw

[Nick]

ahhhh gotcha, ok

[mbonnin]

They just live forever

[mbonnin]

Until their scope dies ...

[Nick]

👍

[wasyl]

Late to the party, but

TBH, I’m not sure why would anyone use anything else than CacheOnly on refetchPolicy()

My understanding is that sometimes a query knows it’s outdated and should emit, but there isn’t enough data in the cache to do so. For example, a query Items { items { id, name } } will be observing the cache, and another query query Other { items { id, quantity } } is fetched from the network. If the second query contains new or different items ids, then query Items won’t be able to emit its data, because there are no `name`s in the cache for the new items (but it knows that items have changed). So with a CacheOnly refetch policy, query Items would emit a cache miss. Allowing the query to refetch from network ensures that the data in the app is consistent between different queries, even if they are disjoint like that
*I’m still on Apollo 2 so something might be different in 3

[mbonnin]

That makes complete sense 👍