Why you may not want a headless (decoupled) website.

Posted on 10 Sep 2017 by Oleksii Raiu

Developers used to call this kind of architecture headless, but it's called decoupled more often today (because who wants a "headless" website?!) It's the next cool word today. It's the today's black. There's a lot of talk about the decoupled in the Drupal community now. It's the eye of the hype now, being cool and technologically advanced. There can be reasons, however, why this hype may not at all be for you.

1. What Decoupling is.

What does the term decoupling mean? It means basically, that your Front End is divorced from your Back End. Traditionally, if you use a CMS, like Drupal or Wordpress, the CMS, the Content Management System, handles both the way how you manage your content, and how you serve and display it. Thus, a CMS will allow you to construct pages or data entities with fields of different kind, like text, images, media, links, addresses, etc., and then it will also render and display those pages and data entities to the user on a page visit. However, as the modern web evolves to include web apps and different type of app-like behavior more and more, it becomes more and more needful to serve the content to the apps and sites that do not run off your CMS or off your url. Like a weather app that queries a remote server but serves that data in your Android phone. So, in the decoupled model, an app or another website addresses your CMS and requests the data, and receives a response containing a dataset, which it then handles and displays as it sees fit.

An example. You have a CMS that you use to manage news. In a coupled model, you would create the news articles on the back end, and then the CMS front end would theme them in a certain way and display them. If you wanted to make an iOS or an Android app to show the news, or wanted to build a front page app for your news site that would update and interact without having to refresh the whole page, it would be hard or impossible to do. Now, enter the decoupled approach. You build a REST server with API on your site, which allows the data to be requested from your server in a raw format. Now, you can build an Android or an iOS app, that can query your site and get that raw data that it will display, different in different context. Suddenly, you can also build a live front page for your site, that will be quering the data with javaScript AJAX calls, and displaying the changes in the news feed without having to refresh the page. Thus, decoupling allows you to create app-like behavior for your website. It's good, isn't it? Drupal 8 shines when decoupled, by the way. This is a new cool toy. The question is, do you need this toy?

2. Do you need a decoupled site?

So decoupling being cool and trendy, I see now decoupled blogs, decoupled busines card sites, decoupled everything. Built with React, their usual common traits are fast load times and very simple pages. However, you may not want to have this kind of a site yourself. Why?

First, because decoupling is expensive. Namely, the app part. Writing JavaScript apps that will request your data, handle paths, manage the events and user interactions, and manage the URLs without a page refresh requires lots of work and thus is very costly, despite the existence of dozens of libraries to facilitate this.

Second, content served by AJAX is not really good for SEO. SEO crawlers don't run JavaScript. If you want your content indexed correctly, you end up inventing ways for your site to serve the content on page visits even if JavaScript if off.

Third, decoupled pages are usually very simple because given that cost of development, you don't want to pay for having additional page blocks, bells and whistles, unless you really need them.

3. Conclusion.

If you decouple your site, you may end up with an expensive, SEO unfreindly, and functionally simplistic website. Do you want that? In some cases, you do, like, if you are having a news agency, a huge shop, or an online app. This is when you either don't care about SEO (an online weather app), or you have so much money that decoupling parts of the site will have sense financially, given the services you provide.

So, if you are having a blog or a web presence web site, that is not requested by the news providers, does not serve it's data to any apps, then there is no need to decouple the site for you. Even if you do serve data, providing a REST server and serving the data without the need to decouple the site would be the optimal approach.

In my observation, in most cases, it's much more efficient to use a hybrid approach and add app-like functionality to the site where it's needed, rather than to decouple the whole site.