Legacy code is a by-product of running a business. There’s no escape from it no matter how hard you try. Even if you started off as a brand new project, over time you’ll accumulate legacy code to a point where you just want to throw everything away and start again.
But you can’t.
Business must go on — even when you’re taping code here, there and everywhere just to make things work. If you’ve ever had the chance to work with any legacy system or code that is older than 6 months, you’ll know exactly what I mean.
The best part of this experience is that new tech comes out all the time. The boss or someone in your team wants to implement the next feature using the latest framework or library. But you can’t let it happen because the application is a monolith that will get angry if you try to change the core technology from what it’s currently using.
Either that or a rewrite of the entire system. Because rewrites are the equivalent of starting anew — just for the cycle to repeat all over again.
It’s an issue that many organizations face. So how can we fix it?
I guess it’s time to talk about a thing called scalable micro frontends.
The issue with monoliths
Monolithic applications ensure that your core technology remains the same — even when the rest of the future is speeding off into a great and glorious space of better speed, coding practices, ideas and everything else that your current front end tech stack cannot do.
While monoliths are easy boot up and build over time, it can hamper the application’s ability to pivot and grow. Things get worse when there are multiple people or teams trying to work on the same code base. It can get messy really fast and several code janitors may be required to keep everything clean, cohesive and conflict-free.
Even then, a code repo can descend into madness when teams create solutions using different ideologies, implementations, standards and more than a few dozen branches. It happens a lot.
The art of decoupling your front end application from frameworks
When your front end solution becomes technologically agnostic, you allow your entire solution to become decoupled from using only one particular framework or library that may or may not be out of date. This means that your application as a whole is indifferent to whatever you decide to use for whatever reason.
You could have parts of a page running in React, another in Angular or even Vue. Legacy code doesn’t need to be thrown out completely and reused until the business decides to address it. While this sounds like a Frankenstein kind of application, it is a friendlier and more modern beast than one that’s required to use old tech.
Your front end becomes a stack of organized lego pieces that fits together in a modular manner rather than a monolith covered in sticky taped code.
The perks of Angular, React and even Vue is that they can work in a containerized manner. Modules in Angular and React’s component based structures allow for each to operate freely on its own. It will require a change in the way things are coded — such as moving from a Model View Controller structure to a component based one with restricted and isolated scopes.
However, clear feature boundaries are required to ensure that scope is maintained and a shared state management system may be required if components and modules are required to communicate with each other. Either that or this is the chance to leverage micro services and backend functions to act as the glue to keeping data persistent and consistent.
Perks of transitioning to micro front ends
In the world of agile, a team’s ability to effectively produce is also tied to their autonomy to create.
Using a micro frontend architecture reduces the number of dependencies and scope, allowing for teams to create without fear of breaking another section of the application that’s coded by someone else. While fragmentation of an application’s front end may feel scary and counter intuitive when talking about code cohesion, it is actually better for the business and decentralizes the risk from a single point of failure.
If one part is not working then it shouldn’t impact on the rest of the application. It can also decrease load speed and increase a positive user experience as they are able to interact with the application before everything is loaded.
You will still need a base app to keep everything together but overall, the ability to create your application in a distributed manner can result in better isolation of issues and grading of different team performances. It can also increase the speed of your tech stack upgrade over time and thus ensuring the maintained modernity and compatibility of your application with browsers and devices.
Final words
With a micro frontend architecture, it doesn’t matter what framework you end up using — only that you code in a module based mindset. Architecture is a unifying ideology that keeps everything from falling over.
The thought of architecture is often overlooked and only addressed when there is an issue or when new technology is released. When you’re not required to remain reliant on a particular framework to solve your front end issues, it gives you the ability to pivot your teams, technology and features to suit requirements. The business and its requirements becomes the centerpiece rather than trying to deal with the application’s restrictions.
Micro front ends, however, will pose its own series of issues such as visual cohesion, cross module state sharing and transitioning out old code into a new architecture. Nevertheless, the benefits still remains.
While a monolitic or single repo structures may work well for smaller applications, enterprise sized projects may benefit greatly from the decoupling of features and technology that micro frontend brings. The ideology behind this is similar and for the same reason why micro backends are making big waves and embracing the services that cloud providers are coming out with. It’s time we start doing the same and leverage the module concept to construct an application that isn’t tied to a single framework or library and focus on the solution rather than the tool.
