Applied progressive decoupling weather.com, angular, and drupal

Applied Progressive DecouplingWeather.com, Angular, and Drupal

Matt Davis (Mediacurrent)John Kennedy (Acquia)Preston So (Acquia)

April 20, 2016

Welcome!→ Matt Davis (@im_mr_jmd) is Lead Drupal Architect at

Mediacurrent. He is a longtime Drupal developer and avid outdoorsman living in the mountains of Asheville, North Carolina. Matt has been working with Drupal since 2003 and has been a full-time Drupal developer since 2007.

▪ drupal.org/u/mrjmd▪ matt.davis@mediacurrent.com

Welcome!→ John Kennedy (@commercejohn) is Product Manager

for Acquia Lightning, an open-source distribution of Drupal 8, and Program Manager for the Drupal 8 Module Acceleration Program (MAP).

▪ drupal.org/u/johnkennedy▪ john.kennedy@acquia.com

Welcome!→ Preston So (@prestonso) has designed and

developed websites since 2001 and built them in Drupal since 2007. He is Development Manager of Acquia Labs at Acquia and a frequent speaker on front-end and Drupal development.

▪ drupal.org/u/prestonso▪ preston.so@acquia.com

What we’ll cover→ Risks and rewards of decoupling Drupal→ Why progressively decouple Drupal?→ Weather.com’s Progressively Decoupled Panels→ Framework-agnostic progressive decoupling→ Progressive decoupling in Acquia Lightning→ The future of progressively decoupled Drupal

Risks and rewards of decoupling Drupal

Decoupled Drupal→ Decoupled Drupal is the process of employing a

different front end from Drupal’s own (most often in a JavaScript or native application framework).

→ This decoupled front end speaks to Drupal via RESTful API, using familiar HTTP methods such as GET, POST, PATCH, and DELETE.

Decoupled Drupal→ Using Drupal solely as a data service is not a new

concept; Services in Drupal 6 and 7, restWS, and other modules have enabled RESTful Drupal.

→ Although Drupal can be used to back other primarily back-end applications (Rails, .NET, PHP), it is predominantly used to drive native applications and single-page JavaScript applications.

Rendering on the client side→ Single-page JavaScript applications tend to depend

on a universal JavaScript framework, which is capable of being executed on both client and server.

→ Popular examples include Angular, Ember, and React. These frameworks perform client-side rerendering without incurring an additional full page request.

→ Native applications usually have their own systems.

Static pages

Subscribe to our newsletter You have been successfully subscribed!

E-mail address

Submit

full-page refresh

Drupal

Drupal front endPHP

Data

Templates

HTML

Drupal

Drupal front end

Data

Templates

HTML

Dynamic pages with AJAX

Subscribe to our newsletter

E-mail address

Submit

Drupal

Drupal front endPHP

Data

Templates

HTML

Subscribe to our newsletter

Success!

E-mail address

Submit

Subscribe to our newsletter

E-mail address

Submit

AJAX request

AJAX response

Dynamic pages with rerendering

Subscribe

E-mail

Submit

HTTP request

HTTP response

Lorem ipsum dolor sit amet, consectetuer adipiscing.

Lorem ipsum dolor sit amet, consectetuer adipiscing.

Success! Here are others that might interest you:

Lorem ipsum dolor sit amet, consectetuer adipiscing.

Drupal

Decoupled front end

REST API

Decoupled Drupal

Drupal

Drupal front end

PHP

Data

Templates

HTML

Drupal

Decoupled front end

PHP

Data

Templates

HTML

Other language

JSONREST API

Decoupled Drupal

Drupal

Native Android application

PHP

Data

Templates

App code

Java

JSON

Drupal

Single-page application(universal JavaScript)

PHP

Data

Templates

HTML

JS

JSONREST API REST API

Decoupled Drupal

Silex application

Data

Templates

HTML or app code

JSON

Drupal

Native iOS application

PHP

Obj-C PHP

REST API

Rewards of decoupled Drupal→ Separation of concerns (structure vs. presentation)→ Content syndication (write once, publish everywhere)→ Differentiated development velocities between front

and back end (independent front-end redesigns)→ Rich application ecosystem (auxiliary applications

such as SPAs, native mobile, and IoT)

