First time, when the world heard about 'microfrontend' term, was in 2011, at an event for software architects. The attendees were experimenting with this approach, and the concept quickly gained popularity in the software development community.
Microfrontends architecture basically breaks down monolithic frontend application into smaller, independent modules (called: microfrontends), that can be developed and deployed separately. Each microfrontend is responsible for one specific part of user interface and can be developed using different technologies, deployed using separated pipelines and implemented by a dedicated team.
On the diagram above, you can see example web application with three separated microfrontends:
- articles,
- reservations,
- promotions.
Each one of them can be developed by a different team, deployed at any time, and written in different technologies, but at the end of the day, from the user perspective, they work as one web application.
Speaking of teams...
The microfrontends approach is inspired by microservices architecture, which also relies on breaking backend service into smaller pieces, that can work separately. One of the main benefits of the approach is better scaling. In case of one or two microservices being overloaded, we can add instances of those services only instead of scaling the whole application up (which causes larger payments for cloud services we use at the end of the day).
Scalability
Of course, it doesn't work exactly like that in the case of microfrontends, because modern web applications are basically downloaded to the user's browser and executed there. When we talk about scaling in the microfrontends world, it means that we can scale development teams. By splitting a big application into smaller, independent blocks, we can also split work and responsibility between teams.
Independent deployments
Thanks to that, if you have CI and CD properly working in your project, for sure there will be a huge benefit of utilizing the microfrontends architecture for a big-size projects. Especially from a business perspective, because delivering features (and reaching business goals) will be faster, and independent from each other (synchronization between teams will be required if there are any existing relations between two or more microfrontends). After deployment - you possibly don't need to do whole system tests and freeze the code until they're done.
Team autonomy
By dividing the frontend into smaller, autonomous units, microfrontends empower teams to take ownership of specific features or functionalities. Because each team will have its own microfrontends to care about, also architecture decisions should be faster and can be made by respective teams. This autonomy fosters a sense of responsibility and accountability among team members, leading to faster decision-making and improved collaboration. When we talk about the teams in the context of microfrontends, it means fullstack teams - teams that consist of both frontend and backend developers who can finish the whole feature from the beginning (UI) to the end (API), without any resources from the outside.
Photo by Marvin Meyer on Unsplash
Technology diversity
One significant advantage of microfrontends is the ability to use different technologies within the same application. Teams can choose the most suitable frameworks, libraries, or programming languages for their specific requirements. This flexibility promotes innovation and empowers teams to leverage the best tools for the job.
So... where is the catch?
So far you could think that the microfrontends approach is a perfect choice to go with. That's not necessarily true. The microfrontends architecture, like any other architecture, has its pros and cons. There are cases when you should consider microfrontends for projects you work on, but there are also the ones you definitely should not. Consider the following points.
Increased complexity
While modularity is a key advantage of microfrontends, it also introduces additional complexity. Coordinating communication between modules, managing shared resources, and ensuring a consistent user experience across the application can be challenging tasks, requiring careful planning and implementation. Certain functionalities, such as authentication, routing, and internationalization, are cross-cutting concerns that affect the entire application. Managing these concerns in a microfrontends architecture requires careful coordination and may result in duplication of efforts across different modules.
Performance and bundle size
There is also a myth that we need to deal with - microfrontends will not speed up your application. They will possibly make the application slightly slower. Microfrontends often involve multiple HTTP requests to load various modules, which can impact the application's performance, especially on slower networks. Additionally, coordinating the rendering of multiple components on the client-side may lead to longer loading times and increased memory consumption. It may also happen to have more than one microfrontend using different versions of the same frameworks or libraries, which will create bigger bundles.
Compatibility problems
Integrating multiple modules developed using different technologies can introduce compatibility issues, especially concerning data exchange formats, APIs, and browser compatibility. Ensuring seamless communication and interoperability between modules may require additional development effort and ongoing maintenance.
Development overhead
Maintaining microfrontends architecture demands a higher level of coordination and collaboration among teams compared to traditional monolithic applications. Teams must establish clear communication channels, standardized interfaces, and consistent development practices to avoid fragmentation and ensure cohesion across modules.
There is one additional thing... Conway's Law
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
In the context of microfrontends - it will be highly impossible (or complicated) to introduce this approach to the architecture if the organization structure is not adapted to it first.
When to use microfrontends?
- large and complex applications - microfrontends are well-suited for large-scale applications with multiple teams working on different parts of the frontend simultaneously,
- technology diversity - when teams require the flexibility to use diverse technologies or frameworks within the same application,
- independent deployments - when there is a requirement for independent deployment and continuous delivery of frontend features,
- modernizing large monolithic application - it's often not possible to rewrite the whole application at once, so it might be a good way to split it into smaller modules and rewrite them one by one as a microfrontends.
When not to use microfrontends?
- simple applications - for small to medium-sized applications with limited development teams and straightforward requirements, the overhead of implementing microfrontends will outweigh the benefits,
- tightly coupled features - when features are tightly integrated and dependent on each other, a monolithic approach may be more appropriate to avoid unnecessary complexity.
Summary
In conclusion, microfrontends offer a compelling approach to frontend development, enabling modularity, scalability, and autonomy. However, they also introduce challenges such as increased complexity, performance overhead, and compatibility issues. Understanding the trade-offs and evaluating the specific business needs of your application is essential in determining whether microfrontends are the right architectural choice.
However, I want you to remember one thing from this article: start new project as a monolith. You can always break it down into smaller modules later.