— 09.27.18 Jack Steadman, Chief Technology Strategist

What does the future of Drupal hold?

We recently attended Decoupled Drupal Days, a conference for developers and tech-inclined marketers, to find out. The idea that the future of Drupal is “decoupled” is certainly gaining traction among major Drupal vendors and community leaders. Session topics included a mix of case studies, reflections on the benefits and challenges of decoupling, and peripheral concepts like serverless infrastructure and bot development.

It’s getting easier to decouple your CMS

In Drupal 8, support for a content API became a core feature of the platform, bypassing its native theming capabilities in favor of a decoupled front-end. Indeed, some presenters talked about their use cases for Drupal 8’s core RESTful web services — and their advantages and disadvantages. In particular, there’s not much flexibility in what data you can request from the CMS at any given time, which means that in some cases you get back way too much data — for example, whole articles when you only need titles and summaries — while in others, you get back too little, forcing you to do things like make separate requests for the author’s name and photo to display alongside an article.

JSON API is a popular alternative to those core services and has options for requesting nested information like author details along with an article, allowing developers to retrieve everything in a single request. It’s still a bit verbose for many use cases, however. Writing custom controllers can give you full control over how your API is called and what it returns, but it requires a lot more custom coding, routing configuration, and so on.

There was a lot of excitement around GraphQL, a query language developed by Facebook for interacting with its social graph. It was open-sourced in 2015 and has since been adapted to many other uses. The GraphQL module provides a GraphQL interface for requesting content from Drupal and gives developers full control over what is requested and returned. This simple example requests the title of matching articles along with the names of their tags:

query {
   nodeQuery {
      entities {
         ... on NodeArticle {
            title
            fieldTags {
               entity {
                  ... on TaxonomyTermTags {
                     name
                  }
               }
            }
         }
      }
   }
}

 

The GraphQL module also comes with a development tool which provides handy auto-completion to help with writing these queries, and because each query is written to ask for exactly what the front-end needs (and nothing it doesn’t), there are fewer costly round-trips to and from the server. This can make a page feel faster, especially on mobile, where connectivity can be much more volatile than on a Wi-Fi or wired connection.

It’s not always obvious whether to decouple or not

Aside from the “how,” a lot of the discussion was about when to decouple and when not to. Indeed, for a conference devoted to decoupled Drupal, there was a fair amount of questioning of the approach — and even some skepticism about its value.

As we’ve mentioned, decoupling sacrifices many things that Drupal does out-of-the-box for a standard website: In addition to the SEO challenges we discussed in our explainer, decoupled sites must provide their own solutions for URL routing, URL shortening and redirection, nav definition, and, most notably for sites with members-only sections, authentication. These are non-trivial concerns that all must be considered as part of the decoupled front-end, which can lead to a significant increase in effort to build a decoupled site. Front-end libraries will continue to evolve their approaches to these issues, but there’s not yet a sense that they are solved problems.

Even when those considerations can be addressed, building a decoupled architecture is inherently more complicated. It requires developers with different skill sets — Drupal CMS developers as well as Javascript specialists who can build the application logic needed for the front-end. Some developers possess all of those skills, but many do not. It also means building two separate pieces of software — the Drupal CMS and the front-end — which need to interact in a clearly-defined way, with clear change management practices on both sides to avoid having either one get out of sync with the other. The choice of whether to decouple may come down to a team’s capabilities, experience, and comfort level with things like API definition, building to an API spec, and modern Javascript development.

There is a compromise, however: Taking a progressive approach to decoupling, rather than going whole-hog, allows a team to dabble with decoupling of specific site features rather than committing to a fully-decoupled architecture. Interaction-heavy features, like faceted search or multi-step registration forms, can be built in-browser, while the rest of the site uses traditional Drupal theming. Many of the success stories at the conference were more about progressive decoupling (or secondary feeds) than about a primarily decoupled main website experience. Yet another “progressive movement” BSD can get behind.

Final thoughts

It was interesting hearing perspectives of longtime Drupal developers on the merits of decoupled architecture. Decoupling isn’t new; fully-custom single-page apps have been around for many years (think Gmail, Facebook, Google Docs, all decoupled in-browser apps with fully-custom backends). What’s changing is the assumption that if you’re building a content or e-commerce site that matches up well with the capabilities of an existing CMS, you build the front-end of that site using native (coupled) CMS theming. Drupal provides so much baseline functionality out of the box that there needs to be a really compelling reason to forego all of that. Many Drupal developers remain understandably unconvinced that the added effort and complexity is worth it.

At BSD, we’ve worked to strike the right balance with our clients. In one recent case, a client’s digital and technology teams were ready to go all-in, requesting up front that their site be built decoupled — but that’s a rare case. Most clients, at all levels of technical sophistication, prefer a more measured approach. For example, we recently built a decoupled search feature (within a traditionally-themed site) which required a lot of dynamic filtering and an option to add donations to a “shopping cart.” Building such a feature in a traditional way would have required multiple page reloads and felt clunky to the user; the decoupled front-end allowed for a faster and more seamless interaction.

All of this makes for a very transitional, almost experimental feeling to the discussion around decoupling. Future conferences will undoubtedly include some more advanced use cases, more refined points of view on when and how to build decoupled sites or features, and many more tools and techniques for addressing some of the challenges detailed by this year’s presenters.

Need some help thinking through whether decoupling is right for your next project? Let’s talk about it.