Decoupled Architecture with WordPress and Drupal

Last week I had the pleasure of hosting a webinar with Brandon Bowersox-Johnson of Pixo and Mike Minecki from Four Kitchens about their use of a decoupled CMS architecture for client projects. It was pretty great — the recording is available now — and there’s clearly a ton of interest in this topic at the moment. (Check out our Decoupled CMS resource page.)

That interest includes my own. The webinar followed my presentation with Amitai Burstein from Gizra on Decoupled Drupal at DrupalCon Los Angeles last month, where I simply could not contain my enthusiasm for the topic.

Clever memes and funky gifs aside, the excitement is real, and for good reason. Here are the high points from our webinar.

Monoliths and Microservices (Everything Old Is New Again)

The whole discussion of decoupled (or “headless”) CMS implementations is really part of a larger zeitgeist in software and internet services: a general trend towards a world with more specialized components integrated via the network, vs holistic software deployments. This is often referred to as Monoliths vs Microservices.

It’s important to recognize that this debate isn’t a question of right and wrong, or even new vs old. Both architectures have been around for ages, and both have their pros and cons. This debate itself is hardly new. Linux aficionados may recognize it as the historical echo of The Cathedral and the Bazaar.

There are many ways that people are looking at decoupling, from fronting their CMS with a native mobile app, to in-browser interactive experiences leveraging the latest JavaScript frameworks, to using static site generators instead of an integrated “theme”.

The latter approach was what we discussed in the Mike and Brandon’s case studies.

Using the Best Tools to Deliver the Best Experiences

The primary motivation for both projects was to deliver a stellar user experience on web, tablet and mobile form factors. We’ve enormous innovation in tools and techniques over the past few years for modern design, but integrating these fast-evolving display with a CMS in a tightly coupled or “monolithic” way can be complex and kludgy.

By separating out the UX layer of the site, Pixo and Four Kitchens were not only able to leverage their chosen tools, they gained the ability to iterate with them independently of the backend CMS. In this way, the frontend can be truly agile, adapting to both client requests, and technology innovation.

The Perfect Website Launch A guide for your next website project, from planning to deployment. Next time you launch a website, do it with confidence.

Future Proofing and Extensibility

Similarly, for Pixo and Four Kitchen’s clients part of the attraction to investing in a decoupled infrastructure is lowering the complexity (and cost) of a future re-design. Decoupling the architecture means decoupling not only the development work of back and frontend, but also the timetable and effort-level for upgrades and refreshes.

Furthermore, by implementing the CMS as a client-agnostic JSON REST API, the open the door other channels for innovation. Multiple frontends can operate independently. In the case of Four Kitchen’s work on twit.com, this even includes a customer community eager to develop their own “apps” that leverage site content.

“Falling in Love with CMS All Over Again” 

One of the the things that was most memorable from both case studies was how Mike and Brandon talked about how pursuing the decoupled architecture renewed their appreciation and enjoyment of using the chosen CMS. By letting Drupal and WordPress play to their strengths — content organization and editing — and avoiding a lot of complex custom code, both Pixo and Four Kitchens re-discovered their love for these core CMS products.

In addition, handling presentation elsewhere means focusing the CMS back on content, putting the editorial user in the spotlight. That means the user experience for these personas comes out better, which makes it much more likely the sites most active users will fall in love again too.

Unlocking Productivity—The API Spec is Key

In addition to delighting their clients, both Mike and Brandon talked about how these projects were a win internally. Developers were happier, and the projects enjoyed good velocity, agility, and efficiency.

In terms of process, agreeing to an API spec was the key to liberating this productivity on both projects. Having an API “contract” between the front and backend means both can operate at their own speed, independently.

This allows techniques like design-in-browser, which Four Kitchens utilized effectively. Pixo reported good results using Apiary, an online API documentation and testing service, to minimize “drift” between the teams.

Best Practices Still Emerging

The decoupled architecture is still fairly new. While techniques are getting better, the path is still not what anyone would call well-worn, and there are definitely potential pitfalls.

In particular, using an independent frontend means giving up on some of the “freebies” that come from a monolithic CMS. Things like content previews and easy string translations. However, with an awareness of the trade-offs, they can easily be worked around.

There’s also no “magic recipe” for putting together a headless implementation — indeed, because of all the different use-cases, there probably never will be — but on this front there’s good news. We’re making progress as more and more developers and agencies are sharing their methods and stacks, even open-sourcing their internal tools.

In Four Kitchen’s case, they made use of the RESTful module, which they contribute to, as well as a NodeJS framework they’ve developed and released called Saucier.

Pixio used the JSON-REST-API plugin, which is planned move into core in its next iteration, along with an open source “atomic design” tool called Patternlab, and a Symfony-based PHP frontend tool called Outpost that they are open-sourcing at getoutpost.org.

While none of these toolchains represent complete solutions yet, as more experts and implementers contribute, the pace of development will continue to increase. Based on what I’ve seen both in these case studies and elsewhere, the decoupled architecture is in for an exciting few years and more and more agencies and clients tap into its benefits.

Are you ready to learn what the buzz is about? Sign up for a free account to try Pantheon’s suite of powerful development tools.