Is a Decoupled CMS Right for You?
“Decoupled” or “headless” CMS architectures are generating a lot buzz, and for good reason, as they offer a lot of benefits and can simplify the day-to-day management of a website. Let’s take a look at some reasons you may want to consider, or not consider, moving towards a decoupled model for your next web project.
Last month, Forum One completed its first-ever fully decoupled CMS with the successful launch of the Sexual and Reproductive Health and Rights Index, an initiative of the Center for Health and Gender Equity (CHANGE). Over the course of the digital project, we learned a lot about what it takes to build a decoupled application, including the pros and cons that this architecture can have for an organization’s overall digital communications strategy.
About the Sexual and Reproductive Health and Rights Index Project
The Sexual and Reproductive Health and Rights Index aims to assess the U.S. government’s work on sexual and reproductive health and rights and communicate its findings to the public. It does this by performing an annual assessment of government agencies and health funding streams related to Sexual and Reproductive Health and Rights, and awards grades (from A+ to F) based on commitments, leadership, funding levels, and actions. The topic and content are complex, and our challenge was, therefore, to present both in an intuitive and engaging manner.
The Sexual Reproductive Health and Rights (SRHR) Index homepage.
Why You Should Consider a Decoupled CMS
“Decoupled” or “headless” CMS architectures are generating a lot of buzz, and for good reason, as they can offer an organization a lot of benefits. In this architecture, the CMS is used as a backend content repository. Administrators use the CMS interface for managing content, which is then made available via an API for third-party applications to present it to end users. This fits nicely with the Create Once Publish Everywhere (COPE) philosophy because it means organizations can store their content in a single repository and publish it to multiple websites, mobile apps, and more. So, decoupling a CMS can give an organization an element of simplicity when managing multiple digital properties because content creators only have to use one system to manage content.
As we saw with the Sexual and Reproductive Health Index project, decoupling also gives incredible flexibility to layout and design. Our UX team and front-end developers began with a blank slate instead of being limited by the markup the CMS handed them. Another benefit was that it allowed our project team a lot of latitude to be agile during the build process because we could focus on the project in two discrete parts: the CMS and React front-end. We iterated on one part without impacting the development of the other. A final benefit is that the end product is really performant: users get nearly instant feedback when interacting with the site since we don’t have to rely on the CMS to assemble components and deliver markup to the browser.
Drupal and WordPress include REST-based APIs in their core applications that make content managed by the CMS available in a format (typically JSON) that can be ingested by external applications. It is relatively easy to decouple both systems. With all the benefits decoupling offers — flexibility, agility, performance — it may seem like a no-brainer to pursue this architecture. There are, however, other important considerations.
First, decoupling means that your CMS is no longer in charge of rendering elements to your site, and your development team will have to write custom code for the entire front-end and to get all necessary elements in the right place. For example, if you rely on Drupal or WordPress to expose filters or facets on your search page, those elements will have to be re-written for the front-end application. Writing custom code requires resources and investment, and maintaining it requires commitment.
Second, a decoupled architecture can increase complexity, depending on a site’s requirements. If your content creators need editorial workflow and the ability to preview unpublished content, that will be a challenge for a decoupled CMS. Likewise, if your administrators need to be able to assign URL aliases, manage meta tags, or create redirects via the CMS, a decoupled CMS might not be the right solution.
Finally, depending on your organization’s digital strategy and project requirements, a decoupled CMS might just be overkill. If your CMS will manage content for one platform, and if you don’t have advanced design needs, you might be best served by relying on to Drupal and WordPress render your content. Both platforms have a proven track record for scalability and flexibility, and you can build beautiful, engaging user experiences with them.
Does a decoupled CMS make sense for your next project?
Our team of user experience professionals and technical architects would love to help you weigh the pros and cons. Get in touch!