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

Slide 1

Slide 1 text

@ManfredSteyer ManfredSteyer 6 Things You Should Know About Micro Frontends Manfred Steyer, ANGULARarchitects.io Angular Copenhagen

Slide 2

Slide 2 text

@ManfredSteyer Do you remember her? Bonnie Barstow, PhD

Slide 3

Slide 3 text

@ManfredSteyer Software Engineering is a Team Sport

Slide 4

Slide 4 text

@ManfredSteyer Coordination b/w Teams

Slide 5

Slide 5 text

@ManfredSteyer Monolith Flight System

Slide 6

Slide 6 text

@ManfredSteyer Booking Service Check-in Service Boarding Service Luggage Service Microservices Sub-Domains (DDD)

Slide 7

Slide 7 text

@ManfredSteyer Booking App Check-in App Boarding App Luggage App Microfrontends

Slide 8

Slide 8 text

@ManfredSteyer Lots of Questions …

Slide 9

Slide 9 text

@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

Slide 10

Slide 10 text

@ManfredSteyer How to implement Microfrontends? ?

Slide 11

Slide 11 text

@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

Slide 12

Slide 12 text

@ManfredSteyer DEMO: Webpack 5 Module Federation

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

@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

Slide 15

Slide 15 text

@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

Slide 16

Slide 16 text

@ManfredSteyer Domain Driven Design gives a lot of advice! Also see blog at: http://angulararchitects.io

Slide 17

Slide 17 text

@ManfredSteyer Monorepo or Polyrepo?

Slide 18

Slide 18 text

@ManfredSteyer Catalog Approval Shared Feature Feature Feature Feature Feature … … … … … … … … … @ManfredSteyer Catalog App Approval App Option 1: One Monorepo w/ several Domains

Slide 19

Slide 19 text

@ManfredSteyer Consequences Easy to share code Decoupling b/w domains: Conventions or Tools (Linting) Easy to enforce one version policy Different technologies: possible

Slide 20

Slide 20 text

@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

Slide 21

Slide 21 text

@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

Slide 22

Slide 22 text

@ManfredSteyer Recommentation, if you are not sure Start with a monorepo Enforce decoupling via linting Reconsider splitting into several repos later

Slide 23

Slide 23 text

@ManfredSteyer Pro Tip: Tooling for Monorepos https://nrwl.io/nx

Slide 24

Slide 24 text

@ManfredSteyer Communication

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

@ManfredSteyer Ideas As little as possible! Messaging/ Eventing: Loosly Coupling Trigger a (Domain) Event Don't expect an answer!

Slide 27

Slide 27 text

@ManfredSteyer Very Simple Message Bus @Injectable({ providedIn: 'root' }) export class MessageBus { events$ = new ReplaySubject(1); }

Slide 28

Slide 28 text

@ManfredSteyer Also Consider: Server-Side Messaging µService µFrontend µService µFrontend µService µFrontend

Slide 29

Slide 29 text

@ManfredSteyer Redux for Communication?

Slide 30

Slide 30 text

@ManfredSteyer Well … Don't directly share state b/w sub-domains (coupling!) You might use Redux for eventing (like a Message Bus)

Slide 31

Slide 31 text

@ManfredSteyer Sharing Widgets

Slide 32

Slide 32 text

@ManfredSteyer Sharing Widgets is a Trade-Off too Decoupled Sub-Domains Shared Widgets Prevent duplicate code (DRY) Separate Ways

Slide 33

Slide 33 text

@ManfredSteyer Recommentation Technical Widgets (e. g. Design System): Sharing ok Use Case-specific widgets: Try to avoid (coupling!)

Slide 34

Slide 34 text

@ManfredSteyer You can't have both: Decoupling and DRY ! Know your Architecture Goals!

Slide 35

Slide 35 text

@ManfredSteyer Good Message: Very often, Separate Ways DOES NOT mean duplicate code!

Slide 36

Slide 36 text

@ManfredSteyer Catalog Approval Bounded Context Ubiquitous Language

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

@ManfredSteyer Web Components

Slide 39

Slide 39 text

@ManfredSteyer Web Components can be useful, esp. if you have to mix several technologies

Slide 40

Slide 40 text

@ManfredSteyer Shadow DOM helps to isolate styles (emulated by default in Angular)

Slide 41

Slide 41 text

@ManfredSteyer Also, lazy loading separately deployed web components is easy

Slide 42

Slide 42 text

@ManfredSteyer µService µApp3 µApp2 µApp1 Shell Web Components for Macro-Architecture Shared Widget Shared Widget Shared Widget Web Components for shared Widgets

Slide 43

Slide 43 text

@ManfredSteyer Authentication and Authorization

Slide 44

Slide 44 text

@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

Slide 45

Slide 45 text

@ManfredSteyer Microservice per Microfrontend?

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

@ManfredSteyer Backend for Frontend (BFF) BFF µFrontend BFF µFrontend BFF µFrontend µServices µServices µServices µServices

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

@ManfredSteyer Dashboards

Slide 50

Slide 50 text

@ManfredSteyer Dashboard: Special Forces Decoupled Sub-Domains Dashboard Data and widgets from each subdomain

Slide 51

Slide 51 text

@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

Slide 52

Slide 52 text

@ManfredSteyer Backend for Frontend (BFF) Dashboard µBFF Dashboard µFrontend BFF µFrontend BFF µFrontend µServices µServices µServices µServices Messaging

Slide 53

Slide 53 text

@ManfredSteyer Free eBook ANGULARarchitects.io/book Updated for Module Federation and Alternatives

Slide 54

Slide 54 text

@ManfredSteyer Challenge

Slide 55

Slide 55 text

@ManfredSteyer ngx-Snake MIT License Credits: Samir Hodzic

Slide 56

Slide 56 text

@ManfredSteyer DEMO

Slide 57

Slide 57 text

@ManfredSteyer Conclusion Main Purpose of µFrontends: Scaling Teams Decoupling Federation: Import From Other App Know Your Domain! Communication & Sharing → Trade-off Monorepo vs. Polyrepo

Slide 58

Slide 58 text

@ManfredSteyer Contact and Downloads [web] ANGULARarchitects.io [twitter] ManfredSteyer d Slides & Examples Remote Company Workshops and Consulting