Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

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.

‘Middle-scale’ 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.

  • 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

    1. is expected to be deleted (see DEPR board).

    2. is scheduled to be rewritten within the next year (see MFE Rewrite Roadmap (work-in-progress)).

    3. 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.

Sub-Pages

  • No labels