Skip to main content

Headless CMS - yet another CMS comparison

[PLACEHOLDER]

If you have used, or are familiar with the term headless CMS (content management system), then you will know the reason behind it. In summary a CMS is called headless because there is no Front end (FE), or output coupled with the CMS. Instead the CMS supports APIs which expose the content that can be consumed by external applications.

                                                    Photo by fotografierende from Pexels


We could say that a decoupling from the CMS is provided, allowing, for those that have chosen this alternative, a certain sense of “freedom” in selecting the FE of the solution.

There are many reasons for selecting the most popular, and so called “traditional” CMSs in the market. Even though, not sure if it is proper to call them “traditional” anymore as they keep evolving, becoming stronger and versatile and offering new services including SaaS. Even some are providing a flavor of headless. I have my fair share of experience using some of the greatest CMSs in the market. This includes Adobe AEM, Sitecore, Umbraco and OpenText teamsite. I used some of them as a developer and others I hold certifications. I also have experience as a product owner in an implementation that supports multiple regions, in a multi-tenancy and/or multi-site and multi-language setup.

But on this occasion, I wanted to focus on this different breed of CMSs. I started my research based on a friend’s request for guidance on a CMS option for his startup. His solution architecture requires a CMS as part of to support his business. He wanted an inexpensive option that allowed him to start, with enough flexibility, in case the new designer and FE development team would like to change the current layout and the creative, as well as eventually do an overhaul of the tech stack selected in the initial phase. His current team is small and focused on development. Consequently I recommended him to explore the headless CMS approach.

Why headless CMS?


Developers enjoy this approach as it is easy to maintain (from a developer’s point of view). Some of the reasons of why that is can be found in the following NFRs (non functional requirements):

  • Flexible: the decoupling, makes it easier for the developer, reducing the dependency.
  • Compatibility: publish to any FE using APIs.
  • Security: reduces attacks, or at least some additional level of security as regularly the APIs of this type of CMS are read-only. As well as, having an API system already in place then developers can work on adding additional security layers, making it less vulnerable.
  • Scalability: FE and BE separation. Allowing easier FE customization, without compromising the BE.
  • Control: freedom to the developer in using the content from the CMS to render on the FE.


Note:
As everything there are some Cons around headless CMS. If you would ask me, the one that is tricky is the “preview” feature, which is to see a live preview of the page that you are authoring. In a headless approach this is not possible to achieve unless you actually develop the preview functionality as well.


Which one was the CMS selected?

There are many variables that need to be evaluated before selecting a vendor and/or product. There is also the risk factor, and we cannot forget about the budget.

As I mentioned in a few paragraphs above, I was in this quest of assisting my friend in selecting the CMS for the startup.

I ended up evaluating seven (7) great CMS alternatives. I reduced the list to 3 for which my friend's team performed Proof-of-Concept (POCs), and eventually I landed on my recommendation.

Some of the criteria I took under account:

  • The community behind it, as well as the product documentation.
  • The tech stack used by/with the CMS.
  • How can the CMS be hosted (cloud, on-prem, hybrid)?
  • How easy was the installation, and get it operational?
  • Integration: How easy the tech stack already selected for the current FE could work with the CMS?
  • The Cost. Is the CMS open-source or not? What would be the potential cost for support, and related services, if the startup grows?


Here is a helpful table that GeekFlare put together in one of their posts (If you want to read their complete list, as well as their good article about headless CMS options, then go to the reference section at the end of this article):


CMS Open source? Highlights Type
Directus Yes Headless CMS managing not workflow but the content API
Contentful No Content management developer platform managed by an API core API
Kentico Kontent No Headless CMS based on cloud computing services API
Prismic No CMS handled by API which serves as a backend for websites and apps API
Squidex Yes Headless CMS which is scalable for developers API
Strapi Yes Most developed Node.js CMS aiding in building powerful API conveniently API
Scrivito No CMS based on cloud computing and ReactJS, set up for digital agencies and large-scale businesses API

So, how did it end?

The team ended by selecting Strapi CMS because of the following four (4) reasons:

  1. Good documentation
  2. Different options for installation
  3. Different framework options such as NuxtJS and React. The development team is currently deciding which of the two (2) they will be selecting.
  4. Open source, with an option to Enterprise features for a price
  5. The use of GraphQL



Additional research:


 

 

Trending posts

AGILE For DIGITAL AGENCIES

Introduction Some Digital agencies have a project process where waterfalls still plays a big part of it, and as far as I can tell, the tech team is usually the one suffering as they are at the last part of the chain left with limited budget and time for execution. I do believe that adopting an Agile approach could make a Digital Agency better and faster. In this article I’m presenting you just another point of view of why it make sense looking at Agile Methodology.  Why Agile for a Digital Agency? The Agile movement started in the software development industry, but it has being proven to be useful in others as well. It becomes handy for the type of business that has changing priorities, changing requirements and flexible deliverables. In the Digital Agency of today you need a different mindset. Creative will always play a huge role (“the bread and butter”). But the “big guys” need to understand that without technology there is no Digital Agency. Technical resources are

AI with great power comes responsibility

Generative AI continues to be front and centre of all topics. Companies continue to make an effort for making sense of the technology, investing in their teams, as well as vendors/providers in order to “crack” those use cases that will give them the advantage in this competitive market, and while we are still in this phase of the “AI revolution” where things are still getting sorted.   Photo by Google DeepMind on Unsplash I bet that Uncle Ben’s advise could go beyond Peter Parker, as many of us can make use of that wisdom due to the many things that are currently happening. AI would not be the exception when using this iconic phrase from one of the best comics out there. Uncle Ben and Peter Parker - Spiderman A short list of products out there in the space of generated AI: Text to image Dall.E-2 Fotor Midjourney NightCafe Adobe Firefly

Designing Habit Forming Mobile Application

Mobile Applications have become an integral part of our daily lives - we use mobile apps as alarm clocks to wake us up in the morning, to create to do lists when we start our day, to communicate with our colleagues at work via apps like Skype. We even check reviews of restaurants to visit on apps like Yelp and we seek entertainment on apps like Netflix and spotify. So what drives us to use these apps so seamlessly in our daily lives? Why we prefer some apps over others? Is there a science behind designing successful mobile apps like Facebook?  Photo by Peter C from Pexels A study in US revealed that a user between the age of 18 and 44 visits the Facebook app on average 14 times a day [1]. This shows that using the Facebook app is a daily routine for many of its users. This makes Facebook a great example of a habit forming mobile app which is designed with human psychology in mind that encourages habit forming behavior in its users .   I recently attended a seminar on the de

Research around JIRA vs TFS

By: Carlos G.    An opportunity came from a colleague to discuss the case of company “X” for improving the ALM by introducing tools to this company. The challenge was to decide between Microsoft and Attlasian . He came to me because I’m a Microsoft kind of guy and he wanted the opinion from my perspective, not as a consultant, but as a friend of what he was trying to accomplish. He said that even though I was inclined to a technology I was able to explore other things and be “fair”. I agreed to be a part of his research because of 3 things: because of my curiosity I'm always willing to learn new techy stuff. Sometimes is good to be the dumbest one of the group. You learn so much! This was a story that I could blog about. (Of course no names are used in this post). My first impression was thinking “cool”; let’s compare Visual Studio TFS vs JIRA. Immediately I got a comment back with: “ Sure but JIRA by itself is more like an issue tracker in simple terms ”. That sa

This blog uses cookies to improve your browsing experience. Simple analytics might be in place for pageviews purposes. They are harmless and never personally identify you.

Agreed