Dries Buytaert on decoupled Drupal
There’s a lot of buzz around decoupled content management systems (CMSs) at the moment, so we were excited to listen to Drupal founder and Acquia CTO Dries Buytaert’s webinar on decoupled Drupal.
On 11 January 2018, Drupal founder and Acquia CTO Dries Buytaert and Director of Research & Innovation Preston So led a webinar on decoupled Drupal. You can view the webinar and presentation slides on the Acquia website. We didn’t watch it live (3am for East Coast Australia!), but we did register and review the webinar. Below is our summary and some key takeaways you may be interested in. You may also like to check out Acquia's Decoupled Drupal ebook.
What is a decoupled CMS?
A decoupled CMS, also known as a ‘headless’ CMS, separates the frontend display from the content management system. Dries discussed the power of a decoupled CMS when used as a content service for distribution to multiple channels, such as mobile, Internet of Things, conversational user interfaces and digital kiosks.
Dries sees decoupled CMSs as delivering benefits to both content creators and developers.
The advantages for content creators are:
- The ability to create content once and then publish to multiple channels
- Creating ‘one source of truth’
Dries also introduced some of the advantages for developers, such as:
- An API-first approach
- The ability for frontend developers to use different programming languages and environments
- A clear separation of frontend and backend teams (which can deliver a few benefits)
- The ability to serve different applications from a single backend (with the content managed in one place)
Why a decoupled CMS?
Two main factors have led to the adoption of decoupled CMSs. Firstly, the desire to separate architecture and presentation so frontend and backend teams can work independently; and secondly the drive by marketers and publishers to push content to multiple channels that aren’t necessarily linked to a website.
While a traditional CMS performs a HTTP request to the CMS, decoupled setup does a four-step request:
Client makes a HTTP request to the consumer application.
Consumer application makes a HTTP request to the CMS
CMS uses REST API, or similar, to return data in a format like JSON.
Consumer application takes the data and converts it into a usable format based on the type of application it is. So in a decoupled website app, it will convert the data into HTML. If it’s Alexa (for instance), it will convert this data into the conversational output used by Alexa.
The execution model follows this path:
- Requests page from server
- Renders initial HTML
- Performs bindings on HTML
- Issues API request
- Issues API response
Tradeoffs of a decoupled CMS
This section of the webinar focused on the disadvantages of a decoupled CMS, emphasising the importance of developers understanding these tradeoffs so they can make the best decision for each project.
Some of the disadvantages covered were:
The loss of ‘in-context’ features such as in-place editing, which makes it harder to make quick edits.
The inability to make changes to the display and layout. The example Dries gave here was landing pages, where you can choose between different layout templates, move blocks of content around, etc. While these layout tools are generally available in a CMS, they’re not available in most decoupled CMSs and it’s a lot of frontend work to recreate this feature.
The lack of page previews, which means that content creators can’t see a preview of what the page would look like…something that Dries identifies as causing a lot of pain for many organisations!
A more complex stack, with more elements in it, which can increase costs and introduces additional risks.
The webinar then covered some additional advantages of a decoupled CMS, specifically:
The ‘separation of concerns’ between content, presentation and frontend and backend.
Better pipeline development because you can develop frontend and backend at different paces, which also facilitates more experimentation.
Easier to resource…here, Dries mentioned that frontend developers are often more affordable than backend developers and a decoupled architecture provides more separation of these roles.
Dries said that when considering a decoupled CMS, you need to look at each project to decide if a decoupled CMS is a good fit. For example, he highlighted the fact that a decoupled CMS is probably not a great idea for a client with lots of content creators who need, and use, layout features and page preview.
Why Drupal is an ideal decoupled CMS
The second half of the webinar focused on Drupal as a decoupled CMS. Dries talked a bit about Drupal — the fact that it’s been around for a long time (18 years) and its perception as a great CMS. He then spoke about why it’s a great decoupled CMS, and the fact that the work Drupal has done around moving web services support into the base Drupal platform means it can work as a decoupled CMS.
He described Drupal as a ‘hybrid’ offering — a point of difference to competitors, which are only decoupled. He referred to Drupal’s API-first approach as a big win compared to the API-only approach of other decoupled CMSs.
He talked about the issues faced with the other decoupled CMSs, namely the shortcomings for content creators including the lack of in-page editing, the lack of a preview facility and the inability to make layout changes.
A simple diagram at slide 33 shows the different Drupal web services:
- Core REST API
- JSON API
- RELAXed web services
- GraphQL - feels it’s a big part of the future
Dries talked about the advantages of JSON API (it allows you to get two objects with one query, e.g. data and author) and the plans to move JSON API into the core Drupal platform.
He also gave a brief rundown on GraphQL, which was created by Facebook. He describes it as a tool to query and fetch data in a more simple and efficient way from a decoupled CMS and that it can also be used to complete more complex queries and return ONLY what you want.
Why Acquia is an ideal platform for decoupled CMS
From here, Dries took a broader viewpoint, looking at Acquia as an ideal platform for a decoupled CMS.
- Acquia Cloud — Node.js application services and cloud CD
- Drupal — Drupal 8, Acquia Lightning, Reservoir, Headless Lightning
- Web services — JSON API, GraphQL, Core REST
- Drupal website
- Native application
Dries described Acquia Cloud as a complete platform for building decoupled CMSs, including Acquia’s tools to help manage teams.
He also showcased the Acquia Cloud user interface, for Drupal as well as Node.js implementations.
Decoupled Drupal case studies
The webinar looked at two case studies that use decoupled Drupal:
MTA (the New York City subway organisation) that has hundreds of signs updated in real-time across the city, using beacons in subway trains to display arrival times.
Princess Cruises, that has an integrated system with multiple endpoints on board, from in-cabin TV to kiosks, all connected to passenger wristbands.
Finally, before the Q&A session, Dries looked at how to decouple Drupal (and whether it’s a good choice for your project) via a flow chart. The flowchart is designed to help stakeholders decide whether to decouple or not. You can view the flowchart on a recent blog Dries wrote.
There were a couple of important questions (and answers) during the final fifteen minutes of the presentation. We thought these four points were particularly important to mention here…
Drupal as hybrid — Dries and Preston emphasised that with Drupal as a hybrid solution, you can have the content previews and other content tools with API.
SEO benefits — Dries and Preston agreed that when you decouple Drupal you lose SEO benefits and also talked about losing accessibility too. While Drupal has spent years optimising code for accessibility, these optimisations aren’t brought across when you convert the object to HTML.
Acquia Site Factory — while decoupled Drupal isn’t available yet on Acquia Site Factory it will be soon.
Decoupled and personalisation — yes, can use Acquia Lift API to provide personalised content to any frontend you have.