Working with a ‘Headless’ CMS

When investigating the concept of a headless CMS and whether it would be a useful tool for an upcoming project, one may encounter various pros and cons. Generally, this doesn’t lead to more clarity when choosing a headless CMS or not. Luckily, you can simplify this process by aligning the advantages and drawbacks of a headless CMS and a comparing them with the classic CMS, making your life and final choice 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 and pretty 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 from it? What is the point? 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 yet another tool in the software engineers toolbelt. 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 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, CMS provides you with the choice in 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 CMS lives in the magical internet place called the Cloud™… meaning that it is a server which is available to you and your end-users 24 hours a day/7 days a week. All the tools 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 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 to define and fire off webhooks. They 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 your websites that a product description in the CMS has changed and they should clear their cache and retrieve a fresh copy of the data.

What are the downsides and ‘gotchas’ 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. 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 do not control are just some of them.

• Testing difficulties: For example, 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 CMS products on the market may include rudimentary 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 should expect a lot of manual data model adjustments in many headless CMS products you can find on the market right now.

• 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 synchronize 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 case you get a paid product, 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 of 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 pretty user 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 come 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 in case your clients lose connection to the headless CMS API, you may run into issues with data synchronization. Finally, if you use a licenced headless CMS your data will be trapped behind a paywall.