Working with a headless CMS

Jonathan Whiteside
Global SVP Technology & Engineering

Length

10 min read

Date

11 June 2020

When investigating headless content management systems and whether it’s the right solution for your business, you will undoubtedly encounter various pros and cons. You can simplify this process by aligning the advantages and drawbacks of a headless CMS by comparing it with a classic CMS, making the decision process a whole lot easier.

What is a headless CMS?

Nothing to lose your head over, to be perfectly honest – yes, pun intended. When you boil a headless CMS down to its essentials, you will get a database with a simple user interface. It serves your data via an API to any client (website, mobile app etc.) that may depend on it.

Similar to database tables, a ‘content model’ is a core concept of any headless CMS that, when defined, gives structure to the data. Content model examples are concepts such as ‘Product’, Contact person details’, ‘Content page’ etc.

Content models contain fields that the end-user can fill in, producing a data object which is essentially your content. Data objects are an equivalent to a table row. Most self-respecting headless CMS systems will allow you to reference other data objects in order to form advanced structure and dependencies within the data itself. A foreign key, if you will.

Now you may be asking yourself “if a headless CMS is nothing more than a database, what use do I have for it? Why not simply have a database?”

Well, you could, but you would be missing out on some key advantages that a good headless CMS will provide you and your team.

What are the advantages of a headless CMS?

When working with a headless CMS, you will benefit from easier setup, simplified maintenance and will be working with a well-tested set of tools that make content creation and validation much simpler. A headless CMS will make your data available to any number of clients across platforms and programming languages, thus allowing you to create platforms instead of simple websites. To top it off, you will also have access to built-in support for data versioning, meaning that you can correct any mistakes without dealing with database backups.

Timesaving tool: A headless CMS is another tool in the software engineer’s tool-belt. It will save you a lot of time when building a system either for yourself or your clients. Moreover, you save even more time if the system you are building is evolving and changing, thereby requiring you to alter your data types.

The very fact that you can open the UI and create new and edit existing data types spares you a lot of effort. No need to mess around with SQL and database upgrade scripts. It is all handled by the CMS.
Validation for properties: Contrarily to a regular database, with a headless CMS, you’ll benefit by being able to define powerful validation properties. By defining the required fields as well as the string field format (email, phone, regex, etc.), managing data quality is effortless. Moreover, a headless CMS provides you with the choice of how to display input to the end-user. The goal may be to display a list of strings as a single text box that produces ‘tags’ on every press of the ‘enter’ button. It could be multiple text boxes, one below the other for easy editing; limiting the scope of available dates on a calendar; the number of decimal points for a number; type of file you want to allow your end-users to upload, or the maximum dimensions of the image.

You get the point, a headless CMS will put all these tools at your disposal with only several clicks, leaving you to spend your time writing meaningful code.
Data history and backup: Once your end-users start using the CMS, you may run into a situation where critical data is deleted or overwritten, and you need to get it back. A headless CMS will generally allow for a smooth data object audit. See who destroyed the data so they can get a slap on the wrists while you restore any lost values in just a few clicks. No need to fumble around with days old database backups that will restore your data to an ancient version only to restore one critical piece of information.
Stability: An established, ‘battle-hardened’ headless CMS will generally be well tested, stable and bug-free. It will save you the stress of writing a custom UI for data input, much like a classic CMS will.
Cloud: Headless content management systems are cloud-based, meaning that it is a server which is available to you and your end-users 24 hours a day/7 days a week. The only tool that you will need to access it and edit the data is a simple web browser. No specialised tools required for you or the end users.

Headless vs. classic CMS

So far, a headless CMS seems to have many advantages over a simple database, but what sets it apart from a classic CMS? Seeing how a classic CMS will usually be able to boast the same features, which of the two is better? Which one should you use? The answer depends on what you are trying to build.

If you’re building a website, a classic CMS is a perfect choice as it will allow your internal users to access it directly and preview any changes while editing the data. If you are dealing with a classic open-source CMS, you will perhaps be able to alter it and install custom plugins to allow more functionality.

But what happens when you want to build a complex platform? Imagine a project where you need to build several websites and mobile apps for both Android and Apple ecosystems which, in turn, share the data with the website. Hypothetically, the system may involve additional services that run on Linux and Windows servers. And what if you want to support third-party developers?

In this over-exaggerated scenario, a classic CMS fails to deliver, given that you would need to write your own API around it to satisfy all those apps and services. You will need to manage caching, security and data consistency, for example.

A headless CMS will provide these features to you ‘out of the box’ as the API is the primary way for you to interact with a client app, website or any other client. It allows you to specify security tokens that can only access a specific subset of data. By generating unique security tokens for each data consumer, you can create a safe way for any client apps to read and write the data that they have access to. Multiplatform compatibility is not a concern since you will generally be dealing with JSON, which every modern programming language can process.

Webhooks

Another powerful feature of a headless CMS is the ability to define and fire off webhooks. These are simple event-driven systems that send HTTP requests that you define to any URL of your choosing. For example, this allows you to notify all of your websites that a product description in the CMS has changed, and that the cache should be cleared to retrieve a fresh copy of the data.

What are the downsides of a headless CMS?

While boasting many advantages, a headless CMS is not perfect. It will put some obstacles in your way and make certain scenarios complicated to deal with. For example, difficulty in testing new features without affecting live environments, offline work for your client systems, and the fact that your data exists on a server which you don’t control.

Testing difficulties: testing your code for various environments (test, integration, production), may not be as straightforward on a headless CMS, because many of them do not support this feature. More often than not, you will be dealing with a single environment and one set of data, which causes issues when developing new features or changing existing ones in a way that forces you to adapt the data models.
Ideally, one would do so on an isolated environment so as not to affect the existing data. Some headless systems include tools for duplicating your data and allowing you to access it separately from the original, which solves half the problems related to this drawback. However, when making changes to content models or the data itself and the time comes to release the new feature, developers often face problems in propagating those changes back to the original environment without damaging it or causing data corruption. You can expect manual data model adjustments in some headless CMS systems.
Always online problems: despite the benefits of a constant online presence, it can be a problem when your client software loses access to the internet. Unless you put in a lot of effort to cache your data and properly synchronise any changes with the headless CMS, it may cause you a lot of headaches when the various mobile apps, services, and applications come online and start injecting old data into the existing system. You may get messed up IDs, duplicate data, out of order data, etc.
Data behind a paywall: in the case of paid solutions, you will be required to shell out a monthly subscription. If you don’t pay your subscription, your data may no longer be made available to you. It’s as simple as that. You may be spared this downside when using a free product, but free products often have a stigma of being of lower quality due to low incentives for developers to maintain and update them.
In most cases, you will probably be able to retrieve your data via support staff, but unless you pay your subscription, the API access is going to be blocked, thus rendering your clients completely cut off from the data.

‘Too long, didn’t read’ summary

A headless CMS is an advanced database with a simple interface. One should view it as a tool that will save you a lot of time and effort because it will usually come with powerful features for validating data, ensuring its safety and versioning. It will generally be stable and well tested. Another major benefit is that your data will be available to you via an API 24 hours a day/7 days a week. A headless CMS’s most important feature is that it bridges the gap between platforms and programming languages, as it will generally serve your data in the form of XML or JSON.

A common problem that comes with using a headless CMS is the lack of support for data separation for multiple environments (test, acceptation, integration, production, etc.). It will often be quite a bit of work to alter production without a lot of careful, manual editing of content types. Being always online is good when it works as intended, but if your clients lose connection to the headless CMS API, you may run into issues with data synchronisation. Finally, if you use a licenced headless CMS, your data will be behind a paywall.