Lesson 4.11.2 asked when a service of its own pays off, and one answer was: when a team of its own owns it. Lesson 4.11.5 showed, with backends for frontends, a pattern that gives every user interface its own backend. Both split the system behind the user interface. The user interface itself often stays a single program that all teams work on, and then becomes the last shared bottleneck. Micro-frontends carry the idea of microservices over to the user interface: every team owns its part of the pages, from the backend to the screen.
This lesson is short on purpose, because for the Kladde the answer in the end is: not needed. You still learn how it works and what it costs, because in larger organizations you will meet such interfaces and should know which questions to ask. What gets built is the cheapest form that .NET brings along: a page from two Razor class libraries of two “teams”, composed at build time. That happens in an exercise folder or a branch that does not go into the Kladde.
Why teams want to split the user interface too
Conway's law from lesson 4.2.5 says that a system mirrors the structure of the organization that builds it. If three teams each have a service but share one web application, the web application is where they have to coordinate:
- Every change to a page waits for the next shared deploy. The appointments team can ship its service every day, but its page only when the web application is shipped as a whole.
- One team's failure holds everyone up. A red test in the web application also blocks the other teams' pull requests.
- The web application knows every area of the business. It calls all the services, so it needs knowledge of all of them, and that is exactly the coupling the services were supposed to avoid.
A micro-frontend therefore cuts the user interface along the same boundaries as the services: the appointments team owns the pages and the parts of pages that show appointments, the tenders team owns its own. A page on which both appear is composed. The question is where.