Idea: Hybrid lightweight Tutor development environment.

[ARMBouhali]

Background

tutor dev runs the whole stack in development mode, which is slower than production builds.
When all you need to do development on is a single service, worker, or frontend app, this development environment becomes unnecessarily costly in terms of computing and memory usage.

The idea, if possible, is to implement a Tutor mechanism, allowing to do one or all of the following:

1. Run a partial dev environment on top of an existing local/k8s environment: Production containers do not contain dev features, and are thus more lightweight compared to dev services. Using them instead of dev containers reduces cpu & memory footprint.

2. Run a minimal dev environment with only the containers needed to work on: if there was a global openedx feature map (some kind of dependency graph), it would be possible to boot up exactly the required environment to work on a specific feature in a specific project. This feature is very complex to implement, but will be a huge help to both developers and site operators.

Examples:
To work on proctoring in frontend-app-learning, you would need:

• edx-proctoring installed
• cms
• studio
• course-authoring

Tasks

TBD

Notes

Kinda overlaps with openedx/wg-devops#39

[kdmccormick]

I am interested in this particularly for MFEs.

There are 6 MFEs in the Olive release; by Q (Dec 2023), I expect that to have nearly doubled. Do we really want tutor dev start to create 10+ frontend Docker containers, in addition to the ~10 default backend containers?

I wonder what it would take to make it so that MFEs run in production (~tutor local) mode by default, served out of the single mfe container, but with ability to be "switched" over to development mode as needed. Development mode could mean they run in their own container, or it could mean they run directly on the host.

For the sake of illustration:

tutor dev start             # starts databases, lms, cms, etc., plus a single mfe container
tutor mfe develop learning  # switch to 'dev' mode for the Learning MFE
tutor mfe done learning     # switch back to 'local' mode.

cc @bmtcril since we chatted about this once

[kdmccormick]

Sorry, wrong Brian-- @brian-smith-tcril ^

[brian-smith-tcril]

this would be great!
to add an example, if someone were to run:

tutor dev start
tutor mfe develop course-authoring

we would want to set COURSE_AUTHORING_MICROFRONTEND_URL (like we do in openedx-cms-development-settings and openedx-cms-production-settings) to http://localhost:2001/ (we know it's 2001 in frontend-app-course-authoring and in tutor-mfe)

depending on where this is done, it could be possible with

COURSE_AUTHORING_MICROFRONTEND_URL = "http://localhost:{{ MFE_COURSE_AUTHORING_MFE_APP["port"] }}"

i'm not sure if we'd need to do anything with CORS_ORIGIN_WHITELIST/LOGIN_REDIRECT_WHITELIST/CSRF_TRUSTED_ORIGINS like we do in openedx-cms-development-settings but we might.

at this point, the MFE developer could run

git clone https://github.com/openedx/frontend-app-course-authoring.git
cd frontend-app-course-authoring
nvm use
npm install
npm start

and have a local version of the MFE up and running at http://localhost:2001/.

assuming COURSE_AUTHORING_MICROFRONTEND_URL is being used properly everywhere, this should mean that all the MFE dev can happen outside of docker, browser communication with the webpack-dev-server will work without any issues, hot reloading should happen almost instantly, and adding/updating npm packages will work as expected. there will be no need for the MFE dev to think about docker at all

this would really help lower the barrier of entry for MFE dev!

[kdmccormick]

@ARMBouhali , I will keep trying to make openedx/wg-devops#25 happen, but I don't think I can work on this particular issue.

Will you be able to drive it, or should I close it?