Micro frontends — migrating legacy systems

A modular approach to replacing legacy code

One of the biggest issues we face today is dealing with legacy web systems that were written before we had the knowledge we have today. This is my approach to dealing with the migration.

Micro frontends are the new kids on the block. It is an elusive concept that is often misconstrued. The benefit of this concept is that it provides freedom to explore and growth to the frontend developer who engages in it. As opposed to being shoved onto a monolith system to support or burn out on features. If you aren’t familiar with the micro frontend topic have a look at Tom’s post.

I first implemented micro frontends in practice when we needed a new module in our customer support admin system, which was no longer maintainable — at least in my mind. I spun up a Vue application using the Vue-cli, with routing, and state management. In addition I included a couple of helpers like LESS and a library with prebuilt Vue components — Element.

I decided to use Vue because of its size, incredible scalability, ease of use for non FE devs and the freedom that allows choice of preferred tools. I hosted the new module on the same domain as the bigger admin app, which allowed the sharing of cookies for authentication, and if the user wasn’t authenticated I simply redirected them to the main application which has the authentication module.

That alone made this transition extremely easy, and that’s all there is to this in its core. The biggest issue when it comes to using a whole new framework is sharing state, or in this case it was authentication. Having your authentication token stored in a cookie which is stored on the same domain allowed for this behaviour, if you aren’t keeping track of authentication in that manner there are many others ways to solve this.

I will refrain from tackling the finer things with this post such as having a shared style library as there is already a considerable amount of literature covering this topic . However if you are interested this article can get you up to speed. This is quite important for this to work efficiently, it will improve the life of your application in the end as well.

How will this help migrate the legacy systems to fresher and better systems built around past experiences? We can start migrating modules in isolation, while they are still being used. This is where a good framework becomes important, a framework that can support reusable parts your legacy system, your API calls that were written with axios or superagent, your component specific pre-processed styling and your translation module.

Once all modules are migrated, one essentially has a routing application at its core. At this point if all the modules are using the same framework one can convert your application back into the monolith you once had, which will be a simple task to do. If one avoids confining all modules to the same framework then one can enjoy the freedom of having isolated modules that are independent of one another.

Share your experiences of using the micro frontend approach with me.