The real value of headless CMS – the situations where it can provide unique advantages – are more interesting than this. Peter, Artas, and I scribbled on a whiteboard for an hour and ended up with at least nine alternate use cases where headless CMS can be a good fit and is worth considering.
The biggest group are use cases that arise from channel and source dispersion –
Non-web content publishing, where you’re not powering a website at all. Mobile apps are a clear example. If you have content needs for your mobile app, a web CMS might be overkill and include a ton of functionality that has nothing to do with what you need.
Contentful has some features which clearly cater to things like mobile apps. A synchronization API, for example, which is designed to deliver “all the content that has changed since the last time I checked.” This is perfect for mobile apps with spotty connections and is not something a website really needs to worry about at all.
Multi-channel publishing, where content is being pushed into multiple channels: web, mobile, print, etc. This is a classic content re-use scenario. While most multi-channel scenarios are pretty web-centric, your website might only be one place where your content gets published. Contentful, in this situation, has no idea where the content will end up, and doesn’t care. It’s just standing by to serve content to whatever channel requests it.
Content aggregation, where content from multiple sources is being aggregated in one place to power a website. If your website is comprised of a bunch of different content sources, you could push them all into Contentful to give your developers a single point of access for all of it.
I see this more in the intranet space, but there are situations where multiple content sources need to be “homogenized” at some layer. I call this the “content warehouse” approach. Like a data warehouse, you push content from all over the place into one location. Instead of your website dealing with N different data sources, it has one, into which content is placed through a variety of processes. This eases developer access and training, avoids many latency and performance issues, and provides some fault tolerance.
Closely related to this would be content middleware, which is really a combination of the above two. Content from multiple sources could be combined in Contentful, then pushed to multiple channels. So, in this situation, Contentful becomes the “traffic cop” in the middle that controls the flow of content.
I interviewed Zach Brand from NPR once about their COPE strategy – Create Once Publish Everywhere. This was an example of multi-channel publishing. Zach told me that the strategy eventually morphed into what they informally called CAPE – Create Anywhere Publish Everywhere. Content streamed in from all over the place, was aggregated and managed in one platform, then was requested from multiple other channels.
Visually, it’s a “bow tie” – a broad array of multiple sources focuses content into the “knot,” and an equally broad array of channels fans it out the other side. (I would use the word “bottleneck,” but for the negative connotations.)
Beyond channel and source use cases, there are some even more interesting scenarios –
Development operations support, where “quasi-code” elements are stored in Contentful for use in another system. These are things like text string translations, non-core CSS, even HTML snippets – things which are code-ish, but around which you have a fundamentally different management model than “true” code files checked into source control.
For example, let’s say your SaaS service allows client-specific configuration and theme files. These aren’t core code of the system itself, and they shouldn’t be muddled it with that. However, they do need management tools and processes. These could be managed from a headless CMS and dynamically referenced at runtime.
"Subservient” content management, where content isn’t the main point of the application. In these situations, content is used as part of a larger application that can’t support a CMS directly. For instance, if you have a massive online banking app that has some content for help files or marketing promos or whatever, you can’t just a drop a CMS on top of this. The CMS has to exist apart from the app, and push content into it, as unobtrusively as possible.
We did this for a well-known company with a very large and complex SaaS web application. Every form field in this application had a little question mark next to it. Holding the cursor over it made an Ajax call to a headless CMS – an API-only instance of Episerver, in this case – to retrieve the help text for display. This help text was managed by a documentation group making full use of Episerver’s management and workflow tools, just without an actual website. The content was only published to the API, to appear as mouseover help text.
Temporary content abstraction, where Contentful is used get content “out of the way,” even just temporarily. We’re working on a large application that has some minor content needs, and we really just don’t want to make a decision on a CMS right now, in the face of everything else we have to do. We’re looking at Contentful to just take that decision away and delay us having to make it. It’s a responsible way to “kick the can down the road,” although, in the end, our “temporary” solution will likely work well enough to become permanent.
Structured content segmentation, where Contentful would be used for a certain type of content, among other types. While this means you have two CMSs, sometimes this isn’t a bad thing. A CMS that you (or your marketing department) love might not handle highly structured, relational content well, but could do other things that make it desirable.
For example, you might have a manufacturing website consisting of two major types of content: (1) highly artisanal, unstructured, marketing-style content; and (2) a highly structured and relational dealer database for users to search. If you can’t find a CMS that does both well, then there’s no rule that says you can’t split this content up. Find a highly visual “page management system” for the marketing department (or even code it by hand, if you don’t need to manage it), and then manage the dealer data in Contentful. If the models between domains of content are very different, then use the tool that works best for each and glue them together.
Editorial segmentation, where a subset of editors do a very specific, limited thing, and whom you don’t want to let into the core CMS. Perhaps they just publish blog posts into a larger website, and for this, you don’t need to train them specifically or customize for any specific need they have. Instead, you just show them how to use Contentful and integrate. Not every editor is created equal, and you might not want to incur the training costs or changes necessary to make your uber-CMS work for absolutely everyone. This is a way to put a subset of editors in a simplified interface and never expose them to all sorts of edge features they’ll never use.
Now, note that these are the rational cases for headless CMS. It’s worth mentioning that there’s an irrational case too –
From time to time, we see development groups that simply don’t want to work with a CMS. They’re used to rolling their own systems and are distrustful of anything big and monolithic which they don’t understand. Yet, their editors – the marketing or documentation groups of their organizations – still want the tools of a “real” CMS.
With Contentful, the editors get a CMS, and the developers don’t actually have to work with one. The Contentful API is competent enough to feel like raw database calls, and any competent developer can be throwing around Contentful objects within about 15 minutes of reading the documentation. If that’s even too much voodoo, it’s shockingly easy to serialize Contentful objects into flat database tables in real-time using webhooks.
(Not even kidding – look at this tweet for an example of serializing Contentful objects into simple XML files in about nine lines of code. Give me another dozen lines, and I’d have it serializing to rows in a database table. Seriously – your developers don’t even have to know Contentful exists.)