Micro Frontends in Action

Micro Frontends in Action
contents
preface
acknowledgments
about this book
Who should read this book
How this book is organized: a roadmap
About the code
Online resources
about the author
about the cover illustration
Part 1 Getting started with micro frontends
1 What are micro frontends?
1.1 The big picture
1.1.1 Systems and teams
1.1.2 The frontend
1.1.3 Frontend integration
1.1.4 Shared topics
1.2 What problems do micro frontends solve?
1.2.1 Optimize for feature development
1.2.2 No more frontend monolith
1.2.3 Be able to keep changing
1.2.4 The benefits of independence
1.3 The downsides of micro frontends
1.3.1 Redundancy
1.3.2 Consistency
1.3.3 Heterogeneity
1.3.4 More frontend code
1.4 When do micro frontends make sense?
1.4.1 Good for medium-to-large projects
1.4.2 Works best on the web
1.4.3 Productivity versus overhead
1.4.4 Where micro frontends are not a great fit
1.4.5 Who uses micro frontends?
Summary
2 My first micro frontends project
2.1 Introducing The Tractor Store
2.1.1 Getting started
2.1.2 Running this book’s example code
2.2 Page transition via links
2.2.1 Data ownership
2.2.2 Contract between the teams
2.2.3 How to do it
2.2.4 Dealing with changing URLs
2.2.5 The benefits
2.2.6 The drawbacks
2.2.7 When do links make sense?
2.3 Composition via iframe
2.3.1 How to do it
2.3.2 The benefits
2.3.3 The drawbacks
2.3.4 When do iframes make sense?
2.4 What’s next?
Summary
Part 2 Routing, composition, and communication
3 Composition with Ajax and server-side routing
3.1 Composition via Ajax
3.1.1 How to do it
3.1.2 Namespacing styles and scripts
3.1.3 Declarative loading with h-include
3.1.4 The benefits
3.1.5 The drawbacks
3.1.6 When does an Ajax integration make sense?
3.1.7 Summary
3.2 Server-side routing via Nginx
3.2.1 How to do it
3.2.2 Namespacing resources
3.2.3 Route configuration methods
3.2.4 Infrastructure ownership
3.2.5 When does it make sense?
Summary
4 Server-side composition
4.1 Composition via Nginx and Server-Side Includes (SSI)
4.1.1 How to do it
4.1.2 Better load times
4.2 Dealing with unreliable fragments
4.2.1 The flaky fragment
4.2.2 Integrating the Near You fragment
4.2.3 Timeouts and fallbacks
4.2.4 Fallback content
4.3 Markup assembly performance in depth
4.3.1 Parallel loading
4.3.2 Nested fragments
4.3.3 Deferred loading
4.3.4 Time to first byte and streaming
4.4 A quick look into other solutions
4.4.1 Edge-Side Includes
4.4.2 Zalando Tailor
4.4.3 Podium
4.4.4 Which solution is right for me?
4.5 The good and bad of server-side composition
4.5.1 The benefits
4.5.2 The drawbacks
4.5.3 When does server-side integration make sense?
Summary
5 Client-side composition
5.1 Wrapping micro frontends using Web Components
5.1.1 How to do it
5.1.2 Wrapping your framework in a Web Component
5.2 Style isolation using Shadow DOM
5.2.1 Creating a shadow root
5.2.2 Scoping styles
5.2.3 When to use Shadow DOM
5.3 The good and bad of using Web Components for composition
5.3.1 The benefits
5.3.2 The drawbacks
5.3.3 When does client-side integration make sense?
Summary
6 Communication patterns
6.1 User interface communication
6.1.1 Parent to fragment
6.1.2 Fragment to parent
6.1.3 Fragment to fragment
6.1.4 Publish/Subscribe with the Broadcast Channel API
6.1.5 When UI communication is a good fit
6.2 Other communication mechanisms
6.2.1 Global context and authentication
6.2.2 Managing state
6.2.3 Frontend-backend communication
6.2.4 Data replication
Summary
7 Client-side routing and the application shell
7.1 App shell with flat routing
7.1.1 What’s an app shell?
7.1.2 Anatomy of the app shell
7.1.3 Client-side routing
7.1.4 Rendering pages
7.1.5 Contracts between app shell and teams
7.2 App shell with two-level routing
7.2.1 Implementing the top-level router
7.2.2 Implementing team-level routing
7.2.3 What happens on a URL change?
7.2.4 App shell APIs
7.3 A quick look into the single-spa meta-framework
7.3.1 How single-spa works
7.4 The challenges of a unified single-page app
7.4.1 Topics you need to think about
7.4.2 When does a unified single-page app make sense?
Summary
8 Composition and universal rendering
8.1 Combining server- and client-side composition
8.1.1 SSI and Web Components
8.1.2 Contract between the teams
8.1.3 Other solutions
8.2 When does universal composition make sense?
8.2.1 Universal rendering with pure server-side composition
8.2.2 Increased complexity
8.2.3 Universal unified single-page app?
Summary
9 Which architecture fits my project?
9.1 Revisiting the terminology
9.1.1 Routing and page transitions
9.1.2 Composition techniques
9.1.3 High-level architectures
9.2 Comparing complexity
9.2.1 Heterogeneous architectures
9.3 Are you building a site or an app?
9.3.1 The Documents-to-Applications Continuum
9.3.2 Server, client, or both
9.4 Picking the right architecture and integration technique
9.4.1 Strong isolation (legacy, third party)
9.4.2 Fast first-page load/progressive enhancement
9.4.3 Instant user feedback
9.4.4 Soft navigation
9.4.5 Multiple micro frontends on one page
Summary
Part 3 How to be fast, consistent, and effective
10 Asset loading
10.1 Asset referencing strategies
10.1.1 Direct referencing
10.1.2 Challenge: Cache-busting and independent deployments
10.1.3 Referencing via redirect (client)
10.1.4 Referencing via include (server)
10.1.5 Challenge: Synchronizing markup and asset versions
10.1.6 Inlining
10.1.7 Integrated solutions (Tailor, Podium, …)
10.1.8 Quick summary
10.2 Bundle granularity
10.2.1 HTTP/2
10.2.2 All-in-one bundle
10.2.3 Team bundles
10.2.4 Page and fragment bundles
10.3 On-demand loading
10.3.1 Proxy micro frontends
10.3.2 Lazy loading CSS
Summary
11 Performance is key
11.1 Architecting for performance
11.1.1 Different teams, different metrics
11.1.2 Multi-team performance budgets
11.1.3 Attributing slowdowns
11.1.4 Performance benefits
11.2 Reduce, reuse… vendor libraries
11.2.1 Cost of autonomy
11.2.2 Pick small
11.2.3 One global version
11.2.4 Versioned vendor bundles
11.2.5 Don’t share business code
Summary
12 User interface and design system
12.1 Why a design system?
12.1.1 Purpose and role
12.1.2 Benefits
12.2 Central design system versus autonomous teams
12.2.1 Do I need my own design system?
12.2.2 Process, not project
12.2.3 Ensure sustained budget and responsibility
12.2.4 Get buy-in from the teams
12.2.5 Development process: Central versus federated
12.2.6 Development phases
12.3 Runtime versus build-time integration
12.3.1 Runtime integration
12.3.2 Versioned package
12.4 Pattern library artifacts: Generic versus specific
12.4.1 Choose your component format
12.4.2 There will be change
12.5 What goes into the central pattern library?
12.5.1 The costs of sharing components
12.5.2 Central or local?
12.5.3 Central and local pattern libraries
Summary
13 Teams and boundaries
13.1 Aligning systems and teams
13.1.1 Identifying team boundaries
13.1.2 Team depth
13.1.3 Cultural change
13.2 Sharing knowledge
13.2.1 Community of practice
13.2.2 Learning and enabling
13.2.3 Present your work
13.3 Cross-cutting concerns
13.3.1 Central infrastructure
13.3.2 Specialized component team
13.3.3 Global agreements and conventions
13.4 Technology diversity
13.4.1 Toolbox and defaults
13.4.2 Frontend blueprint
13.4.3 Don’t fear the copy
13.4.4 The value of similarity
Summary
14 Migration, local development, and testing
14.1 Migration
14.1.1 Proof of concept and building a lighthouse
14.1.2 Strategy #1: Slice-by-slice
14.1.3 Strategy #2: Frontend first
14.1.4 Strategy #3: Greenfield and big bang
14.2 Local development
14.2.1 Don’t run another team’s code
14.2.2 Mocking fragments
14.2.3 Fragments in isolation
14.2.4 Pulling other teams micro frontends from staging or production
14.3 Testing
Summary
index
Numerics
A
B
C
D
E
F
G
H
I
J
L
M
N
O
P
R
S
T
U
V
W
Z
Micro Frontends in Action - back