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

2019-01-21-WebArch--OOP.pdf

 2019-01-21-WebArch--OOP.pdf

A presentation about modularity, architecture and organization patterns, applied to the development of large web apps

Stefan Tilkov

January 21, 2019
Tweet

More Decks by Stefan Tilkov

Other Decks in Technology

Transcript

  1. Architecting
    Large Web Apps
    Stefan Tilkov

    [email protected]
    @stilkov

    View full-size slide

  2. What is “large“?

    View full-size slide

  3. Scaling Dimensions
    Logic
    Load
    written in

    a day
    depends on

    German tax law
    a dozen

    users
    half

    of the

    planet
    Netflix
    Twitter
    Insurance

    Policy Management
    Facebook
    Amazon
    Random CMS

    View full-size slide

  4. Pick the best car:

    View full-size slide

  5. Architecture & Organization
    Modularization
    Frontend Strategies

    View full-size slide

  6. Architecture &
    Organization

    View full-size slide

  7. Conway’s Law: Organization → Architecture
    “Organizations which design systems
    are constrained to produce systems
    which are copies of the communication
    structures of these organizations.”

    – M.E. Conway

    View full-size slide

  8. Antipatterns

    View full-size slide

  9. Antipattern: Conference-driven Architecture

    View full-size slide

  10. Antipattern: Decoupling Illusion
    Stakeholder
    Stakeholder
    Stakeholder
    Platform Person

    View full-size slide

  11. Antipattern: Half-hearted Modularization
    Dev Ops

    View full-size slide

  12. Antipattern: Solution Centrism
    Stakeholder
    Stakeholder
    Stakeholder
    Solution

    View full-size slide

  13. Antipattern: Uncreative Chaos

    View full-size slide

  14. Antipattern: Authoritarian Regime

    View full-size slide

  15. Pattern: Autonomous Cells
    Stakeholder
    Stakeholder
    Stakeholder
    Biz
    Dev
    Ops
    Biz
    Dev
    Ops
    Biz
    Dev
    Ops

    View full-size slide

  16. Pattern: Autonomous Cells
    Stakeholder
    Stakeholder
    Stakeholder
    Biz
    Dev
    Ops
    Biz
    Dev
    Ops
    Biz
    Dev
    Ops

    View full-size slide

  17. Pattern: Evolutionary Architecture

    View full-size slide

  18. Pattern: Regulated Market

    View full-size slide

  19. Pattern: Marketing-based Governance

    View full-size slide

  20. Sizing Patterns

    View full-size slide

  21. Example: Product Detail Page
    • Core product data
    • Prose description
    • Images
    • Reviews
    • Related content Orchestration
    →μSOA

    View full-size slide

  22. Pattern: μSOA (Microservice-SOA)
    • Small, self-hosted
    • Communicating
    synchronously
    • Cascaded/streaming
    • Containerized
    Description: As seen on:
    • Netflix
    • Twitter
    • Gilt

    View full-size slide

  23. Pattern: μSOA (Microservice-SOA)
    • Close collaboration – common goal
    • Need for resilience/stability patterns for invocations
    • High cost of coordination (versioning, compatibility, …)
    • High infrastructure demand
    • Often combined with parallel/streaming approach
    • Well suited to environments with extreme scalability
    requirements
    Consequences:

    View full-size slide

  24. Example: Logistics Application
    • Order management
    • Shipping
    • Route planning
    • Invoicing
    Frontend
    →DDDD
    Event Bus/Infrastructure

    View full-size slide

  25. Pattern: DDDD (Distributed Domain-driven Design)
    • Small, self-hosted
    • Bounded contexts
    • Redundant data/CQRS
    • Business events
    • Containerized
    Description: As seen on:
    • (undisclosed)

    View full-size slide

  26. Pattern: DDDD (Distributed Domain-driven Design)
    • Loose coupling between context
    • Acknowledges separate evolution of contexts
    • Asynchronicity increases stability
    • Well-suited for to support parallel development
    Consequences:

    View full-size slide

  27. That UI thing? Easy!

    View full-size slide

  28. Example: E-Commerce Site
    • Register & maintain
    account
    • Browse catalog
    • See product details
    • Checkout
    • Track status
    →SCS

    View full-size slide

  29. Pattern: SCS (Self-contained Systems)
    • Self-contained,
    autonomous
    • Including UI + DB
    • Possibly composed of
    smaller microservices
    Description: As seen on:
    • Amazon
    • Groupon
    • Otto.de
    • https://scs-architecture.org

    View full-size slide

  30. Pattern: SCS (Self-contained Systems)
    • Larger, independent systems,

    including data + UI (if present)
    • Able to autonomously serve requests
    • Light-weight integration, ideally via front-end
    • No extra infrastructure needed
    • Well suited if goal is decoupling of development teams
    Consequences:

    View full-size slide

  31. The final sizing pattern …

    View full-size slide

  32. Benefits of Monoliths
    • Highly cohesive, tightly integrated, single unit of deployment
    • Standard application with internal modularity
    • No artificially introduced distribution
    • Single unit of development and evolution
    • Easy to refactor
    • Homogeneous technical choices
    • Ideally suited for single small team

    View full-size slide

  33. We love monoliths –

    so let’s build a lot of them!

    View full-size slide

  34. Frontend Architecture

    View full-size slide

  35. “Really remote” vs. “almost local”
    μS μS
    μS
    μS μS
    μS
    Inside DC;

    Latency: μs
    Frontend Typically Internet;

    Latency: ms

    View full-size slide

  36. “Backend for Frontend”
    μS μS
    μS
    μS μS
    μS
    BFF
    Frontend
    http://samnewman.io/patterns/architectural/bff/

    View full-size slide

  37. Multiple BFFs for different clients
    μS μS
    μS
    μS μS
    μS
    BFF
    Frontend
    BFF
    Frontend
    BFF
    Frontend
    Imagine more
    arrows here

    View full-size slide

  38. Multiple channels – facing every user
    Browse product Pick recommendation Buy Check status Comment

    View full-size slide

  39. Users expect a seamless
    experience across
    channels

    – everything accessible,
    everywhere.

    View full-size slide

  40. Build services that actually do something
    Process Flow
    Presentation
    Domain Logic
    Data
    JDBC in
    disguise
    Useful
    and
    specific
    Re-
    usable
    and low-
    level

    View full-size slide

  41. Assumption:
    Services matter most
    (a.k.a. “SOAs Original Sin”)
    UIs matter
    more.

    View full-size slide

  42. μS
    μS
    μS μS
    μS
    Frontend
    μS
    Frontend + services in a
    backend architect’s mind
    μS
    μS
    μS μS
    μS
    Frontend
    μS
    Frontend + services in
    the real world

    View full-size slide

  43. Redundancy with Multiple BFFs
    μS
    μS
    μS μS
    μS
    μS
    Frontend A Frontend B Frontend C

    View full-size slide

  44. Ideal world UI componentization
    μS
    μS
    μS μS
    μS
    μS
    FE
    μS μS
    FE
    Not all μS
    need a UI
    “Vertical”

    Responsibilit

    View full-size slide

  45. SCS: Self-contained Systems
    http:/
    /scs-architecture.org

    View full-size slide

  46. Backend Platform
    More than one platform
    μS
    μS
    μS μS
    μS
    μS
    Frontend Platform
    FE
    μS μS
    FE

    View full-size slide

  47. Rendered on
    Client
    Rendered on
    Server
    Desktop
    Mobile Set top
    Web App Native App
    Frontend, we’ve got frontends
    Frontend
    Hybrid

    View full-size slide

  48. Web UI Integration: Links
    System 1 System 2

    View full-size slide

  49. Web UI Integration: Redirection
    System 1 System 2

    View full-size slide

  50. Web UI Integration: Transclusion
    System 1 System 2

    View full-size slide

  51. Web UI Integration: Web Components
    System 1 Component

    View full-size slide

  52. How to get away with “just” the Web
    • Mobile first
    • Responsive design
    • Progressive enhancement
    • Shared assets
    • Pull vs. push
    • Sacrifice (some) efficiency
    Small frontends, loosely coupled

    View full-size slide

  53. Rendered on
    Client
    Rendered on
    Server
    Desktop
    Mobile Set top
    Web App Native App
    What about other approaches?
    Frontend
    Hybrid

    ✔ ✔
    ?

    View full-size slide

  54. Native frontends resemble server monoliths
    Goals:
    • As few assumptions as possible
    • No implementation dependencies
    • Small interface surface
    • Based on standards
    • Parallel development
    • Independent deployment
    • Autonomous operations
    Constraint:
    • Only internal modularization
    Solution (sort of):
    • Organizational
    structure
    • Platform interfaces
    • Release trains
    • Discipline

    View full-size slide

  55. Rendered on
    Client
    Rendered on
    Server
    Desktop
    Mobile Set top
    Web App Native App
    What about other “modern” web apps?
    Frontend
    Hybrid

    ✔ ✔
    (✔)
    ?

    View full-size slide

  56. Assumption:
    JS-centric web apps can

    be as good as native apps
    They shouldn’t be as bad!

    View full-size slide

  57. “Web service”1)
    • Use HTTP as transport
    • Ignore verbs
    • Ignores URIs
    • Expose single “endpoint”
    • Fails to embrace the
    Web
    1) in the SOAP/WSDL sense
    “Web app”2)
    > Uses browser as runtime
    > Ignores forward, back,
    refresh
    > Does not support linking
    > Exposes monolithic “app”
    > Fails to embrace the
    browser
    2) built as a careless SPA

    View full-size slide

  58. HTML & Hypermedia
    • In REST, servers expose a hypermedia format
    • Option 1: Just use HTML
    • Option 2: Just invent your own JSON-based, incomplete
    clone
    • Clients need to be RESTful, too
    • Option 1: Use the browser
    • Option 2: Invent your own, JS-based, buggy, incomplete
    implementation

    View full-size slide

  59. $('.multiselect', context).each(function() {

    $(this).multiselect({

    selectedList: 2,

    checkAllText: "Alle",

    uncheckAllText: "Keinen"

    }).multiselectfilter({label:"",

    width:"200px"});

    });

    Project

    name="project" size="5" multiple>

    DISCOVER

    IMPROVE

    MAGENTA

    ROCA

    ROCKET



    View full-size slide

  60. Why choose a monolith if you don’t have to?
    Any sufficiently complicated JavaScript client
    application contains an ad hoc, informally-
    specified, bug-ridden, slow implementation of
    half a browser.
    (Me, with apologies to Phillip Greenspun)

    View full-size slide

  61. ROCA: Resource-oriented Client
    Architecture
    http:/
    /roca-style.org

    View full-size slide

  62. If you’re a fan of single page apps,

    at least build more than one
    • Don’t reinvent browser integration features
    • Accept some inefficiency
    • Trade-off for framework independence
    • Avoid modularity à la Java EE, OSGi etc.

    View full-size slide

  63. Maintaining Consistency

    View full-size slide

  64. Challenges & Cross-cutting Concerns
    Single sign-on
    End-to-end testing
    Visual consistency
    Re-use
    Skill transfer

    View full-size slide

  65. Visual Components
    • Design System
    • Style guide
    • Pattern library
    http://styleguides.io

    View full-size slide

  66. Style Guide Challenges
    • Possible centralization & resulting bottlenecks
    • (Semi-)manual workflow
    • Copy/paste & resulting redundancy & overhead

    View full-size slide

  67. Recommendations

    View full-size slide

  68. 1.
    Know where your problems are

    View full-size slide

  69. 2.
    Beware of the monolith …

    View full-size slide

  70. 3.
    … unless it makes sense

    View full-size slide

  71. 4.
    Create evolvable structures

    View full-size slide

  72. 5.
    Embrace the Web

    View full-size slide

  73. Christian Albrecht
    [email protected]
    Phone: +49 171 5514847
    innoQ Deutschland GmbH
    Krischerstr. 100
    40789 Monheim am Rhein
    Germany
    Phone: +49 2173 3366-0
    innoQ Schweiz GmbH
    Gewerbestr. 11
    CH-6330 Cham
    Switzerland
    Phone: +41 41 743 0116
    www.innoq.com
    Ohlauer Straße 43
    10999 Berlin
    Germany
    Phone: +49 2173 3366-0
    Ludwigstr. 180E
    63067 Offenbach
    Germany
    Phone: +49 2173 3366-0
    Kreuzstraße 16

    80331 München
    Germany
    Phone: +49 2173 3366-0
    @stilkov
    That’s all I have.

    Thanks for listening!
    Questions?
    Stefan Tilkov
    @stilkov

    [email protected]
    Phone: +49 170 471 2625

    View full-size slide

  74. www.innoq.com
    OFFICES
    Monheim
    Berlin
    Offenbach
    Munich
    Hamburg
    Zurich
    FACTS
    ~150 employees
    Privately owned
    Vendor-independent
    SERVICES
    Strategy & technology consulting
    Digital business models
    Software architecture & development
    Digital platforms & infrastructures
    Knowledge transfer, coaching & trainings
    CLIENTS
    Finance
    Telecommunications
    Logistics
    E-commerce
    Fortune 500
    SMBs
    Startups

    View full-size slide