Exploring Decoupled Drupal Through the Eyes of a Front‑End Themer

For the past year, I’ve been on the outer edges of the decoupled Drupal conversation. I have watched from the sidelines looking for the right moment to jump in. What kept me back? Was it the cacophony of unfamiliar terms? Perhaps a lack of understanding when decoupled was the right fit for a project? Was I being left behind because I had not fully embraced a JavaScript framework like React, and was viewed as “just a front-end themer?" Was I missing out on the great JavaScript renaissance?

Let’s back up. Decoupled Drupal, or headless Drupal, is the practice of using Drupal to manage and centralize content, then making it available to use on your website and beyond, feeding into any number of applications or scopes like single-page applications, mobile applications, IOT apps, you name it! Drupal controls the content but this concept allows you to use a variety of technologies or frameworks to create the front-end experience

After reviewing my personal notes from sessions I attended at MidCamp, DrupalCon 2018, and BADCamp last year, I realized I had a lot of information, but I didn’t quite know where to start. I still felt lost and needed a nudge in the right direction. Then, I found three sources that have helped me pull the pieces together. I’ll cover these three pieces that are helping me gain a deeper understanding of decoupled Drupal.

First Piece: Recognizing the Divide

I have to say it’s been a rather intimidating and confusing year to be called a Front-End Developer. Chris Coyer’s recent article clearly articulated a lot of the feelings I’ve been having regarding the “identity crisis of Front-End Developers.” By the end of Chris’ article, I felt validated in my experiences as a Front-End Themer. It helped me to proudly embrace my skills crafting elegant interfaces using Drupal’s templating layer without feeling inferior to hardcore JavaScript developers. Theming is a specialization, and not that different of a skill set from the “cool kids,” who are working with ReAngulVueBer Framework* or { please insert your favorite JavaScript hotness of the month here }.

*ReAngVueBer is my imaginary JavaScript Framework combining React, Angular, Vue.js, and Ember. :)

My projects were using JavaScript. Actually, they were using a lot of JavaScript in the case of Wilson’s Team Shop Configurator. However, I was not well versed in a full-on JavaScript framework. Did that make me a “bad,” or “outdated,” Front-End Developer? Was I being left behind?

Second Piece: Understanding My Place in Drupal

Another piece, and a breath of fresh air, came in the form of Dries Buytart’s post How to Decouple Drupal in 2019. Dries’ mentions of “talented Front-End Drupal developers with Twig knowledge,” helped boost my feelings of belonging and not feeling like a second class Front Ender. His flowchart outlining clear decisions where fully coupled Drupal is a good fit for projects once again validated my skills at crafting a solid theme using the templating engine. Also, the criteria for progressively decoupled Drupal allows room for both types of Front-End Developers: hardcore JavaScript devs as well as themers like myself. With this refreshing mindset, I feel less intimidated to begin exploring decoupled Drupal.

Third Piece: Discovering a Guide to Decoupling

I began to realize that I wanted a little more context and fundamentals that would set up the need, not just the desire, for decoupling. I was looking for a trusted mentor that would help me digest the wide range of terms, tools, and approaches. And then after I gained an understanding of these basics, I wanted a tour of best-in-class examples and a playbook to help me get started with whichever JavaScript framework I chose to explore deeper.

I believe I have found my guide by picking up the book Decoupled Drupal in Practice: Architect and Implement Decoupled Drupal Architectures Across the Stack by Preston So. While the first part of the book can be skipped for those already familiar with RESTful approaches and decoupled CMS architectures, I found Preston’s back-to-basics approach to be very helpful and it provided the context I needed. It allowed me to look at past projects and recognize how they were the beginnings of progressive decoupling. As I move further along in the book, I’m feeling more confident and finding my place in the decoupled conversation.

Where Do We Go From Here?

Over the next few weeks, I’ll continue progressing through the “Decoupled Drupal in Practice,” book. I’m seeing the pieces falling in place and I am confident that my guide, Preston So, will help me digest the terms and approaches. In addition to the book, I plan to attend the Decoupled CMS Summit as well as sessions from the Builder Track at DrupalCon 2019 in Seattle. I’m excited, energized, and feeling more confident as I continue to explore decoupled Drupal.

While it may seem easy to spot the benefits to our clients, it’s clear there needs to be a lot of thought in designing any centralized content system — especially as the applications that use the content can vary as widely as extolled by decoupled enthusiasts. “Create once, publish anywhere,” is a powerful mantra, and with the right planning and development work up front, this approach is poised to enable and empower your entire organization; freeing up resources, reducing duplicate effort, and allowing for freedom in quickly employing the latest, greatest technologies and frameworks.