# Working with Apollo Client Cache: Cache Keys, Invalidation, and Fetch Policies

DevFeed: [Working with Apollo Client Cache: Cache Keys, Invalidation, and Fetch Policies](<https://devfeed.tech/articles/tips-and-tricks-for-working-with-apollo-cache-19125.md>)

Original publisher: [Read original article](<https://medium.com/rbi-tech/tips-and-tricks-for-working-with-apollo-cache-3b5a757f10a0?source=rss----904782439303---4>)

Author: Tommy Suwunrut

Published: 2020-10-29T19:16:34Z

Content type: tutorial

Language: en

Sources: [RBI Tech](<https://devfeed.tech/sources/rbi-tech.md>)

Topics: [apollo-client](<https://devfeed.tech/topics/apollo-client.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [GraphQL](<https://devfeed.tech/topics/graphql.md>), [Front end](<https://devfeed.tech/topics/frontend.md>)

Tags: [apollo](<https://devfeed.tech/tags/apollo.md>), [apollo-client](<https://devfeed.tech/tags/apollo-client.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [cache](<https://devfeed.tech/tags/cache.md>), [cache-invalidation](<https://devfeed.tech/tags/cache-invalidation.md>), [caching](<https://devfeed.tech/tags/caching.md>), [fetch](<https://devfeed.tech/tags/fetch.md>), [frontend](<https://devfeed.tech/tags/frontend.md>), [graphql](<https://devfeed.tech/tags/graphql.md>), [programming](<https://devfeed.tech/tags/programming.md>), [react](<https://devfeed.tech/tags/react.md>)

## AI overview

This tutorial explains how Apollo Client normalizes and stores GraphQL query results, including cache keys based on object properties and schema types. It discusses why collection queries may remain stale after server-side updates and introduces fetch policies as one way to manage cache behavior.

## Source excerpt

Photo by Stephen Walker on Unsplash With its declarative fetching, helpful tooling, extensive type definitions, and built-in integration with React, Apollo Client has played a fundamental role in simplifying frontend architecture over the past few years. Its built-in caching layer, which allows you to retrieve previously requested data without needing to make additional network requests to the server, has the potential to make any application feel snappier. Apollo even provides ways of warming up the cache to be used for later, freeing our frontends from the dreaded loading spinners. But cache invalidation is one of those notoriously difficult problems in any computer program, and trying to update or bust Apollo's cache after server-side updates is far from a perfect experience, especially when the queries being cached have many filters and constraints. Let's begin with an overview of how Apollo's cache works, and then discuss the tradeoffs involved with a few different approaches to working with it. Throughout this article we'll be using this Mock List application as a reference. Cache Keys When you make any graphQL query, by default Apollo caches the response in what it calls a flat, normalized lookup table. It constructs a unique identifier for each object returned from your query, by combining its id or _id properties with the __typename defined in your schema. So if the application above executes queries as the user types "G", then "Go", then "Go g", all the way to "Go groceries shopping", Apollo could potentially pull down information about many different tasks and cache each one roughly like this: Task:1234: { name: "Go grocery shopping" } Task:2345: { name: "Go to gym" } Task:3456: { name: "Learn GoLang" } This is great if the user navigates to a detail view about a given task, because there will already be some data immediately available. Apollo will also store the results of each of those individual queries, in case you make the same exact query again late