Revamping a Legacy React Application with Micro-frontends

A recent client project presented a challenge where a legacy web application was built with ReactJS using outdated packages and poor coding practices. The application relied on jQuery for DOM manipulation and lacked proper global state management, leading to scattered state across components.

Rewriting the entire codebase from scratch wasn’t feasible due to the application being in production and requiring new features. The team needed a way to incrementally revamp the application, addressing issues piece by piece. Ideally, they could have rewritten the codebase component by component, but outdated dependencies and poor state management made this impractical.

The need for micro-frontend architecture

This is where the concept of micro-frontends came in. Inspired by microservices architecture, micro-frontends offer a solution for front-end development. The idea involves isolating newly developed components and seamlessly integrating them within the existing application.

From an end users’ perspective, there wouldn’t be any noticeable differences, but behind the scenes, parts of the application would be powered by the newly developed codebases. This approach allows us to gradually replace the old components with well-written code, ensuring a smoother transition. Hence, the team decided to give this approach a try.

If the application modules are complex, then by adopting the microfrontend architecture, teams can work on various parts of the application simultaneously, without interfering with each other’s work. This approach promotes better collaboration and faster development cycles. However, in this case, the modules weren’t complex enough to warrant separate teams.

Implementing the solution

Careful planning was required for implementation. First, key areas for improvement were identified, and specific parts were planned for redevelopment. There are several ways to implement micro-frontends. These include:

iframes
Module federation
Web components

iframes seem like an obvious choice as it is simple to implement, but there are a few drawbacks with this approach. The main issue was the lack of seamless integration with the parent application. Communication between the two can be difficult, and sharing data and state becomes a challenge. Additionally, iframes can impact performance and introduce security concerns. Therefore, the team explored other options.

While Web Components were a viable option due to their lack of iframe drawbacks, the learning curve discouraged their use. However, it would have been a viable choice as it does not have the drawbacks of iframes. After discussing the tradeoffs, the team decided to use Module Federation with Webpack. The team already had experience with Webpack and the ability to use React to build the new modules was a win. The basic idea of Module Federation is to combine multiple separate builds from application modules to create an application. Theoretically, these separate builds could be from different frameworks, such as ReactJS or Angular.

After these architectural decisions were taken the team started to create a new codebase for one of the most bugged components. These new modules were built using modern technologies like ReactJS, Typescript, Redux and followed best practices, ensuring cleaner code and better maintainability.

The Module Federation plugin was used to modify the Webpack configuration. It specifies the name of the module, the filename for the remote entry, and the components to expose from the new codebases. For example, in the given snippet, the team exposed the app component from the src/ components directory.

These modules (React Apps) were then deployed on subdomains of the parent domain and to enable their discovery, the Webpack configuration of the existing app needed to be changed too. This involved adding the following code snippet to the configuration file:

This configuration allowed the existing app to communicate with the webpack builds of the other microfrontends and integrate the exposed components seamlessly. Within the existing application code, the newly developed module could be lazily loaded and used within the JSX code.

This approach allowed the team to start revamping the old application fast as different team members worked on different modules.

With this approach most of the drawbacks of the iframes were gone as the communication between the existing app and the new modules as they were just React components. Additionally, a global state management system with Redux was gradually introduced to the existing app, and the new modules were able to hook into this new global state without any problems. So, it’s a win!

Conclusion

Micro-frontends proved to be a valuable approach for incrementally improving the legacy application’s front-end codebase. By isolating newly developed components and gradually replacing the old ones, the team was able to address the issues of outdated packages and poor coding practices without disrupting the user experience. This approach allowed them to leverage the benefits of modern technologies and best practices while minimising the risks associated with a complete rewrite.

However, it’s important to acknowledge that there are tradeoffs when using microfrontends. Managing multiple codebases and ensuring proper communication between microfrontends can introduce complexity. Additionally, maintaining consistency in design and user experience across different microfrontends requires careful attention. Further, the need to host these microfrontends separately would add more complexity to infrastructure as well.

So, as a final note, if you’re facing a comparable situation with a legacy frontend codebase, consider exploring the possibilities of microfrontends. Even for new applications this approach can be considered after considering the tradeoffs between the added complexity and the advantages it introduces.