As our web applications keep growing, companies face the challenge to have multiple teams working in parallel on one big application. Over the years, we moved from developing monoliths to separating backend from frontend to cutting down the backend to multiple microservices but our frontend application especially single page applications stayed as one big codebase.
The technique of micro frontends came to resolve this issue, of splitting complex frontend monoliths into smaller parts so we can have multiple teams working independently and in parallel on one large application.
In this setup, frontend codebase is split into many smaller, more manageable applications that can be built and deployed in parallel.
To achieve this, there are many implementations:
1- Server side integration:
It is an old approach where an application renders HTML pages based on multiple fragments using includes
2- Build time integration:
With this solution we can easily remove duplicated shared dependencies between the micro frontends but we still have to rebuild the container application whenever a team releases a new update for their micro application.
3- Run time integration:
All these approaches come with some challenges that teams try to solve when implementing micro frontends such as how to control the bundle size of the application? How to handle duplicate dependencies between different applications? How to handle communication across these micro frontends? or how to enforce UI consistency if it’s being built by different teams using different technologies?
All these questions have to be considered before deciding for your structure to adopt micro frontends to scale your frontend development.