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

AWS Lambda and containers

Did you know that you can package and deploy containerized AWS Lambda functions? This capability was introduced in 2019. Amazon AWS also provides base images in Python, Nodes, Java, .Net, and other supported runtimes. Photo by Tom Fisk from Pexels There are prerequisites and limitations which you can take a deeper dive in this article from AWS documentation. In general, consider Lambda for event-driven applications, meaning for solutions that are not continuously running.The AWS Lambda container approach supports: Consistency in the set of tools used for the Lambda-based applications Your image can be up to 10 GB You get the same benefits as the function packages, such as familiar container tooling, automatic scaling, high availability, and others There are existing base images for Lambda, available on ECR public and Docker hub that you can leverage In addition, AWS has made available a set of packages  that implement the Lambda Runtime API, allowing developers to seamlessly extend th

Essence of email deliverability - SPF, DKIM, DMARC and segmentation

Recently I attended a lively discussion on email deliverability hosted by Litmus, one of the leading providers of email marketing tools. As email marketers one of the core metrics we often rely on is email deliverability and the discussion was around how to improve the email deliverability in today’s world where our audiences are ever inundated with emails. In addition we often find ourselves operating in a very competitive landscape vying for these audiences' precious attention. Photo by Ivan Samkov from Pexels   Hence it’s becoming increasingly important to ensure our emails are reaching our audiences’ inbox and driving engagement. This is why email clicks and engagement are strong indicators of the performance of our email campaigns instead of just the delivery rate of our campaigns partly thanks to Apple’s Mail Privacy Protection . So let’s start with the distinction between email delivery and email deliverability . This is very well articulated by Dimiter Batmaziam in the Li

Adobe Summit 2022 - Email nurturing takeaways

I had the pleasure of attending a number of sessions at the 2022 Adobe Summit and one of those sessions was by Don Mayberry on the importance of email nurturing in driving business outcomes. Don shared many interesting perspectives on email nurturing and strategies that really resonated with me. Don described these concepts through the lens of Marketo Engage but they can be easily applied using other marketing automation tools in the market including Adobe Campaign Classic, Salesforce Marketing Cloud, HubSpot, etc.  Photo by Richard Horvath on Unsplash Here are the key three (3) takeaways: Don compared the importance of nurturing email campaigns in generating sales to the nurturing of a young plant until it bears fruit. He highlighted that nurturing email campaigns may not lead to sales conversion right away however if done correctly it will sow the seed for future conversions. Don shared six (6) nurture tracks for email marketing.  The Red Carpet Track - An example of this is

Adobe Summit 2022 - Experience Platform

 Our hero image features many air balloons flying, scattered in a blue sky. Each of them has characteristics in their designs that are “part of a whole”, which in this case is an exhibition that is part of a festival. Now, let us leverage this analogy, mapping it to the elements that are relevant for this post’s agenda. Think about the pieces of data scattered through different systems, which combined (behaviour and PII data) becomes part of a whole: an enriched consumer profile that can provide you a “360 view”. This allows corporations to find opportunities, and turn them into value: “enabling ways to engage with that customer(s) to meet a cluster of business goals.” Photo by Lad Fury from Pexels   The objectives for this article are: To provide our takeaways from two (2) Adobe summit 2022 sessions, related to the Adobe Experience Platform and Real-time CDP (Customer Data Platform). Those sessions being S401 (AEP a modern foundation - by Klaasjan Tukler) and  S408 (DMP vs CDP:

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