preston.so

Reprinted from the Acquia Developer Center with permission from DC Denison (Senior Editor).

As the weather heated up last week in Nashville and the city's eponymous hot chicken incinerated tongues left and right, something else was burning in the spotlight at DrupalCon Nashville: decoupled Drupal.

The Music City Center played host to the Drupal community and a coterie of developers, technologists, businesspeople, and community builders passionate about our flinty open-source content management system.

For me, the most significant outcome of the conference, which I've attended for almost a decade now, was the excitement — and lingering bewilderment — surrounding decoupled Drupal. Every session room concerning decoupled Drupal was standing room only, and the interest was palpable.

That meant it was a great time to announce the second edition of Decoupled Drupal Days, the premier conference on decoupled Drupal, to be held again in New York City between August 17–19, 2018.

This year, DrupalCon Nashville was also the venue for the inaugural Decoupled Summit, which attracted a diverse range of speakers, panelists, and attendees.

For this column, I popped into a few sessions and examined some of the most compelling content from DrupalCon that consistently attracted attendees like yours truly. As someone who has been tracking the decoupled Drupal phenomenon for several years now, it was exciting to witness the best practices and ideas taking shape in Nashville. In short, decoupled Drupal is no longer theoretical, and it's clear that it will be a force to be reckoned with in Drupal for many years to come.

Solving hard problems in decoupled Drupal

To kick things off after the Driesnote, Mateu Aguiló Bosch (Senior Developer at Lullabot and co-coordinator of the API-first Initiative) jumped head-first into tackling some of the thorniest issues in decoupled Drupal, namely performance, derived schemas, routing, editorial layouts, and authentication. Mateu proceeded to explore each topic in turn, offering a thoughtful analysis or robust solution at each juncture. In this section I'm focusing only on performance, routing, and editorial layouts.

Core REST typically requires multiple sequential requests to fetch related entities referred to by the retrieved entity in a single request. While JSON API mitigates this problem, sometimes there are cases where multiple requests are still required in sequence. Mateu highlighted the case of creating an article with many taxonomy terms, which requires creating the vocabulary (if it does not exist), the terms therein, the user that is the author, and the article itself. The Subrequests module alleviates this need by accepting JSON blueprints which contain placeholders that can be filled in later when each constituent request succeeds.

Oftentimes, routing becomes a significant issue in JavaScript applications, which aren't aware when routes where requests can be resolved are available. For instance, Mateu offered an example in which

/recipes/sliced-bread

can change to

/sliced-bread

, but there is no way for the client to know. In response, Mateu presented the Decoupled Router module, which provides a redirect that Drupal can then resolve to issue the response from a path alias that was modified.

