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

Decoupled web applications have recently gotten attention in the software development industry, this is because of how useful and effective it can be for development teams. Decoupling is a software architecture pattern that entails splitting web applications into smaller components that perform only a subset of tasks.

This is advantageous because it becomes easier to maintain and update code without affecting the whole application or needing to understand each part of the site. Decoupling comes with its own risks of added complexity, and cannot always be implemented quickly or even the right choice for every site.

In this talk, we'll explore the basics of decoupling, and how you can identify whether decoupling is appropriate for your site. We’ll also cover progressive decoupling as a migration strategy, as well as a series of success stories from teams and individuals that have used a decoupled architecture for their applications in production.

shedrack akintayo

February 17, 2022
Tweet

More Decks by shedrack akintayo

Other Decks in Programming

Transcript

  1. Decoupling 101
    Why decouple, when not to,
    progressive decoupling and
    success stores in decoupling

    View full-size slide

  2. Shedrack Akintayo
    Lagos (Nigeria)
    whoami
    ● Developer Relations
    Engineer @ Platform.sh
    ● Technical Writer and
    Community Builder

    View full-size slide

  3. Table of
    contents ● What is Decoupling
    ● Basics of decoupling
    ● Deploying decoupled
    ● Why decouple
    ● When not to
    ● Progressive decoupling
    ● Success stories

    View full-size slide

  4. The basics of decoupling

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  7. Deploying decoupled

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  12. Why decouple
    advantages and improvements

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  15. … or not to decouple
    consider the following (or your CMS)

    View full-size slide

  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

    View full-size slide

  17. Progressive decoupling

    View full-size slide

  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

    View full-size slide

  19. Drawbacks of Progressive
    decoupling

    View full-size slide

  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

    View full-size slide

  21. Decoupling success stories

    View full-size slide

  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 »

    View full-size slide

  23. OpenSocial: 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 »

    View full-size slide

  24. Thank you!
    Shedrack Akintayo
    Developer Relations Engineer,
    Platform.sh
    [email protected]

    View full-size slide