Skip to content

Author Display Name Changes

When data changes in your database, it's difficult to pinpoint all the different places where that data was being used. FastQL solves this by keeping track of where specific objects appear in your server's responses.

For an example of how this could be useful, let's look at a very simple blog and show how we can refresh every cache that includes a specific author.

Blog Site Setup

For a simple blog site you might display an author's name in many difference places: the homepage, category pages, individual article pages, the author page for that person, etc. Here are some example queries to demonstrate how you might set this up.

Homepage

Query

{
  allArticles {
    id
    title
    slug
    tags
    body
    authors {
      id
      name
    }
  }
}

Article Page

Query

query ArticlePage($slug: String!){
  allArticles(filter: {slug: $slug}) {
    id
    title
    slug
    tags
    body
    author {
      id
      name
    }
  }
}

Update an Author's Name

So now one of the writers for this blog decides to change the name on their profile. If your site has a long tail of pages, and significant traffic, it's going to be challenging to find all the locations that need to be purged from cache.

However, FastQL solves this by allowing for implicit invalidation when performing mutations that update data. Below is an example of a mutation you might run when an author decides to update their name.

Query

mutation UpdateAuthorName($id: ID!, $name: String!) {
  updateAuthor(id: $id, name: $name) {
    id
    __typename
  }
}

Variables

{
  "id": "cjfa87ri3hiy50184jxop6arb",
  "__typename": "author"
}

So now the author's name has changed, and there is potentially hundreds or thousands of stale cache entries instantly. This can be solved by smart invalidation.

Automatic Invalidation

With FastQL any cache entry that has an object with type authors and an id with a value of cjfa87ri3hiy50184jxop6arb in the response will be automatically purged from the cache.

So in this example, without any code changes on your client or in your server, FastQL was able to automatically invalidate any queries that have stale author data.

Warning

This will invalidate all places where an author with this ID is in the result, regardless of whether the name field is in the result. So this could lead to unnecessary cache purges if you are often updating a field on an object that never appears in the UI of your app.

Manual Invalidation

If your mutation isn't being sent through FastQL, or you've disabled automatic invalidation, you can also manually trigger this invalidation by passing the type and id to the invalidate object API endpoint.