Skip to content

Formalize frontend caching strategy for ALL queries and mutations #875

@Parkreiner

Description

@Parkreiner

This is something that's already caused pain points for us, and it feels like adding the logic for Secrets gives us a good opportunity to revisit what we have right now.

Context

The entire frontend relies on React Query to handle all data-caching. We started using React Query seriously towards the end of 2023 (replacing XState), but in the time since, we haven't really been deliberate with how we use it.

The way React Query works is that it lets you define a bunch of buckets of state for storing cache results, while associating each bucket with a query key. These query keys are array values, and RQ will actually group buckets by each query key segment. That is, all queries that have a first value of "workspaces" will be in a bucket, and that bucket will get split up more and more for each segment of the query key. React Query supports a number of features that let you invalidate and manipulate these buckets – if you invalidate by the array ["workspaces"], that will invalidate all queries that have "workspaces" as the first segment. Similarly, RQ has tools for sharing query data between buckets – for example, if you query all workspaces, and then two minutes later, query a specific workspace, you can patch the first set of data to use the more fresh workspace

There are just two problems:

  • We're not currently using this data-sharing functionality, meaning that we're at higher risk of mixing fresh and stale data for the same page in the UI
  • We also don't have a consistent approach to defining query keys, meaning that queries that should be grouped up aren't. This makes the group invalidation functionality basically impossible to use, because there's a risk that we'll hit the wrong data.

I propose that we update how all of our query keys and objects are defined, so that we can start taking advantage of these features.

Requirements

  • Update all existing query object/key logic to be more predictable
  • Update the frontend contributing guide to reflect these changes

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions