Should you decouple? When? How? What are the risks that a decoupled Drupal site involve? What are the undeniable, hard-to-resist-to advantages of “teaming up” your Drupal site/mobile/native app with a fast, cool JavaScript framework and of using Drupal as a back-end content repository “only”?
And, most importantly: is a “headless” build suitable for your own web project?
Our web development team here, in Toronto, comes with its very first piece of advice for you now, when you're facing all these crucial questions: always use the context of your very own web project to filter all the “trends” seeming to dominate the digital landscape at some point or another!
Before deciding to go for a decoupled implementation, make sure that all the members of the team involved (Drupal developers, project managers, content editors) clearly understand what a decoupled Drupal architecture is. And whether the technical risk involved is worth the effort.
Whether this approach is exactly what your web project needs.
Now, let us help you find the answer to your legitimate decoupling-related questions:
1. “But What Is a Decoupled Drupal Architecture, After All?”
To put it simply: decoupling Drupal means separating the back-end of your website/app from its front-end (either partially or totally).
Now if we are to detail a bit, we would have to add that:
- in a decoupled Drupal context we would have Drupal playing its role in the back-end, that of storing and sending forward pure data
- the front-end (aka, the “responsible” of everything related to the user experience) role will be played by a JavaScript framework (e.g. Backbone.js, Angular.js)
- the presentation layer can range from Alexa to Raspberry PI, to pretty much anything that can consume the data sent over by the Drupal-powered back-end
Drupal's “role” can easily resume to what the content producers...produce, while the coupled front-end framework will be “responsible” for what the users see on your site/app. Responsible for creating a faster and richer user experience.
In other words: Drupal will be handling the editorial, content creation and administrative tasks, while the coupled framework will be handling the front-end, communicating with the Drupal back-end via API.
The obvious “points of attraction” of such an API-only approach are the unlimited freedom and flexibility granted to front-end developers.
Unchained from the “need” to know how to write or to decipher Drupal-specific code each time they need to improve the look and feel of a website, front-end developers get to choose from different approaches of building a website.
They're free from the monolithic Drupal architecture with the presentation layer backed in through the Drupal theme itself. Free from the tightly interconnected back-end and front end.
2. “Why Should I Decouple? What's In It for My Own Site/App?”
Now this is a more than legitimate question that you should be asking yourself once you've fully understood what a decoupled Drupal build is.
Here are some key advantages if you decide to go for a “headless” Drupal site/app:
- it allows you to create some truly interactive user experiences (it's the browser who'll take over the user experience responsibility and so all the back-and-forth interaction will be a real-time one; a key aspect to consider when developing in-browser apps)
- it grants your team of front-end developers almost unlimited creative power; no more restrictions coming from the back-end + total freedom for front-end developers to use their native tools and to craft the user experience while they still get to harness Drupal's power via APIs
- it enables you, as a decoupled Drupal site owner, to future-proof your website; once you decide to redesign it, you can do that without having to re-implement your whole back-end, too. And vice versa. Flexibility and convenience!
- it enables you, the site owner, to hire non-Drupal specialists, too, since front-end developers won't need to be Drupal experts, as well. You will no longer be limited to collaborating exclusively with developers having a deep understanding on the Drupal back-end architecture, of the Drual-specific code. Even more flexibility for you!
3. “What Type Web Projects Would Benefit Most from Decoupling Drupal?”
And this might just be the best headless Drupal-related question you've asked yourself so far!
It's definitely a matter of: “Is this solution a perfect fit for my own site/app, too?”
See if you can identify your own type of Drupal web project in the examples here below and you'll have the answer to your question.
So, decoupled Drupal is best used for:
- Native mobile apps, especially now, that you're “spoiled” with RESTful services in Drupal 8 core, creating clean APIs is easier than ever. Your mobile apps users won't even need to interact directly with your Drupal site when accessing your native app. Your website's front-end will be using the same APIs as your native mobile app! Also, you get to build new and new mobile apps without the need to access the data that your back-end stores.
- Web projects involving front-end developers with no Drupal expertise
- Web projects that include multiple development teams
- Web projects with front-end teams depending on unlimited freedom for structuring and displaying the content
- Web projects where the presentation layer combines data coming from several API sources: social media, CMSs, video management systems
- Web projects with multiple content consumers that are live simultaneously (e.g. a Drupal site plus several mobile apps, as well)
4. “Which Are The Main Drawbacks of a Decoupled Drupal Site?”
“So, do you suggest that I should just go... headless, that Drupal 8's new them layer is just something I can easily do without?”
This might just be the question bumping into your head right now, isn't it?
Well, it's true that going headless comes with its drawbacks. You risk to throw away some of Drupal 8s' “goodies”:
- permissions
- a well-enhanced, seamless admin experience in Drupal 8
- user authentication
The best approach is the “moderate decoupling” or, if you prefer, the “progressively decoupled Drupal”.
This means that instead of going reckless and losing all of Drupal 8's out-of-the box flexibility and power as you go for a fully decoupled Drupal site, you should:
- Still leverage Drupal's theme layer's power, using it to render most of a given web page
- Decouple only SOME of the web page's components, mostly those that require a faster and richer user experience
In a nutshell: moderation is key! No need to waste time, energy and a good “load” of incredibly powerful Drupal elements and... reinvent the wheel!
And now, to support our pledge for the progressive approach to decoupling, let us back it up with one single example: NBA.com!
This site's using Angular 2 for rendering only certain parts of its web pages, while their static components are rendered by Drupal!
And speaking of this site using the “hybrid” approach, here's a Drupalcon Baltimore 2017 session filled with all the details and “enlightening” infos that you might find useful:
In Conclusion:
It's not for no reason that decoupled Drupal makes such a tempting type of CMS architecture, but you should first of all:
- not take API-fist Drupal 8 for an API- only CMS
- give it a very deep thought, lest you should decouple too much of your site and lose some of the already-built, powerful Drupal tools.
