The Open edX micro-frontend framework has some problems and growing pains which we’re trying to solve in a variety of ways. This is an attempt at cataloging those so we can understand which of them the frontend composability project (FC-0054) should be responsible for fixing, vs. things like the frontend plugin framework or improvements to Tutor, which are both arguably outside the scope of this work.

Vision

• Independent Deployment

• Composable UI

• Efficient Development

• Shared Dependencies

Potential Solutions

• 🔌 Plugin Framework

• 🎓 Tutor Improvements

• 🥗 MFE Combining🧱 Module Federation

• 🧩 Piral

• 👀 People Processes

• 🏨 Multi-tenancy Support

Pains (with associated potential solution icons)

• Consistency

  • 🥗🧩 🧱🧩 Reusable Component Consistency

    • MFEs will have different versions of Paragon, resulting in UI inconsistencies

  • 🥗🧩 🧱🧩 Shared Organism (header/footer/navigation) Consistency

    • MFEs will have different versions of shared components like the header and footer, resulting in navigation inconsistencies

  • 🥗🧩 🧱🧩 Branding/Styling Consistency

    • MFEs will have different versions of the brand and paragon, resulting in visual inconsistencies

  • 👀 User Experience Consistency

    • MFEs do not have a unified user experience, since they were all made at different times.

  • 🥗🧩 🧱🧩 Dependency Consistency

    • Inconsistent dependency versions between MFEs will have different capabilities and bugs.

  • 👀 Testing Standards Consistency

    • MFEs will have been written with different testing standards

  • 🥗🧩 👀 Technology Consistency

    • Different MFEs will sometimes use different libraries and paradigms, like redux, react-query, redux-saga, react context, font awesome, paragon icons, etc.

  • 👀 Documentation Consistency

    • MFEs will have been written with different documentation standards and levels of completion.

  • 👀 Deprecation Standards

    • We lack consistent application of DEPR standards and processes across MFEs.

• Performance

  • 🎓🥗 🎓🧱 Build time

    • Because each MFE bundles its own complete set of dependencies, and because there are so many, build time suffers.

  • 🥗🧩 🧱🧩 Bundle size

    • Because each MFE bundles its own complete set of dependencies, our bundle sizes are much larger than should be necessary.

  • 🎓🥗 🎓 Development Cycle Time

    • The tools we need to manage running so many MFEs slow down development for any given MFE. (i.e., in Tutor, making a change in one MFE means they all need to be rebuilt since they share an image)

• Development

  • 🔌🧩Decoupled 🧱🔌🧩Decoupled Cross-MFE Composability

    • We have no good way displaying components from two MFEs (think domains) at the same time short of creating a hard-coded build-time dependency between the two.

  • 🎓🥗 🎓 Development Resource Consumption

    • Running so many development servers, one for each MFE, is very resource intensive.

  • 🎓Library Development Complexity

    • Developing libraries means fooling an MFE into using local sibling code, which can be brittle.

  • 🥗🧩 🧱🧩 Dependency Maintenance Burden

    • Each MFE bundles its own version of all MFE dependencies, drastically increasing the number of dependencies we need to keep up-to-date overall.

  • Repository Proliferation

    • We rely on creating separate repositories frequently as a way of being flexible (separating deployments, custom libraries, overrides, etc.) which increases complexity for all the above roles.

  • 👀 Documentation Quality

    • A lack of complete documentation makes the platform more difficult to work with.

• Customization

  • 🔌 MFE Component Overrides

    • Overriding an MFE component is not supported

  • 🔌 Limited Non-Invasive Customization

    • We have few ways of customizing MFEs short of forking them.

  • 🏨 Multi-tenancy Configuration

    • Configuring an instance to use different MFEs and brands per tenant is not supported.

• Autonomy

  • 🔌 🧱🧩🔌 Independent Deployment