Finally, Mateu deftly explored the topic of editorial layouts in decoupled Drupal architectures, which can be a fraught issue with software architects and marketing professionals on opposite sides of the aisle. After agreeing that decoupled layout is potentially damaging due to the coupling of a front-end consumer to the back-end management of presentation (I've referred to this problem as pseudo-decoupling in the past), Mateu recommends a solution that provides configuration on a per-consumer basis. This means that individual consumers could retrieve the layout appropriate to them based on their own UUID, which would be provided in every request to identify the consumer issuing it.

Pushing Drupal's JavaScript modernization efforts

I only managed to catch the second half of the core conversation held by the JavaScript Modernization Initiative, hosted by Sally Young (Senior Technical Architect at Lullabot and initiative co-coordinator), Daniel Wehner (Senior Software Engineer at TES Global), Matt Grill (Senior JavaScript Engineer at Acquia and initiative co-coordinator), and Angie Byron (Senior Director of Product and Community Development at Acquia and initiative co-coordinator).

The talk walked through the initiative's overall goals — to implement a React-based decoupled administrative UI for Drupal, while improving the underpinnings by "dogfooding" Drupal's REST API and other fruits of the API-First initiative, and making Drupal more palatable to JavaScript developers by adopting tools and best practices from the wider JavaScript community. The team also provided a demo of the current progress, which you can try yourself.

The discussion portion of the session was edifying and opened several avenues for further exploration. As someone who has been lurking in the #javascript channel on Drupal Slack for some time, it was wonderful to see the fruits of the initiative's efforts in person. The JavaScript Modernization Initiative meets weekly on Mondays at 12:30pm EST on the #javascript channel, and anyone is welcome to contribute to the jsdrupal organization on GitHub, where the issue queue and in-progress code are both located. Here's information on how to get involved!

Mike Gifford (President of OpenConcept Consulting) asked a question that is on many minds as JavaScript becomes more widely used to drive interactions on applications: How is the JavaScript Modernization Initiative thinking about accessibility? The initiative coordinators invited accessibility experts to contribute and offer the tough feedback needed to ensure that the work successfully meets accessibility guidelines. While there is an accessibility baseline that tests require components to pass, it is not yet at the WCAG 2.0 AA level.

On the other side of the spectrum, Steve Persch (Lead Developer Advocate at Pantheon) and Marc Drummond (Senior Front-end Developer at Lullabot) posed several questions about extensibility. In response to Steve's question, which added that it might be beneficial that React has fewer modes of extensibility than Drupal, Daniel noted that if the same flexibility found in Drupal is desired in React, we would need to introduce more than simply React to the Drupal ecosystem. From the front-end perspective, Marc asked whether modules would be able to pull in their own React components and register their own routes — a question that the initiative doesn't yet have an answer to but certainly will need in the future.

Tackling challenging topics in decoupled Drupal

Last but not least, I was able to catch the first half of a session dedicated to advanced topics in decoupled Drupal presented by my colleagues Jason Enter (Front-end Lead, Professional Services at Acquia) and Steve Worley (Technical Consultant, Professional Services at Acquia).

Jason and Steve got down to business quickly with a rapid-fire introduction to the motivations for decoupling Drupal before leaping headlong into API security. They highlighted the Simple OAuth module, available in the Drupal contributed ecosystem, which provides OAuth2 token-based authentication for decoupled Drupal architectures. In short, the most compelling reason to use OAuth2 in Drupal is that each consumer can be associated with a particular user role which allows the content to be scoped appropriately.

On the subject of orchestrating data exposed by Drupal-provisioned APIs, Steve and Jason offered up their experience using a GraphQL server as a proxy through which data can be forwarded and manipulated from disparate sources. After all, many business requirements force consumers to communicate with multiple APIs, such as a legacy API or external API. Using a GraphQL server to proxy this differently sourced data and issue requests in the client's stead to those other APIs can lead to performance improvements.

Planning for Decoupled Drupal Days 2018

As a co-founder and co-organizer of Decoupled Drupal Days, I had the pleasure of catching up with most of the organizing team in person at DrupalCon. In its second year, the only conference about decoupled Drupal was a smash hit last year, with the presence of JavaScript luminaries from the Angular and Ember core teams and an incredible speaker lineup that led one presenter to deem it among the best conferences they attended last year.

Decoupled Drupal Days is scheduled for August 17–19, 2018 this year and will be held at the John Jay College of Criminal Justice in Midtown Manhattan. We're busy at work rebuilding the website, readying the call for papers, and preparing registration. In early May, we'll be opening up the first batch of tickets and session proposals.

This year, we'll be moving on from our scrappy beginnings and embracing three tracks: Drupal, JavaScript, and Future. We'll also be welcoming two keynote speakers and bringing back our familiar sprints on Sunday. If you're interested in sponsoring, presenting, or attending, please follow @decoupleddays on Twitter for updates, or contact us at decoupleddevdays@gmail.com.

Conclusion

All in all, DrupalCon Nashville seemed like an inflection point in the history of decoupled Drupal. I've long espoused the benefits (and inevitable drawbacks) of decoupled Drupal architectures, but it was thrilling to see so many engaging with these themes and revealing details about their own implementations, including where things went awry.

In the next installment of Experience Express, we're back in Drupal territory and spelunking deep into Drupal's core REST modules and powerful contributed modules like JSON API, GraphQL, and RELAXed Web Services. In addition, watch for another event roundup soon from Philadelphia, where I'm participating in Drupaldelphia. All aboard!

Special thanks to Mateu Aguiló Bosch, Angie Byron, Marc Drummond, Jason Enter, Mike Gifford, Steve Persch, and Daniel Wehner for their feedback during the writing process.