What is Decoupled?
Breaking It Down
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.
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.
What Does Decoupling Change?
Content driven websites, and really most websites, are 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 messing with 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.
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)
The Heads In Headless
Angular and AngularJS
But Really, Do You Need A Decoupled Website? Maybe.
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.