Headless Drupal, decoupling Drupal

Drupal is often and rightly referred to as a classic CMS. However, in recent years Drupal has also made a name for itself in the headless and decoupled scene. There isn't just one way of doing things and thanks to its modularity, Drupal offers many possibilities for decoupling.

Drupal is API-First

[Drupal 8][1] offers various interfaces to perform decoupling in several stages. Operated as a classic monolithic CMS, backend and frontend are closely interlinked and enable the efficient implementation of web projects. Using the integrated API interfaces such as [REST][2], [JSON:API][3] and [GraphQL][4], parts of the Drupal web solution can be “progressively decoupled”. The specific page areas then operate like a decoupled app which accesses the backend via the interface. In fully decoupled operation, one or more frontends consume the data from Drupal to display them in a stand-alone web site or application.

The web site is often only the start

The web solution can evolve dynamically, especially with the gradual expandability of Drupal. New requirements for the integration of a [PWA][5], connection of a [React Native App][6] or the delivery of web content to other third-party systems can be complemented by Drupal's modular interface capabilities. This allows the website to evolve into a landscape of web applications without the core system having to abandon its primary tasks. The structured collection of content through an appropriate editorial interface with finely granular permissions and adaptive workflows form the heart of most modern Drupal websites. Complex translation workflows or integrated e-commerce applications can be optimally built upon.

To decouple or not?

Coupled, progressively decoupled or fully decoupled? Lately, this question has been repeatedly raised. Whether you want to implement a classic monolithic Drupal or simply publish content via an interface – or both –, it makes sense to form a basis for decision-making first. Therefore, let me show you some advantages and disadvantages of decoupling:

Advantages:

• Distributed use cases can be implemented (Content Syndication, Omni-Channel Publishing or “COPE – Write Once Publish Everywhere”).
• Additional devices may be recorded (apps, conversational content, augmented & virtual reality).

• Developer needs can be satisfied (pull instead of push in the frontend; isomorphic JavaScript).

  Disadvantages:

• You need to solve tricky questions (image styles, routing, schemes).
• Lost out-of-the-box-features of Drupal must be implemented additionaly (quick edit, in-site preview).

• There is additional complexity (frontend-stack, interfaces, hosting, authentication).

  When does it make sense?

• Several frontends are to be played by one backend.
• Separating frontend and backend makes sense, due to the size of the team or of the organisation.
• The modern frontend is implemented purely in JavaScript and therefore requires a standardised interface.
• Backend and frontend must be developed independently of one another.

• Decoupled Drupal solutions are already strongly represented on the market. If you want to learn more about the topic, I recommend you “[Decoupled Drupal in Practice][7]” by Preston So. It gives you a good overview about the topic. You can also follow the current development at the Drupal Core [API-First Initiative][8].

  [1]: https://www.unic.com/en/technology-partner/unic/drupal [2]: https://en.wikipedia.org/wiki/Representational_state_transfer [3]: https://jsonapi.org/ [4]: https://graphql.org/ [5]: https://en.wikipedia.org/wiki/Progressive_web_applications [6]: https://facebook.github.io/react-native/ [7]: https://www.apress.com/us/book/9781484240717 [8]: https://www.drupal.org/about/strategic-initiatives/api-first