Micro Frontends in Action
Michael Geers
  • MEAP began July 2019
  • Publication in September 2020 (estimated)
  • ISBN 9781617296871
  • 296 pages (estimated)
  • 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

Gone are the days of web UI being simply built with HTML and CSS. Modern web frontends are complex and require the same care in design and implementation as back-end services. The micro frontends approach tackles those issues by extending the principles of microservices to frontend development. With micro frontends different teams can work effectively on a large software system. The application is divided into multiple independent slices — from the database right up to the UI. These different frontends are then integrated using standards such as web components into a single user-facing frontend. Thanks to the smaller scope of a micro frontend, teams can then deliver features faster, upgrade more easily, and make their own choices about their technology stack so they’re always using the right tool for the job.

About the book

Micro Frontends in Action teaches you how to put the theory of micro frontends into practice. Frontend expert Michael Geers teaches you with a complete ecommerce example application that illustrates how a large-scale business application can adopt the micro frontends approach. You’ll learn to integrate web applications made up of smaller fragments using tools such as web components or server side includes, how to solve the organizational challenges of micro frontends, and how to create a design system that ensures an end user gets a consistent look and feel for your application. When you’re done, you’ll be able to better distribute your team’s skills and resources to deliver quality software quickly and flexibly.
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 & 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.2.5 The downsides of micro frontends

1.3 When do micro frontends make sense?

1.3.1 Good for medium to large projects

1.3.2 Works best on the web

1.3.3 Productivity vs. overhead

1.3.4 Where micro frontends are not a great fit

1.4 Who uses micro frontends?

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

2.5 Summary

Part 2: Routing, Composition, and Communication

3 Composition with AJAX & 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?

3.3 Summary

4 Server-side Composition

4.1 Composition via Nginx & 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 & 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 & 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?

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

5.4 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 When UI communication is a good fit

6.2 Other communication mechanisms

6.2.1 Global context & authentication

6.2.2 Managing state

6.2.3 Frontend-backend communication

6.2.4 Data Replication

6.3 Summary

7 Client-side Routing & 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?

7.5 Summary

8 Composition & Universal Rendering

8.1 Combining server- and client-side composition

8.1.1 SSI & 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?

8.3 Summary

9 Which Architecture Fits My Project?

9.1 Revisiting the terminology

9.1.1 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, 3rd 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

9.5 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 & 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 & fragment bundles

10.3 On-demand loading

10.3.1 Proxy micro frontends

10.3.2 Lazy loading CSS

10.4 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

11.3 Summary

12 User Interface & Design System

12.1 Why a design system?

12.1.1 Purpose and role

12.1.2 Benefits

12.2 Central design system vs. autonomous teams

12.2.1 Do I need my own design system?

12.2.2 Process, not project

12.2.3 Ensure sustained budget & responsibility

12.2.4 Get buy-in from the teams

12.2.5 Development process: central vs. federated

12.2.6 Development phases

12.3 Runtime vs. build-time integration

12.3.1 Runtime Integration

12.3.2 Versioned package

12.4 Pattern library artifacts: generic vs. 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

12.6 Summary

13 Teams & Boundaries

13.1 Aligning systems and teams

13.1.1 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 & 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 & conventions

13.4 Technology diversity

13.4.1 Toolbox & Defaults

13.4.2 Frontend Blueprint

13.4.3 Don’t fear the copy

13.4.4 The value of similarity

13.5 Summary

14 Migration, Local Development & Testing

14.1 Migration

14.1.1 Proof of concept & building a lighthouse

14.1.2 Strategy #1: Slice-by-slice

14.1.3 Strategy #2: Frontend first

14.1.4 Strategy #3: Greenfield & big bang

14.2 Local Development

14.2.1 Don’t run other teams 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

14.4 Summary

What's inside

  • Applying integration strategies with iframes, AJAX, server-side includes, web components and the app-shell approach
  • Optimizing for performance and asset delivery strategies
  • Designing coherent user interfaces
  • Migrating to a micro frontends architecture

About the reader

For intermediate web developers, team leaders, and software architects.

About the author

Michael Geers is a software developer specializing in building user interfaces. He has written software for the web since he was a teenager. In the last few years, he has worked on various customer projects with verticalized architectures. He shares his experiences on this topic at international conferences, in a series of magazine articles, and runs the site micro-frontends.org.

placing your order...

Don't refresh or navigate away from the page.
Manning Early Access Program (MEAP) Read chapters as they are written, get the finished eBook as soon as it’s ready, and receive the pBook long before it's in bookstores.
print book $34.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 $27.99 $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.

FREE domestic shipping on three or more pBooks