-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Micro-frontend Plugins #27
Comments
Unassigning myself until such time I or somebody else gets back to this. |
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! |
@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. |
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. |
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? |
Just ran into another plugin case, to add to our salad: |
Slots that enable various use cases:
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. |
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. |
All of this sounds great to me. Looking forward to helping develop this further! |
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. |
Is this proposal ready for product review? |
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. |
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:
Related Repositories
Related PRs
OEPs
Implementations
The text was updated successfully, but these errors were encountered: