With many options comes many decisions, and it is easy to drown in all the many and various stated benefits of the different systems. So how do you approach evaluating these options? Two weeks ago, Aaron Hans shed light on the use cases of going headless and what it is good for here on slots empire bonus codes Magazine. Today, I’ll give you a little bit of a primer on the CMS landscape, as well as some questions to ask to aid you in making a decision.
Headless content management is the practice of decoupling your content management system (CMS) from your front-end. Unlike with traditional (or “monolith”) systems, the CMS is not directly responsible for powering the web front-end. Instead, content is served to the front end from a remote system by way of an API, and the front-end consumes this data to render its pages. This can occur either at run-time (when a user lands on your website), or at build-time (content gets pre-rendered and generated in advance), but the important concept here is the separation between content and presentation layers.
If you’re planning to create a site using the Jamstack, you’re going to end up heading in this direction by default, but the approach is just as valid for other kinds of projects, using server-side languages such as PHP, .Net, or Ruby.
But Why Is This Even A Thing?
Headless came about originally as a way to manage content for the Jamstack (before Jamstack got its snazzy name), but the approach has garnered fans for a lot of reasons. Headless content management allows us to deploy content to different platforms, so you can use content from your website in a native mobile app, for example.
Headless also allows us to patch up shortcomings in other systems. For example, Shopify. Whilst great at what it does, it isn’t the most flexible system when it comes to managing content for your online store. Using a headless CMS, we can remotely manage additional content for a Shopify site and bring more power and flexibility than we would have by default.
I recently worked on a project doing exactly this — extending the content that Shopify provides with additional, richer content from a headless CMS (we happened to use Contentful for this particular project, but any headless CMS could do this job). Using a headless content management solution allowed us to create custom data structures that we could tailor to our needs. For instance, the client wanted to highlight the ingredients they used in the making of their products, and Shopify doesn’t really provide a good way to manage this. We created a new content type in Shopify and allowed that to be added to a custom product page full of other types of content we created.
Shopify content was pulled through and synced to Contentful, and this became the primary data driver for the site, with the Shopify APIs only really getting involved for stock level checks and basket creation. Being able to add this kind of rich data to a SaaS-based eCommerce site was incredibly powerful.
Decoupling your content from your presentation layer can be really powerful. Allowing your content to plug in to different platforms and presentation layers helps keep your content consistent across your touchpoints, and it helps make sure that your content doesn’t get fragmented across a bunch of different systems managed by different teams.
Imagine you have a product that you want to talk about on your website, in a mobile app and also in programatic ads. With headless, you could have one central content repository and deploy the same content (or aspects of it) to all of these platforms and more. With more traditional content management, you would need to manage the content for different platforms separately.
This Sounds Great! So Is Headless Right For Me?
There are a bunch of things to consider when choosing your approach. There are benefits to going headless, but there are costs as well. Here are some questions to ask yourself when considering headless as an approach:
Are You Comfortable With The Knowledge Requirements Of Making The Split?
A lot of people think that moving to headless can “get rid” of the need for back-end developers, but the truth is that the mindset to structure data effectively and build content models that work and scale well is still very different from the mindset needed to be a great front-end developer much of the time. There is still a knowledge gap and that will still need to be filled.
If you’re dealing with a project of significant scale, you’re still probably going to want some developers to focus on the “back end” areas, and some to focus on the “front end”. The divisions are finer and more malleable in headless land, but don’t labor under the false assumption that you can halve your development workforce just by going headless.
Do You Know The Total Cost Of Ownership?
Whilst headless can often prove cheaper than a monolith, the SaaS nature of most of these systems can mean that for large, rapidly changing datasets, or very large teams, the costs may not add up. Always check how the costs scale, and what that scaling is based on. Some vendors scale based on data volume, some on number of API requests, and some on number of collaborators editing your content. The combination of these can have a dramatic effect on how your costs grow with scale.
You will also likely need to look at multiple different platforms to formulate an idea of your total cost of ownership. If you aren’t getting search “out of the box”, you’ll need to consider how much it will cost you to add that feature. You can usually predict how these costs will scale, and you can often start out small, but it’s worth being aware of what these things might cost you in the long run.
Also keep a close eye on your build minutes if you do choose to go headless: these can mount up quickly, especially in the development and content population phases. Be aware that, if you choose to staticly generate your site, then you will require a build after each publish action from the CMS. With large sites, these builds can take a while, so its worth keeping in mind that these will need to be kept in check. Many of the popular static hosting services (such as Netlify and Vercel) support build asset caching and, in combination with modern frameworks enabling incremental builds, this can help mitigate this increasing cost, but you still need to keep an eye on it and do your research to ensure you don’t get caught out.
Have You Explained It Well Enough For Your Client?
You might love the developer experience of working with the Jamstack and headless, but when making these evaluations, you must keep in mind that the clients are the ones who have to use and live with the solutions you put together, so you’ll want to try to make their lives as easy as possible.
In a previous role, I was involved in a pitch to an automotive manufacturer who said they wanted industry-leading performance as a top priority, but they ultimately went with another agency offering a more traditional solution. This can happen for a number of reasons. (We most probably didn’t do a good enough job of selling the benefits of our approach, but going headless can also seem pretty scary to content editors, especially when put up against some of the traditional “enterprise” systems who have a talent for making it look like everything “just works”.)
When you go headless, you will be bringing together individual tools that are each designed to be very good at one particular thing, rather than having one large system that can do all of these things in one place. That can be pretty intimidating to deal with unless you can make it easy as possible for your client to deal with.
Are You Taking The Additional Development Time Into Account?
All of the potential power and flexibility of headless doesn’t come for free. One of the downsides to everything being custom is that this means that everything needs to be developed from scratch. With many of the options in this space, there is no real “default” document schema — indeed, they are set up very deliberately to not have any defaults like that. This is great on the one hand because it means that you get tightly-tailored document models that precisely match your needs.
On the other hand, though, it means that someone needs to define these document models, and then someone needs to create them for the system you are using. Then, because the frontend and backend are decoupled, somebody will usually need to create an engine to allow previewing of draft content; many modern frameworks include a system to allow previewing of draught content, but they universally require additional configuration to get working, and some will require a level of custom code. Of course, the front-end isn’t tied to the content, so any mapping of data to front-end components needs to be done as well. You will usually have to do at least some of this even with a tightly-coupled CMS, but the fact that you will likely have to allocate time to all of these things can be costly.
Are You/Your Client Comfortable With Data Not Living On Your Own Infrastructure?
Whilst many who work with headless CMS systems and other SaaS vendors frequently consider this a positive, there are situations where your data being outside of your own infrastructure could be less than desirable, for instance where sensitive product or non-public production data is involved. Security for these companies is usually pretty good, but there are always risks.
Make sure you weigh up the relative benefits of having your content housed on an anonymous AWS server somewhere. We have seen before that even the mighty AWS can have outages and, for business-critical systems, these can be extremely costly. The difference here between SaaS on AWS or using your own infrastructure is that if you have an outage or security breach on your own infrastructure, that is likely to be down to your own product or code, but in a SaaS/AWS environment, outages are more likely to be caused by factors unrelated to your business. These instances are rare, but they do happen and it is important that this is taken into account when making these decisions.
Ok, Great. So What Are My Options?
The number of headless and headless-capable content management solutions available in 2021 is staggering and growing constantly. Rather than trying to cover all of the options here, I want to give just a very brief introduction to a few of the better-known options. If you’re looking for a more comprehensive list, then you might want to check out Headless CMS or CMS Comparison.
Contentful is one of the most established of the headless CMS options, having been founded in 2016 and having enjoyed several successful seed investment rounds, and describe themselves as “an API-first content platform to deliver digital experiences”.
Contentful have made great strides in recent years to better support translated and trans-created content, and they have good support for multiple content “environments”, allowing changes to be made away from your production data and migrated later.