dries buytaert shares his view on decoupled drupal: when, why, and how

©2018 Acquia Inc. — Confidential and Proprietary

Decoupled Drupal When, Why, and How

January 11, 2017

Dries BuytaertChairman & CTO, Acquia

Preston SoDirector of Research & Innovation


In today's webinar

I. What is a decoupled CMS? II. Trade-offs & nuances of the decoupled CMS III. Why Drupal is an ideal decoupled CMS IV. The decoupled Drupal ecosystem

V. Why Acquia is an ideal platform for decoupled CMS VI. Decoupled Drupal case studies VII. How to decouple Drupal in 2018 VIII. Q&A


What is a decoupled CMS?


What is a decoupled CMS?

Decoupled CMS (also known as a "headless" CMS) is the use of a CMS as a content service providing content for consumption and manipulation by other applications.

A decoupled CMS can be used to deliver content to native applications, single-page applications, digital signage, conversational interfaces, AR-driven interfaces, and many others — even other back-end applications.


Why does it matter to content creators?

A decoupled CMS offers these advantages:

– Write once, publish everywhere. Content creators can take their content and deliver it on any experience.

– Single source of truth. Content creators can harness all of their content in one sole repository.


A decoupled CMS offers these advantages:

– API-first approach. Developers can use a set of APIs for data consumption rather than building the entire stack.

– Front-end freedom. Developers can create the experiences they want to build with the tools they want to use.

Why does it matter to developers?


Decoupled CMSes have gained popularity

These factors have led to decoupled CMS adoption:

– A desire to separate concerns of structure and presentation so that front-end teams and back-end teams can work independently from each other.

– Marketers and publishers are looking for solutions that can serve content to a growing list of channels and aren't coupled to a website.


API-first Drupal at a glance

IoT apps

Native apps

Chat apps

Single- page apps

Other back ends

Set-top boxes

Title

Body

Lorem ipsum dolor sit amet

Consectetur adipiscing elit lorem ipsum dolor sit amet.

Decoupled CMS

Lorem ipsum dolor sit amet Lorem ipsum dolor sit amet



How a decoupled CMS works

CMS

Site or repository built in CMS

REST API

Consumer application

Consumer applicationHTTP client

HTTP request

HTTP response


CMS

CMS front end

Server-side language

Data

Templates

Front-end code

CMS



Data

Templates

Front-end code

Other language

JSONWeb services

Monolithic vs. decoupled CMS

Monolithic Decoupled


CMS

Native Android application


Data

Templates

App code

Java

JSONWeb services

CMS

Single-page application (universal JavaScript)


Data

Templates

HTML

JavaScript

JSONWeb services

Two sample decoupled architectures


Silex application

Data

Templates

HTML or app code

PHP

JSON

Decoupled CMS

Native iOS application


Swift

Web services

Single repository for multiple consumers


Synchronous

AsynchronousExecution model: Universal JavaScript

Node.js

Server-side execution of JavaScript framework

Browser

Client-side execution of JavaScript framework

Executes JavaScript framework

Requests page from server

Renders initial HTML

Clie

ntS

erve

r


Performs bindings on HTML

Issues API request

Issues API response


Synchronous

AsynchronousExecution model: Universal JS with CMS

Server-side execution of JS

framework

CMS

Browser

Client-side execution of JS

framework

Renders initial HTML

Clie

ntS

erve

r


Performs bindings on HTML

Issues API request

Issues API response

Node.jsExecutes JavaScript

framework

Responds with CMS data

Requests page from server


Trade-offs and nuances of the decoupled CMS


Decoupled CMS trade-offs

Disadvantages

– Loss of in-context features

– Display and layout management difficulties

– No seamless end-to-end preview

– Additional point of failure

Advantages – Separation of concerns– Pipelined development– Easier resourcing


Disadvantage: Loss of in-context features

– Decoupled CMSes lack full-fledged editorial experiences integrated into the front ends to which they serve content

– Unless they expose a content editing interface tied to each front end, in-context administration and in-place editing are impossible

– In order to provide an editorial experience on the front end, the front end must be aware of that content editing interface


Disadvantage: No display and layout manipulation

– Decoupled CMSes are unopinionated about display and layout settings

– Among traditional CMSes' key features is the ability to control where content appears in a layout structure

– Editorial tools which enable this need have to be integrated into the front end that faces the end user to be useful


Disadvantage: No seamless end-to-end preview

– Editors are particularly concerned about how content will look once it's published

– Access to an easy end-to-end preview system, especially for unpublished content, is essential to editors' workflows

– In the headless CMS paradigm, developers have to jump through fairly significant hoops to enable seamless preview


Disadvantage: Additional point of failure

– If you're building a JavaScript application, adding a Node.js stack creates an additional maintenance burden

– Any other consumer applications will also require additional infrastructure

– If the repository serving content to consumers is not public-facing, then your users can't access your content


Advantage: Separation of concerns

– Structure versus presentation is increasingly relevant in decoupled architectures

– Increasingly, architects want to divide monolithic architectures into services with single responsibilities

– Front-end developers don't want to be encumbered by obstacles presented by the back end


Advantage: Pipelined development

– An API-design-first approach gives front-end and back-end teams independence

– The back-end team can build out the API while the front-end team consumes a dummy API that mimics the eventual production API

