book

Micro Frontends in Action

by Michael Geers

September 2020

Intermediate to advanced

296 pages

8h 35m

English

Manning Publications

Read now

Unlock full access

prefaceacknowledgmentsabout this bookWho should read this bookHow this book is organized: a roadmapAbout the codeOnline resourcesabout the authorabout the cover illustration
1.1 The big picture1.1.1 Systems and teams1.1.2 The frontend1.1.3 Frontend integration1.1.4 Shared topics1.2 What problems do micro frontends solve?1.2.1 Optimize for feature development1.2.2 No more frontend monolith1.2.3 Be able to keep changing1.2.4 The benefits of independence1.3 The downsides of micro frontends1.3.1 Redundancy1.3.2 Consistency1.3.3 Heterogeneity1.3.4 More frontend code1.4 When do micro frontends make sense?1.4.1 Good for medium-to-large projects1.4.2 Works best on the web1.4.3 Productivity versus overhead1.4.4 Where micro frontends are not a great fit1.4.5 Who uses micro frontends?Summary
2.1 Introducing The Tractor Store2.1.1 Getting started2.1.2 Running this book’s example code2.2 Page transition via links2.2.1 Data ownershipContract between the teams2.2.3 How to do it2.2.4 Dealing with changing URLs2.2.5 The benefits2.2.6 The drawbacks2.2.7 When do links make sense?2.3 Composition via iframe2.3.1 How to do it2.3.2 The benefits2.3.3 The drawbacks2.3.4 When do iframes make sense?2.4 What’s next?Summary
3.1 Composition via Ajax3.1.1 How to do it3.1.2 Namespacing styles and scripts3.1.3 Declarative loading with h-include3.1.4 The benefits3.1.5 The drawbacks3.1.6 When does an Ajax integration make sense?3.1.7 Summary3.2 Server-side routing via Nginx3.2.1 How to do it3.2.2 Namespacing resources3.2.3 Route configuration methods3.2.4 Infrastructure ownership3.2.5 When does it make sense?Summary
4.1 Composition via Nginx and Server-Side Includes (SSI)4.1.1 How to do it4.1.2 Better load times4.2 Dealing with unreliable fragments4.2.1 The flaky fragment4.2.2 Integrating the Near You fragment4.2.3 Timeouts and fallbacks4.2.4 Fallback content4.3 Markup assembly performance in depth4.3.1 Parallel loading4.3.2 Nested fragments4.3.3 Deferred loading4.3.4 Time to first byte and streaming4.4 A quick look into other solutions4.4.1 Edge-Side Includes4.4.2 Zalando Tailor4.4.3 Podium4.4.4 Which solution is right for me?4.5 The good and bad of server-side composition4.5.1 The benefits4.5.2 The drawbacks4.5.3 When does server-side integration make sense?Summary

