Categories
Complex problems

How to pick a headless CMS without losing your head

With new marketing challenges right around the corner, our CMS is getting overburdened like a truck above its weight limit. We need to fix that!

We are ending this quarter with some substantial reinforcements on the marketing front. The new, talented new hires are working their way toward a future where our products reach and help even more drivers, which sounds like great news if you ask me.

And with new marketing challenges right around the corner, we realised that our CMS is getting overburdened just like a truck above its weight limit. Our current implementation works well but relies on way more raw JSON editing than our copywriting people should ever handle. 

We need a flexible, faster solution for content management that empowers the marketing team to do what they do best. Let’s talk about content management systems, but headless.

Where did the head go?

Despite the mildly spooky name, the concept of a headless CMS is easy to understand when you compare them to traditional CMSs.

See, while traditional CMSs handle both the data and presentation of some content—think dealing with how an article is saved AND how it looks on the browser—headless CMSs are only concerned with storing content and providing access through an API or repository.

WordPress, for instance, used to be full traditional until its 4.7 release. If you wanted a bite of that WP admin panel, you had to deal with its theming API. The 4.7 release officially introduced a content API, so people were able to use it either as traditional or headless CMS.

The most significant advantage of using a headless CMS is that you have complete flexibility over how you’ll handle that data. Write your “privacy policy” or “FAQ” pages once and fetch them on your React, Android and iOS applications. The sky is the limit.

Git-based vs API driven

While searching for the right tool, I found out that headless CMSs come in not one but two flavours, Git-based and API driven.

Git-based CMSs work, unsurprisingly, over a versioned environment. Generally more straightforward in nature, that kind of CMS provides GUI tools to write and edit your versioned content files. 

I mentioned in the intro that our current solution expects our content people to edit JSON files on Github. A Git-based CMS, like NetlifyCMS, provides the same experience code-wise (our website would read static content files) but a much friendlier editing experience.

API driven CMSs are more classic in a way that they still save your content in a database. You only need to decide if that database will be yours or someone else’s.

Self-hosted vs PaaS

Now, let’s say we’ve decided on an API-driven CMS. Most of the popular tools offer both self-hosted and “Platform as a Service” options. You can install Ghost/Strapi/Directus on DigitalOcean/Heroku/AWS or pay for each services’ managed alternatives.

Generally speaking, self-hosting allows more flexibility and control over the tool you’re using, at the expense of also having to deal with security and availability concerns. While PaaS solutions can be significantly costlier than self-hosting on the cloud but save a lot on engineering hours.

This is one of the most important decisions to make when picking an approach to the headless CMS problem. One that we will have to do soon enough.

Support and popularity

Reaching 85 different listings on Jamstack.org, the amount of available headless CMSs tools triggers a Netflix-like analysis paralysis. I can’t conceive what the person behind the 85th tool didn’t like about the other eighty-four alternatives. Programmers just enjoy coming up with new ways to make the same stuff, I guess.

That being said, picking between Git-based/API driven and self-hosted/PaaS certainly lowers the number of alternatives. However, there are still a couple of things to keep in mind, support and popularity.

A PaaS CMS with no support whatsoever can be a pain when an unexpected issue arises. The same risk applies to not-so-popular self-hosted options; the lower a community behind a tool, the smaller the chances of someone who had the same problem coming up to save the day.

Our choice and next-steps

Personally, I lean toward solid PaaS tools (I’ve had my fair share of backend blog configuring during my WordPress days), but at the time of writing, we haven’t picked any. Some look promising, but a deeper dive into documentation is required to make a more educated decision.

This is kind of a meta-article, to be honest. I’m writing to share practical decision factors if you ever need to choose a headless CMS and direct our internal debate about available tools. 

My goal was to save both my time and yours, and I hope I achieved that today. 😄

Stay tuned for more updates on our headless CMS journey. I cannot wait to migrate this article to our future implementation!

Leave a Reply

Your email address will not be published. Required fields are marked *