Decoupled Drupal is a topic that's been in larger community conversation for years, and has recently taken center stage with the release and growth of Drupal 8 and its API-first architecture.
But what does it all really mean? What is decoupled Drupal, and how could your business and its specific challenges benefit from decoupled Drupal powering your applications?
When a fresh copy of Drupal is installed on a server, the out-of-the-box functionality is to behave as a normal website. There are two main pieces at play in this setup: backend code that runs on the server to assemble pages before they go out to a user, and frontend code that runs in the browser once the user requests a page and it's delivered. This is a pretty typical use case for Drupal, and is a great option for a corporate site that may need some room to grow in complexity down the road, but not just yet. We call this monolithic Drupal.
Decoupled Drupal (also known as headless) removes the latter layer, no longer serving normal pages you'd typically get to via a web browser. Instead, headless Drupal is configured and developed to serve data to other applications that request the data they need to serve their purpose.
Consider Twitter for a moment. While not Drupal, Twitter has its own website, as well as many first- and third-party apps presenting its content, and all of that data comes from a separate application that serves that data (tweets) to all these apps at blinding speed. Each app in the ecosystem is requesting what it needs from this data layer by making calls to the Twitter API as the user navigates the app.
Now imagine your business sells widgets, both direct to end users and through channel resellers, and you've got a massive catalog problem. Certain products are only intended for specific resellers. Different resellers get different pricing. Discounts are a mismanaged mess. Widget sales staffers like to joke that nobody truly knows how it all works or where the numbers come from. And it's less a joke based on a modicum of truth than it is a playful way to communicate what's actually happening. Nobody even knows how this thing makes any money.
Now let's imagine we're restructuring all of this. A headless Drupal deployment will serve as our single source of truth. This gets you a great interface for adding new products, managing all approved discounts, managing pricing tiers, viewing detailed reports of your inventory and catalog, and having complete visibility over every ounce of data involved in powering your business.
A team of Drupal specialists maintain the code, adding any new business logic and features that need to be accommodated over time. But the real magic lies in what's possible when you begin building other applications that speak to our decoupled Drupal system via the APIs your Drupal experts have created.
We've got our rock solid source of data, complete with APIs to access that data. It can be queried on an as-needed basis to serve a consuming application's specific needs. Now we'll have separate websites, desktop and mobile applications consuming that data.
Let's say one of our larger resellers – this company brings us so much business that we created our best pricing tier because of them – wants its own ordering portal. Approved users can hop on and order whatever they need for their customers, and even have it drop shipped right to them. They want this to be a web app at their own domain, complete with logins and a checkout-like ordering process. With decoupled Drupal, this app can be built and maintained completely independently of any Drupal development, consume data from Drupal, and send data back, including that order that was just placed.
This app could then serve as boilerplate for a smaller reseller who wants something similar. Perhaps their needs are the exact same, but you need to make some configuration changes to set another price tier, maybe remove some special interface, and of course redesign the app's look and feel to match the reseller's unique brand.
We could also build a native mobile app to use in our warehouses. The rugged tablets and finger-mounted scanners being used in the warehouse can be integrated with our headless Drupal installation to keep it abreast of inventory in real time, ensuring that when the last XL Q-frame widget is coming off the shelf and shipping out, every app being powered by our decoupled Drupal installation will know it's gone, and let end users know. A notification system we built into Drupal can inform employees of the shortage so they can take appropriate action to secure fresh stock or let marketing know that we'll have a shortage for a while.
Speaking of marketing, we can build a completely separate dashboard that can be displayed on digital signage throughout the building, showing up-to-the-minute information on hot products, corporate messaging, upcoming events, and any other information imaginable, and it can all be centrally managed from Drupal.
Perhaps our executives want a data-heavy reporting app they can load up on tablets and computers. With our catalog and inventory data in Drupal, we can send the raw numbers, and said app can present any charts and graphs needed to help inform our decision makers when they're deciding what's next.
We could even build a print catalog generator that assembles the data into PDFs for each price tier every time a product is updated. You get the idea... Any data can be stored in Drupal, and presented any number of ways via any number of separate apps consuming just the data they need.
There's a lot of power there, but what other benefits are we looking at here?
Decoupled Drupal can grow with your business
Your Drupal experts can easily add new features and data fields whenever the need arises. If we want to add a completely new and unique feature for one specific downstream app, we can do so without affecting existing data and functionality of other apps.
When going with a decoupled architecture, you don't need to tackle everything at once. I can even imagine resellers and shareholders looking rather favorably upon a steady stream of useful apps and features coming down the pipe.
Have your cake, and eat it, too
Drupal doesn't need to be completely decoupled to serve non-Drupal apps. We can leave the typical monolithic Drupal intact while also building our external APIs on top to support our external apps.
This means we can use Drupal the more traditional way, presenting our corporate website as we normally would, while also building our web services to support access to data for all of our other apps. This can be an attractive route if you'd like to easily present some of that product data on web pages, but this could also be done with a separate website consuming data from a decoupled Drupal instance, so it's not 100% necessary.
But this also means that a smaller company that doesn't want to go all-in on decoupled Drupal right away can start small by first building its website with Drupal and going from there.
Front end developers can use whatever they want
Let's say you wanted to build that executive data app, and found a Javascript shop that makes great data-driven experiences using an ocean of Javascript libraries and proprietary frameworks. You've got a great in-house team, but they're already working on another app, and this other shop is just too perfect for the job.
With decoupled Drupal, these guys can use whatever languages and frameworks they'd like to get our results. Drupal's primary concern is to send the data that app needs. Your developers can focus on the app they're building, the chosen shop can do the same, working directly with your Drupal experts to get any API changes or additions they need to get the job done.
Drupal will become even better at operating as a service to other apps
Everything I've already mentioned is being done today using Drupal and a number of customer-facing technologies, such as Javascript or native mobile apps. But part of the beauty of Drupal is that it's always growing, and new functionality is always being contributed by community members.
Over time it's likely we'll see more community functionality geared towards apps consuming data from headless Drupal. It's also likely we'll see SDKs and other Drupal-supporting tools emerge out of other communities, particularly Javascript.