Decoupled and Headless CMS: An Introduction

Decoupled architecture. It’s making waves in the development community and all for the right reasons.

Separating your back-end from your front-end simply makes sense.

Content management systems like WordPress and Drupal both offer a set of features that streamline development. Features such as:

• User-friendly content authoring panel
• Prebuilt functionality that could be costly to otherwise independently develop
• Documentation to extend and customize the code to specific needs
• Thriving development communities that contribute to the improvement of the platforms

With so much to offer, these content management systems have become staples in the industry, however, there was one small problem.

They were monolithic. This means the front-end and back-end were tied. This bottleneck was frustrating and limiting because of:

• The inability to fully utilize demanding user interfaces and experiences on the front-end
• Certain incompatibility to adopting modern front-end frameworks that utilize a presentational view and client-side state management.
• The lack of web services that could communicate and deliver content to multiple channels

There had to be a way to get the best of worlds, and when these platforms finally caught up and released their APIs, decoupled architecture was just a short step away.

Before proceeding, it’s important to clarify the key difference between decoupled cms and headless cms.

Decoupled and headless aren’t exactly the one and the same, despite the similar guiding principles.

In fact, you can have a decoupled system that is not headless, that is: a presentational API-consuming front-end can live and work jointly with the back-end, though not together as you would expect from a monolithic CMS.

Headless on the other hand specifically means no presentational layer lives on your CMS. Your CMS is simply there to provide an API. Drupal or WordPress can be decoupled easily, but they aren’t headless out of the box.

There is a consistent increase in examples of websites moving towards a headless architecture, and more than to inspire, they prove a point: headless is working.

Which leads to an important question: why?

Answering this is probably the best possible step in ensuring that your next project is headed in the right direction.

Let’s discuss why decoupled systems are logically better for web development in general and potentially for your next project as well.

Is headless architecture what you should consider for your next project?

A brief intro to APIs

Before diving into headless architecture, let’s take a brief history lesson on the technology behind it.

Web development has come a long way, certainly now as the web progressively evolves into web services.

Web services are not a new concept, in fact, it’s been around for more than a decade, but the way that we have begun to utilize them has drastically improved mobile and web development and more importantly, user experience.

Application Programming Interfaces (API) are a central piece of how we currently build our websites.

Most websites today are using APIs in the background to both retrieve/present data and expose their own data to other applications.

If you’re unfamiliar with web services, think of RESTful APIs.

Sending data through XML or JSON format to be consumed by client-side applications.

With certainty, most of the websites you as an end-user visit regularly are already using RESTful APIs to communicate and transfer data in some way or form; for example, Amazon, Twitter, and Google.

In addition to RESTful APIs, there is another popular technique: Asynchronous JavaScript and XML (AJAX).

Incorporating AJAX techniques on your website allows the ability to fetch data for a specific component of your website is far more efficient than reloading the entire page.

Furthermore, writing your backend to provide REST API means that your service was scalable and performant, not to mention simpler to implement and build.

AJAX techniques and RESTful APIs are prominent and battle-tested solutions, and thus accordingly are the pillars that uphold most of the current web.

These techniques usually work in conjecture. As a result, it was inevitable that this approach to web development would integrate with the software we already love and use to build our sites.

Cheeky Monkey Media Free Tech Dictionary

Traditional / Monolithic Content Management Systems

Traditional (or monolithic) content management systems combine both front-end and back-end code through their use of templates.

They also happen to be the most widely used platforms for content creation and the majority of the web is built with these systems.

Historically, traditional systems functioned well during their inception and prime but quickly began to bottleneck development.

With the fusion of front-end and back-end code, the theming and templating for monolithic CMS was frustrating and limiting.

For this article, we will focus on the most popular platforms, your friendly neighborhood content management platforms: WordPress and Drupal.

WordPress powers roughly 33.7% of the web, with Drupal, also contributing 1.9% of all known websites.

Combined, these evidently popular content management systems power more than a third or 35.6% of the entire internet.

Unfortunately, these platforms were notoriously slow in adapting to modern development trends.

In fact, there have been unofficial RESTful APIs modules/plugins available for both as early as 2008 for Drupal and similarly for WordPress.

Despite this, it was not until 2016 that these simple monolithic systems transcended by providing official APIs.

It could be fair to say that this was revolutionary.

By natively supporting web services, WordPress and Drupal unleashed their full potential.

Now your content authoring system could power mobile apps, and complicated single-page applications and provide incredible user interfaces, without having to use middleware.

But most importantly, this paved the way to finally decouple our front end from the monolithic CMS that Drupal and WordPress previously were.

With the separation of the front-end and back-end, the bottleneck is gone at last!

The next step was to look at the headless.

Going Headless At Last

With all the necessary background information, it’s time to look at what headless actually is.

As previously mentioned decoupled is not the same as headless.

Headless architecture is a subset of decoupling.

Headless Drupal or headless WordPress is a new architecture style that removes the entire presentational concern from the content management system and instead focuses on using the platform as a backend service.

We already know that as monolithic systems, popular content management systems were limiting the flexibility of what could be accomplished on the front end.

While AJAX and RESTful principles were widely adopted, another major leap in web development occurred simultaneously: the rise of JavaScript and JavaScript libraries like React.js.

Short Summary of Modern Javascript Libraries

The key to understanding the demand and eventual push to headless, you really have to look at what technologies out there really take advantage of a decoupled system, to begin with.

There is an abundance of choices available when it comes to javascript libraries, similarly to how there are countless front-end frameworks, (i.e, bootstrap and foundation).
To name a few of these popular Javascript frameworks:

Angular
React
Vue
Backbone.js.

With the release and mass adoption of ECMAScript 6, building applications has become easier and more accessible for developers than ever.

In particular, the ability to create modules and use promises.

Promises, in particular, made working with REST APIs more efficient than what could be accomplished previously.

With these new modern JavaScript frameworks and the new capabilities of ES6, websites were now web apps. You’ve probably heard of at least one of these:

Airbnb
Instagram
Netflix 

These are built with React.js.

As you can see, the power and potential are endless.

So, we ask you again, is headless architecture what you should consider for your next project?

Want more information? Contact us, we are always available to chat!