applied progressive decoupling weather.com, angular, and drupal
TRANSCRIPT
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▪ [email protected]
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▪ [email protected]
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▪ [email protected]
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
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
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
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
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
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
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/[email protected]
John Kennedy (@commercejohn)drupal.org/u/[email protected]
Preston So (@prestonso)drupal.org/u/[email protected]