A casual talk about microfrontends

Talking about microfrontends while Bob is in the bathroom.

10 minutes read.

The last two months I was researching about microfrontends for a migration for one project of the company where I work, it is a HUGE application with more than 10 years of code, build on a very old JS framework from the times of IE. It's horrible add something new or fix stuff on that app, the framework is old, the JS is old and the styling is painful, and... we can not migrate it, the application is so big, the estimate time for migrate it to a modern JS framework like React or Vue is 2 years at least, and we can not say to the client that he have to pay another team for two years for have an exact copy of the current app.

So, what can we do? Probably the answer is using microfrontends, build the new parts of the app in React and connect them with the legacy app is a great idea.

Usually  microfrontends work in two or three ways,  the first one is using iFrames, loading the required application where needed on an "orchestrator" application,  the second one is develop the applications independently but build them in a single bundle and the last one, and my favorite is develop and build each microapp independantly and have an orchestrator app that take together all the microapps, that allow us to have separate deploy lines for each microapp.

But, we have some issues here, if you remember we are using an old JS paid framework, it does not uses node or webpack, it uses his own tools for build and run the app, so we don't have any control over that. So we have to consume the legacy app as an iFrame, but at least we can make the new parts as independent microfrontends.

 iFrame issues

Using iFrames have some issues, almost all of them related to performance, security and microforntends communication. Probably the bigger problem is related to cookies,  them are stored in the iframe not the web page. iFrames can send events to the parent webpage, so probably we can try to move all the cookies to the orchestrator webpage, but I think that is not safe or a good idea in general, is better migrate some important parts like the auth to a local storage approach.

Using single-spa

Single-spa (https://single-spa.js.org/) is a framework for build microfrontends based apps easily. Make a microfrontend from scratch is very hard, there are lots of configurations and things that you have to keep in mind and every error can be fatal. single-spa provide tools to generate and configure your microfrontends for prevent issues with routing, rendering, communication etc...

My idea, is build a small and simple React app that is just an iFrame that loads the legacy app, and over that react app build a routing system to keep the application routing the same as the legacy app.

Other advantages of microfrontends

But, microfrontends are not good only for migrating very old apps, it optimize the development of new parts of the app, can improve the performance on the client side if every microfrontend is lazy loaded, and finally, have separated deploys for each app make the devops workflow easier in some times.

(Take a look to my discord server: https://discord.gg/ZAa8buptpm)