...
With the onset of the LMS courseware MFE effort, it’s become more apparent than ever that edX is we are serious about rewriting its frontends, and not just the ones that are edX.org-specific. In the medium-term future, Open edX operators will need to be able to deploy MFEs.
Furthermore, MFE development seems to be a great opportunity for Open edX developers who are interested in customizing the experience that they offer their learners.
Despite this, it As time goes on, we will need to done one of the following:
Continue to support all non-edX.org-specific Django frontends for Open edX instances.
Deprecate significant portions of Open edX frontend without any official alternative implementation, leaving it up to the Open edX community to figure out how to either run our MFEs or develop their own.
Officially make Microfrontends part of Open edX
Option #1 seems like a lose-lose situation for both Open edX and edX.org. The Open edX community would be excluded from all the frontend innovations and UX imporvements that we make the in the future, and we (edX.org developers) would not be able to remove the large swaths of Django frontend code that we had hoped to deprecate as part of the frontend replatforming.
Option #2 strikes me as a betrayal of trust to the Open edX community that would be against our mission of improving access to high-quality education.
Given that, it is clear that we should pursue Option #3.
Can Open edX developers use MFEs now?
Yes and no.
YES, the …
NO, …
Will this affect edX.org developers?
Ideally, yes, and positively!
As mentioned earlier, if we make it easy for Open edX devs to use our MFEs, then we can feel better about deciding to delete thousands and thousands of lines of Django frontend code from edx-platform and empower ourselves to decompose the monolith.
Furthermore,