How Decoupled Architectures Can Benefit the Entire Web Team, and Drive User Engagement

Teams using decoupled architectures can drive more value. That's why we're expanding Pantheon's offering to accommodate sites beyond monolithic WordPress and Drupal implementations.

At Pantheon's first ever WebOps Summit in June, I was happy to take the opportunity to share some of what I've been working on for the past few months around decoupled sites and modern front-end architectures. The short version is that we're expanding Pantheon to accommodate sites beyond monolithic WordPress and Drupal implementations, as we've found teams using decoupled architectures can drive more value.  You can watch the whole video here. We're currently in a pilot project stage with a small group of customers and will have an expanded offering in the coming months.

Watch Steve talk through the forces driving modern front-end development, and the pros and cons of various approaches to decoupling, at Decoupled Days this Wednesday. 

Why Consider Decoupled Architecture?

Most websites visitors will not care whether or not a site they visit is decoupled. But they will care about whether or not the site is usable on their device. Over a decade into the rise of smartphones, many sites still have a poor experience across different screen sizes, device capabilities, and network speeds. In short, many websites struggle to compete with the native applications built specifically for the devices we carry. For the web to remain vibrant over the long-term, people need to regularly choose to visit them over native applications.

Decoupled architectures are often more likely to hold the attention of visitors for a variety of reasons. A site built with Gatsby, or another static site generator, is likely to respond nearly instantaneously when a person clicks from one page to the next. Pantheon's own Documentation site was recently rebuilt with Gatsby and it loads so fast that the people visiting are very unlikely to find their attention drifting because of a slow load time. Similarly the design and experience of a decoupled site is often more compelling than a monolithic site because decoupling can mean designers and front-end developers are more likely to be working with their preferred tools.

How Every Team Member Can Benefit  

There's a lot from my Summit presentation that I'll unpack here on the blog in upcoming posts. Questions like: 

• Why would an organization for WordPress professionals in higher education switch it's main site to Gatsby?

• What's the role of an open source CMS after its head has been chopped off?

• How can Node.js and PHP run in parallel?

First though, I'd like to highlight why this architecture, one that separates the back-end CMS used by content editors from the front-end public facing site, can benefit every member of a web team.

Designers and Developers

Creating a great user experience in a browser has become such a complex and specialized job that more and more web teams are drawing a hard line between who is a front-end developer or designer working in the browser and who is a back-end developer working on the server. Front-end development alone has gotten so specialized that there is a "great divide" between different front-end skill sets.

Unfortunately for traditional monolithic WordPress and Drupal sites, someone trying to work just on the front-end experience will inevitably find themselve debugging back-end CMS internals. A primary driver for this decoupled architecture is the decoupling of front-end and back-end developers. Although that is not to say that developers on either side can ignore one another. A team with poor communication between developers might find that decoupling makes coordinating efforts worse. Teams with strong communication skills can find that decoupling their technology enables better coordination of their efforts.

System Administrators and IT Directors

This architecture can also align with the needs of IT departments. IT directors tend to be concerned with stability and security, so they're often enthusiastic about a decoupled approach that involves locking down the back-end so only content editors can access it directly. In addition, the public sides of decoupled architectures are often built so that there's no runtime to attack or database to hack.

A pain point we have frequently heard from administrators around decoupled architectures is the spreading of infrastructure across multiple providers. If the CMS, build process, and the public facing site are all on separate services with separate billing and separate access models, the administrators of these sites can become overwhelmed. We expect that by handling more concerns within Pantheon, web teams will find more time to focus on improving customer experience and creating valuable features. 

Marketers and Content Editors

In the early days of decoupling, the day-to-day workflow for marketers and content editors could be significantly worse compared to a monolithic CMS. Many early implementations made it difficult for those editing content to preview their changes. Even so, for marketers concerned with driving results through the website, decoupling could still be a wise choice because of an overall increase in the whole team's ability to complete more iterations.

Maximizing the value of a website usually requires maximizing a team's ability to change the website, at least the public facing side. Splitting apart the code that controls the back- end CMSfrom the code that controls the front-end site can enable a team to make more deployments in a given week. Much of the overhead testing time in monolithic sites comes from a fear that any given deployment might catastrophically break the database. When the team can more easily see that the changes being deployed are visual changes only, they can deploy those changes faster. And those public-facing changes are often more valuable than changes to the back-end CMS.

Fulfilling Pantheon's Mission

This last idea in particular, that teams picking decoupled architectures can drive more value, highlights why Pantheon is expanding our offering. Our mission is to make the open web a first-class platform that delivers results. We're confident that over the next decade, teams most concerned with delivering results through their website will be thinking about the front-end user experience and picking their tools accordingly. We see it as our job to enable teams to spend less time focused on the details of those tools and more time focused on the reason their sites exist. As our co-founder Josh Koenig said in our very first blog post in 2011, we want to put the human at the top of the stack.

You might also like: 

• Headless Websites: What's the Big Deal with Decoupled Architecture?
• Five Ways to Speed Up Your Website, and Tips for Testing
• Pantheon Ranked #1 in WebOps, and More