Context
Recently, at an Arch Tea Time and at a Consumer Review, questions were raised on tradeoffs and decisions on when to rewrite legacy frontend pages to MFE technology.
...
The following set of recommendations can be used as a basis for discussion by the owning squad. As with other implementation decisions, consider tradeoffs between schedule, budget, and resources, along with code quality as defined below.
New large-scale frontend development
...
For a minimal required change, the team will likely not invest in an entire re-write effort.
...
‘Medium effort’ changes
For a more substantial change, here are a few options that the owning squad can consider given other business considerations.
Option 1 Rewrite: Invest in a complete rewrite if this is a “core” functionality of the platform and the business expects to innovate further in this area.
Note that this rewrite could be resourced via a blended project.
Option 2 Stepping Transition: A middle-ground approach is to use ReactRenderer to embed new React code into legacy code. Implementing the newer code in the latest supported technology is a good transitory stepping stone in anticipation of a future rewrite.
The new React code can be implemented as its own separated “nano-FE” code that is included into the legacy FE code.
Option 3 Stick with Legacy: The team can decide to simply stick with the legacy frontend code for now, especially if the required change is in a part of the frontend experience that
is expected to be deleted (see DEPR board).
is scheduled to be rewritten within the next year (see MFE Rewrite Roadmap (work-in-progress)).
is not critical to business operations and not expected to be updated with feature changes in the next 2 years.
Quality
For MFE rewrites, see Definition of Done for an MFE Rewrite.
For legacy frontend updates that are somewhat temporary (e.g., #1 and #2 in Option 3 above), the team may choose to not invest as much time on otherwise “Clean Code” practices - with the caveat that the team create a backlog reminder to remove any “hack” code within (3) months. Adding a TODO statement in the code along with a link to a Jira ticket is one way of tracking this.
...