What is micro frontend architecture and when is it worth applying?
Managing, modifying and scaling monolithic applications is not an easy task. To make it less overwhelming, developers started to break frontend monoliths into smaller pieces and work on them independently. That’s how micro frontend architecture came to be. Read on to find out what exactly micro fronted architecture is and how it can help you with developing your product.
Table of contents
Micro frontend architecture - definition
Micro frontend architecture is a digital product architecture in which the frontend is divided into small pieces, called micro frontends. Micro frontends (similarly to microservices on the backend of a product) make it easier to implement any changes of design and generally help maintain focus on a single, independent domain. The well-known software specialist, Martin Fowler, defines the micro frontend technique as:
an architectural style where independently deliverable frontend applications are composed into a greater whole
With micro frontends, you can build innovative, scalable and responsive modern digital applications. Micro frontend architecture composes all micro frontend elements into one but keeps them independent and easy to manage at the same time.
When to use micro frontends?
Micro frontends are especially helpful when you want to develop or scale a highly complex application with plenty of functionalities. Choosing this architecture introduces multiple new dependencies on different levels than monolithic apps. It is useful, for example, when rewriting your monolithic application incrementally for newer technology, or when managing multiple teams struggling with communication between each other.
Benefits of applying micro frontend architecture
When old, large-scale frontend monoliths become too difficult to manage and develop, companies often decide to rewrite their applications as micro frontends. Here are some benefits of such a solution:
- Technology agnostic - Each team can choose its tech stack without needing to agree on it with other teams. When rewriting code, a team (or a part of it) can write the new part as a micro frontend and use a framework of their liking, separate from the technology used to create the “old” part.
- Team scalability - Multiple teams can work independently and contribute to many various systems. This enables dividing the work and scaling it through multiple teams.
- Single responsibility - Each team can concentrate on a single domain.
- Easy learning - For new engineers joining the teams, it is easier to learn smaller apps than it is to understand a huge monolith with thousands of lines of code.
- Independent deployment - Each micro frontend has its own continuous delivery pipeline, which builds, tests and deploys it all the way to production.
How does micro frontend architecture influence the product development process?
Product development of complex applications is in general much easier and smoother with micro frontends in place. It’s easier for teams to focus on smaller chunks of code, so the product quality is higher. Micro frontend architecture helps to:
- split the frontend by domains,
- conduct an incremental rewrite of a legacy codebase,
- modify elements of the frontend in small increments,
- add more independence and freedom between teams.
On the other hand, it has its risks and disadvantages. Sometimes, migration to a micro frontend can result in duplication of dependencies. Also, the significant increase in team autonomy can lead to major disturbances in your teams’ work (team independence can cause separation). That’s why choosing a micro frontend architecture should be a conscious decision based on an analysis of the current product situation and future assumptions.
When not to use micro frontends
There are quite a few instances when micro frontend architecture should not be used, as it can disturb the product development process and team cooperation. Micro frontends should be avoided when:
- You have doubts. You can always start building your product as a monolith and later migrate to micro frontends. The micro frontends approach is quite immature, current micro frontends implementations are not perfect - all of them have trade-offs.
- The team is small or has no communication issues.
- Page load time is crucial from a business point of view, as micro frontends will not speed up your application.
- Micro frontend applications need to communicate often with each other. The coupling between the apps should be minimal. When you need to share a lot of logic, consider building (or staying with) a monolith.
- You don’t have enough automation in place to feasibly provision and manage the additional required infrastructure.
- You are not comfortable with decisions around tooling and development practices that become more decentralized and less controllable.
- You are not able to ensure a minimum level of quality, consistency, or governance across your many independent frontend codebases.
Micro frontend architecture - a summary
Monolithic frontend codebases can be problematic for digital product developers as well as for businesses. Especially if you want to scale your product with multiple teams involved. Migration to micro frontends could be the solution. If your product has reached that point, we hope that this article has shed some light on the issue. And if there’s anything you could use our help with, feel free to contact us.
Share this article:
