Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Decoupling 101 - Why decouple, when not to, progressive decoupling and success stories in decoupling

Decoupling 101 - Why decouple, when not to, progressive decoupling and success stories in decoupling

shedrack akintayo

April 05, 2022
Tweet

More Decks by shedrack akintayo

Other Decks in Programming

Transcript

  1. Shedrack Akintayo Lagos (Nigeria) whoami • Developer Relations Engineer @

    Platform.sh • Technical Writer and Community Builder
  2. Table of contents • What is Decoupling • Basics of

    decoupling • Deploying decoupled • Why decouple • When not to • Progressive decoupling • Success stories
  3. backend frontend backend REST API/GraphQL frontend Monolithic Decoupled THE BASICS

    OF DECOUPLING Monolithic Drupal: content management & content presentation Decoupling: separates presentation responsibilities to JS app, powered by an accessible Drupal API for content Abstraction: if API is abstract enough, frontends can be switched out Teams: allows for dedicated teams with narrower responsibilities; JS recruitment & collaboration together Heads: replacing heads → many heads
  4. THE BASICS OF DECOUPLING Monolithic Drupal: content management & content

    presentation Decoupling: separates presentation responsibilities to JS app, powered by an accessible Drupal API for content Abstraction: if API is abstract enough, frontends can be switched out Teams: allows for dedicated teams with narrower responsibilities; JS recruitment & collaboration together Heads: replacing heads → many heads
  5. DEPLOYING DECOUPLED • Platform.sh multi-app: project is a cluster of

    containers, communicating over internal network. • Each app resides in own subdirectory • Communicate over a relationship, where Gatsby pulls content from API • Build app and serve, or configure environment-dependent builds → start dev server → Live Previews • Single project: develop alongside each other; teams focused on single app
  6. DEPLOYING DECOUPLED • Platform.sh multi-app: project is a cluster of

    containers, communicating over internal network. • Each app resides in own subdirectory • Communicate over a relationship, where Gatsby pulls content from API • Build app and serve, or configure environment-dependent builds → start dev server → Live Previews • Single project: develop alongside each other; teams focused on single app
  7. DEPLOYING DECOUPLED • Platform.sh multi-app: project is a cluster of

    containers, communicating over internal network. • Each app resides in own subdirectory • Communicate over a relationship, where Gatsby pulls content from API • Build app and serve, or configure environment-dependent builds → start dev server → Live Previews • Single project: develop alongside each other; teams focused on single app
  8. DEPLOYING DECOUPLED • Platform.sh multi-app: project is a cluster of

    containers, communicating over internal network. • Each app resides in own subdirectory • Communicate over a relationship, where Gatsby pulls content from API • Build app and serve, or configure environment-dependent builds → start dev server → Live Previews • Single project: develop alongside each other; teams focused on single app
  9. The Pros • Focus • Hiring experts • Interchangeable frontends

    • Common API Expert teams with dedicated responsibilities With an abstract enough API, teams can focus on one part rather than the whole site. Node.js experts focus on the frontend, WordPress experts on the backend, etc. Better recruiting around other languages Far more talented Node.js developers out there than WP/PHP. Use the tools best for the job Gatsby, React, etc. are far better and more flexible at solving the frontend problem; don’t rely on plugins. Interchangeable frontends Again, requires an abstract API - switch out the frontend to the newest and best framework you need. Many heads! Same backend consumed by multiple frontends with different purposes. Reasons to decouple your apps
  10. MANY HEADS ACROSS MANY TEAMS • Headless is a bit

    of a misnomer • Removing presentation responsibilities from Drupal to one or many sites • One for each device • One for each regional site • One site for each team, collaborating back upstream • Keep content in sync across them all
  11. The cons • Work to get there • Double the

    concerns • Rewrite tools • Constant vigilance Work required to abstract API Decoupling means removing context/dependence of frontend from the backend. Work will have to go into a strong API that can be consumed by anything/no assumptions. x2 tests + security concerns to worry about Two apps, two teams, double the tests and security oversight. Rewrite tools supported by monoliths Plugin ecosystems establish (editorial) workflow standards that will need to be rewritten from the ground up to continue supporting those teams work. Team isolation Promise: frontend/backend teams don’t need to worry about backend/frontend engineering. Reality: work is necessary to keep coordination and visibility - especially when hosted in two places. Reasons not to decouple your apps
  12. ⍅ A bit Different from full decoupling ⍅ You get

    all the benefits of decoupling while avoiding some of the downsides ⍅ In progressive decoupling, a JavaScript framework is layered on top of the preexisting Drupal front end (Vue, React). ⍅ Best way to progressively decouple a website progressively is to use widget because of the flexibility they provide. ⍅ Widgets are stand-alone applications, by nature they adhere to the decoupled principle ⍅ Appeals to both developers and content editors ⍅ Developers get to leverage whatever javascript framework of their choice without having to mess with the content editors workflow Progressive decoupling
  13. - Progressive decoupling doesn’t leverage server-side rendering via Node.js -

    Higher Cost - JavaScript's ascension is not going to stop any time soon; therefore, the risk of sacrificing some of Drupal's popular capabilities might still seem insignificant compared to the JS advantages at a front-end level Drawbacks of Progressive Decoupling
  14. IFFR + Burst + Pre-pandemic: film festival run on a

    single Drupal 7 site + Challenge: moving entire festival online during COVID; improve site reliability and festival credibility + Delivered 100% online festival, which opened up for further microservice enhancements towards a general streaming platform + Created a flexible, virtual platform that sets the stage for new, exciting digital opportunities and experiences for future festivals Read the case study »
  15. Open Social: decoupling in progress for a SaaS + A

    fully built Decoupled SaaS product + a Drupal installation profile they sell to individual users so that they can get their own community site + They decouple because It allows independent development + It opens us up to more integrations and external channels + Decoupling has provided a Open Social a platform that is faster, leaner, more flexible and easier to continuously update and improve. Read the case study »
  16. Thank you To our wonderful sponsors, our awesome community and

    fantastic volunteers! Platinum sponsors