...
Consistency
🧱🧩 Reusable Component Consistency
MFEs will have 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