A New Drupal Development Dilemma: Should You Decouple Your Website?
Learn what headless Drupal is and when you should choose it for your own project.
In this post, we discuss decoupled Drupal. We define it, talk about its most common use cases, its advantages and drawbacks, and, finally, give recommendations as to whether you should make your own Drupal website headless. Walking down the decoupled Drupal path can be either beneficial or detrimental for your business. Read on to know the details.
The world of web technology evolves at a lightning-fast pace. New tools and methods crop up almost every day. Many businesses are tempted to adopt these blindly only because there’s so much hype about them.
Quite often, though, the new “toys” turn out to have hidden drawbacks no one has noticed before. As a result, a company that has fallen for an ultramodern solution may have to face dire consequences of its hasty decision.
These can range from temporary problems in operating a website to its complete crash, causing a loss of revenue and customer base. What could be worse for a business? That’s why scrutinizing every new technology under a microscope before adding it to your ecosystem is vital.
One of the most hotly discussed subjects among the Drupal community at the moment is decoupling. No one argues that this is a breakthrough in Drupal development. It provides a number of great benefits both for developers and business owners.
That said, there can always be a fly in the ointment. Along with the exciting advantages that headless Drupal offers, it also has some unpleasant shortcomings that can significantly affect the operation of a business resource.
In this post, we have reviewed the dark and light spots of decoupled Drupal for you. Before we tackle them, though, let us explain what Drupal without the head actually is.
Decoupled/Headless Drupal: What It Means
Everyone knows that content rules the digital world. However, targeting one group of consumers, as was the case in the past, is no longer enough. According to the data from HubSpot, last year most marketers produced content for three audience segments.
This diversity is, in part, due to the new technological landscape. Tablets, laptops, PCs, Macs, smartphones…the list of devices that consumers use to surf the Internet these days has grown considerably compared to a decade or so ago. Add to that various software platforms, and you’ll see the problem.
They enabled developers to build desktop-like, highly interactive websites and apps with a clear separation between the UI and the database-facing part. This new development paradigm came to be known as decoupling.
Drupal has always been a paradise for content marketers with its custom types and simple administration. The only downside of this CMS is the close ties between the presentation layer and back-end. Everything is handled in one place, as this figure illustrates:
Unfortunately, this “sandbox” arrangement slows down the request-response process. More importantly, from a content marketing perspective, it hinders an equally adequate rendering of content on multiple media.
Under this approach, Drupal’s mission is limited to providing data to all the front-ends that require it. Drupal developers only need to expose specific endpoints through the built-in REST API. Data is exchanged between the back-and and front-end over the HTTP protocol normally in the JSON format, although other options are available as well (e.g., XML).
As we’ve said, decoupling brings Drupal developers and site owners a number of benefits. Let’s have a look at these next.
What Value Does Decoupled Drupal Bring to the Table?
There’s no need to worry how a specific front-end will display the content
That’s the primary advantage of decoupled Drupal, hands down. Of course, it’s crucial to write an efficient content API. Once it’s done, it becomes available for every platform to consume. Whether it’s an Android or iOS powered device, a standard computer monitor, or a smart TV screen, a decoupled Drupal website should render perfectly everywhere.
There’s almost no interdependence between developers responsible for each end
Another great benefit of the headless Drupal approach is a clear distinction between the two teams working on a project. They can handle their own tasks, only occasionally synchronizing with the other group of professionals.
You can hire front-end developers who know little or nothing about the structure and operation of Drupal
All they have to do is ensure that correct data is transmitted from the CMS and the user interface meets the requirements of the respective device or platform. Back-end developers, in turn, can take care of their part of the website. The visual aspect is not their concern.
An arrangement like this contributes to building more robust and secure solutions free of bugs. It also speeds up the development process.
You can upgrade your site in a piecemeal manner
What if you decide to change something in the user interface of your website in the future? With the coupled approach, you would have to tweak both the front-end and back-end.
The headless Drupal option, by contrast, allows front-end developers not to touch the “bottom” part of your website at all. The same goes true for the back-end. Edit, remove, or add any content. These changes will be immediately reflected in the user interface. Front-end developers won’t need to lift a finger.
You can add true interactivity to your website
Thus, front-end developers can make decoupled Drupal websites highly interactive and personalized. A user doesn’t have to click the reload button every time something changes in the UI. Take a look at this site as an example of employing the headless Drupal architecture.
What Are the Most Conspicuous Drawbacks of Decoupled Drupal?
As promising as decoupled Drupal is, it is not an ideal solution for all cases. Here are some things that you should be aware of when considering this development option.
You may end up paying more for a decoupled site
There are several things that can increase the total of the bill if you choose to detach your website’s front-end from its back-end.
You will have to hire front-end pros in addition to the Drupal team
Jack of all trades and master of none. While there are many full-stack developers around, a professional well-versed in one particular technology or technology stack can bring you more value. Thus, having two separate teams responsible for each end is wiser. This, naturally, depletes your budget more than it does with the traditional coupled approach.
You will have to wave good-bye to many of the Drupal off-the-shelf functions
You might be using some inherent Drupal capabilities or contributed modules without even thinking about how they make your life easier until you decide to choose the decoupled path. Then you will suddenly discover that you cannot apply these features to the front-end any longer.
For instance, coupled Drupal allows you to view a page before it goes live. Headless Drupal doesn’t provide this option. Front-end developers will have to create this functionality for each and every front-end where the page is expected to render. The same goes true for many other Drupal features we take for granted, such as presenting the content in a regional language or templating. More time and expenses.
Performance can suffer
You might ask, “How’s that? Decoupled Drupal sites are faster, aren’t they?” They are, but only if front-end developers do some additional work to ensure that.
For example, decoupled Drupal websites can’t take full advantage of the smooth and efficient Drupal caching mechanism. Developers will have to rebuild it almost from scratch. The cache will have to reside on the front-facing side and be kept in sync with the server all the time.
Not all hosting providers can adequately handle the decoupled architecture
You get a conglomerate of apps hard to maintain and debug
Too many cooks spoil the broth. The decoupled Drupal approach suggests a number of front-end apps that consume the same API. This is an advantage and drawback simultaneously. The more apps you have, the harder it becomes to maintain them and ensure their error-free operation.
If something breaks, you might find it hard to identify the source of the problem. Did the app itself send an incorrect request? Did the developers make a mistake when building the API? It may take a lot of patience and time to put things right. Time is money.
To Decouple, or Not to Decouple, That Is the Question
Considering all the pros and cons of the decoupled Drupal approach, it all boils down to specific project requirements. Here are two main cases when headless Drupal will bring you real value:
- You’re going to distribute your content through several channels, including mobile traffic.
- Your website has a lot of interactive features. For example, this can be an online training platform.
Conversely, if you just have one website with mostly text content (e.g., a blog) that requires almost no interaction on the part of your visitors, going for decoupled Drupal will be overkill.
Decoupled Drupal is the next step in the evolution of this time-tested content management system. It provides valuable benefits for site owners such as independence of the development teams, an easy way to upgrade the front-end and back-end without affecting one another, the ability to distribute content to an almost unlimited number of platforms, and others.
The decoupled approach also poses some tough challenges. You might have to spend more money on development, face problems with hosting providers, and experience performance issues. Thus, take a good stock of your financial and human resources before making the final decision.
Still unsure whether headless Drupal is the way to go for your project? Get in touch with our expert Drupal development team. With years of industry experience, there’s nothing we don’t know about this CMS.
Talk to us about your Drupal project, and we’ll tell you if you should decouple it. We can also help you with any front-end or back-end task, optimize your site performance, or assist you with migrating to a new version of Drupal.