A closer look at how Drupal adopts the 4 MACH principles

Posted on
Drupal or MACH


Is Drupal monolithic or when having a closer look, it's absolutely not? 


Do you really need an API for everything? And what about Drupal and APIs?


Drupal is not Cloud-native. But there are enough tools to help you run Drupal in the cloud.


Headless or not is not the question. It's how you go headless. Drupal strikes a great balance.


If we take a step back and look at the modular architecture of Drupal we see that indeed yes Drupal core does a lot of things and could be deemed monolithic. However, Drupal's core is getting smaller and smaller, moving more and more core modules to contrib modules. In Drupal 11 this trend will even accelerate.

While core still does a lot, it is this interdependency of data, users, and content that allows building the more ambitious multi-languages, countries, markets, channels, roles, sites... with multiple integrations for multiple personas experiences. On the other hand, there are enough examples of DIY microservice hell, where customers need to hire people to maintain all these microservices, do release management, DevOps, and maintain knowledge of all the separate services. A lot of risks are introduced for the sake of speed. That's not acceptable for every organization. Monoliths are often called a big ball of mud, microservice can easily become a big distributed ball of mud.

Having a standard in Drupal on how modules interact with core creates stability and allows the 1M strong Drupal community to maintain the 45k module ecosystem of functionality. So a bit of packaging and creating valuable dependencies out of the box has a lot of value. As a customer, having the possibility to move your project to another integrator gives you lots of freedom too. For developers, knowing there are standards the framework brings, allows them to easily take over projects, so less need for heroes saving the day. This re-usability is the foundation of contribution. It's also the foundation of industrialisation in an agency, being able to implement all projects the same way allows for maximum maintainability.

Drupal moving to automatic updates is a good thing. Maintaining Drupal has never been easier either. Yes, there is a certain maintenance cost to Drupal and there is a level of complexity and dependency present. On the other hand, this is needed to build ambitious digital experiences and give all that no-code/low-code power to the site builder while maintaining developer freedom.

Finally Drupal is based on Symfony which gives you the possibility to develop custom parts in the application by overriding existing code. This increases flexibility where needed.

I believe Drupal is striking a great balance between microservice and monolith. Core brings value in the sense that a lot of choices have been made through 20 years of evolution. Being microservice or not is not the question. It's how you balance and create value with it, that's the question.


Drupal exposes the most relevant data through its APIs. Can it improve? Yes, there is certainly room, but does one need an API for everything? No. Striking the right balance between no APIs VS everything having an API is better. APIs were relevant and I believe Drupal does this pretty well. Being API-first is not the selling point. Deriving value from APIs is. Drupal is perfectly capable of delivering any piece of content or data through its APIs to deliver a great customer experience across channels.


Drupal is not cloud-native but companies like acquia.com, pantheon.io, platform.sh, and dropsolid.io help you to run Drupal in the cloud. Drupal runs events like the Olympics which means it's pretty scalable. Here too, is cloud-native a selling point? No, it's how you derive value from the cloud. Use the cloud where needed. Drupal being open means you can also run Drupal on your own premise if you want to guarantee data sovereignty. Companies like amazee.io and dropsolid.io help you do this.

Run the parts of your stack in the cloud or use cloud services where it makes sense. The cloud can also lock you in and make your costs spiral out of control. Keeping a sense of openness and ability to move your stack keeps a healthy pressure on cloud suppliers and service providers to keep costs under control.

Here too, to cloud or not to cloud is not the question. Use it where it creates value for you while maintaining your sovereignty.


Is headless in itself a selling point? No. Being able to deliver content multi-channel to improve customer experience across channels is creating a more interactive experience for wizards and search for example.

With JSONAPI, GraphQL, and native support for custom REST endpoints, Drupal delivers the Hybrid Headless model. It can serve your needs when it comes to connectivity and a flexible delivery model. With over 45,000 Drupal modules, you can integrate with all the back-end systems you need to keep your business moving forward. Whether you need to consume or interact with an outside service or make use of data inside our digital experience platform, a powerful Hybrid Decoupled model ensures there are no limits to what you can achieve.

Where can Drupal improve? By connecting its powerful site-building system with JavaScript front-ends out of the box. For example, connecting layout-builder with front-ends out of the box. Interesting contributions are happening to provide more JavaScript out of the box. For example, Next.js for Drupal allows components to build Drupal out of the box. Here is a demo. There is also this contribution on how to build static blog sites with Drupal.

Headless or not headless is not the question. It's how you go headless. Again Drupal strikes a great balance.