About the Drupal Decoupled Menus Initiative

Have you heard about the Drupal decoupled menus initiative? If not, I'll explain more in a moment. But first, if you've got any experience creating JavaScript front-ends for a decoupled CMS (Drupal or other) the initiative is looking for input through this survey: https://www.surveymonkey.com/r/N2JZFLD

Take the survey

It only took me about 10 minutes to fill out, and it's an easy contribution to the Drupal community with a big impact. Fill it out, then come back, and read the rest of this post. (I'll wait.)

What is the decoupled menus initiative?

The decoupled menus initiative (DMI) was introduced in Dries' keynote from DrupalCon Europe 2020, and this video by Gabe Sullice (embedded below) does a great job of explaining what it's all about.

Video credit: Gabe Sullice

The goal of the decoupled menus initiative is to:

"Provide the best way for JavaScript front-ends to consume configurable menus managed in Drupal"

This includes creating official, community-supported components (e.g. React & Vue) that you can use in your own project or as a reference implementation--and everything required to support it including docs, packaging, security, etc. And at the same time keeping the scope small and attainable by saying we'll ship a single menu component rather than a complete overhaul of Drupal's admin UI.

Credit: Dries Buytaert, DrupalCon Europe 2020 Credit: Dries Buytaert, DrupalCon Europe 2020

While on the surface this might sound like we're building a React component that displays links, I think it's the work that needs to happen to ensure that component can be effectively managed and maintained by the Drupal community that is the real value of this initiative. Some of the problems that need to be solved include:

  • Updating the Drupal.org infrastructure to handle any requirements for bundling, testing, and shipping JavaScript packages via GitLab etc.
  • Defining policies and practices for handling security issues with JavaScript packages
  • Defining tooling, and processes, for creating best-in-class documentation for how to consume menu data from Drupal
  • Developing an ideal data structure for consuming menu data, and then updating to Drupal core to facilitate providing that data
  • Allowing content creators to configure, and turn on/off, menus served via JSON:API through an intuitive UI
  • And of course writing the code for the different reference implementations in React, Vue, etc.

Why?

Looking at that list, most of those problems, once solved, will reduce the barriers to creating more awesome JavaScript integrations with Drupal's web services API. This. in itself, is a huge win. And hopefully results in a bunch of additional initiatives tackling things like authentication, content editor-generated layouts, image styles, routing, and other things that are traditional hard problems of decoupled architectures.

Think of the decoupled menus initiative as laying the groundwork for future innovations.

This is important; because, as Dries' pointed out in his keynote introducing the initiative in order for Drupal to continue grow, and to remain relevant for the next 20 years, it has to be better positioned to compete with the current class of decoupled content management systems. Drupal is already the best option from the perspective of content architecture, editorial workflows, and a deep feature set. But it lacks a developer experience that is attractive to JavaScript developers. and gets overlooked as a result. Since these devs are often influential in the decision regarding what CMS to use, it's important that they view Drupal as an awesome choice.

The experience of integrating with Drupal has to be as good, or better, than that of the competitors. This means meeting JavaScript developers where they are, and not making them jump through hurdles to integrate with Drupal. Because more often then not, we developers will prefer the path of least resistance. And speaking from my own experience npm install --save @contentful/app-sdk is a lot less friction than writing my own JavaScript library to integrate with Drupal's back-end. While there have been numerous attempts to create reusable libraries, they tend to lack the visibility required to make them truly useful.

Assuming this initiative is successful, I would love to see something similar for dealing with authentication: a set of community supported components that deal with the complex OAuth workflow, specifically designed to integrate with Drupal and the Simple OAuth module. This would get us closer to the experience of using solutions like Auth0.

Want to know more? Or get involved?

Did I mention there's a survey?

Take the survey

Related Topics: 

Comments

Add new comment