By Sebastian Gonzalez – Drupal Developer at Santex
I would like to clarify first off that I love to work with Drupal. I’ve been working with the Drupal platform for about 10 years now, and through all those years of getting frustrated over the same things, I realized something. I noticed that when certain clients or businesses had a previous project in Drupal that was successful, they would want to handle any future projects in the same way, when in reality Drupal may not have been the best tool to use.
In all these years of experience, I came across various projects and had a lot of different experiences – some very rewarding and others not so great. In some of these last projects that I didn’t think were so great, I noticed that something kept repeating. Drupal was being used for any kind of project on the simple premise that “it can do everything.”
If a client needs just any sort of app, we as developers usually say that Drupal is the solution. But what we should is is that Drupal could be the solution. Changing the message from “Drupal can do that” to “Drupal should be able to do that” is fundamental to starting any project off on the right foot.
Drupal is a CMS (Content Management System) that was intended to be a content administrator. Every page in the world has content, and when we talk about ‘content,’ we automatically think that it should be able to be handled administratively. This leads one to automatically think of a CMS like Drupal, WordPress, or Joomla. For me, the important question is what you want to do with the content. Where is this going and what is it going to be used for?
A lot of people view Drupal as a CWMS (Content Workflow Management System), and I agree with this vision. In my opinion, it makes sense to use Drupal when a business’s domain entails a lot of different types of content with multiple users who have different levels of permission. All of these users can alter the state of the content, making it fluctuate through different phases of the workflow where there aren’t annotations, reports, or emails involved.
The reality is that the vast majority of websites built using Drupal should not have used Drupal. This is not because Drupal can’t do the job, but rather because it’s a waste of all its functionalities that end up not getting used. A clear case of this is with classic brochure websites or institutional sites where the content is static and hardly changes over time. There isn’t much interaction between users beyond basic contact forms or a comments section.
Our world is currently dominated by mobile devices. Drupal was able to enter into the competition with its latest version 8, which came out in November 2016. Using and integrating components with the popular framework Symfony provides a robust back-end to facilitate API development. Drupal is jumping onto this trend with something called Headless – an architecture that uses Drupal as the back-end paired with a framework to present the data, which could be AngularJS, React.js, or any other framework.
In summary, I believe Drupal should not be used for:
- Simple brochure websites
- Single-purpose apps (like a chat application)
- Gaming apps
I think Drupal should be used for:
- News websites with multiple users
- Multi-user publishing apps
- Any app or website that includes workflows among people with different roles/permissions
- A mobile version for Drupal
To conclude, here are 4 more pieces of advice:
- Choosing one tool or another has to do with understanding the business’s control over the application or website. The more you know about the project, the greater the decision power in choosing which platform to use to meet those needs.
- Use Drupal from the start and don’t try to switch and start using it for something else when things are not properly in place.
- Stop saying “Drupal is the solution” and starting saying “Drupal could be the solution!”
- Always explore alternatives because new technologies are coming out everyday.
Those are my two cents.
About the Author – Sebastian Gonzalez is an experienced Drupal Developer at Santex, passionate about his work. Sebastian is a strategic team player always willing to contribute and to solve problems.