The web has no shortage of digital trends that will pop up on your radar, and one whose momentum has increased over the last couple years is decoupling. In simple terms, the concept of decoupling means separating the frontend of your website from the backend. This means the components of a site that a visitor sees and interacts with (menus, page content, widgets) are built and displayed by software running in the web browser. The backend software, running on the server, accepts requests from the frontend for these different page components and returns them as essentially raw data.

With this full separation of concerns, each half of the website can focus on what it does best; the backend focusing on business logic and retrieval of data, the frontend focusing on display and user experience.

How Do We Achieve This?

This is where JavaScript frontend frameworks come into play. Popular ones include Angular, which we at FFW have used quite successfully on projects, or React, Ember, and many others too numerous to count. These frameworks enable a skilled developer to build a complex and highly interactive frontend without constant page refreshes that require the full attention of the backend.

To do this, it helps to have a powerful and flexible content management system, which doesn’t require lots of custom programming and reinvention of the wheel. This is where Drupal comes in. We’ve done this quite successfully with Drupal due to its robust and flexible API. Drupal 8 pushes this even further with its API first approach, and superior set of APIs.

Things like the built-in RESTful web services and superior content modeling tools do most of the work of building that backend system. Eventually the backend will communicate effortlessly with frontend systems and other applications and third-party service. This makes Drupal an effective content hub for distributing your content to any application that needs it.

Pros and Cons

When introducing anything new there are various factors to consider. A decoupled fronted can improve perceived performance and enhance interactivity. It can also do something very difficult with a fully baked content management system, where all rendering is handled by the backend. It enables developers and development teams to design and build a frontend almost completely independently from how the backend is developed. Your templating system, how CSS is built and managed, preferred methods for design components, all this can be treated like a separate project. Your designers and frontend developers don’t even have to have skills specific to the CMS you are using.

Life, of course, is never perfect. The main drawbacks become apparent when really thinking about how all this affects the way your site is built and managed. When using a CMS like Drupal, you start losing a lot of the key features that make it the tool it is. Can you use Drupal’s site building tools to, for example, change the order of fields displayed on a page? Things like that are now being hard-coded into the frontend. We also start losing some of the multilingual features, it plays less nice with metatags and other SEO features, and potentially increases the amount of work and skills needed to build your website. Those aren’t all unsolvable problems, but you’ll need to consider them when deciding where you are willing to devote the development time to building a decoupled site.

Two Approaches

If you understand the concept of separating your frontend and backend, you’ll start seeing two approaches while doing your research. “Headless” Drupal, which just means a fully decoupled frontend. The other is “progressive” decoupling. “What the heck is that?” you might say. Progressive decoupling blurs the line between what the frontend and backend are doing, rather than fully decoupling the two.

Progressive decoupling starts with a traditional website approach, with no decoupling, and the backend doing most of the work to produce the web page. Then, individual components that are deemed more interactive or take longer to produce are handled by the frontend. This approach plays a little more nicely with tools already present in your CMS, and is easier to implement on any existing website.

New Hotness Can Burn

Decoupling a website is a great way to solve some problems of the traditional website module. We certainly advocate it for projects suffering from those problems. But, as with all technology, make sure your use case has the need before forcing technology onto it. The decoupling approach can revolutionize your site visitor’s experience, but if forced to fit it can create new problems, increase development time, and inflate your costs.

A simple site, with few frontend performance problems, largely static content, and little need for things like user- or region-specific content, is not likely to need something like a decoupled frontend. My advice: Let your requirements always inform your solution. Technology is great at solving problems, but don’t let it create them by misapplying it to your project. If you want to talk about whether decoupled Drupal might be right for you, please contact us.