Decouple Drupal’s Theming Layer into a REST Service

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:

• https://github.com/PatternBuilder/pattern-kit

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