Second part about Dave Hall's post named "Drupal, we need to talk" : The End of the Monolith.
Here are some elements of our discussions pided into 3 posts:
Part 1: CMS Drupal losing pace?
Part 2: The end of the monolith
Part 2/3 The End of the Monolith
In the five years Drupal 8 was being developed there was a fundamental shift in software architecture. During this time we witnessed the rise of microservices. Drupal is a monolithic application that tries to do everything.
Let’s just cut to the chase.
From a marketing perspective, it is imperative to recall that we have portrayed Drupal as the ultimate monolith. We must not deny it. It was something like this:
- Wordpress is the best to create a blog;
- With SPIP (Joomla, etc.) you can build an information portal;
- With Prestashop and Magento, an e-commerce website;
- With Drupal, dear friends, you can do everything! You can start off with one of the three options, add modules, and have a blast with Workbench, Rules and Services and have your job application, community portal, and e-commerce available in 26 languages.
We are not the only one to be held accountable, for several other institutions or companies had a wide-eyed faith in Drupal, and had reasonable grounds not to waste their time with other technologies.
We have historically chosen Drupal because of its cross-cutting functional coverage.
And then, the world has changed, and reality turned out a little bit different from what we had expected.
With Drupal, we have managed to build a multifunctional machine. We tried to spare you the confusion that comes with choosing the right module, the adequate stability, bugs, patches and forks, and for that we have worked with skilled developers. Our approach is undeniably time-consuming, but it cannot be portrayed as false advertising.
However, it is usually with a simple straw, a grain of sand, the increased performance of this well-oiled machine, and the inclusion of new functionalities, that tragedy strikes.
For that, Drupal is not the one to blame. This incredible, highly configurable system uses back-office site builders and relies on dozens of code lines to facilitate content management via a neat graphic interface.
For each http request, whether in back or front-office requires the execution of all the code lines. Each module will have to check and authenticate the request, and then to reference.
And then,
Then what?
so...
Sorry! The request has timed out, it is maybe necessary to increase the execution time, or the RAM allotted to PHP…
To the users, the back-office is as reactive as an anesthetized turtle and your system administrator refuses to increase these values just to make it work (why not perform a chmod 777 on the entire directory since we’re at it?)
This is when trouble found us…
First solution: We call the money-making machine! First, we increase the memory limit, then we add fronts, and MySQL servers, which could work for a while, but it’s better not to be the one to pay the bill.
With some experience you could’ve anticipated that, by separating the Back office from the front office and setting up each on a different server, using Varninsh, by disabling the cache according to certain rules, and using JS to wrap up the number of items in a bundle, etc, as well as including admin-sys during the very first stages of conception to anticipate any problem that might arise. The application could’ve been pided in… Wait a minute … Isn’t it a monolith?
In sum, this incredible V1 monolith is being increasingly damaged by each added feature… The team will soon feel as if the website was a house of cards running as fast as a high-speed train.
The Web has changed as well (caution: we are not taking coals to Newcastle here):
- In an enterprise/institution, everything used to go through the website or via e-mailing.
- Nowadays, the website is just an element among others: social media, mobile applications, broadcast platforms.
- Do you remember the comment box below the articles? Now we use a third-party service (Disqus) for them to show elsewhere.
- The management of a catalogue or a media library rarely stems from the website itself. In fact, products management is usually deported; for the website is no longer the sole sales channel.
- Do you use the same server to send your emails and to host your website? No. You use a third-party server such as Mailjet or MailChimp. The same applies to the push notifications of your mobile application, etc.
Which logically brings us to :
The first are the main components of your application, the second are the messengers and the cement that ensure cohesion and positive communication among all parties.
Should we leave it to the youth?
Today it is more common to see an application that is built using a handful of Laravel micro services, a couple of golang services and one built with nodejs. These applications often have multiple frontends; web (react, vuejs etc), mobile apps and an API. This is more effort to build out, but it likely to be less effort maintaining it long term.
We have worked really hard on it. We have a pipeline application with:
- Drupal 8, for content management
- A PHP Phalcon framework for business
- Several inbound and outbound APIs (ex: e-mailing);
- Several fronts with VueJS/ Volt (Phalcon template) and Drupal.
It’s the trend, our daily bread. It has become very rare not to stumble upon a subsequent project without interfaces with other systems, since Drupal has become a simple link of the chain.
Without wanting to mar the image of Laravel (Symfony, Phalcon, or your favorite framework), we can easily say that things are not so rosy.
Drupal’s days are over. Your development team is currently working with Laravel. Farewell. Farewell?
In nothing but hours we will have to work with a CRUD and a beautifully scaffolded back-office.
The front office is simple and direct, theme creators do not need a compass to find this or that function. The last JS library is also included in the pipeline asset management, without any interference whatsoever.
No magic, no hidden functions, nothing more, nothing less than what the client requested.
With excellent performances, you will feel powerful… Driiiiiing ! Your ringtone. Your client is calling. He wishes to add an additional field to his data entry interface.
After all, nothing sounds so bad. All you need is a few minutes to develop your back office, and your front office.
Dring, dring! Your client, again, who wishes to change a field’s title in the Back-office, and to add an explanation textbox for the sake of the writers. He does not understand why everything requires the intervention of the developer (even minor changes) whereas with Drupal he didn’t even have to inform you of such operations. Oh, and it’s also good to have a comprehensive system to manage passwords and send welcome emails. He’s able to change the text at any minute isn’t he?
Your developers and yourself will soon feel like giving up.
Why? Because they consider that their work is not as rewarding as they’d thought and because you will find it very difficult to explain why each small modification requires the intervention of developers.
Should we carry on? I think you should’ve understood by now. All we need is a good CMS.
Laravel and Symphony have good components indeed, but frankly did we already have one?
Now it’s all about performance.
I don’t want to state false information, for I do not have enough benchmarks to rely on. I know that a simple solution with a recent Framework and a CMS module can really compete with Drupal 8 website. But the more you add functionalities… the more time-consuming it will get, (knowing that Drupal 8 has a sufficient number of contributed modules) and the more you will narrow the performance gap.
The lesson you can learn from this story is that if you ever need content management that it not basic and/or if you ever think of further developing your project and you do not have enough resources to use all the necessary technologies, Drupal 8 might be what you are looking for...
To be continued...
Part 1: CMS Drupal losing pace?
