Dries Buytaert on decoupled Drupal

The presentation

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.

The appeal

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.

Created by Preston So, Acquia

The model

Created by Preston So, Acquia

While a traditional CMS performs a HTTP request to the CMS, decoupled setup does a four-step request:

1. Client makes a HTTP request to the consumer application.

2. Consumer application makes a HTTP request to the CMS

3. CMS uses REST API, or similar, to return data in a format like JSON.

4. 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.

Created by Preston So, Acquia

Created by Preston So, Acquia

The execution model follows this path:

1. Requests page from server
2. Executes JavaScript framework
3. Renders initial HTML
4. Executes JavaScript framework
5. Performs bindings on HTML
6. Issues API request
7. 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:

1. The loss of ‘in-context’ features such as in-place editing, which makes it harder to make quick edits.

2. 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.

3. 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!

4. 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:

1. The ‘separation of concerns’ between content, presentation and frontend and backend.

2. Better pipeline development because you can develop frontend and backend at different paces, which also facilitates more experimentation.

3. 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.

Specifically he mentioned the tools available, the web services support and the integration between Drupal and different JavaScript frameworks.

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.

Created by Preston So, Acquia

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.

From here, the webinar focused on some specifics of the Drupal offering, such as the established ecosystem of tools and SDKs (e.g. JavaScript SDK) and easy-to-use APIs.

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.

Dries gave examples of Drupal’s SDK and reference applications within the Waterwheel ecosystem (such as SDKs for JavaScript and SWIFT, all available as open source). He recommended Headless Lightning and Reservoir as great starting points for building a headless Drupal system.

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.

Backend:

• Acquia Cloud — Node.js application services and cloud CD
• Drupal — Drupal 8, Acquia Lightning, Reservoir, Headless Lightning
• Web services — JSON API, GraphQL, Core REST
• Node.js

Frontend:

• Drupal website
• Native application
• JavaScript application

Created by Preston So, Acquia

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:

1. 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.

2. Princess Cruises, that has an integrated system with multiple endpoints on board, from in-cabin TV to kiosks, all connected to passenger wristbands.

Decoupling Drupal

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.

Q&A

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.