Apollo Cache is Your Friend, If You Get To Know It

Summary

Shopify’s migration from Apollo GraphQL client 2 to client 3 prompted a closer examination of the Apollo InMemoryCache after past bugs were linked to misunderstanding or misuse. The cache stores an in-memory representation of queried data for the current browser session, and its lifecycle covers fetching, normalization, updating and merging, then garbage collection and eviction. Fetch policies determine whether data comes from the cache, the network, or both; under the default cache-first policy, incomplete data triggers a network request. Normalization breaks responses into objects, assigns cache identifiers usually from __typename and id or configured key fields, and stores them in a flattened structure. Automatic UI updates depend on matching identifiers and suitable query or mutation responses, while objects made unreachable by changed identifiers can remain until garbage collection removes them.

Takeaways

1. 1

   With the default cache-first policy, Apollo returns cached data when all requested data is present; otherwise it queries the network, saves the response in the cache, and returns it.

2. 2

   Normalization assigns cache identifiers normally from __typename and id, while the keyfields API supports other stable, reproducible field combinations for objects without suitable id fields.

3. 3

   Automatic UI updates require incoming data to match cached identifiers and include the relevant fields; objects with replaced identifiers can become unreachable and later be removed by garbage collection.