Skip to main content

Headless CMS - yet another CMS comparison

[PLACEHOLDER]
Image

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

SLA-SLO-SLI and DevOps metrics

Companies are in need of the metrics that will allow them to stay in business by making sure they meet the expectations of their customers. The name of the game is higher customer satisfaction by winning their trust and loyalty. To do so, you want to provide good products and services. Therefore you need to find ways to monitor performance, drive continuous improvements and deliver the quality expected by the consumer in this highly competitive market. Photos from AlphaTradeZone via Pexel and Spacejoy via Unsplash SLAs, SLOs and SLIs are a good way to achieve the above. They allow clients and vendors to be on the same page when it comes to expected system performance. If we go one level deeper, vendors/providers work on NFRs (Non-Functional Requirements) when working on their solutions. NFRs define the quality attributes of a system. I bring them up because the relationship between them and the SLAs is that they provide, in a way, foundational aspects for the SLA-SLO-SL...
Read more

AI Agents is the new thing to talk about

Tech is evolving faster than ever in this AI era, that it feels every week there is something new to talk about, and what you learn weeks back is no longer relevant, or “that AI tools” already has gone through changes that you need to catch up with in order to stay relevant.  Fear not, embrace the challenges and learnings, and find applications for it that are good and ethical for this present, and the hereafter.  The new “craze” is AI agents, and for good reason!  Image generated with NightCafe In contrast with AI chatbots, an AI agent can execute tasks on your behalf. If you are thinking “ that this could be agents that we leave running independently for many days for a group of deliveries ”… Well then you are correct! Are there risks? Should we talk about trust and accountability? The answer for both is yes. I already hinted at it a couple of paragraphs above, when I wrote “ good and ethical ”. AI (Artificial Intelligence) agents are software that work autonomously,...
Read more

SRE, DevOps and ITOps

 If you are wondering what the differences between the SRE and DevOps are, as well as how these roles work with ITOps within an organisation then you are not alone; and best of all you are on the right blog post. Often enough business units in a company get confused, assigning the ServiceNow or Jira tickets or any other ticketing system of your preference, to the wrong group, and even having the incorrect expectations when doing resourcing. Let us go through definitions, insights and scenarios that will help you understand the difference. DevOps software development operations - AI Generated When it comes to DevOps and SRE, then you might be wondering which practice came first. While SRE may have originated a bit earlier, internally at Google, DevOps came first publicly as a practice and started to be used by companies. A few years later was when Google decided to open SRE to the world after the publication of the "Site Reliability Engineering" book. Therefore, technically sp...
Read more

The value of listening

 Have you ever been in a conversation that you feel at best is just a waste of time; at worst, that the other person does not care? Have you been the messenger in some of them, the recipient in another? We’ve all been there; at times with family, with friends, at work. When at work, has this ever happened to you in a group meeting, at a one-on-one; when giving or receiving feedback?   Photo by Christina Morillo via Pexels   I knew the type of manager I wanted to be from the start of my mentorship. As I continued to navigate the waters, it became increasingly clear that the path I had chosen was appropriate, and therefore, the type of future colleagues I wanted to be surrounded by, and the type of mentors I wanted to continue seeking guidance from.  For me, the path has always been of being a leader over a manager. I believe I can attribute that, first and foremost, to my family’s values and  principles, and the way my parents raised us. Secondly, my path in the ...
Read more

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