Page Properties | |||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Table of Contents | ||
---|---|---|
|
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?
...
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.
Browser caching of remoteEntry.js
The remoteEntry.js file is created by webpack without a hash on it. This means that browsers may cache it beyond when they should, or we need to find another way of cache busting it.
...
Suggestion: I think we’ll go with the latter, since that’s dead simple.
Behavior for long-lived chunks after a new deployment
If someone loads the page (and manifest/remoteEntry.js) for an MFE and then someone does a deployment, in certain setups the previous versions of the files may be removed and no longer available. Think an S3 bucket that gets cleaned out each time there’s a deployment. If this happens, users viewing a previous version of the page will get 404 errors when trying to load chunks that no longer exist.
...
Suggestion: I think we could likely build in a mechanism to do the third fairly easily.
Header and Footer loading
We need to determine how we efficiently load headers and footers, particularly when MFEs request different ones.
Module federation has no issues allowing a host to load a module from itself. Step one, I think, is to split out the header and footer into runtime modules and configuring the shell to load them by default from itself. This also means if an MFE wants to use a different header, we don’t waste bandwidth downloading headers to a client that we don’t intend to use.