Recommendation: When to MFE
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.
Recommendation
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
Implement new large-scale frontend development using our latest frontend technology: React-based micro-frontends, bootstrapped with our frontend-template “cookie-cutter”.
Updates to legacy frontend code
'Minimal' changes
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 Status).
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 MFE Definition of Done.
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.