Apollo Client InMemoryCache serving stale results under default cache-first policy

Direct Answers

1. Is there a supported TTL for cache‑first queries? No. Apollo Client 3.x does not expose a time‑to‑live or staleness threshold for the cache-first policy. Cached data remains until a mutation writes new data, refetchQueries is called, or the entry is evicted/garbage‑collected.

2. How do refetchQueries, cache eviction, and pollInterval compare for keeping server‑side data fresh? Each has a different trade‑off profile:

• refetchQueries – runs after a mutation, guarantees the affected queries are refreshed, but only covers changes that happen as a direct result of that mutation. It won’t pick up unrelated server updates.
• cache.evict + cache.gc – removes specific cache entries (or a whole type) so the next read triggers a full network fetch. It forces freshness but can be expensive if many entities are evicted.
• pollInterval – attaches a polling interval to a query so it automatically refetches at that cadence. It guarantees up‑to‑date data but increases network traffic and may hit rate limits.

3. Does cache‑first ever revalidate in the background? No. cache-first only falls back to the network on a cache miss. Once a query has a cached result, the client will never trigger a background fetch unless you change the fetch policy or explicitly poll.

Why the Difference Matters

Because Apollo’s cache is purely in‑memory and normalized, it has no notion of “age.” The library deliberately keeps data until it is overwritten or cleared. This design keeps the default policy fast and deterministic but requires developers to add freshness logic when needed.

Practical Steps for Your Use‑Case

Below are concrete actions you can take, grouped by strategy. Pick the one that best fits your data volatility and network constraints.

1. Implement a Manual TTL (if you need time‑based invalidation)

1. Store a timestamp alongside each entity in the cache. For example, add a @client field __cacheTimestamp that you set to Date.now() whenever you write the entity.
2. Write a custom read function in typePolicies that checks the timestamp against the current time. If the age exceeds your threshold, return undefined so Apollo falls back to the network.
3. Example snippet:

4. const client = new ApolloClient({
     cache: new InMemoryCache({
       typePolicies: {
         Query: {
           fields: {
             user: {
               read(existing, { readField }) {
                 const ts = readField('__cacheTimestamp');
                 if (!ts || Date.now() - ts > MAX_AGE_MS) {
                   return undefined; // trigger network
                 }
                 return existing;
               }
             }
           }
         }
       }
     })
   });
   

2. Use refetchQueries After Mutations

1. When performing a mutation that could affect other queries, add refetchQueries: [{ query: OtherQuery }] to the mutation options.
2. This forces a fresh GET for the listed queries immediately after the mutation succeeds.
3. Best suited when you know exactly which queries depend on the mutated data.

3. Evict Specific Cache Entries

1. Identify the entity or type that may become stale.
2. Call client.cache.evict({ id: 'User:123' }) or client.cache.evict({ fieldName: 'users' }) to remove it from the store.
3. Optionally run client.cache.gc() to clean up any dangling references.
4. Next read will trigger a network request.

4. Set pollInterval on Queries

1. When you need continuous freshness, pass pollInterval: 30000 (30 s) to the useQuery hook.
2. The client will automatically refetch the query at that interval, merging results into the cache.
3. Use this sparingly on high‑traffic queries or where rate limits apply.

When to Choose Which Strategy?

• Low server churn, high network cost: Prefer refetchQueries or manual TTL.
• High server churn, acceptable bandwidth: Use pollInterval for the most critical queries.
• Specific entities become stale frequently: Evict those entries after a mutation or on a scheduled job.

Missing Diagnostic Detail

To fine‑tune the recommendation, could you share what “acceptable staleness” looks like for your app? For example, do you need data to be fresh within 5 minutes, or is a 30‑second window acceptable?