Micro Frontends in Action
Michael Geers
  • August 2020
  • ISBN 9781617296871
  • 296 pages
  • printed in black & white

An excellent starting point to understand how to introduce micro frontends in your projects.

Potito Coluccelli
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.
Table of Contents detailed table of contents

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?


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.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.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?


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?


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?


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?


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


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?


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?


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


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


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


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


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


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


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.

placing your order...

Don't refresh or navigate away from the page.
print book $24.99 $49.99 pBook + eBook + liveBook
Additional shipping charges may apply
Micro Frontends in Action (print book) added to cart
continue shopping
go to cart

eBook $39.99 3 formats + liveBook
Micro Frontends in Action (eBook) added to cart
continue shopping
go to cart

Prices displayed in rupees will be charged in USD when you check out.
customers also reading

This book

FREE domestic shipping on three or more pBooks