It's hard to choose the right headless CMS when there are so many options. There's one decision you can make before comparing CMS products.
Originally posted on www.ample.co.
That makes it challenging to choose the right CMS for your project. Especially when there are so many factors to consider, like price, front-end integrations, publishing workflows, etc. And that's before you even begin to get a sense for how the product feels, which is an intangible quality that a spreadsheet comparison simply can't provide.
But, before you get to that step of weighing a conglomeration of factors important to you and your project, there's one decision you can make. A decision that can come before you need to know the details of individual products. That decision is which type of headless CMS you're going to use.
There are two types of headless CMS products: API-Driven and Git-Based.
The difference between the two is all about (You guessed it!) the content. How the content is stored, and how it is consumed.
API-driven CMS products store content in a database. This is more like the traditional (i.e. monolithic) CMS approach, used by products like WordPress, which takes the data you type into the page or post form, validates it, then stores it in its database.
Monolithic types of CMS applications like WordPress then pull that same content from that same database and present it to the user on the front-end. An API-driven CMS, on the other hand, has its data consumed via an—You guessed it again!—API.
With git-based content management systems, the content is stored in files, committed directly to the project's git repository. Most of these services communicate directly with the remote repository host—GitHub, GitLab, Bitbucket, etc.—via their APIs. In other words, these products are often actually making commits to your codebase on your behalf.
The question you really care about, right? Which one is better?
Well, there are two types of CMS products for a reason. Neither is a perfect solution for every front-end project. In fact, at Ample, we have two go-to CMS recommendations we make on the majority of our projects — one API-driven and the other git-based.
What we ask ourselves at the beginning of each project is Which type of CMS will best serve this project?
To help unpack that question, let's look at the top few benefits for each...
API-driven CMS products tend to have the following qualities:
Git-based CMS products tend to have the following qualities:
The list of benefits to each approach goes on and on, but those are a few of the high points. The reality is that they are both great solutions for different reasons. And, in contrast, in the wrong scenario, they can feel like poor decisions.
For example, paying a monthly fee for a hosted API-driven CMS that powers a super small site with a few pages and blog posts is very likely overkill. And it'll hurt to pay that invoice every month when you could simply be editing a few markdown files. On the other hand, if you have to support multiple front-ends from the same data source, it'll feel like an uphill battle if you're using a git-based CMS, while an API-driven CMS is designed specifically to solve that problem right out of the box.
At Ample, we've evaluated the field on both sides and have found what makes us and our clients happy. We love Contentful (API-driven) and Forestry (Git-Based), each for different reasons. We have projects that are better suited for one over the other, and that's usually apparent early on in the process. Standardizing on these two approaches has enabled us to build tooling around each. That way we can choose one based on the project's criteria, and then move quickly through the development process.
But that may not be a good approach for you. You may build projects that are similar enough to be able to standardize on one CMS, or at least one type of CMS. And that's great! What's important is that you evaluate your options based on criteria that is important to you and your projects.
Then we can build Jamstack sites with ease and your editors might just stop hating their CMS!
And if you want to talk more about content management systems, our door is open. But, be warned, we're a little obsessed.
Help your content editors enjoy their CMS experience by designing a content schema that balances productivity and flexibility.