OEP-65: Composable Micro-frontends

[davidjoy]

This PR is a replacement for #410 based on an updated architectural approach. We expect to use module federation instead of adopting a framework like Piral.

@arbrandes and I agreed we should create this PR and close #410 so we can start with a bit of a clean slate after the lengthy conversation on that one. Some of the comments over there are definitely still applicable; if you feel a point got lost and hasn't been taken into consideration in this version of the OEP, feel free to comment again.

Running changelog based on PR feedback:

2024-05-03

• After some discussion, we agreed that the ‘passthrough library’ idea is too experimental/unknown to add to the OEP. Instead, we’ve described the goals of reorganizing our code and suggested that we add a specific approach as an ADR on this OEP on it becomes more clear. See @sarina's comment here: https://github.com/openedx/open-edx-proposals/pull/575#discussion_r1589575484
• RST formatting changes.
• Simplified language here and there.
• Removing language around “today” and “current”, which will not age well for folks reading this OEP in the future.
• Making Specification section easier to follow with better headers, and a more “oomphy”/active voice introduction.
• Simplifying the shared dependency table, since most didn’t have “notes” anyway.
• Adding links and references throughout.
• Adding diagram “alt” text description and link to LucidChart source.
• Removing the “Appendix” on how Module Federation works - the Specification and Reference Implementation sections cover it.
• Removing secondary concerns around central data store and eventing - we seem to be in agreement that those are not concerns that we expect to have, so they feel superfluous for the OEP.

2024-05-01

• Added table of contents.
• Editing for clarity throughout.
• Linking out to Open edX repositories and dropping the organization prefix from their names.

2024-04-22

• Clarifying the "Motivation" section to talk about how our MFEs are more like single-page apps than true micro-frontends.
• Review feedback: correct package names around @edx/@openedx npm orgs and some punctuation fixes.

2024-04-12

• Updates the OEP-65 status from "Draft" to "Under Review" and set a 2-week review period from April 15, 2024 - April 29, 2024.

2024-04-10

• Adding references to the discovery projects for this OEP: FC-0054 and FC-0007.
• Adding a diagram of the proposed MFE architecture.

2024-04-09

• Rewriting and clarifying the Specification section. Simplifying language around Webpack module federation and adding a variety of links out to external resources.
• Adding specific recommendations for Maintaining Dependency Consistency. Also adding it to the Rationale.
• Rewriting the section on why "build time" and "dependency maintenance" aren't improved by adding shared dependencies.
• Adding monorepos to the Rejected Alternatives section.
• Adding a sub-section on Proposed MFE Architecture to the Reference Implementation section.
• Adding a link to the Upgrade Project Runbook.

2024-04-04

• Pull request #575 <https://github.com/openedx/open-edx-proposals/pull/575>_
• Adding an arbiter.
• Light editing for punctuation and clarity
• Adding another use case for composability.
• Adding build-time package overrides as a composability option.
• Adding more details to the reference implementation section.

2024-04-03

• Document created

[openedx-webhooks]

Thanks for the pull request, @davidjoy! Please note that it may take us up to several weeks or months to complete a review and merge your PR.

Feel free to add as much of the following information to the ticket as you can:

• supporting documentation
• Open edX discussion forum threads
• timeline information ("this must be merged by XX date", and why that is)
• partner information ("this is a course on edx.org")
• any other information that can help Product understand the context for the PR

All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here.

Please let us know once your PR is ready for our review and all tests are green.

[davidjoy]

Hi all - I've done another pass on the OEP. Please see the changelog at the bottom of the document for details. The rewrite of a few of the sections that needed the most work has wiped the comments above from the diff.

[bradenmacdonald]

@davidjoy @arbrandes and all: I got a simple version of this working in Vite. I haven't yet analyzed the details, but you're welcome to play around with it! So far I only configured it to de-duplicate react and frontend-platform, and it seems to be doing that but more analysis is needed.

In the video, you'll see the shell provides the header and footer, and the profile app is loaded dynamically.

https://github.com/openedx/open-edx-proposals/assets/945577/0252d590-c72e-4f1b-9594-ff56b2699244

