This article covers a few important tips to consider before choosing micro-frontends for your tech stack. I also cover what other tools fit well with it (AI) but most importantly what you need to always practice no matter if you choose micro-frontends or another tech to create modularization.

---

"Understanding the problem and finding a solution for that specific problem is vital"

First of all, let me explain the problem I was trying to solve. Understanding the problem and finding a solution for that specific problem is vital in order to not end up with a platform with bloated features and unnecessary complexity.
Reading up on micro-frontends can also be a little confusing since it can solve a number of problems and there are a lot of different - both in flavors and in numbers - actors in this space.
You have to be careful - as always, when adopting new technologies - trusting the blatant claim that “this tech is the best”; especially when picking a micro-frontend framework.

"We actually spent most of the time fixing bugs in our testing framework"

What we initially set out to do was to do legacy displacement of tech, meaning we had an existing platform that over the years had become a “house of cards” and accumulated so much technical debt that it created more problems than we could handle.
We actually spent most of the time fixing bugs in our testing framework for the application - yes, read that sentence again; it was that bad - than actually delivering new features or value to the customers.

"avoid a “big bang” and slowly transition to the new technical platform"

So, we wanted to replace and re-write parts of the application to avoid a “big bang” and slowly transition to the new technical platform. This is almost a must when trying to convince stakeholders of going down this path.

This did not necessarily require micro-frontends, it could be done way easier using normal routing and sane code structure. Just some good old hard work, simply fixing the existing code. However; since there were so many issues with the code-base and after talking with some colleagues who had tried out micro-frontends recently, we decided to give it a try.

"what micro-frontend tech to use"

Now we needed to decide what micro-frontend technology to use. And here is where it gets a bit confusing - or even messy at times - and you really need to pay attention how the framework is implemented and possible caveats with the solutions.
I will not attempt to summarize the whole landscape in this article - that is too huge of a topic to cover - I am trying to get another point out there. But I will still name a few things to consider for those of you who are currently considering implementing micro-frontends for your organization.

• Micro-frontends is all about running smaller components inside a single container. Separating these components and making them runnable on their own is a lot what this technology is trying to provide. But trust me it is very complicated to solve this in the JavaScript eco system with how bundles are handles, dependencies are loaded and how code is shared and not isolated.
  I rarely express that something in software engineering is complicated - but the orchestration of multiple (at least in our case) independent frontend frameworks, all co-existing in the same single page application, has so many areas where it can go wrong I would carefully consider the need before recommending this to anyone.
As I said earlier, make sure you truly understand what problem you are trying to solve.
  Comparing this to micro-services i.e. tt is way more complicated since everything needs to run in the same browser on a client - where-as micro-services all run independently and then just deliver the result to a client.

• Client vs. server side capabilities. In recent times the popularity of meta frameworks that both render on client & server has grown a lot. Micro-frontends is somewhat of an old technology actually and many of the frameworks was built with client side only at mind. So, you need to consider this because orchestrating this alone is hard - adding hydration between client & server adds exponential complexity. Not to mention having to deal with all the CORS and security rules in modern browsers. If you can, opt for a framework that has server side rendering.

• Isolation. It is pretty funny to me that still to this day true isolation can only be achieved with the (in)famous IFRAME. We would probably have considered using it to some extent if it was not for the issues related to privacy. As with cookies and shared domains many browsers have increased the security by disabling a lot of what can be done using these technologies; so unfortunately it was not an option for us.
  So, micro-frontends does not come with true isolation. Since it is living in the same document there is noting that prevents one component from affecting another through either CSS "bleed-out" or the use of JavaScript to reach different parts of the document.
  This can be controlled with careful implementation though, i.e. using prefixed CSS rules or even more modern things such as layers - but there is no guarantee and since we planned to gradually transition - and by this co-existing with an extremely badly written legacy application - it took a lot of efforts to just get basic boundaries set up.

