Pains and Requirements
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