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

Content preview from Micro Frontends in Action

front matter

preface

I’ve been developing applications for the web for over 20 years now. On this journey, I’ve seen a variety of different-sized projects. I’ve built tiny side-projects all by myself, have been part of smaller projects with a couple of people, and have also worked on larger projects that involved more people than can comfortably fit around our kitchen table.

In 2014, my colleagues at neuland Büro für Informatik and I had the task of rebuilding an e-commerce system for a department store chain. The existing monolithic shop not only suffered from performance issues. The major pain-point was an organizational one: adding new features took a long time and often broke unrelated parts of the system. Increasing the development team ...