Use-Cases for Frontend Plugins

What we’re looking to solve

  1. There should be a clear separation of the Frontend Plugin from the Host MFE that it would “live” in. 

    1. This would isolate teams from each other’s work, which we recognize has been an issue for the open source community and 2U-internal development across several teams. 

  2. The Frontend Plugin should be deployed and maintained by the team that created it, as opposed to the team that is responsible for the Host MFE. 

    1. This allows teams to deploy independently while working in the same user interface.

    2. The only major change that should be made in the Host MFE is the configuration for the space in which the Frontend Plugin would exist, so that the Host Team would only need to review that which they were already maintaining. 

    3. Host team defines the Plugin Slot’s space and location, while the plugin renders within that defined space.

  3. If there is a breaking change in the Frontend Plugin, the Host MFE should not be affected or prevented from being built/rendered. 

    1. This would cut down on unnecessary communication between any teams working in the same Host MFE.

What our Frontend Plugin Framework accomplishes

The first version will use iFrame-based plugins to render the “child” MFE’s component into the Host MFE.

  1. The Frontend Plugin Framework lives in its own library that is maintained independently from the MFEs.

    1. Very few dependencies are needed for the Framework, but this allows for a dedicated team to maintain and improve on the Framework over time while making sure that all teams are able to agree on the plugin configuration.

  2. A Frontend Plugin receives the component it needs to render via a route in the “child” MFE, and Frontend Plugins can only be added to Plugin Slots in the Host MFE.

    1. This ensures the actual work lives separately from the Host MFE and that the Host MFE team is only responsible for making a Plugin Slot available.

    2. Immediate example: We would extract the Recommendations panel.

    3. Example: The team that maintains Learner Record MFE would like to display the learner’s record inside Profile MFE, which is maintained by another team (“host”). The Profile team would create make a Plugin Slot available on the Profile page (/u/{learner_username}), which the Learner Record team would then provide with the route to their Learner Record component (/record/{learner_username}/plugin).

  3. Host MFE owners are responsible for maintaining and owning PluginSlot extension points.