Headless, Decoupled and Coupled CMS

First, let’s look into the evolution of CMS systems. The web has seen many CMS (content management systems) applications, but they can be grouped into three main categories, based on what they aim to achieve.

Headless content management systems have gained popularity due to the abundant development of Jamstack technology [1]. Head means the frontend. When you decide on a headless CMS, you will most probably end up with a database, a standard backend, and a form of a dashboard interface for managing content. The content is exposed via API without any responsibility for how it is displayed. Naturally, the next step would be choosing a frontend technology layer for rendering content based on consumed API for example from rich ECMAScript, JavaScript (ES, JS) and TypeScript (TS) ecosystem.

For Decoupled solutions, the situation is subtly different. In this type of architecture, the content management application not only allows you to input and modify content but also partially controls the presentation of its data (e.g. via a WYSIWYG editor). Unlike traditional CMS systems, communication with decoupled CMS takes place from an integrated database via API, which allows you to build distributed services. Such an approach to CMS is more scalable and efficient than those based on coupled, although still largely dependent on the frontend push of the presentation layer of the CMS itself.

In the case of Coupled CMS applications, the system owns every incoming request. Each request is processed by the CMS, which maps it to the content and templates and returns the result. The content and presentation management takes place in the same system, which can be described as full stack (so both frontend and backend) or monolithic. That makes coupled content management systems pose limitations in scalability and distribution of and as any framework - may end up as a cage.

Strapi - The Headless CMS

Strapi is an open source headless type CMS. It is a relatively young framework, published first on GitHub in 2015. Compared to global usage of content management systems and frameworks, Strapi represents less than 0.1% absolute and market share [2] [3]. However, the number of implementations have increased steadily over time [4] [5].

Strapi offers a high level of granularity to build your own API (application programming interface) even without expertise in the field of backend technologies. This is true for both configuring content types, fields, components, and of course, building the content itself and managing it all in one dashboard. It’s also completely agnostic to the kind of code editor of choice that a developer prefers.

Strapi Pros and Cons

Migrating from Monolithic CMS

Strapi offers great flexibility and very granular (low-level) modeling of APIs, which may be created by this software. It has some drawbacks when it comes to migrating data and structure from classic CMSs (like WordPress). In most cases, a headless CMS requires a dedicated solution (so additional code development).

The process involved creating a data structure in Strapi API and later a type of middleware which translates data and structure from traditional CMS to Strapi. However, this inconvenience is just a consequence of Strapi’s features allowing in-depth control of every detail in data and structure at a very low level. This means even very subtle or significant modifications can be made easily, and most importantly, independently when working across multiple teams.

Breaking Changes

The application is updated quite frequently, consisting of improvements, bug fixes, new features, which are great for overall security and futureproofing, but in rare cases may result in changes that break already developed APIs.

For example, the latest Major v4 version changed database structure in Q4 2021, and migration instructions from v3 are planned to be released in March 2022. This is subject to change in the near future, as Strapi becomes more stable and mature with time.

TypeScript Support

TypeScript is a typed programming language, proven to be a powerhouse at maintaining and developing complex and large-scale implementations. Unfortunately, Strapi doesn’t support it without custom modifications. It is planned to be introduced to the core, but there is no specific date for this feature yet.

CI/CD

Developing and hosting production Strapi requires slightly more sophisticated DevOps resources compared to traditional CMS like WordPress running on PHP and Apache or Nginx. This also creates a need to implement continuous integration and development processes, which helps to improve the stability of the codebase and maintenance over time.

WordPress - The Monolithic CMS

WordPress is an open source coupled type content management system CMS used by millions of developers worldwide. The sheer magnitude of people using and maintaining it accounts for more than 43% of CMS usage in comparison to other solutions. It claims over a 65% market share worldwide [6]. WordPress dates back to 2003, and has remained one of the most popular choices for content delivery ever since.

WordPress can be considered a truly traditional CMS, coupling the frontend and backend from a dashboard and Gutenberg (sort of WYSIWYG editor, powered by React.js) [7]. Even though many pro-Strapi developers have the opinion that WordPress core technology is outdated, there is actually no limit to transform it into a decoupled or headless system, thanks to native REST API [8] and community driven GraphQL interface support [9].

WordPress Pros and Cons

Backwards Compatibility

WordPress has constantly made progress in developing its platform and supports PHP, including versions marked as deprecated. This ensures that every WordPress powered website will perform as intended, regardless of the hosting provider you use. It also means that your theme and plugins will continue to work even after updating WordPress to the latest version.

In the long run, a stable platform means your website is less prone to downtime, but at the same time it may be vulnerable to attacks and performance degradation due to the obsolete code.

Versatility of Applications

The WordPress CMS was originally a simple blogging platform. However, templating and plugin APIs in combination with a huge community of developers resulted in an abundant codebase of extending functionalities allowing to build on top of this CMS almost any kind of web app - ranging from a single-page website, to full-fledged e-commerce store with payment processing and stock management.

The availability of multiple themes and plugins in the form of visual wizards (so-called Page Builders), allows the creation of entire websites by non-technical people, using numerous predefined templates and themed content.

However, many “homebrewed” WordPress applications remain slow, vulnerable to exploits, and typically don’t show the full potential of the technology. Many examples of poor WordPress sites are out there, and they are often used as examples of moving beyond simple monolithic applications.

Full Documentation & Extensive Codebase

One of the most important features influencing the choice of technology when creating projects is its development and technical support from the authors and the community using the platform. In this regard, WordPress’ detailed, clear and developer-friendly documentation with many use cases of this CMS can set a nice example to follow [10]. The community behind WordPress is significant, and able to help in solving many problems.

On the other hand, the low barrier to entry attracts many amateurs to WordPress. The effects are that there are many sites built using bad practices (e.g. ready-made website templates and plugins of dubious quality). The vast array of themes and plugins that extend WordPress functionalities do not always follow best development practices and may pose a risk of introducing technological debt if not used wisely.

So, Strapi or WordPress?

No matter how popular a given software architecture is, following the hype is never the correct way to form a decision. It all comes down to business requirements, preferences of the developers themselves, and the conditions you want to set for growth in the future.

The argument for WordPress

For example, if you own a family business, sole proprietorship, or you want to stay on a well-known platform of your choice, WordPress can be a better solution than Strapi, as it allows you to make an entire business site in a few hours — and maintain it easily over time.

If you need an e-commerce system with a low start-up cost and low cost of ownership with less than a thousand products, WordPress with WooCommerce can be a great choice.

As a developer who loves frontend technologies such as React.js or Vue.js, WordPress enables headless or decoupled operation (via REST API or GraphQL), so you will not have to worry about influence of backend operations on frontend page load speed.

The argument for Strapi

Strapi is more suitable when it comes to a strictly headless approach, unlimited scalability and customizations at each small detail. Due to the complexity of present web applications and methods of delivering content, often based on microservices, companies tend to use pure headless solutions for CMS accompanied by mature frontend technologies for the presentation layer.

For large teams of developers, Strapi can offer outstanding developer experiences, breaking down projects and work into smaller chunks that improve productivity and time to market. Strapi accommodates a wide range of versatile applications, tools, and technologies, so developers with different objectives or goals might prefer Strapi as a way to unify work.

With time, it is very likely that Strapi’s codebase (with its open-source community-driven plugins) will follow a similar path as for WordPress. It’s possible that Strapi becomes more accessible to non-technical people over time, which could increase adoption and make it a direct competitor to WordPress.