Introduction
Many organizations are talking about how they are launching a modernization effort, but it seems as some organizations are struggling to move to React 18. It can be a challenge to get product teams to prioritize the upgrade from 16 or 17.
There is a modernization strategy that can help make the transition without causing disruptions.
Why Modernize in the first place?
There are several reasons why an organization should upgrade to React 18, beyond the basic fact that React 15 and 16 are no longer receiving security patches from the React team.
- Performance, with each new version of React, performance increases. Users are demanding more snappiness, additionally SEO is becoming even more top of mind for many organizations. Performance gains and the revenue they can potentially generate are a huge driving factor.
- Developer productivity, moving outside of the current major version leads to a large decrease in availability of maintained third party packages. Most large OSS libraries support n-1 (current major version minus one), so the moment a team gets outside of that range they risk being deprecated and having to support the package on their own.
- New Features, for organizations using SSR in particular the server side suspense that comes with React 18 is a real boost for performance and reduction in code complexity.
The Strategy
Most of the organizations that we work with are rather large enterprises. Their development efforts typically consist of multiple teams, multiple backlogs, and multiple, sometimes competing, priorities. Trying to land complicated upgrades takes a rather large amount of effort just in coordination. This has an impact on overall delivery velocity as well since it distracts from feature work.
We need to work in a way that is:
- Easily repeatable
- Automated
- Scalable
- Non-disruptive
- Incremental
Quick note regarding supported stacks
While the main stack being mentioned in this article is React, it is important to mention that Module Federation as a strategy can be used with other frontend stacks; Angular, Next.js, Vue as well in Mobile with ReactNaive and NativeScript and backends with Node or Node with NestJS.
Decomposing and strategizing
When starting a modernization effort that involves frontend development, one of the table stakes for Valor Software in its modernization efforts is the use of Nx.
Too often when working with an organization there are undocumented requirements, configurations spread throughout the organization, or just high levels of repetitive boilerplate. One of the first things we do in an organization is create a series of generators based on their current architecture best practices.
ESLint configs, docker compose configs, sonar-cube, whatever they may be using, we take it and wrap it into a nice enterprise workspace generator tailored to their specific needs.
Having organizational consistency, particularly at the onset of a modernization effort helps ease the adoption curve later on.
Why is Nx table stakes
Changing methodologies is inherently challenging, while many developers will be able to adopt quickly, others benefit greatly from having guardrails. Codifying the existing architecture best practices allow for organizations to understand how those are evolving over time.
Creating incremental demos
Often organizations have their own, boutique, combinations of technologies they have built their application architecture ecosystem around. An organization using React 16 with Loadable Components, Apollo Client all requiring SSR and backed by Enzyme tests and built with Make is going to have some adventures moving to React 18 for a multitude of reasons.
Creating incremental demos allows the team to start with the working reference architecture. These demos start by following the current organizational standards, with all of their niche complexities. Once the Nx workspace is able to generate that reference architecture properly the organization now has its starting point for each of the next stages of platform evolution.
Nx shines again in the aspect that after the reference architecture can be generated, so can the migrations. For the most part the changes needed to add Module Federation to a React application is a known quantity. Which configurations to add, where to add them and which things to test afterwards is also known. With the reference architecture created Nx migrations to perform these known operations. For those unfamiliar, Nx migrations work a bit like code mods on steroids.
Each migration becomes increasingly more challenging but also reveals more value to the platform. Typically Valor sees the following steps.
- Move to Webpack 5
- Add Module Federation
- Create an application shell with target technology stack and methodologies that wraps the existing React 16 application and still loads them with an adaptor
- Migrate federated remotes to React 17 (this may be skipped sometimes)
- Migrate federated remotes to React 18
- Refactor SSR implementations to begin to use Suspense
Most times there is also a migration to Typescript during one of these stages. This helps quite a bit with testability and reusability overall while also boosting developer productivity.
Power of Module Federation with an Application Shell
Adding an Application Shell around the existing application, then added module federation gives teams greater freedom. With this combination they are now able to incrementally upgrade each of the federated remotes with higher relative autonomy. This allows the team to decide how to prioritize migrating the rest of the application. With clear communication patterns and backwards compatibility in place the efforts required to coordinate are significantly lower.
Long term benefits
Architecture standards change, design systems get updated, and as with all software breaking changes are always potentially around the corner. By leveraging an enterprise Nx workspace those change can be propagated throughout the enterprise with a single command, which can also be automated.
With the new Nx workspaces and usage of caching builds also become dramatically faster (typically on an order of 10-100x). We saw one customer's builds go from zero cache-ability and taking 90+ minutes to run, to high cache-ability around 300-600 milliseconds.
We can help!
Valor Software has worked with multiple organizations now begin this migration process and the results are, to put it blunt, astonishing. As partners with the team behind Nx, Nrwl, and the exclusive partners for Module Federation, we would love the opportunity to share specific details on how we can help your organization move to React 18 and Module Federation, schedule a call today!
Top comments (0)