5.1 Wrapping micro frontends using Web Components5.1.1 How to do it5.1.2 Wrapping your framework in a Web Component5.2 Style isolation using Shadow DOM5.2.1 Creating a shadow root5.2.2 Scoping styles5.2.3 When to use Shadow DOM5.3 The good and bad of using Web Components for composition5.3.1 The benefits5.3.2 The drawbacks5.3.3 When does client-side integration make sense?Summary
6.1 User interface communication6.1.1 Parent to fragment6.1.2 Fragment to parent6.1.3 Fragment to fragment6.1.4 Publish/Subscribe with the Broadcast Channel API6.1.5 When UI communication is a good fit6.2 Other communication mechanisms6.2.1 Global context and authentication6.2.2 Managing state6.2.3 Frontend-backend communication6.2.4 Data replicationSummary
7.1 App shell with flat routing7.1.1 What’s an app shell?7.1.2 Anatomy of the app shell7.1.3 Client-side routing7.1.4 Rendering pages7.1.5 Contracts between app shell and teams7.2 App shell with two-level routing7.2.1 Implementing the top-level router7.2.2 Implementing team-level routing7.2.3 What happens on a URL change?7.2.4 App shell APIs7.3 A quick look into the single-spa meta-framework7.3.1 How single-spa works7.4 The challenges of a unified single-page app7.4.1 Topics you need to think about7.4.2 When does a unified single-page app make sense?Summary
8.1 Combining server- and client-side composition8.1.1 SSI and Web Components8.1.2 Contract between the teams8.1.3 Other solutions8.2 When does universal composition make sense?8.2.1 Universal rendering with pure server-side composition8.2.2 Increased complexity8.2.3 Universal unified single-page app?Summary
9.1 Revisiting the terminology9.1.1 Routing and page transitions9.1.2 Composition techniques9.1.3 High-level architectures9.2 Comparing complexity9.2.1 Heterogeneous architectures9.3 Are you building a site or an app?9.3.1 The Documents-to-Applications Continuum9.3.2 Server, client, or both9.4 Picking the right architecture and integration technique9.4.1 Strong isolation (legacy, third party)9.4.2 Fast first-page load/progressive enhancement9.4.3 Instant user feedback9.4.4 Soft navigation9.4.5 Multiple micro frontends on one pageSummary
10.1 Asset referencing strategies10.1.1 Direct referencing10.1.2 Challenge: Cache-busting and independent deployments10.1.3 Referencing via redirect (client)10.1.4 Referencing via include (server)10.1.5 Challenge: Synchronizing markup and asset versions10.1.6 Inlining10.1.7 Integrated solutions (Tailor, Podium, ...)10.1.8 Quick summary10.2 Bundle granularity10.2.1 HTTP/210.2.2 All-in-one bundle10.2.3 Team bundles10.2.4 Page and fragment bundles10.3 On-demand loading10.3.1 Proxy micro frontends10.3.2 Lazy loading CSSSummary
11.1 Architecting for performance11.1.1 Different teams, different metrics11.1.2 Multi-team performance budgets11.1.3 Attributing slowdowns11.1.4 Performance benefits11.2 Reduce, reuse... vendor libraries11.2.1 Cost of autonomy11.2.2 Pick small11.2.3 One global version11.2.4 Versioned vendor bundles11.2.5 Don’t share business codeSummary
12.1 Why a design system?12.1.1 Purpose and role12.1.2 Benefits12.2 Central design system versus autonomous teams12.2.1 Do I need my own design system?12.2.2 Process, not project12.2.3 Ensure sustained budget and responsibility12.2.4 Get buy-in from the teams12.2.5 Development process: Central versus federated12.2.6 Development phases12.3 Runtime versus build-time integration12.3.1 Runtime integration12.3.2 Versioned package12.4 Pattern library artifacts: Generic versus specific12.4.1 Choose your component format12.4.2 There will be change12.5 What goes into the central pattern library?12.5.1 The costs of sharing components12.5.2 Central or local?12.5.3 Central and local pattern librariesSummary
13.1 Aligning systems and teams13.1.1 Identifying team boundaries13.1.2 Team depth13.1.3 Cultural change13.2 Sharing knowledge13.2.1 Community of practice13.2.2 Learning and enabling13.2.3 Present your work13.3 Cross-cutting concerns13.3.1 Central infrastructure13.3.2 Specialized component team13.3.3 Global agreements and conventions13.4 Technology diversity13.4.1 Toolbox and defaults13.4.2 Frontend blueprint13.4.3 Don’t fear the copy13.4.4 The value of similaritySummary
14.1 Migration14.1.1 Proof of concept and building a lighthouse14.1.2 Strategy #1: Slice-by-slice14.1.3 Strategy #2: Frontend first14.1.4 Strategy #3: Greenfield and big bang14.2 Local development14.2.1 Don’t run another team’s code14.2.2 Mocking fragments14.2.3 Fragments in isolation14.2.4 Pulling other teams micro frontends from staging or production14.3 TestingSummary

Overview

Browser-based software can quickly become complex and difficult to maintain, especially when it's implemented as a large single-page application. By adopting the micro frontends approach and designing your web apps as systems of features, you can deliver faster feature development, easier upgrades, and pick and choose the technology you use in your stack. Micro Frontends in Action is your guide to simplifying unwieldy frontends by composing them from small, well-defined units.

About the Technology
Micro frontends deliver the same flexibility and maintainability to browser-based applications that microservices provide for backend systems. You design your project as a set of standalone components that include their own interfaces, logic, and storage. Then you develop these mini-applications independently and compose them in the browser.

About the Book
Micro Frontends in Action teaches you to apply the microservices approach to the frontend. You’ll start with the core micro frontend design ideas. Then, you'll build an e-commerce application, working through practical issues like server-side and client-side composition, routing, and maintaining a consistent look and feel. Finally, you'll explore team workflow patterns that maximize the benefit of developing application components independently.

What's Inside

Create a unified frontend from independent applications
Combine JavaScript code from multiple frameworks
Browser and server-side composition and routing
Implement effective dev teams and project workflow

About the Reader
For web developers, software architects, and team leaders.

About the Author
Michael Geers is a software developer specializing in building user interfaces.

Quotes
An excellent starting point to understand how to introduce micro frontends in your projects.
- Potito Coluccelli

You can base your Micro Frontends directly off the examples in the book!
- Barnaby Norman, Frontend Developer

Expert practical advice for robust frontend development. The final piece of the micro puzzle!
- Adail Retamal, Cubic Transportation Systems

A very concise and logically structured introduction to implementing a micro frontends team infrastructure.
- Tanya Wilke, Sanlam

A definitive guide for applying micro frontends architecture to any existing UI technology.
- Karthikeyarajan Rajendran, Johnson Controls India