Is there any benefit to using `prefetch` if we’re already observing the query we want to prefetch? W...

# apollo-kotlin

[wasyl]

Is there any benefit to using prefetch if we’re already observing the query we want to prefetch? Will we avoid some parsing, for example?

Context: we’re trying to have a separation between observing data from cache and refreshing it. Observers will do:

val observer = apolloClient.query(operation).toBuilder()
    .responseFetcher(ApolloResponseFetchers.CACHE_ONLY)
    .build()
    .toFlow()

and I wonder if there’s preferred refreshing method. One is prefetch:

fun refresh() = apolloClient.prefetch(operation).await()

another is a NETWORK_ONLY request and awaiting first response:

fun refresh() = apolloClient.query(operation).toBuilder()
    .responseFetcher(ApolloResponseFetchers.NETWORK_ONLY)
    .build()
    .toFlow()
    .first()

I also see ApolloQueryWatcher#refetch, but I don’t think it’ll work for us because it doesn’t propagate errors.

Prefetch has some optimisations mentioned in the docs, are they relevant if we have another query observing the cache?

[mbonnin]

Not super familiar with prefetch but I think it will save one model parsing.

[mbonnin]

It should be a bit faster although I would not expect the difference to be huge

[wasyl]

Other than than it should functionally the same, right?

[mbonnin]

Yep

[mbonnin]

If you end up benchmarking this, I'm curious what the difference is. The prefetch code is a bit awkward and not the most tested one so unless there a strong reason to keep it, it might make sense to deprecate it at some point

[wasyl]

I’m not sure if we have any reasonable benchmarking process that could capture something useful but I’ll take a look. We still don’t know if we event want to skip this parsing — if we do, the refresh() wouldn’t fail but observer would. I’m afraid it’d lead to some inconsistencies, and seems like prefetch is more appropriate for fire-and-forget kind of things