What is headless?

If you have looked at recent trends in website development, you may have came across terms like “Headless CMS”, “Decoupled CMS”, “Fully Decoupled”, “Partially Decoupled”, or “Progressively Decoupled”. For the most part, these terms are just different ways to describe a few variants of an architecture where the front and back ends of a website are managed by different systems. These methods are becoming more popular in the sphere of websites built with a robust content management system, like Drupal, because there is a distinct lack of flexibility in the frontend capabilities of the various CMS out there right now.

The first thing to cover here is the distinction between headless and decoupled as they are not synonyms for the same approach in this. Headless, in this case, refers to the CMS not having a frontend head of its own in the equation. For example, this would be a Drupal CMS without any sort of GUI. Decoupled is the term that describes the architecture used with a headless CMS. The frontend is decoupled from the backend system and they are now in a spot where they are managed separately.

Traditional Website versus decoupled CMS versus partially decoupled CMS
It's not as complicated as it looks.

As you can see, the traditional dynamic website model has the CMS responsible for the front and back ends of the site. This means that it not only is in charge of storing information about the content, it is also powering the display directly. This could mean it is making use of various libraries or methods to display the content, but those rules are managed in the CMS and not anywhere else.

With the description we covered briefly before, it becomes a bit more clear how a decoupled setup is a bit different. In this scenario, the CMS backend will behave like any other service with an API and simply is used as the content management and storage. The decoupled frontend framework will then be able to consume the content via the API and display it according to the rules setup there. It may sound like more to keep track of and manage, and though that isn't necessarily wrong, it isn’t as complex as it may seem.

Wondering if a decoupled site is right for your project?

What does Decoupling Change?

Content driven websites, and really most websites, are a quite a bit easier to manage in content management system. This has been a fairly common conclusion that many website developers have come to over the last decade. They tend to offer a nice collection of tools that make both development teams and editors happy without being overly difficult to use for either of those groups. What comes with all of those tools and robust features is a bit of weight and restriction on certain aspects of the website. While the top CMS options out there are incredibly flexible, they are not exempt from having these inherent restrictions. It would be difficult to make a generic one-size-fits-all type tool and not have some limitations.

The restrictions tend to clump up on the frontend aspects of the website. Themes and custom code become required to do anything significantly different with the frontend. While that isn’t wholly a bad thing, it can be difficult when you have specific needs for the design of the site or you are trying to tightly control the markup of the website. This is the biggest thing that decoupling changes about the approach, it solves a pain point that a few have with an otherwise fantastic solution.

Freeing up the frontend of the website to be something much different and more flexible actually allows the CMS behind it to be even more useful than before. All of the permission and security handling that is inherent to those systems can be leveraged without the risk of majorly hacking the display layer to meet your specific needs. A change like this isn’t coming from the CMS being a bad fit, but actually makes better use of why it was a great fit in the first place.

Decoupled CMS feeds apps and website

Should you decouple?

The answer to whether you should have a decoupled website setup is a bit more complex than a simple yes or no. There are quite a few follow up questions that should be asked along with that. Rather than generically say that everyone should or shouldn’t have a decoupled website, it is probably more useful to describe in a bit more detail what decoupling is for and what it isn’t for.

Decoupling your website is for:

  • Easily creating reusable design aspects of the website

  • More easily redesigning the look of the website without worrying about the back

  • Taking advantage of the latest frontend approaches

  • Future-proofing an important website

Decoupling your website isn’t for:

  • Improving performance of your website

  • Reducing overall complexity

  • A team that isn’t familiar with any of the new frontend solutions (React, Angular, etc)

  • Providing a quick facelift to a large website (More on that later)

More than just trying to be showy, a decoupled architecture can be a big benefit to the longevity of your website. The next time your site needs a facelift, you won’t have to immediately worry about swapping out the backend to accommodate the new look and feel. Not to mention the freedom of design it offers frontend teams for your site. Without the oddities and restrictions that inevitably come with using a CMS or complicated backend, clean and simple markup is a lot easier to achieve. This will help ensure cross-browser compatibility can be maintained without having to majorly hack things together on the backend.

The Heads in Headless

One of the biggest drivers in making use of the decoupled approach for websites is the ability to make use of the latest technology for the frontend. In a time when browser and device compatibility is paramount, your website has to look great in an even wider variety of situations that before. This is much more easily accomplished when employing one of the new JavaScript based frameworks that have become popular lately.

React and Angular are some of the most popular in the category of JavaScript frameworks right now and for good reason. These frameworks allow for a different method of development for websites that isn’t as easily available to more backend focused solutions out there.

AngularJS by Google

Angular and AngularJS

There aren't many JavaScript-based frameworks that have been as consistently popular as Angular. Developed by teams at Google, this open-source framework has been used as a decoupled frontend for a while now. It even spawned a development and website stack that has become the basis for a large number of websites, MEAN. (MongoDB, Express.js, Angular, and NodeJS) With the release of version 2, Angular has seen continued adoption from the development community and should be around for a while.

ReactJS by Facebook

ReactJS

Originally developed for Facebook, React has been made open-source and available for all to use. It is another JavaScript-based framework has been gaining popularity rather quickly. React is mostly known for making single-page applications and easily creating native applications for smart devices with the same codebase. There is some debate in the developer community as to whether React is a framework or a library, because it doesn't come with all of the pieces needed to run an application when you download it by itself. We feel like the lightweight-nature of that is one of the perks of using React over other options.

But really, do you need a decoupled website?

Maybe. There are a lot of deciding factors that go into a decision as broad as should your website be decoupled. We’ve covered them above, but the short of it is that  It is nearly impossible to generically recommend any single approach for all web projects. Even when subdividing into specific categories and verticals, it is still difficult to unilaterally suggest that one technology is a superior solution to all others. The best way to determine the needs for your project is to get the details and requirements sorted out.

We feel that many new projects would benefit from the longer-term perks of a decoupled architecture with a headless CMS like Drupal. Being able to make major changes to the front or back of a site without interrupting the other solves some major pain points that almost all websites face. The portability is huge and even more it allows use of much more cutting edge technology on the frontend than ever before. Needless to say, we at Ashday are pretty big fans of this sort of approach.

Still not sure about this headless thing?

Your upcoming web project might be a perfect fit for a decoupled or headless setup. We've been doing this long enough that we can give you the advice you need to make that decision.