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.
Potential Solutions
🔌 Plugin Framework
🎓 Tutor Improvements
🥗 MFE Combining
🧩 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 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