In this post we’ll compare rich GraphQL clients that come with a normalized cache implementation and the generated WunderGraph clients that rely on HTTP caching.

As you might have already found out, WunderGraph uses persisted queries by default. With the WunderGraph code generator WunderGen you can generate a client that knows exactly how to invoke your previously registered operations. With the @cache directive you’re able to configure that the response of an operation should be cached by the server & client. Cache Control headers will be set accordingly, including etags. This mechanism is fully compatible with all major browsers and CDN’s who implement caching according to the  HTTP Caching RFC.

To illustrate this a bit better I’d like to introduce two example queries. The first one fetches a list of friends. The second one fetches some details about those friends.

Let’s consider we want to show a list of friends:

query Friends {
    friends {
        id
        name
        age
        avatarURL
    }
}

For each friend we’d like to be able to click on the friend in the list and open up a detail page:

query FriendByID {
    friend(id: 123) {
        id
        name
        age
        avatarURL
    }
}

You will recognize that we already have all the data for the detail page. So in an ideal scenario the client won’t have to make another request. This is possible thanks to cache normalization.

A smart normalized cache will identify the Friend entity and will recognize that the “FriendByID” query can be fulfilled using the data from the “Friends” query which we already ran.

What are the pros of this concept?

• Navigating to a friend detail page will be instant because there is no network request required
• The client will save bandwidth, and the user experience will be more fluent
• If we navigate back we can also immediately pull out the list of friends from the normalized cache

#graphql