1 What are micro frontends?

This chapter covers:

  • Discovering what micro frontends are
  • Comparing the micro frontends approach to other architectures
  • Pointing out the importance of scaling frontend development
  • Recognizing the challenges that this architecture introduces

I’ve worked as a software developer on many projects over the last 15 years. In this time, I’ve had multiple chances to observe a pattern that repeats itself throughout our industry: working with a handful of people on a new project feels fantastic. Every developer has an overview of all functionality. Features get built quickly. Discussing topics with your coworkers is straightforward. This changes when the project’s scope and the team size increases. Suddenly one developer can’t know every edge of the system anymore. Knowledge silos emerge inside your team. Complexity rises--making a change on one part of the system may have unexpected effects on other parts. Discussions inside the team are more cumbersome. Before, team members made decisions at the coffee machine. Now you need formal meetings to get everyone on the same page. Frederick Brooks described this in the book The Mythical Man-Month back in 1975. At some point, adding new developers to a team does not increase productivity.

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?