Pains and Requirements

Owned by David Joy
Last updated: Mar 28, 2024

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 of MFEs

  • Composable UI

  • Efficient Development

  • Shared Dependencies

  • Less dependency overhead

  • More consistent dependencies

Potential Solutions

These are things we think we can reach for to solve the problems described below; each pain is annotated with which of these solutions addresses it (up for debate, this is my gut interpretation of which actually fixes it. For instance, adopting module federation or piral may give us some options regarding multi-tenancy, but we still don’t get that without additional, dedicated effort. People Processes is here because many of the pains we described in the original FC-0007 description, and our upcoming frontend modules OEP, aren’t actually things that are solved by frontend composability itself, but which require us to follow-through with a process to ensure quality and consistency.

  • Plugin Framework

  • Tutor Improvements

  • 🧱 Module Federation

  • Piral

  • People Processes

  • Multi-tenancy Support

Pains (with associated potential solution icons)

  • Consistency

    • 🧱 Reusable Component Consistency

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

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

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

    • 🧱 Branding/Styling Consistency

      • MFEs 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 have different capabilities and bugs.

    • Testing Standards Consistency

      • MFEs have been written with different testing standards

    • Technology Consistency

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

    • Documentation Consistency

      • MFEs 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 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