Caching & Performance

Component & GraphQL Response Caching

The AEM CIF Core Components already have built-in support for caching GraphQL responses for individual components. This feature can be used to reduce the number of GraphQL backend calls by a large factor. An effective caching can be achieved especially for repeating queries like retrieving the category tree for a navigation component or fetching all the available aggregations/facets values displayed on the product search and category pages.

For the AEM CIF Core Components, caching is configured on a component basis, so it is possible to control if (and how long) GraphQL requests/responses are being cached for each component. It is also possible to define the caching behavior for OSGi services using the GraphQL client.

Configuration

Once configured for a given component, the cache starts storing GraphQL queries and responses as defined by each cache configuration entry. The size of the cache and the caching duration of each entry is to be defined on a project basis, depending for example, on how often the catalog data might change, how critical it is that a component always displays the latest possible data, and so on. Note that there is not any cache invalidation, so be careful when setting the cache durations.

When configuring caching for components, the cache name must be the name of the proxy components that you define in your project.

Before the client sends a GraphQL request, it checks if that exact same GraphQL request is already cached and possibly returns the cached response. To match, the GraphQL request MUST exactly match, that is, the query, operation name (if any), variables (if any) MUST all be equal to the cached request, and also all custom HTTP headers that might be set MUST also be the same. For example, the Adobe Commerce Store header MUST match.