Decoupled Drupal: A 10,000 ft View

Part 2 in this series is continued from Setting the Stage: Hosting a Decoupled Drupal Site.

With numerous ski resorts, several Camp Woodward destinations around the country, and roughly 50 unique events hosted each year, the content demands of POWDR’s portfolio are significant. Managing the volume and variety of this content is a challenge in itself - and managing it across disparate systems with different processes and siloed data makes it much harder. With that in mind, POWDR set out to unify the technology driving their digital presence using a new platform powered by Drupal 8.

The Requirements

The platform needed to serve two seemingly different goals: flexibility allowing for different designs on the frontend and a uniform data model on the backend for maintaining content. To meet these needs, POWDR opted for a decoupled approach, using the backend system as a data API that’s consumed by individual frontends that can be styled however necessary, and at times, completely differently.

The Responsibilities

With our partners Hoorooh Digitial and Acquia providing the frontend and hosting solutions respectively, our job at Elevated Third was to design and build the data layer at the platform’s center. As Drupal experts, we knew Drupal 8 had the right tools for this job. Our solution used a combination of Drupal 8’s REST API, Views, the Paragraphs module, and some custom modules to provide the right amount of flexibility and maintainability for POWDR’s needs.

An Initial Architectural Consideration

When building a solution like this, the first decision will revolve around structuring the technology powering it. Currently, there are a couple architectural options in the decoupled application landscape.

The first option consists of running two servers: one for the frontend application(s) and one for the backend data API. In this scenario, the frontends are responsible for all the routing and the backend simply provides a JSON endpoint that communicates with the frontends.

The second option consists of storing the frontend applications as compiled assets on the same server as the backend. In this scenario, the backend will respond to initial incoming requests and route them to the proper frontend application which takes over from there.

There’s not a right or a wrong choice here. And any decision will depend on the combination of hosting options, technical expertise, and development team’s appetite for complexity. We chose the second option. And after some fiddling with HTTP requests and Apache proxying, the POWDR platform has been performing excellently.

To Be Continued...

In the next entry of this blog series, my project partner Joe Flores will detail some of specific Drupal technologies and techniques we used to power POWDR.

Thanks for reading!