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.
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
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.
Cognitive Load
Developer Cognitive Load
The inconsistency described above increases developer cognitive load, lowering velocity
Operator Cognitive Load
The inconsistency described above complicates operating an instance even if you’re not doing development.
Maintainer Cognitive Load
Maintainers need to remember the differences between MFEs.
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.
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.
Customization
MFE Overrides
Overriding an MFE with a custom implementation is difficult to maintain
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.