Discovery: How could we include new MFEs in releases without slowing down Tutor builds?

[kdmccormick]

Context

The tutor-mfe plugin is our method for including micro-frontends to the named releases. It currently builds four MFEs into its Docker image by default, leaving the end user the ability to build in extra MFEs. Each additional MFE significantly increases the plugin's build time and image size.

We need Open edX releases to work "out-of-the-box", so all MFEs that are required to in order for the platform to work need to be built into the tutor-mfe image by default. As more MFEs become default and old frontends removed, the build time and size of the MFE image will continue to balloon.

In this Nutmeg issue, we discussed whether the Authn MFE should be included in Nutmeg. One of the arguments against including it was that it'd increase tutor-mfe build time and size. Going forward, we'd like if this didn't need to be such a consideration.

The solution to this issue may be related to the dynamic MFE config idea which is being floated at the frontend WG. There also may be salient points in the recent MFE retrospective.

Acceptance

Investigate the problem and list potential solution(s).

[kdmccormick]

Since this is issue is a longer-term one and will require some discovery, I think it'd be fine to table it to post-Nutmeg.

[arbrandes]

eduNext is working on this, as outlined in this exporation document. (In particular, Epic 1.)

[kdmccormick]

Late update: This is being solved in time for Olive (🤞🏻) with:

• MFE runtime configuration wg-frontend#103 and
• Create small MFE base image using runtime MFE config system #235

Closing this since the discovery work has been done for a while.