Once you’ve picked your caching strategy, handling cache dependencies becomes crucial.That way you always know which part of your cache to invalidate when something in your Kontent.ai project changes.
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
.
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.
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.
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 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.
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.
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.
Use the following guidelines to specify which cache dependencies must be invalidated after your app receives a webhook notification.
. The linked items are dependencies of the blog post. If the dependencies change, so does the blog post.
. Structurally, components and content items look the same.
Sign in with your Kontent.ai credentials or sign up for free to unlock the full lesson, track your progress, and access exclusive expert insights and tips!
// Without custom actions, you use the Delivery client directly, specifying its parameters each time.Client = DeliveryClient("<YOUR_PROJECT_ID>")response = Client.items() .type("<type_codename>") .limit(10) .skip(20)// With custom actions, you use named action to perform business logic.// GetPost action retrieves a blog post by its codename.GetPost("<post_codename>")// GetPosts action retrieves a list of blog posts and provides paging.GetPosts( <skip>, <limit>)// GetPostsByCategory action retrieves a list of blog posts tagged with a specific category, and provides paging.GetPostsByCategory("<category_codename>", <skip>, <limit>)
Jan Cerman
8 minutes
. All rights reserved.