Risks of decoupling Drupal→ Additional point of failure (REST API, other hosting)→ No cross-site scripting or input sanitization→ No in-place, in-context editing or administration→ No layout and display management→ No previewable content workflow→ No modules affecting the front end→ No system notifications (errors, messages)→ No BigPipe progressive loading or cache tags→ No accessible markup or user experience benefits

When should you decouple Drupal?→ A site powering one or more other sites→ A site powering one or more other applications→ A site powering multiple sites or applications

→ Standalone applications→ Standalone sites

For standalone sites and apps ...→ You don’t need the overhead of a decoupled

architecture to power a standalone site or application.→ Doing so can lead to workarounds that duplicate,

interrupt, or otherwise obfuscate the integrity of end-to-end Drupal.

→ There is a better solution: progressive decoupling.

Why progressivelydecouple Drupal?

Fully decoupled Drupal

Subscribe

E-mail

Submit

HTTP request

HTTP response

Lorem ipsum dolor sit amet, consectetuer adipiscing.

Lorem ipsum dolor sit amet, consectetuer adipiscing.

Success! Here are others that might interest you:

Lorem ipsum dolor sit amet, consectetuer adipiscing.

Drupal

JavaScript framework

REST API

Fully decoupled Drupal

Subscribe

E-mail

Submit

HTTP request

HTTP response

Lorem ipsum dolor sit amet, consectetuer adipiscing.

Lorem ipsum dolor sit amet, consectetuer adipiscing.

Success! Here are others that might interest you:

Lorem ipsum dolor sit amet, consectetuer adipiscing.

Drupal

JavaScript framework

REST API

Progressively decoupled Drupal

Subscribe

E-mail

Submit

HTTP request

HTTP response

Lorem ipsum dolor sit amet, consectetuer adipiscing.

Lorem ipsum dolor sit amet, consectetuer adipiscing.

Success! Here are others that might interest you:

Lorem ipsum dolor sit amet, consectetuer adipiscing.

Drupal

REST API

Drupal front end

JS framework

Risks of decoupling Drupal→ Additional point of failure (REST API, other hosting)→ No cross-site scripting protection or input sanitization→ No in-place, in-context editing or administration→ No layout and display management→ No previewable content workflow→ No modules affecting the front end→ No system notifications (errors, messages)→ No BigPipe progressive loading or cache tags→ No accessible markup or user experience benefits

Rewards of progressive decoupling→ No additional point of failure (REST API, other hosting)→ Cross-site scripting protection and input sanitization→ In-place, in-context editing or administration→ Layout and display management→ Previewable content workflow→ Modules affecting the front end→ System notifications (errors, messages)→ BigPipe progressive loading and cache tags→ Accessible markup and user experience benefits

No additional point of failure→ You will likely need to find an additional place to host

a fully decoupled application. If the REST API fails to give a response, then your application will lack the data it needs.

→ Reserving client-side rendering responsibilities for JavaScript means that Drupal’s server-side output and JavaScript framework can be at the same origin.

Security and input sanitization→ Drupal provides extensive protection against cross-

site scripting and cross-site request forgery.

→ Drupal also provides built-in input sanitization on forms submitted to Drupal. Most JavaScript frameworks have their own input sanitization systems.

In-place, in-context administration→ Do your editors need Toolbar, Contextual Links, or

Quick Edit?

→ Ensure that your client is aware of what administrative capabilities they could lose when these tools are unavailable in a fully decoupled environment.

Layout and display management→ Does your application need Panels (IPE, Panelizer,

Page Manager) or block placement?

→ Interpolating JavaScript framework components into existing Drupal front-end elements means the retention of layout management benefits.

→ Option for fully decoupled: RESTful Panels module (encodes Panels configuration as JSON)

Previewable content workflow→ How will your decoupled application handle preview

of unpublished or moderated content?

→ By definition, embargoed content cannot be publicly accessible, but your marketers will want to preview it.

→ Drupal already is adept at content workflow and preview, thus limiting the overhead of customizing your REST API to include unpublished content.

Modules affecting the front end→ Many modules provide forms or other front-end

elements as part of their functionality, which fully decoupled applications have no access to.

→ Rather than adding overhead to custom REST API development, progressive decoupling ensures continued access to front-end components of modules.

System notifications→ Many editors rely on contextualized system errors as

part of their everyday workflow.

→ Fully decoupled applications are unable to easily consume Drupal’s built-in system notifications.

BigPipe and cache tags→ BigPipe enables progressive loads of pages based on

the cacheability of a page’s component, thus abbreviating time to first paint.

