With many development projects ongoing at OpenCraft we feel it would be helpful to have a way to publicly discuss any potential areas where the work across different projects can overlap, so we can not only avoid duplication, or conflicts.
As we work on these projects we’ll aim to share the major architectural directions or potential sources of conflict here so that they can be resolved in public. Hopefully, developers outside of OpenCraft or edX will also find this useful, especially if it overlaps with other ongoing work.
A recap of discussions that necessitated the original discussion and the creation of this thread:
As part of making discussion pluggable we need support for embedding LTI components outside of the xblock-lti-consumer. xblock-lti-consumer also has a work going on to add support for LTI 1.3 in addition to 1.1
So we coordinated around this to make sure we had a unified API for working with and embedding both.
For the Libraries V2 UI, TypeScript is being used on an experimental basis.
Emphasis should be placed when developing all new MFEs to make them themable.
A new document is being maintained that lists all extension points in edx-platform. Any PR adding a new extension point should also include an update to this document.
There are multiple parallel streams of work going on ORA, so it will be important to ensure no conflicts arise there.
An update on this point: due to time constraints, Typescript was pushed back. Making it truly useful will require typing not only the MFE itself, but at the very least paragon and frontend-platform. And we simply haven’t had the resources to do that, yet.
On making MFE’s themable: are any of them actually themable, yet? Can we point to any examples of how to do this, even if just a WIP? The relevant section of the guide you link to is less a guide, and more a statement of intent. Which is all to say, I have not given any attention to making the Libraries V2 MFE themable at all - I’m having enough of a hard time porting the Studio CSS to it.
@xitij2000@Agrendalath@marcotuts I think I’ve found a few conflict points in the currently ongoing projects (Instructor Dashboard MFE rewrite (BD-12) and the ORA Improvements (BD-05) epics touch overlapping points in the codebase).
We’ve planned to rewrite the Open Assesments tab in the instructor dashboard entirely in React, but there are a few challenges:
As opposed to Studio (with studio-frontend integration), the LMS doesn’t have a well defined React embedding development flow (there’s only 2 paths available: embedding small components into the bundle using renderReact or create an entire new MFE).
My plan is to kickstart a separate React repo to rewrite the ORA tab, and then integrate it with the new MFE once it’s ready (so it’s partially blocked by BD-12).
The main issue with this is that the old instructor dashboard will not have the new features unless we come up with some form of embedding (I’m using an iframe embed so far for development, but we can look for a solution like studio-frontend).
How should we go about this @Agrendalath? Can I go ahead with creating a separate repo for a provisional rework while the Instructor Dashboard is being worked on?
Or should we aim to implement something like studio-frontend?
@djoy Since you’re working a lot on these new MFEs, can you comment on this too?
There’s no supported deployment method for any MFE, meaning that these changes will only be supported on edX.org, and everyone will need to build it’s own deployment mechanism (making Open edX harder to support due to code fragmentation).
For Open edX instances, we have edx/configuration as deployment mechanism and reference, so maybe we can extend it and add support to deploy the MFEs (though it’s not the ideal deployment method for this kind of application).
Ideally, the supported mechanism should deploy to something like AWS S3 + CloudFormation (or similar services in other cloud providers) through Terraform and have some scripts to allow rebuilding and updating assets.
Are there any proposals on this?
I know that there were previous discussions about having a reference deployment on this OEP, to serve as a recommended and supported way of hosting Open edX Instances (and replace edx/configuration).
With ramp up in the MFE work, the lack of a deployment method will gate a lot of new functionality in the platform and should ideally land on the next named release (Koa).
That sounds reasonable if we assume that we will have a way to deploy MFEs with Open edX in Koa (the second part of your post). If we won’t, we are not going to have any backwards compatibility in Open edX instances for this tab.
@marcotuts, @djoy, should we actually merge it into the Instructor Dashboard later or keep it as a separate MFE?
If the former, would it make sense to increase the priority of BD-12 to at least create a skeleton version of the Instructor Dashboard to have this functionality in the correct place?
I mentioned this on the internal ticket, but I feel it might be good to post here as well. If crafted in a way to account for this it should be possible to create a UI that is wrapped in an MFE, but also available to embed in the platform.
The way this could be done is to install the entire MFE as an npm package in edx-platform, and then simply import and use the bits of the UI needed in edx-platform. This can bridge the gap between a proper MFE and an embedded UI.
There’s a lot here across a bunch of initiatives and I don’t have 100% context on them all, so just to repeat it back to make sure I’m parsing all this correctly:
My understanding is that we want to replace the Open Assessments tab on the instructor dashboard with a micro-frontend/modern approach. We expect that the instructor dashboard will be re-written at some point soon, so it stands to reason we’d want to have this tab available in that MFE. That said we also need to ensure the updated tab is available in the LMS for backwards compatibility. This backwards compatibility is especially necessary since we lack a well-defined deployment story for MFEs in Open edX.
We’ve painted ourselves into a bit of a corner. I’m not sure of the implications of trying to embed an MFE in an existing LMS page, especially in terms of its build process/EcmaScript versions, etc. We can certainly do - temporarily at least - what @xitij2000 mentions below around making it npm package, but it might be a bit difficult. We haven’t tried embedding some of our modern code into the LMS in that way. Nor is working out the details of that hybrid build process very rewarding, since we expect to deprecate the LMS pages anyway.
I think creating a new repository for this is the right path forward, certainly in the short term. With that new repository, we can publish the contents as an npm package for consumption in the MFE instructor dashboard when it’s ready, and it also gives us some options for how we embed it in the existing experience, if we decide we need to do that. @marcotuts, I’m curious on your take on supporting this new work in the old experience, and how that dovetails with MFE deployments for Open edX. I don’t have an answer around the deployments, much to my chagrin.
If we say 1) yes we need to support it in the old instructor dash, and 2) no we don’t yet have an MFE deployment story for Open edX, then we’re going to have to do some throw-away work around how we actually embed this thing.
The question about whether it gets merged into the instructor dash MFE down the line is something I think we can defer for a bit - if we think it’s a plugin, like so many other things, then it gets caught up in that discussion.
I think for any code that we would like to embed in both an MFE and in the LMS we can make sure to keep compatible versions of react and other libraries, so the MFE components can be imported like they would be from any other third party component.
Hmm, in the existing instructor dashboard, would that use the top-level edx-platform package.json? If so, we have react version 16.1.2 there, whereas many MFEs are around 16.12.0.
While I think the two are technically compatible as there weren’t any breaking changes in there - there have been a number of commonly used features in between those releases. (Such as react hooks, as a big one, and a bunch of changes to the context API). Development might be a bit fraught with potential issues if we develop against the later version then try to run it in the older one. Worse, most developers (myself included) aren’t going to be aware of which features are valid in 16.1.2 and which aren’t supported, and it’s not really a reasonable expectation that they can keep that in mind as they work.
Updating edx-platform to the latest is one option, though it’ll likely cause a slew of deprecation warnings to start being emitted. I don’t think we’d want to develop the tab against a version from a few years ago… similarly, pulling such an old component into a newer MFE will probably result in a bunch of deprecation warnings as well.
(Not much in the way of answers in this post, but just adding color to why this may be difficult)
In this case my suggestion is that MFEs that need to also be embeddable in studio should use the version of React that studio uses. All others can use the latest release. However, upgrading edx-platform to the same release is probably a better idea, given that hooks are now the predominant mechanism we’re using in MFEs now and developing the old-style way and then refactoring later (or not) sounds like more work. I forget that they were added in a 16.8 and not in 16.
It definitely is a pickle! Though I do favour upgrading edx-platform and seeing how that goes. It might not be that much work. There is very little react code in edx-platform, although I guess the bigger issues is that most of it doesn’t have tests, so finding breakages will be harder.
Any solution will require some development work, such as:
Using different versions of React for different components in edx-platform and isolating them in iframes, and sharing code between edx-platform and MFEs.
Upgrade edx-platform to React 16.8+ and importing that in edx-platform
Use React 16.1 in MFE and importing that in edx-platform
I think the last option seems like the lowest work overall, the first might be too much work and the second is a happy middle.
I think upgrading edx-platform would probably be my preference - as you said, there’s not too much react in there to begin with.
Using react 16.1 for a new MFE might actually be pretty limiting. One, developers won’t be sure which features they can use which will just create drag on the project, but perhaps more importantly it means the code likely won’t be able to use Paragon or any of the helpers in frontend-platform, which feels a bit like a non-starter.
I think one of the discussions is kinda resolved: the decision is to upgrade React in the platform to allow using the latest paragon components. @djoy Is this something that can be done by the TNL team? I don’t think I have excess budget on the ORA epic to do the upgrade.
As for the ORA instructor dashboard rewrite there are these possible solutions:
Do the ORA rework in the LMS, introduce some code that might end up being deprecated soon (react on edx-platform) and has a lot of complexities to deal with (packaging and compiling react into the static pipeline from a plugin).
Also, edx-platform is using paragon here, but I haven’t checked if this is an older pinned version.
Create a separate MFE, so the changes will only be available to edX.org until we have a proper deployment method for the frontends. Also, we need to work on the instructor dashboard work to place the ORA tabs and components there.
I’m leaning towards option #1 since it allows us to move the work forward while still reducing some rework from the MFE migration (containers and components will use React and can be moved to the MFE when it lands).
