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

Transcript

1. Decoupling 101 Why decouple, when not to, progressive decoupling and success stores in decoupling
2. Shedrack Akintayo Lagos (Nigeria) whoami • Developer Relations Engineer @ Platform.sh • Technical Writer and Community Builder
3. Table of contents • What is Decoupling • Basics of decoupling • Deploying decoupled • Why decouple • When not to • Progressive decoupling • Success stories
4. The basics of decoupling
5. 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
6. 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
7. Deploying decoupled
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. 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
10. 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
11. 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
12. Why decouple advantages and improvements
13. 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
14. 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
15. … or not to decouple consider the following (or your CMS)
16. 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
17. Progressive decoupling
18. ⍅ 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
19. Drawbacks of Progressive decoupling
20. - 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
21. Decoupling success stories
22. 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 »
23. 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 »
24. Thank you! Shedrack Akintayo Developer Relations Engineer, Platform.sh firstname.lastname@platform.sh
25. Thank you To our wonderful sponsors, our awesome community and fantastic volunteers! Platinum sponsors
26. Thank you Gold sponsors Silver sponsors
27. Stay in touch #ddd2022 on Drupal slack @drupaldevdays /drupaldevdays