Keep your cached content up to date

Cache implementation 101

Let's go through the general process of storing API responses in your app's cache. The following sample scenario assumes a web application that powers a blog site. The site can show a list of blog posts, display a specific blog post, and organize posts by tags. With Kontent.ai, each blog post is a content item, and each tag is a taxonomy term.

Step 1: Define your app’s business layer

It's a good practice to define specific custom actions within your app (such as retrieving a blog post) and rely on those custom actions in your app. Think about the actions that your app performs regularly and create methods for them. Using the blog site example, these actions can be:

• Get a blog post
• Get a list of blog posts
• Get a list of blog posts by category

In pseudocode, the actions might look like the following: One of the benefits of using your own custom actions is that you can use a combination of the action's name and input parameters to name the API response (that is compose a cache entry key) and store it in the cache.

Step 2: Implement logic for caching your content

When you retrieve a blog post using your custom GetPost() action, you get a JSON response with the specified blog post. Whenever you get a response from the API, you store the response in the cache. To cache the response, create a cache entry that uses a naming pattern such as <action_name>|<action_parameters> for its key. Use this pattern to uniquely identify the responses within the cache for each of your custom actions. For example, if you retrieve a blog post named My blog post, you name the cache entry key for the response GetPost|my_blog_post. You can adjust the pattern to suit your needs and naming conventions. Once you put the response in the cache, you're done. The next time your app calls GetPost("my_blog_post"), it retrieves the blog post from the cache without having to make any request to the API.

Handle cache dependencies

If fresh content is important to you, correct cache dependency handling is crucial. Let's see how to identify the cache dependencies and store them in the cache. Imagine your app requests a blog post and gets an API response with several components and a few links to content items. The linked items are dependencies of the blog post. If the dependencies change, so does the blog post. The structure of the API response looks similar to the simplified JSON below.

• In the item object, you find a content item representing the blog post itself.
• In the modular_content object property, you find the components and linked items as separate object properties.

You need to go through the API response, differentiate content items from components, and add the content items as dependencies for the cached JSON response. To uniquely identify the cache dependencies, use a naming pattern such as <object_type>:<object_codename>. Using the content item from the simplified JSON, the dependency name would be item:guest_blog_post. This way, you can invalidate the correct dependencies whenever there’s a change in your content items.

Differentiate content items from components

When you get content items from Delivery API, the modular_content object in the API response contains both content items and components. Structurally, components and content items look the same. To tell content items and components apart, find the object’s ID and check the third group of characters in the ID.

• If the characters do NOT start with 01, for example, ce0288e7-294c-46e5-b9bc-b086656d5c48, it's a content item.
• If the characters start with 01, for example, ce0288e7-294c-01e5-b9bc-b086656d5c48, it's a component.

Guidelines on creating cache dependencies

Use the following guidelines for constructing your app’s cache dependency logic. For a Delivery API response with:

• Single content item
  • If the number of objects in the modular_content object property is below 30, add cache dependencies for all the objects.
  • If the modular_content property contains too many objects to define as separate dependencies, add a special general dependency for any content item. In such case, your app invalidates the cached response whenever any other content item is invalidated.
• List of content items – Add cache dependencies for all the content items in the list.
• Single taxonomy group – Add a cache dependency for the taxonomy group object returned in the response.
• List of taxonomy groups – Add a cache dependency for all the taxonomy groups in the list.

Once you’re done adding the logic, you need to specify when each dependency needs to be invalidated.

Guidelines on invalidating cache dependencies