Caching

Every Component's response may can be cached in order to improve performance. The cache key is the combination of the Component's available configurations.

Consider the following Component response from a CMS:

{
  "records": [
    {
      "id": "01",
      "title": "Article 01",
      "body": "This is the body of article 01",
      "category": "01",
      "tags": [
        "tag01",
        "tag02"
      ]
    },
    {
      "id": "02",
      "title": "Article 02",
      "body": "This is the body of article 02",
      "category": "01",
      "tags": [
        "tag01",
        "tag03"
      ]
    },
    {
      "id": "03",
      "title": "Article 03",
      "body": "This is the body of article 03",
      "category": "02",
      "tags": [
        "tag02",
        "tag03"
      ],
      "frequencyPurchasedWith": [
        "01",
        "02"
      ]
    }
  ]
}

This response may have been returned from a Component that was configured to retrieve a specified list of articles from a CMS or from a query to the CMS based on some critieria.

Cache entries are stored in a cache with a time-to-live value.

At query time, if the component receives the same configuration, the component will fetch the response from the cache instead of making a request to the CMS (while respecting the time-to-live value). If a response was fetched from the cache, the response will contain the cacheInfo property which contain the timestamp at which the cache entry was created.

Each cache entry can be tagged with a list of tags. This allows to invalidate all cache entries with a specific tag. For example, if a Component is used to render a list of articles, the cache entry can be tagged with the articles ids where each tag is an article id. For example, if the cached response, was a list of articles with the ids, 01, 02, 03, the cache entry can be tagged with article01, article02, article03. If either of the articles is updated or removed, the cache entry can be invalidated by any of the articles' ids (i.e. article01 or article02).

Each tag is a string and can be any value. However, it is recommended to use a unique value for each tag. For example, if the Component is used to render a list of articles, you would add one tag per article where each tage is an aericle id. If the Component is used to render a list of articles in a specific category, you could also add a tag that is the category's id. This would allow you to invalidate all cache entries for a specific category as well as all cache entries for a specific article.

Cache Tag Configuration

[
  {
    "prefix": "article",
    "expressionType": "jmespath",
    "valueExpressions": [
      "records[*].id",  // Evaluates to ["01", "02", "03"]
      "records[*].frequencyPurchasedWith[]" // Evaluates to ["01", "02"]
    ]
  },
  {
    "prefix": "category",
    "expressionType": "jmespath",
    "valueExpressions": ["records[*].category"] // Evaluates to ["01", "02"]
  },
  {
    "prefix": "from_cms_",
    "expressionType": "jmespath",
    "valueExpressions": ["records[*].tags[]"] // Evaluates to ["tag01", "tag02", "tag03"]
  }
]

With the above Cache Tag Configurations, the following cache tags would be generated:

Article Id	Cache Tags
01	article01, category01, from_cms_tag01, from_cms_tag02
02	article02, category01, from_cms_tag01, from_cms_tag03
03	article01, article02, article03, category02, from_cms_tag02, from_cms_tag03

Notes:

• The prefix is added to the beginning of each tag (if it is specified1).
• The expressionType is one of: jmespath, jsonpath, jsonata, javascript. See this for more details on these types of expressions.
• The valueExpressions are used to extract the values from the Component's response. The values are then used to generate the tags. If an extracted value is an array, each value in the array is used to generate a tag.
• If the extracted value(s) is a boolean or number, the value is converted to a string and used to generate a tag. If the value is a string, the value is used to generate a tag. If the value is an object, no tag is generated.

Cache Invalidation API

DELETE /cache/components/{{componentCode}}
X-Customer-Code: {{customerCode}}
X-Environment-Code: {{environmentCode}}
Authorization: Bearer {{dxEngineToken}}

DELETE /cache/components/{{componentCode}}/tags/{{cacheTag}}
X-Customer-Code: {{customerCode}}
X-Environment-Code: {{environmentCode}}
Authorization: Bearer {{dxEngineToken}}

DELETE /cache/components/{{componentCode}}/tags?tag={{cacheTag}}&tag={{cacheTag}}
X-Customer-Code: {{customerCode}}
X-Environment-Code: {{environmentCode}}
Authorization: Bearer {{dxEngineToken}}

Examples

Remove all cache entries for the articles Component:

DELETE /cache/components/articles

Remove all cache entries with the tag article01:

DELETE /cache/components/{componentCode}/tags/article01

Remove all cache entries with the tag article01 or article02 or category01:

DELETE /cache/components/{componentCode}/tags?tag=article01&tag=article02&category=category01

Warming the Cache

Warming the Cache for the DX Engine means that the engine is pulling data out of its cache based on the context parameters it has seen before. For example, if you want to DX Engine to return product details by stitching together data and content from a PIM and a CMS, you can access the unified record via the Product ID. This ID has to be provided to DX Engine as a context field so that it can take it as an input to return some information to you.

DX Engine APIs can be called from any client, which means that you can create a script to call a set of API calls based on a variety of context parameters. In the example provided above, you may want to warm the cache for the component that fetches product information. You can do so by iterating through the set of Product IDs. These Product IDs can then be retrieved in any orchestration flow using the ID as the cache key.