We are continuously trying to improve the caching experience and for that, we have started looking into invalidation. We have looked into the most common times someone needs to manually invalidate their cached data, we came to some conclusions:

We can’t do much about the second one but we, however, can work on the first one, looking at where this pain point lies we soon find out that it relates to lists, this is why we want to create something called the mutation-policy which initially will have two modes:

We think that the Type policy will introduce an easier way to onboard and avoid the custom logic initially.

mutation {
  updateTodo {
    id ## 1
    __typename ## Todo
  }
}

The policy Type would invalidate all responses containing a Todo type, while the Entity would only invalidate the Todo with an identifier value of 1.

There is a third option called List + Entity which would be a combination of Entity + purging all cached data that contains a list of the Type this, however, can get a bit difficult considering the different ways people paginate, we could by default account for the Relay Pagination spec for instance.

When considering the above example this policy would invalidate all lists containing the Todo type and the Todo with an identifier value of 1.

The most important question to push the last one forward is what kind of pagination spec are you using, for the Relay spec we would dive into the object when we see a type that ends with Edge, and otherwise we would explore the array and get the __typename from there.

In the config, it would look something like

name: my-app
schema: <https://end.point>
originUrl: <https://end.point>
passThroughOnly: false
injectHeaders: false
mutationPolicy: Type | List | Entity

Questions

We want to hear from you: