If you are working on a large scale application and the friction between your teams is exponentially increasing as your application grows larger, you are probably considering if the Micro-Frontend pattern is a good fit for you and your organisation. Architecture is a series of decisions and trade-offs, and you want to make the right choice and avoid creating an even bigger problem.

So here are some common Micro-Frontends risks and disadvantages you should be aware of:

The Browser

Microservices allow a deeper level of encapsulation by using containerisation to ensure the same piece of software runs consistently on any infrastructure, however, with Micro-Frontends, there is a platform that we cannot avoid: The Browser. As a result, we have to deal with the different variations and ensure that we optimise for performance without compromising on the flexibility of independent deployments.

Following best practices, keeping bundle sizes small and implementing container applications (also called shells) that are in charge of composition and configuration should help solve most of the quirks of running "Microservices" inside the browser.

Too many Micro-Frontends

I have seen so many Micro-Frontends implementations that fall for this trap; splitting your modules too thin produces exponential complexity, discoverability issues, more infrastructure to maintain and unnecessary overhead.

The key to splitting Micro-Frontends is to avoid having single entities that require other modules to function, instead,
you should divide them into different Bounded Contexts and follow Domain Driven Design patterns. This ensures explicit relationships, clear boundaries and improved communication between teams.

Multiple Implementations

A downside of Micro-Frontends is that there isn't a single implementation, there are many ways of achieving independent deployments and architectures vary depending on the company applying them. This can cause confusion and a steeper learning curve for developers trying to adopt this architecture.

"Patterns that cause you to ask more questions than they answer are not good patterns". However, in the case of Micro-Frontends, this is an unfortunate side effect of the nature of the problem they are trying to solve. They are an answer to an organisational problem, and all organisations are different, so something that works for company A might cause a lot of issues at company B. The lack of standardisation and variability leads to a lot of questions. It doesn't mean that some approaches taken by companies implementing this architecture are not correct or that the Micro-Frontend pattern is not valid, quite the opposite, they intend to solve a very specific problem that requires personalised solutions.

Scale and Organisational Structures

The Micro-Frontend pattern heavily relies on organisational structures and they are an answer to scaling problems that are the result of a quick expansion in the application and the number of developers who maintain it. Because organisational structures vary so much, some patterns like Vertical ownership of end to end features or The BFF (Backend for Frontend) pattern might not make sense to your organisation. The good news is Micro-Frontends are very flexible and you don't have to adopt those patterns to get the benefits. As long as you can achieve independent deployments of properly divided pieces of frontend functionality, the rest is up to your organisation to decide what works best for your teams.

 Micro-Frontend Frameworks

"11 Micro-Frontend Frameworks you should know" 🙄

As a result of the lack of standard implementations, several frameworks have emerged to provide you with the building blocks and guide you on how to use Micro-Frontends. I am not saying these Frameworks are not valuable or helpful, however, if you decide to use them, just remember that you are automatically accepting all their opinions and trade-offs that were the results of the experience and requirements at their companies. Micro-Frontends are the solution to scaling and an organisational issue, if you apply a framework tailored to another organisation that is not yours, it might not solve your particular problem and could cause even more issues.

Conclusion

Should you adopt Micro-Frontends? Ask yourself first, Do you have a problem?. If the answer is yes and you are part of a big organisation working on a large scale application, you can assess the benefits and risks of this architectural pattern and decide if it is going to help you solve your particular problem. You can reach out to other companies for inspiration and example architectures that worked well for their specific context but bear in mind that your solution might look very different.

Remember, an architecture is only as good as its implementation.