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

6 Things You Should Know About MicroFrontends @ngCopenhagen, Juni 2020

6 Things You Should Know About MicroFrontends @ngCopenhagen, Juni 2020


Manfred Steyer

June 23, 2020


  1. @ManfredSteyer ManfredSteyer 6 Things You Should Know About Micro Frontends

    Manfred Steyer, ANGULARarchitects.io Angular Copenhagen
  2. @ManfredSteyer Do you remember her? Bonnie Barstow, PhD

  3. @ManfredSteyer Software Engineering is a Team Sport

  4. @ManfredSteyer Coordination b/w Teams

  5. @ManfredSteyer Monolith Flight System

  6. @ManfredSteyer Booking Service Check-in Service Boarding Service Luggage Service Microservices

    Sub-Domains (DDD)
  7. @ManfredSteyer Booking App Check-in App Boarding App Luggage App Microfrontends

  8. @ManfredSteyer Lots of Questions …

  9. @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
  10. @ManfredSteyer How to implement Microfrontends? ?

  11. @ManfredSteyer Several Options • Hyperlink-Integration • Loading Web Components into

    your index.html • Loading separate SPAs into your index.html • Loading separately compiled Angular Modules • Webpack 5 Module Federation
  12. @ManfredSteyer DEMO: Webpack 5 Module Federation

  13. @ManfredSteyer How To Identify Good Sub-Domains and hence Microfrontends?

  14. @ManfredSteyer Request Product Specify Order Approve Order Send Order Budget

    Hierarchy Employee IT-Expert Manager Buying Agent Product Organizational boundaries like departments or different domain experts Different models or same entities w/ different meaning
  15. @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
  16. @ManfredSteyer Domain Driven Design gives a lot of advice! Also

    see blog at: http://angulararchitects.io
  17. @ManfredSteyer Monorepo or Polyrepo?

  18. @ManfredSteyer Catalog Approval Shared Feature Feature Feature Feature Feature …

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

    or Tools (Linting) Easy to enforce one version policy Different technologies: possible
  20. @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
  21. @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
  22. @ManfredSteyer Recommentation, if you are not sure Start with a

    monorepo Enforce decoupling via linting Reconsider splitting into several repos later
  23. @ManfredSteyer Pro Tip: Tooling for Monorepos https://nrwl.io/nx

  24. @ManfredSteyer Communication

  25. @ManfredSteyer Communication is a Trade-Off Decoupled Sub-Domains Communication b/w Sub-Domains

  26. @ManfredSteyer Ideas As little as possible! Messaging/ Eventing: Loosly Coupling

    Trigger a (Domain) Event Don't expect an answer!
  27. @ManfredSteyer Very Simple Message Bus @Injectable({ providedIn: 'root' }) export

    class MessageBus { events$ = new ReplaySubject<DomainEvent>(1); }
  28. @ManfredSteyer Also Consider: Server-Side Messaging µService µFrontend µService µFrontend µService

  29. @ManfredSteyer Redux for Communication?

  30. @ManfredSteyer Well … Don't directly share state b/w sub-domains (coupling!)

    You might use Redux for eventing (like a Message Bus)
  31. @ManfredSteyer Sharing Widgets

  32. @ManfredSteyer Sharing Widgets is a Trade-Off too Decoupled Sub-Domains Shared

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

    Use Case-specific widgets: Try to avoid (coupling!)
  34. @ManfredSteyer You can't have both: Decoupling and DRY ! Know

    your Architecture Goals!
  35. @ManfredSteyer Good Message: Very often, Separate Ways DOES NOT mean

    duplicate code!
  36. @ManfredSteyer Catalog Approval Bounded Context Ubiquitous Language

  37. @ManfredSteyer Bounded Context per Sub-Domain Also see blog at: http://angulararchitects.io

  38. @ManfredSteyer Web Components

  39. @ManfredSteyer Web Components can be useful, esp. if you have

    to mix several technologies
  40. @ManfredSteyer Shadow DOM helps to isolate styles (emulated by default

    in Angular)
  41. @ManfredSteyer Also, lazy loading separately deployed web components is easy

  42. @ManfredSteyer µService µApp3 µApp2 µApp1 Shell Web Components for Macro-Architecture

    Shared Widget Shared Widget Shared Widget Web Components for shared Widgets
  43. @ManfredSteyer Authentication and Authorization

  44. @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
  45. @ManfredSteyer Microservice per Microfrontend?

  46. @ManfredSteyer Recommendation: Verticals µService µFrontend µService µFrontend µService µFrontend

  47. @ManfredSteyer Backend for Frontend (BFF) BFF µFrontend BFF µFrontend BFF

    µFrontend µServices µServices µServices µServices
  48. @ManfredSteyer Nevertheless, try this approach if possible! µService µFrontend µService

    µFrontend µService µFrontend
  49. @ManfredSteyer Dashboards

  50. @ManfredSteyer Dashboard: Special Forces Decoupled Sub-Domains Dashboard Data and widgets

    from each subdomain
  51. @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
  52. @ManfredSteyer Backend for Frontend (BFF) Dashboard µBFF Dashboard µFrontend BFF

    µFrontend BFF µFrontend µServices µServices µServices µServices Messaging
  53. @ManfredSteyer Free eBook ANGULARarchitects.io/book Updated for Module Federation and Alternatives

  54. @ManfredSteyer Challenge

  55. @ManfredSteyer ngx-Snake MIT License Credits: Samir Hodzic

  56. @ManfredSteyer DEMO

  57. @ManfredSteyer Conclusion Main Purpose of µFrontends: Scaling Teams Decoupling Federation:

    Import From Other App Know Your Domain! Communication & Sharing → Trade-off Monorepo vs. Polyrepo
  58. @ManfredSteyer Contact and Downloads [web] ANGULARarchitects.io [twitter] ManfredSteyer d Slides

    & Examples Remote Company Workshops and Consulting