Goal: to simplify our codebase, operations, and deployment by combining the CMS and LMS into a single headless REST API server.
Background: Proposal: Combined Headless LMS+CMS
Tentative steps (these should be converted to sub-issues):
- Create and merge an ADR for this.
- Either migrate our course content to
openedx-core (talk, slides, code) or convert the modulestore APIs to be more explicit about draft vs. published (so that calls like modulestore().get_item() become published_modulestore().get_item() or modulestore().get_published_item(), etc.).
Hopefully we can just go with the first option, and the modulestore APIs can become a legacy read-only/published-only API without many changes.
- URL by URL in the CMS URLconf, add the URL to the LMS URLconf; test the behavior and address issues until they are returning identical responses whether accessed via LMS or CMS domain. Then remove it from the CMS URLconf and replace it with a redirect or a proxy.
- Same thing for management commands.
- Eventually the CMS is just a redirect/proxy service and doesn’t even need to be a django app anymore, and can be replaced with some nginx forwarding rules or something like that.
Goal: to simplify our codebase, operations, and deployment by combining the CMS and LMS into a single headless REST API server.
Background: Proposal: Combined Headless LMS+CMS
Tentative steps (these should be converted to sub-issues):
openedx-core(talk, slides, code) or convert the modulestore APIs to be more explicit about draft vs. published (so that calls likemodulestore().get_item()becomepublished_modulestore().get_item()ormodulestore().get_published_item(), etc.).Hopefully we can just go with the first option, and the modulestore APIs can become a legacy read-only/published-only API without many changes.