If you've ever handled dynamic projects with a CMS, you know that cache invalidation is a significant challenge. DatoCMS recently introduced a tag-based cache invalidation system, which paired with Turso's efficient storage capabilities, allows for instant and surgical page regeneration only when content actually changes.
For those who don't know us, DatoCMS is a headless CMS designed for digital teams that want to craft modern digital experiences without the fuss. It's built with a straightforward GraphQL API and a no-code approach to structuring content, letting you focus on bringing projects to life quickly and reliably.
Traditionally, caching has been quite a headache for developers. Implementing it effectively can be complex, often requiring intricate time-based invalidations, or even complete site rebuilds just to ensure content is up-to-date. For this reason, we decided to release a solution we've been using internally for years to handle billions of responses from our Content Delivery API.
DatoCMS Cache Tags offer a powerful and easy-to-implement solution for cache management, ensuring efficient, real-time updates and high performance for web projects of all sizes. Every response from the DatoCMS Content Delivery API comes with its own list of cache tags. These tags track every potential change in the content within DatoCMS and when something changes, we send a list of tags that need invalidation to your frontend via a webhook.
All developers have to do is implement a simple API route to receive these tags and call the invalidateTags()
function provided by their framework or hosting solution. It's that easy!
As part of our efforts, we built a starter project using Next.js and Turso to showcase how you can selectively invalidate the Next.js cache when receiving DatoCMS Cache Tags invalidation events - better show than tell, right?
The story of how Turso came into play is an interesting one. As we progressed developing the starter, it was all smooth sailing, until the unexpected happened - a classic staple in every developer's job. We found out that a Next.js cache item can have a maximum of 64 tags. This limitation was incompatible with our Cache Tags system, so it was a no-go for us.
Fortunately, we had anticipated such challenges and had already explored potential database solutions. We decided to provide our audience with a practical, real-world solution.
To address the root issue, we needed storage to associate our cache tags with the GraphQL queries executed and the HTML pages generated. We set on Turso for its simplicity and its appealing free plan, which is just perfect for users eager to try cache tags right away.
Interestingly, the solution we developed using Turso is even more straightforward and transparent than our initial approach, and we implemented it in a very short time.
The database contains one table with two columns: Query Identifier — we use a SHA1 digest, but a randomly generated identifier like a UUID would work as well — and Cache tags.
When a query is executed:
When a cache tag is invalidated:
Done.
On the developer experience side, the pairing of DatoCMS + Turso couldn't be smoother. We've shared a starter project on GitHub to help our users get familiar with Cache Tags and how to implement them in a Next.js project.
We can use sqlite.new to create a database in seconds:
After signing up or logging into your existing account, Turso will create a database with the schema expected by the starter project. You’ll just need to copy the database URL, create a token for the database, and use them as environment variables. Your Turso DB is now paired with your DatoCMS Cache Tags project!
If you want to learn more about DatoCMS cache tags, you can read the announcement on our blog, or delve into the documentation.
If instead you’re eager to try the starter project, just head over to our GitHub.
Collaborating with the Turso team on this initiative has been a tremendous pleasure, and we can’t wait to see what our developer community thinks of this exciting couple!