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

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-course-authoring#638

[arbrandes]

Unassigning myself until such time I or somebody else gets back to this.

[davidjoy]

It’s worth thinking about whether the modular MFEs work could help with this, or present an alternate approach, etc. I have that prototype of iframe based experience plugins (PR is linked above), for what it’s worth.

This is starting to come up again for 2U and I’m interested in making some progress here, but I also want to make sure it stays aligned with our other efforts!

[arbrandes]

@davidjoy, part of the hang-up here - at least as far as I'm concerned - is finding an actual use case for a plugin. I'd prefer solving a single case than trying to foresee them.

Things like: Why does the feature need to be a plugin rather than built-in? In which MFE (or library, or component) would it go? Or, as you point out, could it realistically be used across MFEs in a modular architecture? How could it realistically be replaced with something else?

As it happens, I came across an old idea again this week, which is the recurring desire by operators to add custom tabs to the learner view in the LMS. It felt to me like a good starting point for a plugin discussion, but I'm sure you'll have other specific ideas as well. Should we get together to talk about it? I'm sure more people are interested, so maybe we can kick something off in the next FWG meeting.

[arbrandes]

Oh, and something else that has been coming up frequently, which I'm sure you're aware of, is the general desire to avoid having features in MFEs that only work (realistically speaking) for one org. I can think of a few instances of this that happened recently in the Authn MFE, but I'm sure we can think of others, future or present, that might also apply.

[arbrandes]

For future reference, this was such an instance: openedx/frontend-app-authn#758 (comment)

Gut feeling says a plugin for this particular use case might be overkill, specially since we already have dynamic config. But MAYBE having a plugin system for dynamic config itself, where different methods of obtaining said config can be used?

[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.