The Delivery API is not only for headless!

The Delivery API is not only for headless!

As usual, this year’s Codegarden offered lots of good chats with other devs. It’s always inspiring to hear how others put Umbraco to use. And since I’m quite vocal about the Delivery API and advocating its many usages, these chats often touched upon that subject 🤓

A thing that struck me was how a few of these devs had discarded the Delivery API from the get-go, because they didn’t do headless builds. Instead, they built custom content APIs to retrieve lazy loaded content on their frontends.

I wrote an article on this subject for 24 Days in Umbraco, but allow me to reiterate here: The Delivery API can be used for lots more than headless builds!

Case in point; when I asked those devs for a high level description of their custom content APIs, most could be replaced more or less directly by the Delivery API 🤷

But… my APIs are special!

Oh yes, I’m sure your APIs perform unique, one-of-a-kind and never-seen-before content queries 😜

All jokes aside, I’m not saying you shouldn’t build custom content APIs. I’m just saying you should know and consider your alternatives.

In case you missed it, the Delivery API can be extended in a bunch of ways. This helps you meet querying requirements that aren’t immediately available out of the box. I believe that with smart usage of extensions and querying in general, the Delivery API can solve nearly any use case. Please prove me wrong!

I’ll also argue that implementing and testing custom Delivery API extensions is a much smaller task in comparison to custom content APIs ⏱️

Last, but certainly not least: The Delivery API will likely outperform custom content APIs, particularly when querying large datasets 🚀

If a custom content API is still your best choice for particular requirements, consider aligning its output with that of the Delivery API. There are a few good reasons for this:

  • It allows you to mix and match the Delivery API with custom content APIs while retaining a common output format. This makes it easier to consume the APIs across the board.
  • The Delivery API output models are cached at property level, whereas custom content API output models usually are generated for each request. Thus, the Delivery API output is likely faster to generate and ultimately saves server resources.

Let’s see some code!

Alright, that’s enough lecturing 😂

I’ve built a sample site to show how Razor templates can leverage the Delivery API to achieve lazy loaded content. You’ll find the whole thing in this GitHub repo. The repo README contains instructions to run the sample site.

The sample site renders an event calendar, which is a web component. The web component is written as a LitElement, and it queries the Delivery API for event entries by month 📆

The event date is defined as a date property on the event content type. To enable querying and sorting by the event date, I have created a custom filter, sorter and indexer for the Delivery API.

I do hope this post has added a little perspective for those who think the Delivery API is only for headless or statically generated sites 😀

Happy hacking 💜