Umbrella issue: Cache invalidation & deletion

[sandervanhooft]

Is there a nice and easy way to set a condition to invalidate a cached query against? Think about time-to-live (TTL) or custom conditions.

For example (pseudo-code warning):

query(...).invalidateIf(fiveMinutesHavePassed())
or
query(...).invalidateIf(state.user.hasNewMessages)

forceFetch serves its purpose, but I think the cache invalidation condition should be able to live close to the query(cache) itself. This way I don't need to check manually if there's a forceFetch required when I rerender a container. The query already knows when it's outdated.

[helfer]

@sandervanhooft we don't have cache invalidation right now, but it's a feature we definitely want to implement in the future. See #41 which is sort of related.

[viridia]

I'd also like some way to invalidate the cached version of a query after a mutation, but for a different reason: the server-side query logic is fairly complex (especially with sorting), and trying to patch in the results of the mutation via updateQueries is simply too complicated in this case. However, I don't want to force an immediate refetch because it may be a while before I actually need the results of the query.

An example of this is an issue tracking system with custom filtering and sorting: I don't want to repeat the custom filtering and sorting logic on the client especially since it's all written in mongo query language. And it will often be the case that a bunch of issues will be updated in sequence before I need to re-query the issue database, at which time I don't mind waiting a little bit longer to get the non-optimistic query result. So ideally I would just set a dirty bit on that query and let everything happen automatically after that.

[viridia]

Thinking about this some more: What I'd like to see is something very much like the API for updateQueries:

client.mutate({
    mutation: SomeMutation,
    variables: { some_vars },
    invalidateQueries: {
      queryName: (previousQueryResult, { mutationResult }) => true,
  });
}

The invalidateQueries hook is called with exactly the same arguments as updateQueries, however the return result is a boolean, where true means it should remove the query result from the cache and false means the cache should be unchanged.

This strategy is very flexible, in that it allows the mutation code to decide on a case-by-case basis which queries should be invalidated based on both the previous query result and the result of the mutation.

(Alternatively, you could overload the existing updateQueries to handle this by returning a special sentinel value instead of an updated query result.)

The effect of invalidating a query removes the query results from the cache but does not immediately cause a refetch. Instead, a refetch will occur the next time the query is run.

[sandervanhooft]

@viridia,

Your solution looks interesting. Would it support Promises? In that case I could set a timer Promise which returns true after a specific period of time.

[viridia]

My suggestion would work for your first use case but not the second, which would require a very different approach (and may already be handled in the current framework).

Specifically, what I'm asking for is a way to invalidation the cache in response to a mutation. That's why I suggest that the new feature be part of the mutation API since it's very similar in concept to the existing updateQueries feature.

Your second use case has to do with invalidating the cache after a time interval and is unrelated to mutations. It seems like you might be able to get what you want using Apollo's polling APIs.

[dallonf]

Popping in on this... I'd like to add that I think this is very badly needed. I'm actually surprised it's not baked into the core of the framework. Without the ability to invalidate parts of the cache, it's almost impossible to cache a paginated list.

[scf4]

Also surprised this isn't in the core.

[swernerx]

We also need this. Our current approach is:

• Separate view specific query files which cherry pick data from a large object mySalesConsultation to just return the areas of data which is required for rendering.
• A mutation which starts quite a complex run of our backend infrastructure which tweaks the affected sales consultation (computes schedules etc. in conjunction with other objects).
• As this process is running on a complex distributed cloud infrastructure we are not able to return the new data set with the mutation result immediately.
• We are also not able to use refetchQueries as there is no option to postpone this call by some timeout right now. Our backend team says that it would be far safer to wait to a second before starting querying the cloud infrastructure again.

We are currently doing a manual query with a pretty top-level data structure with forceFetch=true inside a setTimeout after the mutation has been successfully returned. This has a few issues:

• Our query is not able to wildcard refetch every data entry inside our mySalesConsultation. Therefor we have to list all fragments and entries to exactly match our schema.
• We are possibly even force fetch loading data which has not even loaded before.
• We add a lot of pressure to our backend systems as fetching the whole tree under mySalesConsultation involves asking a few different REST services behind our GraphQL backend. That would be okay, if we actually require this data for rendering the current view - but unfortunately we only need a few fields being updated.

That said, together with my colleague I just brainstormed a way which should work for our needs:

1. Invalidate a whole tree of data under a given base path e.g. salesConsulations/salesConsultation@myId/*
2. Re-Query all queries which are visible inside the current view (with a API possibility to define a timeout). As mentioned, fetching everything under the invalidated tree, is not needed - we would definitely benefit from something more fine grained.

The first is actually matching the comment by @viridia - the second is something which could be useful - alternatively this is something the invalidation does automatically.

[swernerx]

@helfer as #41 was closed now... is this issue still on the radar?

[helfer]

@swernerx yes, it's still on the radar! We trying to simplify the core and API before we add more features though, so this won't be in 1.0, but it could very well be in 1.1!

[lucasconstantino]

I'm feeling the need to have a field based invalidation strategy. As all resources are available in a normalized form under state.apollo.data (based on dataId), and going further with the proposal from @viridia, I believe we could reach a field based invalidation system much like the following:

Given this schema:

type Person {
  id: Id!
  name: String!
  relative: Person
}

type Query {
  people: [Person]
}

type Mutation {
  setRelative (person: String!, relative: String!): Person
}

With a data id resolver such as:

const dataIdFromObject = ({ __typename, id }) => __typename + id

With Person type resources with ids 1, 2, and 3 being found at the apollo store as:

Given person 2 is currently the relative person to person 1

{
  apollo: {
    ...
    data: {
      Person1: {
        id: 1,
        name: 'Lucas',
        relative: {
          type: "id"
          id: "Person2"
          generated: false
        }
      },
      Person2: {
        id: 2,
        name: 'John',
        relative: null
      },
      Person3: {
        id: 3,
        name: 'John',
        relative: null
      },
    }
  }
}

And having a query somewhere in system such as:

query Everyone {
  people {
    id
    name
    relative {
      id
      name
    }
  }
}

I could then perform a mutation to change the relative of person 1 to be person 3 and force invalidation as following::

client.mutate({
  mutation: setRelative,
  variables: { person: 1, relative: 3 },
  invalidateFields: (previousQueryResult, { mutationResult }) => {
    return {
      'Person1': {
        'relative': true
      }
    }
  }
)}

Edit: I do understand that updateQueries is a valid method for this use case, but updateQueries is only fit on mutations which result will bring all the data you need to update the queries, which is almost never true.