Skip to content

Fragment caching on fields used in Union #131

Open
@tomdev

Description

@tomdev

Hey Dimitri,

I'm looking for some guidance. Currently I'm implementing the fragment cache in a rather large codebase. It's working well for most of our not so complex queries, but for queries using a Union we're (obviously) running into the Lookahead error.

I've been looking for ways to solve this without changing the cache key lookup implementation, but no luck so far.

A little context on the codebase and issue:

  • We have thousands of GraphQL fields
  • Some of these fields could be used in a Union
  • It's not manageable to set up a "path_cache_key" and "query_cache_key" on all of them to prevent the lookahead error

I've considered two options:

  • Dynamically adding a "path_cache_key" and "query_cache_key" to the fields that require this to work. However, in the GraphQL Field class where I can add this I don't have the context on wether or not this field is used from within a Union. So I cannot determine this. I don't believe the object is already accessible here, so the ID also can't be used to create a unique "path_cache_key".
  • Disabling caching on fields that hit a lookup error. I wasn't able to do this, with the same reason as above. Also, the error is being hit in the CacheKeyBuilder class, and I don't think that's the right layer to be bumping out of the "should we cache or not" behaviour.

It's been a couple of years since the Lookahead#selects? not matching fragment/type fields discussion and Add union support PR. Are you aware of any things that might have changed in this time that would make it easier to find a solution for the lookahead problem?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions