What It Means to be Drupal Adjacent
One of the major objectives of Drupal 8 is the desire to “get off the island.” Drupal opened its doors to using and contributing to a broader ecosystem of projects instead of replicating functionality in Drupal. We now see tools like Twig and various Symfony components in Core. Contributed modules are also able to integrate projects and Software Development Kits (SDKs). For example, Password Strength, Digital Ocean, and Hubspot API integrate through Drupal’s native use of Composer. This philosophy helps those of us that more closely identify as “Drupal Adjacent.”
I consider being Drupal Adjacent as having some degree of experience in Drupal but maintaining expertise in a breadth of other technology. You are capable of leveraging Drupal’s strengths along with the strengths of other tools. Drupal Adjacent architects use “the right tool for the right job.” Drupal can serve as a bi-directional tool or framework in a broader architecture of systems and other tools can serve a discrete purpose.
As I consider myself Drupal Adjacent, I want to share my experience working in the Drupal community.
My Background
I have experience with a wide breadth of technology that includes Drupal. My first encounter with Drupal was in 2004. A friend of mine had a job implementing a CMS for her client. She evaluated many and chose Drupal - which was at version 4.x at the time. This was before the Security Team created issues and published patches. This was back before the mantra: “don’t hack core.” This was the time when that lesson was learned.
I came in as a backend developer with solid database experience. LAMP was all the rage and this was a great project for me to gain experience with a CMS and framework after writing my own basic CRUD (create, read, update, and delete a database record) without a framework.
Living close to Silicon Valley, once the project ended, I moved on to other opportunities that came along that had different languages, platforms, and storage systems.
Pareto’s Principle and Drupal projects
Over the next 12 years, I had many opportunities to come back to Drupal as it matured. I found how Pareto’s Principle (or the 80/20 rule) applied to Drupal projects. Some clients already had Drupal systems, but had hit limitations. Others had Drupal projects started but weren’t able to launch due to inability to fully integrate the modules they had in place. More than once I saw a site that was 80 percent complete with contrib modules, but still not ready to launch. I made an intermittent career out of helping those teams complete projects that needed custom code to close the gap and launch.
Knowing my way around the Drupal API and framework, I knew how to write modules, hooks, and functions to add the final pieces. I knew when in the development lifecycle I should add custom code. I have written many modules, but many only addressed very niche, custom needs my clients had.
Drupal Adjacent
I have never built a site from scratch that has left my local environment. Don’t ask me to evaluate the best out of a dozen modules in the community.
But,
- You want to upload data from your Drupal system to Hubspot for communication campaigns? I got your back.
- Do you have years of data and would like use some of the new Big Data and Machine Learning tools out there? Hundreds of field_data_field_% tables got you down? Set up a reporting database and create some views to normalize the data.
- The outcome of several contributed modules has created a less-than-ideal outcome for your users? More than once I was able to write functions to change workflow states and other node properties with one user button click.
When you come to realize that not every solution has to be a Drupal solution, a world of tools open up to you. So many times your problem has already been solved, but perhaps not in a Drupal specific fashion. This is where your Drupal knowledge can help bridge that gap allowing use of best in breed tools.