Microfrontends is a new trend in the frontend world however, the idea of being able to compose an application out of other independent applications is not new. Previous experiences such as Java Portlets have not been very successful while other companies, such as Beamery or Spotify, have tried the Microfrontends path with mixed results.
Despite that success, we found our move to micro-frontends also created some new challenges for us. If you’re thinking about taking this path, we hope that you can learn from our experience — Brody Mckee (Beamery)
I don’t understand Microfrontends — Dan Abramov
Why this Microfrontends trend then? Is there substance to it? Is it worth considering?
Single Page Applications have been around for a decade or so and while classic backend frameworks can provide a decent UX on the frontend (ie: Turbolinks, LiveWire), they have been the de-facto standard when it comes to the view layer for most applications.
A frontend monolith is the result of years of continuous development and related technical debt within a single page application. The challanges that come with these kind of applications, independently from the team’s engineering discipline, mostly revolve around dependency management, backend coupling, upgrade and more generally scalability. Managing a Monolith is perfectly acceptable and sometimes the most efficient way to manage the codebase, especially in smaller teams, as it allows consistent deliveries within a simple architecture.
A migration path for a Monolith is complex as it does not offer a clean way to implement incremental structural changes however, breaking changes would be packaged within a single codebase and could be managed successfully. More often than not, a migration of a Monolith simply means developing a new version alongside a legacy version: old code might be difficult to read, but it would not come with side effects.
Monoliths are the future — Kelsey Hightower (Principal Developer Advocate, Google)
Microfrontends is an architecture pattern that offers an alternative to the frontend monolith by breaking up the frontend into multiple frontends, each with its own lifecycle. Being able to administer an application lifecycle independently from other applications allows teams to deploy features to production faster, as they face less dependencies, a concise scope and less risk of failures.
Reducing waiting time between teams is micro frontends’ primary goal. — Michael Geers (Author of Microfrontends in Action, Manning 2020)
The frontend market today offers decent alternatives to the infamous Spotify’s iframe orchestration: Webpack’s Module Federation, Open Components or technology agnostic frameworks such as Single Spa are prime solutions for implementing Microfrontends, despite their young age.
Managing multiple frontends however is not cheap. While the feature frontends might benefit from a reduced scope and a clean API to communicate with the rest of the application, the orchestrator grows in complexity among managing standards, shared state, cache, features API, a uniform UX and inevitable breaking changes.
…a bug on this layer could blow up the entire application and the implementation of new features, if not well co-ordinated, could slow down other teams creating a cross-team dependency — Luca Mezzalira (DAZN)
Is the complexity worth it?
I feel that Microfrontends is a viable solution for scaling frontend within large teams (> 30 developers) working on a single codebase. Even though teams built this way are a product of the organisation’s communication structure, at this scale, it might be a necessary cost in exchange for faster deliveries. Scaling Microfrontends from 30 developers to 100 is a log operation and could incentivise large organisations to structure the teams after the business domain.
On the other side, Microfrontends would be an unnecessary complication for smaller teams where a Monolith could be improved and scaled by simply investing in better engineering standards.