Abstract

We are not currently providing Open edX developers and operators a clear path towards writing, building, and/or deploying edX Microfrontends. As edX.org continues to drive forward its frontend replatforming, this will increasingly become an issue for both the Open edX community and for edX.org itself.

We should address this by:

• Writing and sharing documentation for the open-source portion of our MFE build+deploy pipeline.

• Planning to include at least one microfrontend in Koa (or even Juniper, if possible).

• Settling on a development environment strategy for microfrontends.

• …

Context

What are Microfrontends?

edX is in the midst of a front-end replatforming. The Architecture Team has lead an effort to give us the tools to rapidly build, test, and deploy React.js-based, REST-API-powered frontend apps, a.k.a. “Microfrontends” (MFEs). The eventual goal is to replace all of our existing “Django” front-ends (which are generated by Django/Mako templates and generally use Backbone.js as a front-end framework) with MFEs.

https://github.com/edx/frontend-platform and https://github.com/edx/frontend-build are the two NPM packages upon which most of our MFEs are built (there exist other libraries we use, such as the https://github.com/edx/paragon accessible component library, but all of those are transitively required by @edx/frontend-platform or @edx/frontend-build). Examples of production MFEs are https://publisher.edx.org/, https://profile.edx.org, and https://account.edx.org, all of which replaced Django front-ends. An example of a major Django front-end which we are currently rewriting as an MFE is https://github.com/edx/frontend-app-learning , i.e. the LMS courseware experience.

Why are we doing them?

MFEs give us many advantages. I won’t enumerate them all here, but the ones that are most apparent to me personally are:

• Testing an MFE is easy: just mock the REST API. No need to run costly acceptance tests a la Bok Choy.

• It’s harder to create a tangled mess of frontend/backend logic when you are forced to pipe everything through a REST API.

• One can open a PR, have tests build, and deploy to prod in well under an hour with MFEs. That same process can take over a day with edx-platform.

• Refactoring the backend is much easier when frontend logic is separate. When Django frontends are deprecated, there may be hope to decomposing the edX monolith.

• React.js has a much larger and more active developer community than Backbone.js does.

How does this relate to Open edX?

With the onset of the LMS courseware MFE effort, it’s become more apparent than ever that edX is 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