While the world is shifting to the cloud, web content management systems (CMSs), the most popular ones at least, are still stuck in 20-year old technologies and architectures. This alone does not mean they don’t work. Wordpress for example (released in 2004) powers 36.7% of all the websites on the Internet right now. However, the demand for innovation and better digital experience has grown immensely getting many businesses under pressure to accelerate development and turn to modern frontend tools to create lighter, faster, more secure sites.
But the content of your website still needs to live somewhere, right?
Enter the world of headless CMSs. Rather than going through the explanation of headless CMS and it’s ecosystem (which we did with an opinionated post that got us into trouble, check the link) in this post, I’ll cover Git-based CMSs and API-based CMSs. The differences, the challenges, and the benefits of using them.
With a Git-based CMS, changes are first pushed to your Git repository which then triggers a new build of your site. Without going into details, you are working with files stored in your Git repository. Let’s take a look at the pros and cons of these CMSs.
- Full version control on all content out of the box.
- All content is present as flat-files so developers can use all the tools they typically use.
- Easy to rollback.
- This is the most homogenous approach for most web developers thanks to the existing git-based workflow.
- No vendor lock-in.
- Simple setup.
- If you want to use several apps or sites to pull content from the same CMS, a git-based option might not be the best solution.
- If your site has tons of content, you may want to look into the database instead.
- If you plan on changing content rapidly, like new posts every minute, the Git-based option is not the best option for you.
- Limited options. Less control over content model and formating.
With API-first CMSs, you have been given access to an API, typically a REST API or GraphQL, that serves the content. So, you are getting your data and the way it is structured but it depends on you to choose which framework and language you will use to work with it.
- This is the best solution if you have several different apps or websites that pull the same managed content.
- Easy to use content with multiple front-ends.
- Many available options give you an ability to customize CMS completely to your liking.
- It can handle huge amounts of data.
- This version is not controlled in Git and it is also not integrated into developer workflow as git-based CMS. Now, although this is more of a difference in architecture and approach, some people take it as a downside. I’m just making you aware of it.
- Usually comes with storage and API usage limits. It can be costly if you don’t plan things well.
- Dependancy on devs for bigger changes.
Now that we got that out of our way, let’s take a look at the benefits and disadvantages of each of these systems one should keep in mind when choosing a headless CMS for your next project.
SIGN UP for our newsletter
Get our EXCLUSIVE web development case studies in your mailbox!
Traditional CMS platforms such as Drupal, Kirby, and Wordpress have limited versioning which means they either track single object graphs or maintain clunky data structures.
Nothing wrong with this approach for basic content management needs - for example, blogs or very simple websites but they’re not even close to offering a multi-asset digital experience which is a necessity for most brands nowadays.
The ability to fall back to the previous version of a file is suitable for basic content editing but not for some real-world scenarios such as legal audits, company rebrandings, and future developments that require a more sophisticated CMS.
That’s why the multi-object versioning approach, like the one in the programming space, is necessary. Also, Git is today’s most popular version control system for tracking changes in source code and it’s not difficult to see why today’s digital experience requires both the content and technical component.
Contrary to traditional CMS models, Git allows developers to have their own local and intermediary repositories, all born from a parent repository.
Distributing the versioning and workflow is fast and easy!
With the Git-based system, devs can work locally and still be part of the CMS. This means that the devs can use the tools they prefer and work with daily, with no restraint.
Thanks to branches you can create preview and almost unlimited staging environments which makes development easier in general. Both developers and authors can experiment and work on major features and site enhancements.
Traditional CMS platforms are not able to deliver such an experience but an API-based CMS can. All brands need to do is to simply develop an API for that device or touchpoint and then plug it into their stack.
There are absolutely no restrictions on what device you can deliver experiences.
Thanks to the API-driven environment, brands can freely integrate their most liked marketing tools such as marketing automation, CRM, and analytics. They can also remove them at any time. This gives brands the ability to quickly change their digital experience platform the way they see it fit.
With API-based CMS, all the content is stored centrally which enables brands to deliver their content to any channel. This means that the content creators can write their content once and then repurpose it for any channel or device. In the omnichannel world of today, this comes as a huge benefit as it saves a lot of time and removes the need of having to create content for each channel separately.
Git was not known as an SEO-friendly solution for a long time since there was no specific support for improving SEO. To have better visibility, you’ll need to take some steps such as generating a sitemap, using metatags and open graph tags, and also making sure to have a mobile-friendly theme.
Github is known for not running plugins. If something needs to be customized it can be easily mitigated by pushing locally generated content.
Need to create custom front-end on API-based CMS creates additional work for your team. This will also require constant communication between marketing and web dev teams for any changes that need to be made.
API-based CMS solutions come with a back-end editor that allows content creators to input their content. However, there are still CMS that do not allow you to preview your content before you publish it or the draft option is something you have to set it out yourself. No being able to see how the pages look and feel from the users’ side is often a disadvantage as it leaves little to no room for mistakes.
There are certain costs that you’ll need to keep in mind with the use of API-first CMSs even the open-source one. This includes infrastructure costs (hosting, CDNs, etc. for self-hosted CMSs) but also development, maintenance, and security costs since you’ll be working on a custom made back-end.
No easy answer here. For example, we’ve here found that if you don’t need to create hundreds of posts/pages and rebuild the website every couple of seconds, Git-based CMS is a far better option.
Of course, it depends on your project needs. It is on the whole team (devs, and marketers) to understand the scale of the project, budget, and available dev time (yes, that’s an actual requirement) but also the tech behind it all.
Storyblok - https://www.storyblok.com/
Contentful - https://www.contentful.com
Sanity - https://sanity.io
Dato CMS - https://www.datocms.com/
Prismic - https://prismic.io
Ghost - https://ghost.org
Strapi - https://strapi.io
Kontent - https://kontent.ai/
Cloud CMS - https://www.cloudcms.com
Directus - https://directus.io
Rooftop - https://www.rooftopcms.com
CLICK HERE to schedule 1-on-1 talk and learn more about what we can do for you and your business.