The obvious answer is caching. Which brings me to my first gripe with Umbraco in a headless context.

Let’s say you want to cache your site’s queries—or even the entire page, --I’m not your boss--—based on the path. A very normal pattern. So how does Umbraco help with that?

It doesn’t really. Sure, there are webhooks, and you could make an API on your backend to receive a --ping-- from Umbraco and react to it. But the content you’re sent only tells you something about the page where the change happened. That might seem useful, but let’s say your page is a news article that has a writer attached. You go and change the writer’s email or photo on another content node. Your news article won’t update, because Umbraco only notifies you about the writer node, not the related article.

Many teams end up invalidating --everything-- on publish, but if your site has thousands of pages and a steady stream of visitors, that’s a lot of unnecessary cache churn just because someone fixed a comma somewhere.

My own solution to this problem is my package Cache Keys. It won’t solve everything for everyone, but it adds a set of cache “keys” to every response from the Content Delivery API, giving the returned object an added layer of context: not just “I am this,” but also --“I’m related to these other things.”--

That lets you define caching logic like: “This page is cached with its own key, plus the key of the writer, and the key of every piece of media on the page.” On publish, Umbraco can then send a cache invalidation request to your endpoint with all the related keys of the content.

Blog

Headless - Not Hovedløst

The Culture of Kindness