As technology advances and businesses become increasingly complex, front-end applications built from a single, monolithic resource are struggling to keep up with the growing demands of both businesses and customers.
This arises many issues since all front-end code is bundled into a single application, making it difficult to scale, maintain, and deploy. It also becomes challenging to implement changes or add new features to the application since all developers need to work on the same codebase.
All tech-based companies when talking about the idea of building an application that is scaling and easy to grow will come with these requirements:
- The application has to be developed in parallel between teams
- New features must easy to deploy and test
- The codebase can be easily maintained by developers
- All the application components can be modular so that it easy to add and remove features
- Continually receive feedback from stakeholders and customers
This is when we apply Microservices approach to our front-end application by breaking everything down into smaller components so that each team in the project can work independently.
The idea behind Microfrontend is that no team owns the entire application UI. But every team has to take care of a small piece of front-end component. By breaking down the application into smaller components, Microfrontends simplify the development process, reduce dependencies between teams, and enable faster and more efficient deployment of updates and new features. Furthermore, because every team only takes care of a small part of the entire application so it is easier to deploy new features independently. This can reduce the risk of having a big issue and affect other parts of the application. This increases the application’s flexibility and improves feedback from customers.
While comes with many benefits, Microfrontend is not a silver bullet that solves all our problems of building a large frontend application. Some technical challenges we have to face when implementing Microfrontend applications included:
Consistency: Each team owns and develops its UI component. It is hard to keep up with every dependency version, framework, and technology in different bundles
Performance: Every Microfrontend project means one single repo has to take care and there likely that some dependencies got duplicated that leading to an increase in overall application size.
Testing: Testing a Microfrontend application can be challenging since each component is developed and tested independently.
Reusability: When different teams work with different parts, it may happen the case that they want to use the same functionality but have to write duplicate code since common dependencies don’t provide enough functionality they need – This Violates the DRY principle.
A Monorepo is a single repository containing multiple distinct projects, with well-defined relationships. - monorepo.tools
The first thing that comes to your mind when reading the above definition of Monorepo is: “Why a monolith-like approach could solve the challenges of implementing Microfrontend?”
Turn out, A good Monorepo is the opposite of Monolithic. Let me explain clearer about this, let’s say that our familiar approach of Microfrontend is having multiple, small repositories that take care of small components. Which called these repo “polyrepo” as opposed to “monorepo”.
Since a Monorepo takes all projects into a single repository, here are some benefits that this way can help reduce the challenges of implementing Microfrontend application:
- Code reusability: Since all source code is contained in a single project, developers don’t have to reimplement common functionality anymore.
- Shared dependencies and versioning: In Monorepo, all projects are using the same source of packages so which resolves the headache of having inconsistency dependency and versioning.
- Workflow: All projects in one repo mean project structure, workflow, and practices are the same.
Although solving some challenges of Microfrontend architecture, Monorepo is not an easy approach. To work well with Monorepo, the developer teams should have these capabilities:
- CI/CD & testing: Every Monorepo project should come with integration testing and CI/CD so that is easy to deploy changes with quick feedback.
- Tooling support: Teams working on the same Monorepo should use the same supported tooling that stays consistent and helps improve development time.
- Documenting & clear communication: Monorepo project should have a clear document about the project structure, code owner, and project start guide. Clear communication between teams to channel workflow ensures everything stays on its path.
- Trunk-based development: One final, the most important aspect is that Monorepo project should be developed in a trunk-based approach than a long-lived feature branch. This ensure changes are small enough easy to review and test but also big enough to bring value.
Large monolith front-end applications are considered limited in scalability and are transitioning to Microfrontend approach.
By having a Microfrontend architecture, enterprises have to deal with challenges like inconsistency dependency version, performance, and reusability.
One of the ways to solve issues of Microfrontend is based on Monorepo approach which acts as a centralized project with benefits like centralized dependencies, easy-to-manage version, and atomic developing process.
Original article published on MARCH 11, 2023 at https://junedang.com
Checkout others related articles of me 👇