Blog Insights
Is a Decoupled CMS Right for You?

February 5, 2019

“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. SRHR Index Homepage The Sexual Reproductive Health and Rights (SRHR) Index homepage. The organization needed the ability to manage its content, so we selected WordPress to serve as the content management system (CMS).  Early on, we made the decision that the site’s “front-end,” or public facing user interface, should function as an application. We wanted it to be interactive and performant, and we wanted to enhance the user experience by implementing complex transitions and animations. This required complete flexibility for layout and design, and it led us to the decision to bypass WordPress’s rendering system and write our own using the JavaScript framework, React. The end result had the best of both worlds. We leveraged WordPress’ built-in data, user, and asset management capabilities to avoid having to write and maintain our own. The efficiency we gained allowed us to focus on building a modern, JavaScript-based single-page application with a polished and performant user interface. The project was a success, and we are looking forward to working on more decoupled projects.

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.

Why Not?

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.
LinkedIn

Are you ready to create impact?

We'd love to connect and discuss your next project.