Hi all,
I’m (re)starting to work on a plugin capability for MFEs and wanted to share some background on the work and my current (relatively modest!) plans in the interest of visibility and working in public. I want to make sure that these capabilities are solving broadly applicable problems.
Background, Late 2021/Early 2022
About a year and a half ago, my work at edX was focused on what we were calling “experience plugins” - i.e., the ability to load content from another MFE or external site into a micro-frontend either via an iframe or module federation.
Before the edX acquisition and the formation of Axim (after which we all had a lot of other more pressing work to do!), I pulled together an OEP draft and a PR:
The OEP is intended to govern the architectural approach, security concerns, and need for a plugin/parent contract. The PR is a functioning implementation of iframe-based plugins, allowing an MFE to configure and load a URL at a pre-defined “slot” in the page.
Background, Present
Recently I was also able to pull together a pre-requisite/companion PR around improving our MFE configuration capabilities:
It has become evident that edX/2U would benefit from this work, as we’re finding we have need to embed marketing/product/ecommerce functionality into the platform’s MFEs. Back in the day, I didn’t think I had use cases. Now I do. 
I’d like to avoid a situation where folks can’t find any way to do their work except to suggest checking unrelated code from a different domain into MFEs.
Usage Pattern Overview
Broadly, the intention is that micro-frontends can define areas of the page that can accept a plugin. They do this by including a PluginSlot react component. They will document the required configuration, API contract (props and events provided), and dimensions of the slots that they provide. Plugin authors can reference that documentation when building a plugin appropriate for a given slot. MFEs will have a new portion of their configuration document (where you get LMS_BASE_URL and all that from) used to configure plugins. This should be compatible with runtime configuration (tmfe_config_api) for iframe-based plugins. On page load, the MFE will load an iframe and establish communication between the child page (plugin) and the parent according to the API contract.
A second phase will also allow us to configure build-time plugins. Build-time plugins are more performant (no iframe or child HTML document, just a react component), but are not secure, and require rebuilding the MFE. This is more appropriate for platform customization than embedding third-party plugins. With the right slots, it would let folks extensively modify MFEs without forking the code, all with pre-established API contracts for the plugins/app to communicate along.
This second phase relies on the JavaScript config file work mentioned above.
What’s on the roadmap?
I see the following roadmap project board issues related to this (both from axim-engineering):
- Micro-frontend Plugins
- To overwrite components, users should be able to fill pre-defined locations (“slots”) in the user interface with their own content.
- Explore and define alternative approaches to MFE plugins and tradeoffs
In the context of the Modular Micro-frontends work, I’m hopeful that this is a complementary effort, or at least one that can converge with that effort in the future (we’re talkin’ about it!)
Current Plans
My intention is to get the two above PRs ready for review and merging. I’m not aware of any other prior art or specific requirements in this space, but am happy to try to incorporate that into the plan if it emerges. I also still believe it’d be helpful to have an OEP to describe our approach to this plugin interface, what each type is for, and maybe how it relates to modular MFEs.
I’ll stop there for now, but wanted to open the floor for more input. Thanks for reading.