Decouple Drupal’s Theming Layer into a REST Service

Created on 24 July 2017, almost 8 years ago
Updated 2 July 2025, 11 days ago

Drupal’s current theming layer needs a rework to match the Render Engine rework – and with Web Components becoming more standard along with JavaScript support, another rework will be right behind it. With so much movement on the web front end, Drupal needs an architecture that supports this modern evolution of along with easing use of strategies such as decoupling.

I suggest we take a look at moving the theme layer into a microservice that takes REST requests and returns schemas and formatted HTML. The goal is effectively abstracting/decoupling layout and theme related elements from content and configuration.

The site building process generally is made up of one or more of the following roles (many times, a single individual taking up those roles, but they are still valuable distinctions):

  • Designer - Creates the overall look and feel of the site by creating global design assertions like fonts, colors and a general “style”. This work is done with wireframes, style guides and best practice docs.
  • Themer - Converts the vision of the designer into the structures necessary for the platform, slicing the page up into “components” and building out the reusable templates that wrap the content.
  • Page editor - Composes a page with the reusable components.
  • Content editor - Creates the various bits of content that are aggregated and injected into the templates for display on the site.
  • Developer - Marries the content in the platform to the thematic components to allow them to display dynamic data in the context of this page.

The goal is to allow each of these teams to work as independently and efficiently as possible, and remove any tight coupling to any particular method or framework.

By decoupling the teams and technologies, we enable simpler reuse of the various layers and more flexible implementations in page composition and generation. That is to say, ideally the designer does not know or care what the rendering platform is, and ideally the developer doesn’t know or care what the framework, template engine or design is.

The proposal is to treat the reusable components as first class objects deliverable by an anonymous service (whether that be Drupal or some other platform is inconsequential). The components would be exposed with all information necessary to solicit the dynamic data necessary for rendering - The implementation would choose how to handle the collection and injection of dynamic data.

The current system could remain Twig (as it and Liquid become ever more popular) while allowing easier use of alternative systems. This also aids in decoupling as a developer can choose to request data directly from Drupal or structured HTML from the REST service gating the theming system. The added benefit here is that any application with access can use the same library of patterns and components from Drupal’s theming system.

Related Reading:

This issue composed by the Red Hat Web Patterns Working Group.

🌱 Plan
Status

Closed: duplicate

Component

Idea

Created by

🇺🇸United States cyb.tachyon

Live updates comments and jobs are added and updated live.
  • API clean-up

    Refactors an existing API or subsystem for consistency, performance, modularization, flexibility, third-party integration, etc. May imply an API change. Frequently used during the Code Slush phase of the release cycle.

  • API addition

    Enhances an existing API or introduces a new subsystem. Depending on the size and impact, possibly backportable to earlier major versions.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024