The year is 2021 and so is the number of different web content tools and frameworks at our disposal, or at least that's what it seems. From social media ads to Google search results, it’s easy to feel overwhelmed by the modern options for creating, or updating, a content site.
As an agency with decades of experience building digital products, we believe there are two architectural options for a modern web content application worth considering: a “monolithic” CMS approach that has more or less been the status quo for content management for decades, and a decoupled or “headless” API approach that, though relatively new, has gained serious popularity in recent years (and for good reason).
In capturing some of the nuances of these modern approaches to web content architecture, our goal with this series is to help you select the solution that works best for your institution, whether you are creating a new web application or embarking on a redesign.
The Content Management System (CMS) approach typically provides everything you need in one package: data storage, an editing platform, the front-end display, and any other configuration settings. This coupled approach is commonly referred to as “monolithic” or “off-the-shelf,” as one software framework manages both the back-end and front-end display needs.
A few examples of monolithic CMS frameworks that we frequently work with are WordPress, Drupal, and Craft.Generally speaking, the advantages of choosing one of these frameworks is that they provide a robust editor experience, are easily extensible, and are well-maintained. There are many Platform-as-a-Service (PaaS) hosting options available, which help to automate some of the error-prone laborious aspects of web hosting. However, there are disadvantages to this approach; open-source CMS frameworks require security monitoring and updates, they can add superfluous complexity, and the developer experience can be less appealing to newer developers.
This approach is commonly referred to as “headless” or “decoupled”, meaning that the presentation layer is decoupled from the data layer or content management system. In this scenario, there is often more than one software framework in play. By choosing to separate the back-end needs (administrative and content management) from the front-end displays (websites, apps, etc.) one can leverage multiple back-ends or data sources that can empower many front-ends.
Most modern CMS platforms can provide content via an API. There are also API-first CMS platforms such as Contentful and collaboration services such as Airtable that also expose content through an API. Developers can leverage a front-end framework like GatsbyJS, NextJS (and many others) to “consume” and present the content data exposed by the API. Performance, simpler hosting, personalization, and popularity amongst newer developers are just some advantages of this approach. Disadvantages include longer wait time for deployments and a less robust editor experience; the newness of this approach also means that it trends towards less out-of-the-box functionality and is likely less vetted than its older, more established counterpart.
The honest answer is that it depends; It depends on your speed goals and impacts, tolerance for architectural complexity, and your in-house expertise for content creation and site maintenance. We hope you’ll have a better understanding of your options as they relate to these considerations by the end of the series. Look out for upcoming parts of the Modern Web Content Architecture series, where we’ll do a deeper dive into the pros and cons of a monolithic and later a headless CMS approach.