2025-04-28 Frontend-base Mini-Summit
Date, time, location
Date:Apr 28, 2025
Discussion topic(s)
Morning
What to do about frontend-base.
A story from Adolfo
A long time ago in a frontend far far away
Discussing the enterprise use case where you need features but be very customizable, that’s where the idea of composability first came up.
We funded a version of this with Piral but it was not the right fit.
We tried again to figure out, and this is frontend-base, module-federation. Pre-alpha, not ready to use, but gives glimmers of a positive future
Includes the git history of:
frontend-build (now: tools)
frontend-platform (now: runtime)
frontend-plugin-framework (now: runtime)
frontend-component-{header, footer} (now: shell)
This meeting today is to figure out what to do with frontend-base and steps forward in the Open edX frontend ecosystem.
Story today: We have a bunch of SPAs
Each needs to be built and deployed independently
2U and edx.org builds each to its own domain and deploys them independently
Tutor builds each individually butputs all of them in the same Docker image and Tutor users all have the same entrypoint--do not see these as separate MFE domains.
Pain points
In Tutor, this build is terrible: Tutor gets 12 different builds + no ability to deploy separately
Redundant builds cost for operators and developers
This can occur for lots of reasons including due to changes in Build Time Configuration
Making 12 PRs whenever we want to change something
This makes maintenance more difficult.
Operators will have more PRs in plugins for maintenance on top of this.
Config changes causing full-rebuilds
Tech debt when less-active frontends drift out of date
Nothing like comprehensive theming in the MFE world
Performance cost for users (e.g., re-downloading all of Paragon when navigating across MFEs.
Page load times
Granularity - We don’t actually do micro-frontends.
E.g., chromeless UIs without header/footer to improve composability
Can’t do site-wide customization as easily.
Good points
Team Independence across services / rapid development
Each MFE can choose the dependencies they need without coordinating with other teams
Being able to create new MFEs using the template application
Documented platform
Improved Fronted Development workflows and satisfaction
Frontend-backend seperation
Proven technology
Feanil: How high has the cost been for upgrading things like Profile or Account?
Brian: Generally not too bad because they’re small. e.g. moving to React 18.
Adolfo: Enzyme deprecation example: took a lot of time from FED-BOM (months). But now we’re in a better place because we’re much more careful not to leave MFEs belong.
Feanil: We’re much better at maintenance scheduling than we were in the past.
Adolfo: Worry how many people we have actually pay attention to both their own repos and the overall landscape. I’ve been feeling a little behind.
Kyle: Can Brian and Adolfo go on vacation at the same time and still have this view? (Answer: Probably not.)
Feanil: Important to have people looking at overall arch and dependency/upgrade health, but those are different things.
Adolfo: The original approach was not optimized for global maintenance.
Frontend Base Plan
We’re going to have a new library that unifies all the shared base dependencies.
All the individual MFEs are now modules that are not run as SPAs, and are more like published, versioned libraries.
The libraries will be combined together within a new “project” repo, and using build-time configuration, it will pull in frontend-base, and new MFE modules you configure into a new SPA.
You could have as many projects as you want if you want to continue to deploy multiple SPAs to multiple domains.
Correlate major version upgrades (e.g., React 18 → React 19, Paragon v22 → Paragon v23) with Open edX named releases.
Developer experience
Devs should be able to run modules both in isolation for local development OR within the full project.
Modules would likely contain an example project.
What is a module?
an ECMAScript module
Modules go into Slots
If I have a module, does it live in only one slot or can content from one module be put into different parts of the page.
A module can export multiple “named” modules some of which are components.
Afternoon
Things we agreed on:
We don’t really care about the module federation aspect of frontend-base
@Brian Smith advocated for publishing MFE modules and using a shell.
@Feanil Patel asked if we can get a lot of the benefits that would come from that by just adding a bunch more FPF slots to MFEs as they currently exist.
This would include adding slots to the routers that exist within each MFE to support adding pages.
Nested slots using site.config.js - would need to publish modules buildless to support build time config using slots in the module.
Runtime config? frontend-base doesn’t have anything for the Tutor MFE_CONFIG API stuff yet?
Participants
@Adolfo Brandes , @Adam Stankiewicz , @Max Frank , @Feanil Patel , @Edward Zarecor , @Sarina Canelake , @Brian Smith , @Kyle McCormick , @Dave Ormsbee (Axim)
Action items
Decisions
- Move ahead with conversion of at least one MFE (likely Learner Dashboard since the first draft of the PR is already up) into a plain (as in, not federated) module that can be loaded “chromeless” into the frontend-base shell
- Hold off on module federation; it might make server-side rendering impossible, and given that the latter is one of the only known ways to improve user experience significantly, we should prioritize it (SSR) over module federation.