Micro-frontend Plugins

[e0d]

Abstract

The ability to extend the user interface of the Open edX Platform is a prerequisite for scalable innovation, customization, and experimentation. It allows us to maintain a small, stable, and extensible platform core, and is a vital part of our micro-frontend customization capabilities.

Micro-frontend plugins (a.k.a., "Experience Plugins" or "XPs") give us a dramatic increase in flexibility in how we build and deploy our user experiences. They enable an increase in team autonomy for feature development, modularization of cross-cutting features, code reuse, and approachable experimentation and extensibility.

Approach and Status

MFE plugins may be implemented with variety of technologies, such as LTI, plain iframes or federated modules. The initial implementation has focused on iframe-based plugins, as they're simpler than LTI, but more secure than module federation, and feel like a "sweet spot" that's most applicable to the community's needs.

We intend to write an OEP on Micro-frontend Plugins describing the above approaches and their relative strengths and weaknesses in more detail. @davidjoy is writing an initial draft (openedx/open-edx-proposals#259, openedx/open-edx-proposals#287)

An initial implementation of iframe-based plugins is currently sitting in a pull request in frontend-platform: openedx/frontend-platform#235

Note that this capability depends on improved micro-frontend configuration capabilities. Our current environment variable-based approach is insufficient for build-time MFE configuration. See related tasks below.

Related issues:

• Discovery: MFE Extensibility and Pain Points axim-engineering#146
• Support for JS-based config in frontend-platform wg-frontend#11
• iframe-based Experience Plugins support in frontend-platform wg-frontend#13
• Support for JS-based config in tubular wg-frontend#12
• Proposal: Application headers and footers v2.0 wg-frontend#41
• Standardize plugin slots wg-frontend#178

Related Repositories

• https://github.com/openedx/frontend-plugin-framework

Related PRs

OEPs

• OEP-XXXX: Micro-frontend Customization open-edx-proposals#259
• OEP-XXXX: Micro-frontend plugins open-edx-proposals#287

Implementations

• feat: iframe-based experience plugins frontend-platform#235
• feat: slot component for dynamic plugins frontend-app-communications#184
• Convert "Pages & Resources" page to a plugin system frontend-app-authoring#638

[arbrandes]

Just ran into another plugin case, to add to our salad:

openedx/modular-learning#6 (comment)

[davidjoy]

Slots that enable various use cases:

1. Course tabs
2. Course sidebar content
3. Replacing header/footer overrides with default header/footer plugins configured to use different components
4. Cross-sell/upsell/marketing messaging in user dashboards/courses.
5. Functionality in courses like notes, calculator, etc., which augments the course content.
6. Non-display plugins, like alternate analytics/logging implementations
7. Additional header bars
8. Additional user menu items depending on user role

The idea is these are all enable extension points (slots?) that help operators/developers avoid forking and overrides. We don't know exactly what they'll use them for because we haven't thought of it yet, but they're all relatively obviously useful enough that we can imagine them being helpful. In practice, you don't add a slot until you have a concrete use case from someone.

Some of these I can see 2U using to disentangle some of edX's historical choices and simplify MFE code, removing things that were added "for one org" (edx.org). For example, we have enterprise code in the header user menu, we have 'experiments' littering the frontend-app-learning MFE for upsells, cross-sells, and marketing messages, we're likely to have the same on learner dashboard. Frontend plugins would be an obvious way to add custom course tabs in a modern way, rather than reloading the page back to the monolith.

This effort has come up for me recently because I see the 2U marketplace teams eyeing the LMS as a place where they can do cross-sells and upsells, and there's no good way to do this today without polluting the MFE code.

[davidjoy]

MFE Plugins also enable extending the Open edX architecture, especially around ecommerce, catalog, marketing, etc., by allowing configuration of links/functionality that shuttles the user off to parts of the site that aren't in the 'core', so to speak.

[arbrandes]

All of this sounds great to me. Looking forward to helping develop this further!

[arbrandes]

I elect to use this issue to track developments stemming out of the upcoming Frontend Pluggability Summit.

This is the summit's current wiki page: https://openedx.atlassian.net/l/cp/sdRpN2Tw.

[crathbun428]

Is this proposal ready for product review?

[davidjoy]

Just to chime in here, this proposal has come a long way since 2021 when it was written, and 2023 when it was last considered above. Since then, we've kicked off a project around module federation (FC-0058, which I'm working on). I'm not aware of a "Micro-frontend plugins" document ready for product review, but expect there are some good conversations that could happen to bring product up to speed.

The landscape has changed considerably for the better, and we know a lot more about what we want here and what the options are from a technical perspective. There's a lot of work in flight. FC-0058 is about "modules", which is basically a superset of plugins. It's highly related and I'd love to talk through the details with the product group - it has a lot of potential to improve the extensibility of the frontend and how we work with it in general.