2025-04-28 Frontend-base Mini-Summit

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

@Adolfo Brandes to continue converting Learner Dashboard as per the decision below
@Adolfo Brandes to publicize these notes and invite the community for further discussion during the next FWG meeting

 Decisions

 

  1. 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
  2. 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.