Decoupling Drupal

Several of my colleagues and I attended DrupalCon 2017 in Baltimore last month, and the event was inspiring. I left excited to return to Duo and try out new tools I learned about and help our business continue to move forward.  But DrupalCon also gave me time to think. And as I was thinking, I kept thinking about decoupling.

What is decoupling, you ask? Well, If you are a front-end developer using Drupal 7, you also need to be a Drupal developer. In Drupal 7 and previous versions, the front end and back end are so tightly intertwined that you will have to invoke Drupal-specific code to achieve a desired outcome at some point in your career.

decoupled-363968-edited.jpegThis tight coupling has been a source of frustration for many developers learning Drupal, and it was a driving force for the twig initiative in Drupal 8. With twig templates, front end developers are less reliant on knowing the intricacies of Drupal to hack the front end of a site. The back-end developer exposes the data to the theme, and the front-end developer can create the templates with twig. No php required! (Well, twig compiles to php, but you get what I mean).

The great irony of twig is that php was originally developed as a templating language. But php has become so much more complex that now we need a templating language for our templating language. We’ve created one more level of abstraction between the data layer (Drupal’s back end) and the presentation layer (Drupal’s theme layer).

Enter decoupling/headless applications.

In a completely headless application, Drupal is just serving pure data. The presentation layer can be anything. In most cases for web apps, this would be an MV* framework, with Angular and React leading the charge (there’s also Vue, Ember, Knockout, Riot, and the list goes on). They’re fast, they’re cool, and they offload a lot of work from the server to the browser.

But that’s not all. we can send data from Drupal to anything that can consume the data. Alexa, cars, Raspberry Pi, literally anything can now be Drupal-powered, and Web Services (D8 core) and JSON API (D8 contrib module) make it really easy to expose Drupal data to these devices. The last great paradigm shift in web came with mobile devices. I believe the next great shift — that we are already beginning to experience — is the Internet of Things. The way we think of interfaces will shift from personal devices to nearly everything around us.

So, what does this mean for your Drupal site? Is decoupled Drupal always better? Do we just throw out D8’s great new theme layer and go headless?

I think that it depends. Headless/Decoupled applications are cool, but we lose a lot of great stuff that Drupal can do out of the box: user authentication, permissions, a polished admin user experience with things like contextual editing capabilities, security, etc.

https://events.drupal.org/baltimore2017/sessions/decoupled-inside-out

It might make sense if your data needs to communicate with many different endpoints, but for a primarily browser-based user experience, this might be overkill. Drupal 8 was designed to be API-first, but not necessarily API-only. We don’t want to lose all of the great tools that a non-headless Drupal site gives us. And we don’t want to reinvent the wheel with all these different elements that are already built and really powerful.

I think a better solution for most customers would be a hybrid approach: progressive decoupling. In a progressively decoupled site, we can still take advantage of Drupal’s theme layer to render most of the page, but we can decouple specific components that require more rich experiences.

This concept isn’t exactly new; in fact, we leveraged progressive decoupling here at Duo back in in 2014 with Union Leasing’s Vendor Lookup. While the page is a Drupal page, the vendor lookup form and data are actually an embedded Angular.js app (Also known as Angular 1, not to be confused with ‘Angular,’ which, without the ‘.js’ part, refers to Angular 2).

For a more advanced example, look no further than nba.com. The NBA site uses Angular 2 to render specific components on the page and update them in real time as scores change, while more static components of the site are simply content rendered the regular ol’ Drupal way. There was a great case study for this site presented at Drupalcon Baltimore this year that can be viewed here.

There were a number of other great presentations at DrupalCon, including several that dove deep into the concept of decoupling and what it means for Drupal’s future.

Here are a few of my favorites:

Ready to start a conversation?