There has been amazing progress with Drupal’s API-First Initiative in the past few years. A major milestone was when JSON:API was added to core as a stable module in Drupal 8.7.
An API-first Drupal enables many things, but probably the best known use case of APIs is a decoupled front-end. Numerous blog posts and at least one book have been been written about decoupled Drupal. There have been many conference sessions on the topic, and there is an entire conference focused only on decoupled CMS architectures.
A lot of the activity around decoupled Drupal originates from developers and other employees of Drupal agencies working on projects for large enterprises and organizations. These projects might require a content service not just for for app-like websites, but also for other publishing channels like native mobile apps and digital kiosks.
There are other ways
Component-based theming is a commonly used name for a specific way to develop and organize Twig templates and related assets in Drupal themes. I am not sure how well known it is that component-based theming is actually a way to decouple most of the front-end from Drupal.
The best known benefit of this decoupling approach is the possibility to develop most of the theme layer independently of Drupal, with the help of a tool like Pattern Lab. But while there are already some very interesting examples out there, I believe that the full potential of decoupled Twig components is yet to be realized. By this I mean Twig component libraries that can be used with minimal integration effort in both Drupal and WordPress, for example. I believe that agencies offering services for both platforms could benefit a lot from this.
For ‘small Drupal’ too
Since it is often associated with style guides and design systems, it is possible to get the impression that component-based theming is only useful for large teams working on projects for large clients. However, I know from my own experience that even single-developer projects can benefit from it.
Component-based theming adds very little overhead to regular Drupal theming. Thinking in components can improve the quality of your work in many ways, and most importantly, building anything from blocks is fun!
There is no requirement to develop a style guide – although you might find that you end up with the beginnings of one as a happy side result.
A decoupled front-end means that work on the theme can be started even before Drupal is installed, and clients can be shown the design in a real browser much sooner.
Hi - Great article. This is exactly what I propose for core in my session for DrupalCon Amsterdam in a week:
Would love to see you there to discuss that some more.
Thanks Fabian! Your session was already on my must-see list! I would be very happy to talk after the session, if we don't run into each other before then.
We use a bridge that calls Twig templates on runtime in a separate frontend directory. Every template represents a component.
If you want to have a look:
* The library: https://github.com/namics/twig-nitro-library
* Drupal module that uses the library: https://github.com/namics/drupal-twig-nitro-bridge
* Frontend for it (we use an old version at the moment): https://github.com/namics/generator-nitro
Sadly the documentation is not really up-to-date/detailed.
Thanks Orlando! Nitro is new to me, I will definitely have a look.