There are currently a series of gaps in our understanding of how the Open edX community uses, or intends to use, micro-frontends (henceforth, “MFEs”). While most seem to be in agreement that the current state of the MFEs in the platform, as compared to the current state of the edx-platform monolith, in theory allows Open edX to be improved more productively, it is clear that before proceeding with any further improvements one needs to find out:
If the proposed benefits of this architecture are outweighing, and will continue to outweigh, the cost of implementation;
What those costs actually are;
If the costs are hindering adoption, what can be done to reduce it.
The method of investigation to gauge answers to the above will be via polling community members via forum, chat, or in-person. The identity of the pollees will not be disclosed, so the focus remains on the actual findings.
https://github.com/openedx/tcril-engineering/issues/146
From the interviews of community members it became clear that, with very few exceptions:
As MFEs stand, the benefits of the architecture do not outweigh the costs;
These costs are hindering adoption significantly: in many instances, production deployment of micro-frontends is being pushed back until they can be improved.
With that in mind, what follows is a list of pain points that were named as blockers to general adoption. They are categorized by architectural area and are listed in descending order of occurrence in the interviews (the ones with more mentions are at the top):
Adherence to deprecation standards: in at least one case, a new MFE has replaced a pre-existing IDA without porting commonly used features. This has to be avoided in the future.
Incompatibility with comprehensive theming: The MFE theming and branding methods are not compatible with comprehensive theming. “It was something that we all kind of agreed on and now we are completely ignoring it.”
Yet another theming method that doesn’t fully replace the existing ones: Prior to MFEs, there were multiple theming methods that needed to be used if an Open edX LMS instance were to be totally themed. With MFEs, there is now not only one more method that also needs to be tackled: because MFEs are potentially different, each MFE would required a different one.
Applying theme changes require a full container rebuild: theme changes occur often enough and for enough instances that for many Open edX providers, this can become cost-prohibitive in terms of CPU time. (In one specific case: “1000 hours of compute time in an m5.large machine for building all of them”).
Multi-tenancy is not possible at scale due to the above theming concerns: this was explicitly named as a blocker that stopped upgrades from Koa to Lilac, and from Lilac no Maple.
Bundle size: because each MFE is built completely separately, the LMS user has to download multiple bundles. Bundles may contain different versions of React, for example, causing the user to have to download duplicate data. Furthermore, the more MFEs are built, the less efficient this setup becomes.
Cohesion: MFE authors are currently free to design UX as they see fit. Even with the use of Paragon components as building blocks, this can potentially still lead to a lack of consistency between pages.
Build-time configuration is expensive: having to rebuild containers with every configuration change is very expensive; possibly even more so than with theming changes.
Multi-tenancy is not possible at scale due to the cost of reconfiguration: for the same reason as theming, if every reconfiguration of an MFE - or multiple MFEs - require a full rebuild, multi-tenancy becomes cost-prohibitive at scale.
Lack of documentation: this has always been an issue with edx-platform, but it has unfortunately not been fixed with MFEs: a sysadmin needs to read the code to find out how many features work, or what particular configuration settings actually do.
Lack of consistent documentation: some MFEs are better documented than others. This makes it very difficult to streamline an upgrade pipeline, for example: one can never rely on documentation to be up-to-date on a new MFE.
What MFEs are out there and what do the do? There is a distinct lack of central, official documentation on what MFEs exist, what purpose they serve, and on the ones that are in active development, what state of completion they’re in.
Overwriting components: currently, one has to rely on either forking or module aliasing to achieve some form of extensibility, but this is clunky at best.
A plugin API is missing: edx-platform already has plugins, and it has made development much better. Some form of extensibility architecture should be created so that MFEs can be modified or improved without the necessity to fork them.
Total complexity is now greater: instead of one complex monolith, we now have several less-complex projects in addition to the big one we started with. Plus, while less complex individually, MFEs are collectively harder to work with.
Our MFEs are not “true” micro-frontends: a more common architecture would be to build a mono-framework that, with module federation, still gives the development flexibility we see now, but more tight integration with the overall platform.
Outdated react-intl: the fact a very outdated version of react-intl is being used across the board makes it hard to implement i18n practically for consumers of frontend-platform and Paragon components.
Redux is far too complex for individual MFEs: the use of Redux is encouraged via frontend-platform, but given the size of most MFEs, it is likely overkill.
Further community feedback on the following would be great:
Is there anything missing from the findings?
Does the stated priority reflect the needs of the community?
What can we do to solve the individual issues?