Over the last years we have been migrating our user experiences away from the server side, to micro-frontends based on the React framework. This has allowed us to iterate faster on user experiences and deliver value faster. However, our frontend stack doesn’t provide the same facilities that we have on the backend for extending and customizing the base platform installation. For example, on the backend we now have events and filters and Open edX plugins. Furthermore, XBlock has been available for customizing course content for many years.
I believe that the need for pluggability on the frontend has now become urgent. There have been a number of recent pull requests that have committed features that are specific to a particular user of the platform, rather than general and valuable to the entire community. And while other PRs have pushed the pluggability story forward, without architectural direction and community buy-in these tend to solve for a limited set of use cases, all the while adding to the burden of maintenance and documentation.
We need to be able to support customization of the platform frontends, in support of the needs of independent users, without altering the shared foundation. Unfortunately, we do not currently have a strong, agreed to proposal for moving forward.
Furthermore, I would argue that we need customization to be possible without forking repositories. Doing so is bad for the team forking and the community as contributing back becomes harder. At the very least, we need to minimize forking and enable easy upgrades. We want an approach that minimizes effort to port customizations into future releases.
I’d like to propose a Frontend Pluggability Summit to help us converge on a specific architectural approach to support user specific extension and customization of the Open edX platforms frontend views.
I propose that we do the following before, during and after the summit.
In advance, asynchronously:
- Discuss and catalog the requirements for frontend pluggability in this thread
- Capture any prior art either from the Open edX project or other platforms
- Propose high level approaches and build teams around them to create a high level approach document. This is really like an asynchronous design hackathon, pitch an idea, build a team, produce an artifact.
- Publish and review the proposed approaches
At the summit, synchronously:
- Spend some time reviewing and discussing the requirements.
- Review and discuss proposals that are on the table
- Discuss the pros and cons of all approaches as a group over the course of several synchronous hours
- Converge on a plan that will become an ADR or OEP documenting the approach
- Develop a specific plan to deliver this capability where all stakeholders contribute to completing the work.
After the meeting, asynchronously:
- Do the work to publish the architectural decision
- Do a technical spike/POC to validate the selected technical approach
- Groom the required work, determine who will do which parts, execute and ship it.
I have created a meeting poll to determine the time to meet that works best for interested parties. I am proposing a three hour meeting – with pre-work – so we can make as much progress as possible. Ideally, we would agree on the high-level approach during the workshop. In any event, we would conclude with an agreed set of next steps with owners for each.
There are some existing PRs that should be considered as part of the requirements for what we design and deliver. I’m including them here as a reference and start to the requirements gathering effort.
- Recommendations v2 by zainab-amir · Pull Request #1040 · openedx/frontend-app-authn · GitHub
- Install Xpert chatbot from frontend-lib-learning-assistant. by MichaelRoytman · Pull Request #1166 · openedx/frontend-app-learning · GitHub
- Related problem, different spin
- docs: add an ADR for footer links by Cup0fCoffee · Pull Request #326 · openedx/frontend-component-footer · GitHub