If you’re about to embark on a CMS website project, now is the time to consider whether you might benefit from an approach that decouples your CMS from your website. In this post, we assess the pain points of tightly-coupled Drupal that led us to adopt a decoupled approach. Traditionally, building a Drupal site goes like this:
- Download and install Drupal.
- Establish your look-and-feel with a pre-existing or custom theme.
- Extend functionality with modules.
- Create custom content types, tags, and menus, and make or import the content.
Voila! Your website is now ready for QA, training, and go-live. It is also a tightly-coupled, monolithic system, entirely controlled by Drupal. Drupal and the modules you’ve added handle the needs of every visitor to the site, whether they’re the visitors who come to your public-facing pages or the content authors logging in to manage the site. There are advantages to this traditional approach, and projects for which it is the best fit. But as an industry we’ve started to recognize significant pain points. Before you embark on your next project, let’s take an assessment of the pain points.
Pain Points of Tightly-Coupled Drupal
Drupal Upgrades Require a Rebuild
There is no such thing as an “upgrade” from Drupal 6 to 7 to 8. Each time a new major version is released, adopting that new version requires a time-consuming rebuild. A site Pixo built in Drupal 5 in 2007 required hundreds of hours to upgrade in Drupal 6 in 2011 and hundreds more for Drupal 7 in 2013. It is a significant burden, especially for public sector or non-profit organizations, to finance a rebuild of their website every 3-4 years. Why are Drupal upgrades so hard? Drupal is modular, but unfortunately many of the add-on modules are so dependent on each other that the complete system becomes fragile. When you’re using modules that build on Drupal’s core permissions, workflow, and data structures, upgrading these modules can cause unintended results that automated tests don’t catch. Very popular add-on modules including Views, Features, ctools, Entity API, and Field Group have all had bumpy upgrades during the Drupal 7 era. The Drupal API contributes to this problem. Drupal’s API allows developers to write add-on modules that change and extend the internal workings of Drupal in huge ways. That extensibility has allowed Drupal to become a platform for many different kinds of web applications. But it also means that many add-on modules can influence each other in unexpected ways. Add to that Drupal’s philosophy of non-backwards compatibility. Each new major version is allowed to break everything that came before. To be fair, Drupal core does have a policy of providing automated upgrades of content from one version to the next. But many add-on modules change the database schema to add their own information, and those modules often do not offer support for automatic upgrades of their data. Significant effort is spent to re-build key elements of a site — examples include Views, Features, and content that uses Field Groups or Field Collections. WordPress, on the contrary, is backward compatible, so the cost of upgrading a site from WordPress 3 to 4, for example, is literally one button click. There are still other reasons to decouple WordPress, but the costly Drupal rebuild cycle is a key factor that led Pixo to look for a decoupled approach. Using a decoupled approach can solve much of this upgrade pain. It means that building a comprehensive site requires far fewer add-on modules. Drupal is employed just for its core functions, and the content you build in one version will upgrade to the next version.
Front-end Developers Have to Be Drupal Developers
In tightly-coupled Drupal development, members of the front end development team need to become Drupal developers in order to properly theme a website. The theme work has to be done in tight connection with module configuration and customization. Your entire dev team becomes tightly-coupled. For example, a calendar of events might be powered by the Views module. Putting that onto a page involves configuring the Views module (in the GUI), then dropping pieces of the front-end markup into dozens of small template override files with fun names like views-view-events–display-1-field_date_friendly-unformatted.tpl.php. Developers who do this work need to be experts in the fast-changing front-end arena while also having knowledge of complex Drupal development patterns. It’s typical to have two or three levels of nested divs for each part of a page. In the example above, most of the divs and class names are defaults, not chosen by the front-end team. On top of that, Drupal introduces dozens — sometimes hundreds — of CSS and JS files into your markup. Every module includes CSS and JS for both the admin tools and the visitor experience. With so much markup generated by Drupal core and add-on modules, your front-end work never starts with a clean slate, and you never feel like you are in control over the markup that your site visitors get. In the decoupled Drupal approach, front-end developers get to choose the best front-end tools without starting with all these CMS defaults. The front-end team can work at their own pace, with fewer hand-offs and less friction.
The CMS Delivers Inconsistent Functionality
As we’ve explained, in tightly-coupled Drupal it takes time and effort to customize and alter how your site looks and works. Once you build a site, it requires ongoing, repeated responsibility to re-build it and keep it working over time. Facing this challenge, it is very easy to give up and “go with the flow” of the CMS. If a project requires a calendar of events, you can just install off-the-shelf module for that. If you don’t customize it, you won’t need to fix or rebuild it over time. It’s easy to give up and use features in their off-the-shelf defaults. That can result in a website that starts to have different, inconsistent elements that give the entire site a mismatched feel. The visitor experience on your site is never tailored and polished, never consistent and delightful. In order to reduce the friction with your CMS, you lower your standards. In the decoupled approach, the front-end is a full, first-class citizen of its own. You can build and innovate the public view of your website, and there’s no relying on the defaults, for better or worse. The CMS no longer has to hold you back.
Your Content Is Trapped
In the tightly-coupled Drupal approach, your content can become trapped inside Drupal’s sprawling realm of database tables. In Drupal’s database schema, every field of content is stored in its own database table. So to reconstitute one piece of content with N fields, you need to write a SQL query to join at least N tables or write PHP code to build that query for you. That can become a barrier to sharing your content. In the modern web, it’s natural to want multiple systems, not just your website, to be consumers of your content and to present it to users. It’s natural for native mobile apps to consume content, or for content to be distributed in multiple feeds, formats, and data products. For an excellent treatise on the so-called Create-One-Publish-Everywhere (COPE) approach, check out this article about NPR’s decoupled CMS strategy . In decoupled CMS architecture, all of your content is available through the API. Any other system or device can become a consumer of that content through the same API, unlocking your content for multiple uses.
The decoupled, content-as-a-service approach is one that Pixo and others are adopting as a way to avoid these pain points and launch better websites. Using this approach, your CMS serves up content to a separate web application that delivers your site to visitors.