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