Overview
This SOW began with some initial discovery on Piral and how it might fit into Open edX. Since beginning that discovery, we’ve decided to pivot toward a more narrowly focused effort to enable Webpack Module Federation for Open edX micro-frontends. We intend to repurpose OEP-65 to document that decision.
This top-level document describes a number of considerations in the effort to use module federation in Open edX MFEs with links to other documents where appropriate. Not all of these are going to be explored during the first SOW, but we can consider this an inventory of what we’ll need to work through for a reference implementation.
Discovery Areas
* Starred Areas are being investigated in this SOW.
Frontend Shell Application *
What does our frontend “shell” application look like, and how does it interact with the child MFEs?
Shared dependencies *
How do we upgrade dependencies safely, predictably, and publicly?
Can we create Github actions/workflows to help us keep things in sync?
What dependencies should be shared?
Central Data Store *
What types of central data might exist?
i18n message ingestion
Global state
Inter-MFE Eventing *
Broke this out from ‘central data store’ because it came up during that discovery.
What are the use cases for eventing? Do we have any?
Lazy Loading / Bundle Splitting *
User Experience Impact *
Plugin Framework
How does usage of module federation fit in with the frontend-plugin-framework?
Add “Module Components” back in, use module federation to load them.
Module components likely take the place of build-time “direct” components in many cases.
Paragon Design Tokens
Is there any overlap between this work and the Paragon Design Tokens effort?
Configuration
How do we configure module federation?
MFE config API (“Feed Service”)
env.config.js
Do we do this at runtime? At build time? Both?
Iterative Rollout
How do we add module federation to MFEs iteratively so that they can coexist with MFEs we haven’t yet updated?
Alternate frontend-build webpack config
Build Backwards Compatibility
How do we add module federation to MFEs in such a way that they can continue to be used in “standalone mode” while we adopt the new architecture?
Paragon Lifecycle
Runbook for what happens when there’s a breaking change?
Best practices to reduce breaking changes
Treeshaking/incremental loading options
DevEx Support
How does this change the tutor MFE setup?
What other considerations exist here?
MFE Sandboxing
Error Boundaries
Module Fallback
What happens if a shared dependency is an incompatible version?
What if that dependency is a “singleton”, meaning only one of them can be loaded (i.e., React)?
Child MFE config via unshared dependency
How can a child MFE get to its own config document if we share frontend-platform with the shell?
Glossary
What do we call the parent and child so we have common terminology.
Routing
Does React Router play nice with this setup? Can an MFE include routes and they’ll just work?
How do we assign routes to dynamically loaded pages?
Nesting Dynamic Modules
Can a dynamically loaded module load its own dynamically loaded module?
Static Assets in Guest Modules
Do we need to use getPublicPath in our module federation config to allow guest modules to load their own static assets properly?
PUBLIC_PATH must be specified
Determine if all MFEs must specify a PUBLIC_PATH for module federation at runtime to work. Without PUBLIC_PATH the shell tries to load modules from its own domain. Just need to understand the lay of the land here.