– The two teams aren't blocked by one another, and they converge at the API layer


Advantage: Easier resourcing

– With a robust API, any developer of any technology can communicate with your CMS to build their application.

– For web applications, JavaScript developers are often now less expensive than CMS developers.


Why Drupal is an ideal decoupled CMS


Drupal is an ideal decoupled CMS

You might not have expected it, but Drupal is an ideal option for your decoupled CMS. – Drupal has an expanding ecosystem of tools, web services, and

integrations surrounding it, just like leading content-as-a-service platforms

– Drupal enables you to take an API-first rather than API-only approach, unlike content-as-a-service platforms


The issue with decoupled CMSes on the market

– Decoupled CMSes on the market today like Contentful and Prismic are growing in popularity

– But whereas decoupled CMSes give developers flexibility, editors lose that flexibility on the web

– Here's where decoupled CMSes on the market fall flat:

– In-context administration and in-place editing of content

– Display and layout manipulation

– End-to-end preview of unpublished content


Drupal has a unique value proposition

– I'm not convinced decoupled CMSes as they are today are where the world is headed

– Drupal has one crucial advantage in that it can be, in one single package:

– An exceptional end-to-end CMS for editors who need control over the presentation of their website content

– A rich decoupled CMS for developers building out large content ecosystems


Decoupled content creation at a glance

IoT apps

Native apps

Chat apps

Single- page apps

Other back ends

Set-top boxes

Title

Body


Consectetur adipiscing elit lorem ipsum dolor sit amet.



Decoupled CMS


API-first Drupal at a glance

IoT apps

Native apps

Chat apps

Single- page apps

Other back ends

Set-top boxes

Lorem ipsum dolor sit a|

Title




Website

Decoupled CMS


The decoupled Drupal ecosystem


Site or repository built in Drupal


Web services


SDKs and reference

applications

HTTP request

HTTP response

The decoupled Drupal ecosystem


REST APIs

Core REST JSON API RELAXed Web Services

GraphQL

Overview of Drupal web services

Webservices


JSON API

– JSON API is a specification for REST APIs in JSON popular among JavaScript developers and adopted by the Ember and Rails communities.

– JSON API provides a standard way to query single entities, but it also provides all relationships contained therein and query operations via query string parameters.

drupal.org/project/jsonapi


JSON API

JSON API (abbreviated payloads,

merely illustrative)

Client issues request for an entity resource

Server issues response with single entity and all relationships

GET /jsonapi/node/1 ?include=field_author

{ "data": [{ "type": "articles", "id": "1", "attributes": { "title": "Foo", "body": "Lorem ipsum", }, ... }], "included": [{ "type": "people", "id": "5", "attributes": { "name": "Joe" } }] }


GraphQL

– GraphQL, originally created by Facebook to power its data fetching, is a query language that enables fewer queries and limits response bloat.

– GraphQL shifts responsibility from server to client: the server publishes its possibilities, and the client publishes its needs instead of receiving a response dictated solely by the server.

drupal.org/project/graphql


GraphQL

GraphQL (simplified payloads,

merely illustrative)

Client issues request declaring data requirements

Server issues response matching structure of declared requirements

{ title fieldAuthor { title } }

{ "title": "Foo" "fieldAuthor": { "title": "Joe" } }


The Waterwheel ecosystem

– Waterwheel is an emerging ecosystem of SDKs designed to accelerate development of Drupal-backed applications in a variety of technologies.

– Currently, a helper SDK is available for JavaScript and a full SDK is available for Swift to power iOS, tvOS, and other Apple applications.


SDKs and starter kits

– github.com/acquia/waterwheel.js

– github.com/kylebrowning/waterwheel.swift

– drupal.org/project/waterwheel

– github.com/acquia/ember-drupal-waterwheel

– github.com/acquia/ember-waterwheel-app

– github.com/acquia/react-waterwheel-app


Web services distributions

An ecosystem of distributions for developers consuming decoupled Drupal is emerging.

– github.com/acquia/reservoir

– github.com/acquia/headless-lightning

– github.com/contentacms/contenta_jsonapi

Headless Lightning

http://github.com/contentacms/contenta_jsonapi


Why Acquia is an ideal platform for decoupled CMS


The Acquia platform for decoupled Drupal

Acquia Cloud Drupal and Node.js Application Services • Cloud CD

Node.js

Drupal website Native application JavaScript application

FRO

NT

END

BA

CK

EN

D

Web services JSON API • GraphQL • Core REST

Drupal Drupal 8 • Acquia Lightning • Reservoir • Headless Lightning


Acquia Cloud: Drupal-tuned PaaS


Acquia Cloud for Node.js


Building and deploying Node.js


Managing your developer teams


Decoupled Drupal case studies


Real-time countdown clocks

Decoupled Drupal delivery

Hundreds of signs across the MTA subway system

Real-time updates


Contextual experiences pushed real-time

Multiple endpoints

Beyond the browser

Everything contextual across mobile devices, 120 digital signs, in-cabin video

Transformed passenger cruise experience


How to decouple Drupal in 2018


Q&A


Thank youDries Buytaert (@dries) [email protected]

Preston So (@prestonso) [email protected] drupal.org/u/prestonso

mailto:[email protected]?subject=

http://dri.es


Contact Us [email protected]

dries buytaert shares his view on decoupled drupal: when, why, and how

Technology