Why Micro frontends might fail as microservices

Micro frontends were highly inspired by Microservices. So why not extend the same benefits from microservices to micro frontends, right? Things are a bit easier at the backend because we can actually have proper and real isolation. Meaning process/machine isolation, since we can distribute workloads in different machines. When we are looking into micro frontends is not the same deal. We also need to remember that microservices were highly inspired by SOA and Microservices are a flavor of SOA. Microservices are DEAD and in decline for the Backend, so it’s interesting to see it’s a major trend for the frontend. At the end of the day the Browser architecture did not change much and in the backend is much easier to have isolations and we have different flavors of isolations like Docker, UniKernels, MicroWorkers, etc…

In defense of Micro frontends

First of all, I want to say I believe we need more engineering and more Architecture in the frontend space. We need more content like this and this. At the end of the day, I’m in favor of micro frontends. Meaning we need to get better modularization and better tooling. However, like microservices, I’m afraid we will fail as an industry since often we dont do a good design job and often dont learn from mistakes from the past. Right now it looks like React is the more popular and best way to build web applications. Angular is big on the enterprise side and Vue is growing and we always will have vanilla JS. IMHO the place everybody wants to be right now is using React. However, solutions and frameworks come and go and I’m sure in the near future React will be legacy as much as AngularJS is today(Good luck finding engineers who want to work with AndularJS).

We all want better isolations and have ways to implement a strangler pattern(check out the post I and II) and be able to migrate new parts of an application into better modularized and more concise parts with newer and better technology. However, there are lots of people who are completely terrified to run different react versions in the same application(and I get why). Using the same frameworks makes things easier and you can have builds and repositories per Domain instead of one single monorepo maybe one monorepo( Buck, Bazel, or whatever) per domain? However, we all need to get rid of that AngularJS legacy right?

In the past, I used Mosaic. In sense of architecture was great. There was a clear separation of concerns(SOC) — however, in the frontend, everything is about tooling and developer experience and that was one of the main issues with Mosaic. Module Federation is exciting and scary at the same time. So long story short micro frontends are evolving and thats great.

What killed Microservices?

Microservices was always about 2 things. Isolation and smaller granularity. Thats why we have the word “Micro” and thats why SOA never specified any specific granularity and for me this is important. IMHO there is no such thing as needs to be smaller. IMHO it really depends on the domain and somethings make sense to be small and generic like Authentication, Authorization, Encryption, etc.. And others actually are much better to be bigger or more FAT. This idea that everything needs to be micro is really one of the big flaws in microservices and micro frontends are copying that. This is super dangerous. Don’t believe me well look Uber and their DOMA story.

Also, keep in mind teams and software suffers from entropy or erosion, and thats the whole monorepo argument right there. But thats, not the worst. IMHO the worst is shared libraries. Shared Libraries are different animals, they are not services, not micro frontends or microservices and if you build them with the same service mentality you end up building a distributed monolith and killing microservices. So what that was todo with micro frontends? Well, module federation, which tends to become the way to go has a way to reuse remotes in different containers(hosts) but at the end of the day, the browser is the same. Easily we cant get abuse here, which could lead to some problems as described for Microservices.

Fixing the Problem at the Source

Unless we fix the problem on the Browser in order to have better isolation or fix all iframes and web component limitations we might easily create a distributed micro frontend monolith. Plus if we dont pay attention to dependencies and proper design granularity and start having Design Systems written in module federations will not that time we can a button component used everywhere who brings specific Js lib who dont allow us to upgrade other libs and the whole thing fall apart.

You need to avoid the library Trap at all costs. Library Trap creates Walking Dead libs. So you need to pay attention to that as you will be running on different remotes in the same containers or in common containers. Tooling is improving, which is great but at the same time will be so easy to do something wrong. So I wonder when we gonna have DDD + Micro Frontends and make sure we think about different domains and proper granularity and lean dependency management. It might take some time for these problems to manifest. But one thing I can tell you for sure. Everybody is talking about the benefits of micro frontends but what about the drawn backs, pain points, and issues? If you dont know the problems it does not mean they dont exist it just means you will learn about them later one :D

Originally published at http://diego-pacheco.blogspot.com on March 31, 2021.



Brazilian, Software Architect, SWE(Java, Scala, Rust, Go) SOA & DevOps expert, Author. Working with EKS/K8S. diegopacheco.github.io (Opinions on my own)

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Diego Pacheco

Brazilian, Software Architect, SWE(Java, Scala, Rust, Go) SOA & DevOps expert, Author. Working with EKS/K8S. diegopacheco.github.io (Opinions on my own)