Next-Level Drupal - Applied progressive decoupling with JavaScript

Posted on Mon, 5/9/2016
4 minutes read

This is my first Drupal session I attended about decoupling Drupal from the frontend and using a JavaScript framework. This is interesting to me because I sit on the fence as a Acquia Certified Drupal Developer & a JavaScript developer who wants to do everything in JavaScript these days. Once again this is uploaded right after the session so probably has typos.

This talk was presented by:

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

This talks page is up on the Drupalcon site where there will probably be more good info.

Risks & Rewards

Decoupled Drupal is the process of employing a difference front end from Drupal's own (most often in a JavaScript or native application framework). This decopuled front end speaks to Drupal via RESTful API.

Using Drupal soley as a data serive is not a new concept; Services modules existed on Drupal 6 & 7. It can be used to do lots of things but we're really just focusing on the frontend today.

With Drupal's page model you have a full page refresh on every page load which is what using a JavaScript framework would solve.

Decoupled Drupal is important because you can use whatever language you want to accomplish your site. Freedom! You can have a single REST API that handles lots of different frontends.


  • Seperation of concerns.
  • Content syndication (write once, publish everywhere)
  • Differentiated deelopement velocities between front and backend


  • Additional point of failure
  • No cross-site scripting or input sanitization
  • no in-place, in-context edition or administration
  • no layout and display management
  • no previewable content workflow
  • no modules affecting the front end
  • no system notifications
  • no BigPipe progressive loading or cache tags
  • no accessible markup or user experience benefits.
    • Drupal 8 has built in accessibility :)

When should you do this?

  • A site powering one of more other sites
  • a site powering one of more other applications
  • a site powering multiple sites or applications
  • you don't need the overhead of a decoupled architecture to power a standalone site or application

Why progessivly decouple Drupal

Don't use the JavaScript framework on it's own, put it in Drupal and let Drupal serve it up a bit too. Most of things are served up by Drupal with parts handled by a framework.


  • no additional point of failutre
  • cross-site scripting protection
  • in-place , in context editing and administration
  • layout and display management
  • previewable content workflow
  • modules affecting the frontend
  • system notifications
  • BigPipe progressive loading and cache tags
  • accessible markup and user experience benefits. has been progressively decoupling Drupal for a couple years.

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
  • hundres of dynamic weather maps


  • performacne and caching
    • split page up into wrapper and panes
    • same wrapper from origin to everyone
      • header & footer is cached and same to everyone
    • edge computations using ESI
    • client-side rendering using Angular
  • frontend developer team in house
    • JavaScript developers want to write JavaScript
    • don't want to learn Drupal APIs
    • want to keep up with JavaScript
  • editional team
    • want intuitive ways to create pages
    • want to work indepndently


  • Presentation framework
    • mechanism for putting components into pages
    • supports Angular, PHP, and static templaces
    • modules served by Drupal or ESI
  • why panels?
    • variants and selection rules
    • reusable and exportable pans
    • context
    • drag & drop interface

Framewordk-agnostic progressive decopuling


  • give JavaScript developers flexibility
  • keep some guard rails in place
  • preserve strong editorial experience

in Drupal 8

  • Decoupled Blocks module in development
    • Built on top of blocks
    • Already supports Angualr 2 and React, more comingi
    • developers can tightly copule component functionality to Drupal's exising system of rendered entities.

Final thoughts

My notes on this were pretty rough, but this semes like what we need to start doing on our sites, wanted to for awhile and it's the mix people now talk about where you get server & client rendering. The module they're working on seems cool because you can make rich dynamic blocks and people can just throw them wherever they want on the page.