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
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
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
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
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
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
• 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
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
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
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
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
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 »
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 »
hacktivist123
ug
nonews
bkuhlmann
mattenn
vananth22
slashnephy
quramy
tatsumiakahori
luccafort
nina01
leveragestech
ryotasugawara
keathley
bcantrill
cherdarchuk
sugarenia
jakevdp
eileencodes
nonsquared
davidbonilla
scottboms
hursman
denniskardys
jasonvnalue
![Thank you! Shedrack Akintayo Developer Relations Engineer, Platform.sh fi[email protected]](https://files.speakerdeck.com/presentations/4c5792f781824312a3e734111beff730/slide_23.jpg){kind=link}
