Choose your caching strategy | Kontent.ai Learn

Cache in a nutshell

A cache is an additional layer of storage used to retrieve data in your app quickly. With Kontent.ai, the cache sits between your app and an API. The cache contains entries with responses from the API. When your app fetches content, it first checks whether the content is already in the cache. If it's available in the cache, there's no need to contact an API. If it’s not yet cached, your app makes an API request and stores the response in its cache. When the content is updated in Kontent.ai, the cached response needs to be invalidated. Because specific parts of your content might depend on other parts, you need to keep track of the relations among the cached responses, i.e., their dependencies. When your app invalidates a cached response, it should also invalidate any other related cached responses.

Choose your cache strategy

Your caching strategy depends on your attitude toward stale content. Stale content is the one that has expired in the cache. This means the content in Kontent.ai has been updated, but your app continues to serve stale content. If you're fine with stale content being outdated for 15 minutes or an hour, use time-based caching. This way you cache each response for the same amount of time. If stale content is an issue and you want to ensure your cache is always up to date, you need to synchronize content changes based on recent content changes in your Kontent.ai project.

Fine with stale content? Use time-based caching

For client-side apps and basic mobile apps, we recommend using time-based caching. This means invalidating cached responses after a specific amount of time.

It's easier to implement.
It performs better because your app doesn't need to know about recent content changes and process them.

The expiration time should align with your users' expectations and their tolerance to stale content. To improve your app's performance, set shorter expiration times for the types of content that change often, like articles, and longer times for static content, like navigation. With this approach, your app gets content directly from Delivery API. This approach is also suitable when you don’t have the resources to maintain a server-side app or proxy server to synchronize recent changes.

Need the latest content? Synchronize content changes

If you're building mobile or web apps where up-to-date content is critical and cannot afford stale content, you need to synchronize the latest changes. You can either receive and process webhook notifications or fetch recent changes at your pace with Sync API. Both webhooks and Sync API require a server-side app on your side. This can be a proxy server for your mobile app, a backend for your client-side app, or a regular web app.

With webhooks, your app needs to be always available so that it can receive notifications at any time.
With Sync API, your app regularly synchronizes changes in intervals of your choice.

Whenever your app is notified about a content change (either via a webhook notification or by asking Sync API), your app needs to invalidate specific items in its cache and fetch their latest version from Delivery API. Your app needs to identify dependencies in the responses and invalidate cache entries based on the information it gets either from the webhook notifications or Sync API.