• Avoid mixing multiple JavaScript frameworks. We wanted to change from Angular to React but you can save a lot of head-ace if you do not need to support multiple (any) frameworks. There are simpler implementations that provides most of the micro-frontend capabilities if you can share frontend technology.
  This is another thing I would advice against; if you are choosing micro-frontends as a means to be able to run any framework. This might sound like a good idea in order to give autonomy to teams and allow them to chose technologies freely - but this will create a lot of extra complexity since the frontend frameworks needs to be supported by the micro-frontend framework and there are no guarantees that a framework will be maintained and able to support any of the new features a frontend library decides to implement. We are actually planning to use our micro-frontend setup to move over to React only, as a transition, and then stick with React once all legacy has been replaced.

• Configuration heavy and lack of maintenance. To keep it short; there is a lot of configuration involved solving all things related to micro-frontends, CORS, CSP, deployment, building, runtime etc. Be prepared to really dig deep in most likely multiple build tools in order to set everything up correctly.
  Also, remember that the micro-frontend technology you choose will become a sort of single point of failure. And there is nothing to guarantee that it will be maintained.

Wow, this did become a lot more information on the implementation than I intended but these are all important learnings so I think it is good to include nonetheless.

---

Part 2 - super-charge your AI capabilities

But, back to my original trail of thoughts. So, now we had decided on micro-frontends and we also had our pick of the framework (single-spa). This is the point where we started to see an emerging problem replacing only parts of the old application with new micro-frontends. Let me try to visualize this more clearly.

Imagine a mail client, with a top menu, side bar and then a reading pane. In the micro-frontend container (the “host” or “root” if you will) I can say that the top menu should be served from micro-frontend A, the side bar from micro-frontend B and the reading pane from micro-frontend C. Easy. But, what if we wanted to replace only the attach file component inside the reading pane, while keeping the rest from micro-frontend C?

Do you see the problem?

This is exactly what we wanted, we wanted - to replace the smallest parts of our legacy application but still use everything else from it; and we needed a way to do that. Luckily single-spa has something for just this case. It is called Parcels and basically what it does is it creates a placeholder in the legacy application that it will then inject the micro-frontend in. Looking at the solution it was not really rocket science or anything but it was something we did not really think of initially and we were happy (lucky) to see it was part of the technology we had chosen.

"Now we had a framework where we could surgically replace any parts of an old application"

So now we got to work. And with the aid of AI we started to really quickly replace parts of the legacy platform. With the power of AI we dared more and was able to be extremely productive and fast transitioning to the new platform.
Not only did we replace components we also gave them a touch up in both functionality and visuals. And this is what I wanted to emphasize on in this article - finally - that actually what made this endeavors so successful and powerful is actually three (3) things - that all are equally important. We have micro-frontends on one end, then AI on the other - can you guess what is the third?

"The problem with AI is that doing large scale re-factoring very error-prone and takes A LOT of time"

It is the size of the changes. Being able to replace smaller parts of the legacy application made AI actually usable. One could have argued earlier that one approach to solve the problem we had was to tell AI (without micro-frontends) to re-write the entire application in a new technology.
The problem with AI is that doing large scale re-factoring very error-prone and takes A LOT of time.
We have had experiences where we have tried just to update certain parts to TypeScript strict or just upgrade from one version of .NET to another and it took us weeks to complete (to be honest some parts is still on-going).

But, when the things we are replacing are small, then AI can focus a lot more and we can make sure we have feature parity with less effort. And since we are free to pick and choose any framework for each micro-frontend we can guide AI to give us a solution that is well written and a lot easier to maintain and change in the future.

I did not actually know how important the word "micro" was in micro-frontends but now I see the whole picture and I hope I could inspire others to take the leap, go through the initial hassle and time to set this kind of architecture up. Because it did take some time to get everything working just right - but now I have no regrets at all going down this line.

If you have any question regarding the actual implementation or want me to dive deeper into a topic - please let me know. I would gladly like to share.