I’ve noticed throughout the years discussions about monolithic architectures, which were usually contrasted with either Microservices or Headless – depending on the zoom level of the conversation. Of course, before “headless” was the latest, shiniest thing, the discussion was mostly about microservices. I’d like to point your attention to the “vs.” part.

For me, it shows two groups fighting each other to establish one truth and settle the dispute once and for all. One can then declare a winner and say that “Monolith/Microservices/Headless/Any other system is the way to go.” Truth is a bit more complicated than that.

Let us then explore how to avoid “vs.” conversations and extract real value from this dilemma.

Before we jump into an analysis of Monolith and Headless, let me set the mood for the rest of this article. In such conversations, one critical word should always shine above anything else: Pragmatism.

This article is not about declaring a winner or finding one approach for all scenarios. Rather, we are looking for the practical application of the solution that is the best fit for any given scenario.

As a Tech Lead, a Developer, or a Project Manager, one should not be married to any particular technology, system, or methodology. Each project decision should be measured by the value it brings to the table. There are many angles to the resulting value, and we will not discuss them here. This article aims to describe the main differences between Monolith and Headless and see what conclusions we can draw from them.

Let’s start by defining Monolithic and Headless.

Monolithic CMS – Includes Rendering (presenting data through an interface, i.e., a website), Data Layer (where content lives, i.e., database), and User Management all in one package.
Headless CMS – Includes only Data Layer and User Management. Rendering is done externally through an API.

Here is a picture illustrating the main difference between the two approaches:

Monolithic CMS

The most popular monolithic CMS, by a large margin, is WordPress. Every web developer, at some point in their career, has used WordPress or worked with it. WordPress is a powerful tool allowing people, companies, and organizations to quickly create, launch, and modify a web blog, portal, or just a one-page website.

There are two options to get started with WordPress:

A WordPress SaaS offering with a website builder
A standalone WordPress installation hosted on-premise

We will explore the latter as it is relevant to the conversation.

Pros of a monolithic CMS (WordPress)

Get started quickly
Default templates available
Powerful CMS capabilities out of the box
Rich WordPress ecosystem with thousands of useful plugins
Everything is included in one installation copy – deploy once, enjoy the product
The WordPress API is easy to get started

Cons of a monolithic CMS (WordPress)

You have to host it yourself
It is hard to maintain and scale for complex scenarios
The self-enclosing system makes it hard to extend it to external pieces of the project
The technology stack is not attractive to developers
A lot of the built-in functionality will be redundant for each particular scenario
Reliance on plugins, which adds extra stability and security concerns that need to be addressed
The WordPress API requires significant work to bring it to the level required in more complex project scenarios

Other great Monolithic CMSs worth mentioning are Drupal, Concrete5, and Joomla. All of them are valuable in their own right. We won’t analyze them all since (more or less) they are operating under the same principles as WordPress.

Headless CMS

The Headless space is much more diversified. For some, this can be a con, but having many options is good. Like Monolithic CMS, Headless CMS comes with both self-hosted and SaaS variants. Because of the nature of Headless CMS, SaaS offerings seem to be more and more attractive these days, contrary to Monolithic CMS, where a self-hosted solution is more flexible. That’s the nature of the beast.

Let’s then consider SaaS offerings out there. Contentstack, Contentful, and Hygraph seem to be the most popular ones when writing this article. Strapi, a self-hosted alternative, is also worth mentioning. If SaaS is something you’d rather avoid in your project, then Strapi is certainly worth looking at.

As for the Pros/Cons example, let’s take Contentstack.

Pros of a Headless CMS (Contentstack)

Flexible and powerful API
Shines at scale
Built for Content Managers, so it’s easy to manage campaigns, workflows, data models, and more
While a SaaS, it also offers custom integrations with e-commerce and other tools
Built to be consumed in an omnichannel approach
No need for in-house maintenance
Responsible only for the content (single-responsibility principle)
Easy-to-use SDKs for various programming languages
Great enterprise-level support

Cons of a Headless CMS (Contentstack)

You have to build your website’s front end yourself (the website is just a part of the omnichannel strategy, just like a native mobile app)
Responsibility for proper data consumption in the target applications
Pricing at a smaller scale
Requires entry-level expertise in content data models and how to build them correctly

Monolithic as Headless?

Another interesting question arises once we remove the “vs.” part from the conversation. What if we could go Headless with Monolithic? It is certainly possible! WordPress offers such an option through its API. Of course, all the usual questions apply, but it’s worth knowing the possibilities.

Headless WordPress is still a self-hosted solution. It’s worth looking at the pros and cons and what we are losing with it before making any decision related to that move. It is, though, a great opportunity for companies with existing WordPress setups to expand to Omni-Channel or to accommodate data from other sources, like e-commerce.

Decision-making

Now, we have a better understanding of Monolithic and Headless CMS features. Let’s consider how we could approach the decision-making process.

The first set of questions I would ask is this:

What’s the budget?
What’s the deadline?
Are we using Microservices?
What scale are we considering?
Is the content served only to the website, or are we planning for Omni-Channel?
Are experts available to help us maintain and scale a hosted solution?
Do we have developers who are strong with building interfaces?
What about authorization? Do we have users spanning multiple applications?

This list is, by all means, not complete. It gives us a somewhat clear view of how to tackle the decision-making process. Usually, when such a tactical decision is made, the whole team participates. During such a discovery (or spike), new questions arise, which is good. It’s better to take one more development day to make the right decision than to invest tens of thousands of dollars in the wrong technology.

What’s most important during that discovery period is to remember that each scenario is a bit different. We can utilize our prior experience, but it’s always good to take a fresh look at the options available and pragmatically select tools and technologies.

Do you want to quickly deploy a company blog and don’t plan to re-use its content elsewhere? Are you not concerned with content campaigns just yet? Do you have developers familiar with PHP? Go with WordPress!

Do you plan to use your content in other business areas and have a clear vision of your content campaigns? Are your developers hungry for a diversified technology diet? Consider Contentstack or Strapi.

Another set of questions to consider is:

Are you ready to handle a self-hosted solution?
Is your company considering hiring DevOps staff?
Are you willing to use external contractors to do the implementation and maintenance work for you?
Is your company considering a long-term partnership with a SaaS provider to benefit from their support and expertise?

Conclusion

I hope I was able to illustrate my point, which is: Don’t get caught up in “vs.” discussions. Do not follow the latest buzzwords either. There is not one “right” solution for everything.

Choosing open-source software like WordPress just because it’s free may not always be the best decision. Sometimes paid, headless SaaS offerings will cost less and yield higher value in the long run. Be pragmatic. The world is out there for the taking.

Choose the right tools, and your journey will be much more comfortable.

—

Need help deciding between headless and monolithic CMS? Contact us.

Kamil Wiśniewski

Headless CMS vs Monolithic CMS – What You Need to Know