→ This cacheability is declared in cache tags, which describe dependencies on data managed by Drupal and allow for cache invalidation of items that rely on granular content contained therein.

Accessible markup and UX benefits→ How will your decoupled application handle preview

of unpublished or moderated content?

→ By definition, embargoed content cannot be publicly accessible, but your marketers will want to preview it.

→ Drupal already is adept at content workflow and preview, thus limiting the overhead of customizing your REST API to include unpublished content.

Case study: Weather.com→ Weather.com has been progressively decoupling

Drupal using interactive Angular components for years using Progressively Decoupled Panels.

→ Further background: https://www.youtube.com/watch?v=ehsX6_9TgYc; http://www.mediacurrent.com/blog/migrating-weathercom-drupal-presentation-framework

Case study: Weather.com

Subscribe

E-mail

Submit

Lorem ipsum dolor sit amet, consectetuer adipiscing.

Success! Here are others that might interest you:

Lorem ipsum dolor sit amet, consectetuer adipiscing.

editor manipulates page layout

Subscribe

E-mail

Submit

Lorem ipsum dolor sit amet, consectetuer adipiscing.

Success! Here are others that might interest you:

Lorem ipsum dolor sit amet, consectetuer adipiscing.

Case study: Weather.com

Angular client-side rendered output

Drupal server-side rendered output

editor manipulates page layout

Angular client-side rendered output

Drupal server-side rendered output

Weather.com’sProgressively Decoupled Panels

Weather.com before Drupal→ 144 origin servers in three data centers

→ 50 million page views per day, half going to origin

→ Forecasts for over 2.9 million locations

→ Hundreds of dynamic weather maps

Weather.com major considerations→ Performance and caching

→ Front-end developer team

→ Editorial team

Performance and caching→ Split page up into wrapper and panes

→ Same wrapper from origin to everyone

→ Edge computations using ESI

→ Client-side rendering using Angular

Front-end developers→ JavaScript developers want to write JavaScript

→ Don’t want to learn Drupal APIs

→ Want to keep up with rapidly evolving ecosystem

Editorial team→ Want intuitive ways to create pages

→ Want to work independently

→ Want to create new content and pages without developer involvement

Presentation Framework→ Mechanism for putting components onto pages

→ Supports Angular, PHP and static templates

→ Modules served by Drupal or ESI

Why Panels?→ Variants and selection rules

→ Reusable and exportable panes

→ Context

→ Drag-and-drop interface

Framework-agnostic progressive decoupling

Wunderground.com→ Why not use Angular 2?

→ Rebuilding the foundation under the forty-story building

→ Refactoring opens the door to other frameworks as well

Goals of framework agnosticism→ Give JavaScript developers flexibility

→ Keep some guard rails in place

→ Preserve strong editorial experience

Where is TWC headed?→ Per variant presentation choice

→ Increased experimentation and innovation

Progressive decoupling in Drupal 8→ Decoupled Blocks module in development

→ Built on top of blocks

→ Already supports Angular 2 and React, more coming

Progressive decoupling in Acquia Lightning

Lightning and progressive decoupling→ Current approach

→ Our plans for progressive decoupling integration

→ JavaScript application assembly

Current approach→ Utilize Decoupled Blocks module

→ Share standards with JavaScript developers

→ Train authors

Our plans for progressive decoupling→ Development sprint next week→ Lightning integration by 1.2→ Panels enhancement→ Component configuration standards→ Component communication standards

JavaScript application assembly→ Advantages:

▪ Advanced content management• Layout• Preview

▪ Facilitates large teams▪ Maintenance and security

→ Disadvantages:▪ No server-side JavaScript processing▪ Two-step component publishing process

The future of progressively decoupled Drupal

Dynamic sites and app-like experiences

→ Future features:▪ Socket.io integration▪ Node.js server-side JavaScript processing▪ Component templates▪ JavaScript framework integration into Drupal core▪ Native compilation

Dynamic sites and app-like experiences

→ Future use-cases:▪ Commerce integrations▪ Customer self-service portals▪ Live content streams

Thank you!Matt Davis (@im_mr_jmd)drupal.org/u/mrjmdmatt.davis@mediacurrent.com

John Kennedy (@commercejohn)drupal.org/u/johnkennedyjohn.kennedy@acquia.com

Preston So (@prestonso)drupal.org/u/prestonsopreston.so@acquia.com