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

The Microfrontend Revolution Module Federation with Angular

The Microfrontend Revolution Module Federation with Angular

Manfred Steyer

May 25, 2020
Tweet

More Decks by Manfred Steyer

Other Decks in Programming

Transcript

  1. @ManfredSteyer About me… Manfred Steyer, ANGULARarchitects.io (Remote) Angular Workshops and

    Consulting Google Developer Expert for Angular Trusted Collaborator in the Angular Team Manfred Steyer
  2. @ManfredSteyer Module Federation Solves Some of Them! UI Composition UI

    Consistency Bundle Size/ Sharing Dependencies Version Conflicts between Microfrontends …
  3. @ManfredSteyer Idea const Component = import('http://other-app/xyz') Does not work with

    webpack/ Angular CLI Even lazy parts must be known at compile time!
  4. @ManfredSteyer Webpack 5 Module Federation Shell (Host) Microfrontend (Remote) //

    Maps Urls in // webpack config remotes: { mfe1: "mfe1" } // Expose files in // webpack config exposes: { Cmp: './my.cmp.ts' } import('mfe1/Cmp')
  5. @ManfredSteyer How to Get the Microfrontend's URL? Shell (Host) Microfrontend

    (Remote) RemoteEntrypoint.js <script src="…"></script>
  6. @ManfredSteyer How to Share Libs? Shell (Host) Microfrontend (Remote) shared:

    [ "@angular/core", "…" ] shared: [ "@angular/core", "…" ]
  7. @ManfredSteyer Conflicting Shared Libs Option A: Reuse it anyway Option

    B: Load own Both might be bad Prevent organizationally (e. g. conventions, contracts, monorepos) Integration-Testing
  8. @ManfredSteyer Challenge • Create a proper snake strategy • Publish

    it as a Module Federation Remote • Award Ceremony: ngCopenhagen Online Meetup • June 23th, 2020 • https://www.meetup.com/de-DE/ngCopenhagen/ • All Details • https://github.com/manfredsteyer/snake
  9. @ManfredSteyer Well … Webpack 5 is currently beta Shown examples:

    PoC w/ custom webpack conf + patched CLI lib CLI: Not before version 11 (fall 2020) Squeeze federation config into CLI's webpack config Custom Builder (e. g. ngx-build-plus)
  10. @ManfredSteyer Request Product Specify Order Approve Order Send Order Budget

    Hierarchy Employee IT-Expert Manager Buying Agent Product
  11. @ManfredSteyer "Right" Domain Size Should mirror a real-world domain Large

    enough: Most use cases don't overlap domains Small enough: One team per domain
  12. @ManfredSteyer Domain Driven Design gives a lot of advice! Also

    see blog at: http://angulararchitects.io
  13. @ManfredSteyer Catalog Approval Shared Feature Feature Feature Feature Feature …

    … … … … … … … … @ManfredSteyer Catalog App Approval App Option 1: One Monorepo w/ several Domains
  14. @ManfredSteyer Consequences Easy to share code Decoupling b/w domains: Conventions

    or Tools (Linting) Easy to enforce one version policy Different technologies: possible
  15. @ManfredSteyer Catalog Approval Shared Feature Feature Feature Feature Feature …

    … … … … … … … … @ManfredSteyer Catalog App Approval App Option 2: One Repo per Domains Publish shared libs seperately via npm
  16. @ManfredSteyer Consequences Enforces decoupling b/w domains Allows different versions (good

    or bad?) Allows different technologies Needs lots of automation Sharing Code via npm and versioning might be a pain
  17. @ManfredSteyer Recommentation, if you are not sure Start with a

    monorepo Enforce decoupling via linting Reconsider splitting into several repos later
  18. @ManfredSteyer Very Simple Message Bus @Injectable({ providedIn: 'root' }) export

    class MessageBus { events$ = new ReplaySubject<DomainEvent>(1); }
  19. @ManfredSteyer Well … Don't directly share state b/w sub-domains (coupling!)

    You might use Redux for eventing (like a Message Bus)
  20. @ManfredSteyer Sharing Widgets is a Trade-Off too Decoupled Sub-Domains Shared

    Widgets Prevent duplicate code (DRY) Separate Ways
  21. @ManfredSteyer Recommentation Technical Widgets (e. g. Design System): Sharing ok

    Use Case-specific widgets: Try to avoid (coupling!)
  22. @ManfredSteyer Recommentation Try to stick with one technology (e. g.

    Angular) --> Share framework-specific components Works in the short and mid run Eventually, when needed, export them as web components (e. g. w/ Angular Elements)
  23. @ManfredSteyer Possibilities HTTP Only Cookie: Tunnel through one origin (+XSRF

    Token) Token via Header: Different origins (consider OAuth2/OIDC) • Share token via message bus or session storage
  24. @ManfredSteyer Backend for Frontend (BFF) BFF µFrontend BFF µFrontend BFF

    µFrontend µServices µServices µServices µServices
  25. @ManfredSteyer Approaches Dashboard loads widgets from each sub-domain • Flexibility

    • Needs stable contracts • Agreements on common look and feel • Lots HTTP Calls Dashboard as a own sub-domain • Pros and Cons are inversed
  26. @ManfredSteyer Backend for Frontend (BFF) Dashboard µBFF Dashboard µFrontend BFF

    µFrontend BFF µFrontend µServices µServices µServices µServices Messaging
  27. @ManfredSteyer Conclusion Main Purpose of µFrontends: Scaling Teams Decoupling Federation:

    Import From Other App Sharing Libs Take Care of Conflicts Know your Architecture Goals
  28. @ManfredSteyer Be like Bonnie and think first! Evaluate whether you

    need µFrontends No: Majestic Monolith Yes: Consider Module Federation