Code: https://github.com/open-craft/frontend-app-shell

[davidjoy]

Hi all - I've done another round, editing the document for clarity based on everyone's comments. Easiest way to review the changes may be to just go look at the diff of the last commit; there are little changes all over. Thank you all for the feedback! I think we're getting closer. I've taken the liberty of resolving comments on the PR that I think are now addressed in the document; please feel free to re-open or re-comment if you think something warrants more discussion.

Technically we reached the end of the review period on April 29, but I expect @adamstankiewicz won't object to us taking a little extra time. Do we want to add another week or so? Perhaps until next Wed, 2024-05-08?

[davidjoy]

Another day, another set of revisions. Please see the PR description for changes. To my knowledge I've addressed everything that's been brought up on the PR. Let me know if you don't think that's true. 😛

[bradenmacdonald]

@adamstankiewicz I didn't feel like we finished the conversation you started around Vite vs. webpack

Is there any concern around doubling down on Webpack, given some folks are toying with alternatives such as Vite (for improved build times, etc.)?

I went so far as to build a POC that I think shows many advantages of Vite for this particular endeavour, but the last I heard regarding it was:

We're looking into your PoC, @bradenmacdonald, thanks for that! David and I already had a quick chat about it, but haven't reached a conclusion on whether it's worth pivoting there as part of this work.

If it can achieve the goals of the OEP (including having it be easy to port existing MFEs) with more advantages than disadvantages, I don't see why not, though.

I was hoping for an answer either way before we consider this accepted, or if not then an acknowledgement that there is more investigation needed there.

[davidjoy]

@bradenmacdonald, I feel like the POC you built demonstrates that Vite is definitely faster than Webpack, but as you put in your README comments, it doesn't actually demonstrate an approach akin to module federation that will allow for runtime module loading, shared dependencies, and independent deployment, which are the primary subjects of this OEP.

I think we're all in agreement that there are faster build tools out there than Webpack... we just haven’t proven that any of them have a valid module federation implementation that gives us what we need. It appears there are two module federation implementations for Vite, https://github.com/module-federation/vite and https://github.com/originjs/vite-plugin-federation. It's unclear to me whether those allow for runtime definition of modules or whether the app needs to know all its remotes at build-time. The latter is, I think, insufficient for our use cases.

I’d like to propose that we proceed with merging the OEP as “Provisional”, and would I'd argue that the premise of this OEP is still correct, even if we want to pause and do a little more research on whether the word "Webpack" can/should be replaced with the word "Vite" throughout. I think we should merge as is and update it as necessary. If we can find a compatible/reasonable replacement in Vite or some other, faster bundler, that will be really compelling and a great reason to amend the OEP.

Related to this, though, I think there’s a separate question implicit in the Vite POC about whether maintaining independent deployments for MFEs is something we, as a community, still want to prioritize, or whether the majority of site operators would be better off if we had a simpler architectural model. Module federation is definitely making it more complex, not less in some regards.

I think, long term, we can actually have the best of both architectures. This is a glimpse of a future vision, but by unifying frontend-plugin-framework with module federation, we should be able to allow operators to statically link in MFEs and components at build-time by default, like Braden’s POC, and then override those links with alternative components for customization/extension. These customizations could be loaded at build time, via iframes, or via module federation, all via the plugin framework’s configuration.

So, er, anyway, definitely acknowledge there's more we can do here, but I don't think it's necessarily at odds with the OEP in its current form.

[bradenmacdonald]

Thanks @davidjoy. That sounds good to me, and with that now stated explicitly I'm good with merging this 👍🏻 .

BTW I offered to set up the Vite module federation plugins to demonstrate how they work, but didn't hear back if that would be useful. It sounds like it would be?

[openedx-webhooks]

@davidjoy 🎉 Your pull request was merged! Please take a moment to answer a two question survey so we can improve your experience in the future.

[davidjoy]

BTW I offered to set up the Vite module federation plugins to demonstrate how they work, but didn't hear back if that would be useful. It sounds like it would be?

@bradenmacdonald I missed that offer! Yeah, that'd be great if you have a little time. I got as far as digging around in their code, but couldn't quite tell if they could do what we needed.