Funded Project ID

FC-0054

Provider

Joy Engineering (David Joy)

Axim Contact(s)

Sarina Canelake
Adolfo Brandes

Expected Completion Date

May 2024

Status

Complete

Additional Project Details

OEP-65: Composable Micro-frontends - Pull Request

GitHub

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 *

Shared dependencies *

Central Data Store *

Inter-MFE Eventing *

Lazy Loading / Bundle Splitting *

User Experience Impact *

Plugin Framework

Paragon Design Tokens

Configuration

Iterative Rollout

Build Backwards Compatibility

Paragon Lifecycle

Runbook for what happens when there’s a breaking change?

Best practices to reduce breaking changes

Treeshaking/incremental loading options

DevEx Support

MFE Sandboxing

Child MFE config via unshared dependency

Glossary

Routing

Nesting Dynamic Modules

Static Assets in Guest Modules

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.

Answer: cache control headers or add a timestamp to the URL. Straight from the author’s mouth: https://github.com/module-federation/module-federation-examples/issues/491

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.

Answer: There are a few recommendations floating around online here.

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.