In my most recent project, I had the opportunity to work on a web application with a micro frontend architecture. Going into the project, I had only worked on projects that followed the more traditional monolithic architecture. So, I was excited to see what this new codebase had in store for me.
Greeted by multiple codebases, I realized there was more to micro frontends than I had anticipated. Over a year, I’ve gained experience working with micro frontends and now see the value they bring during project development. I have also seen firsthand what the drawbacks of using a micro frontend architecture could be.
What is micro frontend architecture?
Micro frontend architecture is a strategy to divide a web app into separate stacks of work, each developed end-to-end. That means a single web application will have multiple codebases, each in charge of handling different aspects or features of the app from the user interface to the database. This contrasts with the more traditional monolithic architecture that has a single unified codebase in charge of the whole application.
Why use micro frontend architecture?
In my experience, micro frontend architecture works great for larger teams during development. Organization was one of the primary benefits to the team. When working on a project with a large team, it becomes more difficult to coordinate as the size and number of different locations increase. In addition, the more crowded a single repository gets, the harder it is to not step on each other’s toes in the code. Micro frontends help with this. We can divide our teams based on our app’s separate features, and let each team have full control of their stack.
This allows individual teams to operate more efficiently internally. This is because they’ll work with a codebase that is smaller and more isolated, and they’ll have a better-defined goal. This also allows teams to deploy changes to the system without affecting the whole system, since each team’s work will usually not directly affect the work of another team in their codebase. Another benefit of this separation is project ownership. With the application being separated into full stacked features, each team now has a defined purpose in developing the project and gives the developers agency for a portion of the system.
Why not use micro frontend architecture?
Micro frontend architecture can also cause some problems for the developers. Despite each team working independently, the project requires coordination and communication across teams, particularly when changes in one micro-frontend could impact others. Team members must manage interactions between different parts of the frontend, which can be complex in and of itself. Added to that, the system as a whole can be harder to understand for a developer who hasn’t had experience working with micro frontends. With respect to the application itself, you might notice performance overhead with micro-frontends due to the need for internal communication.
Was it worth it?
This approach added complexity to the application itself and the necessary interactions between teams. However, I would say our project benefited from a micro frontend architecture. As I mentioned, this project had a development team composed of multiple parties in different locations. The ability to have our teams work asynchronously towards a common goal and give each team a specific goal within their respective codebases allowed for a well-structured development process.
As a new developer, it took time to get used to the architecture and the necessary interactions between the separate micro frontends. But, this did not ruin the experience nor the efficiency of development. If anything, it showed me the value of having a well-defined architecture that suits the needs of a given project.