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
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.
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
- 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.
Weather.com has been progressively decoupling Drupal for a couple years.
- 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
- don’t want to learn Drupal APIs
- 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
- drag & drop interface
Framewordk-agnostic progressive decopuling
- 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.
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.