Micro frontend architecture approach is the answer to challenges which in their nature are similar to what microservices architecture solves on the backend. I covered microservice implementation principles and decision framework on choosing such approach previously. Let’s cover what this approach is all about.
What is micro frontend architecture
When company technology landscape is a zoo of backend systems there could be still a few front doors into whole that space – frontend apps. As each of such diverges more and more into pieces related to particular domains it may be less and less efficient to maintain it as a whole. There are at least two possible ways out of this problem space:
- Split the single frontend app into multiple interconnected apps.
- Use module federation to keep independent functionality under the single umbrella.
As usual there’s no silver bullet and each option is a tradeoff to honor some aspects at the expense of others. The former approach provides most independence & flexibility but at the expense of reusability & repeated effort hence costs. The latter approach balances these factors at the expense of technical simplicity as the need for sophisticated technological enablers raises.
The latter approach of the outlined two is exactly what typically meant by micro frontend architecture.
Why use it
Similarly to backend microservices the key factors for chasing micro frontend architecture lie in business / organization context:
- Independent teams & delivery cycles. You’re likely to shoot yourself in the foot with overhead of module federation if there’s a common resource/bottleneck for delivery of most of the modules. Only mostly independent delivery of each module value stream will pay off nicely.
- Portfolio/platform offering. Reusing existing building blocks is natural part of modern software development but it has interesting applications in module federation setting when it comes to frontend apps. For a new piece it lowers time to market and total cost of ownership as usual. It makes the portfolio/platform strategy of the organization more flexible, definitely. In contrast to shared libraries module federation enables shared frontend-side services what helps transform code-level dependencies into loosely coupled functionality dependencies in the same space of the umbrella frontend app on customer’s device.
- Heterogenous consumption. As module federation still lands all modules on the same customer device there’s much less opportunity in terms of server side resources splitting in comparison to microservices. Still the splitting is possible from organizational perspective. Some teams & components are in higher demand, others in less but all that may change from time to time. By balancing technology zoo behind different modules with possibility of team members exchange a prudent portfolio manager can achieve impressive delivery pace.
Remember: everything is a tradeoff
Yes, I can’t overstate the importance of that statement in CS / IT. There’s no silver bullet, don’t be lazy & ride the hype, consider your context first and do it properly.