Extract non-Core apps into Hooks-based platform plugins

[awais786]

This ticket is about refactoring non-core applications in the Open edX platform by converting them into hooks-based plugins. All details available in the oep. Instead of keeping all functionality tightly coupled within the core platform, certain apps/modules should be extracted into standalone plugins that integrate with the system using Open edX’s plugin framework. Following are some suitable candidates.

Goals

• Improve modularity by moving non-essential apps out of the core codebase.
• Utilize hooks-based plugins for seamless extension and integration.
• Reduce technical debt by isolating features that don’t belong in the core platform.

Technical Approach

• Implement appropriate entry points to ensure smooth interaction between the core platform and the extracted plugins.

Potenial apps

1. ora_staff_grader
2. program_enrollment
3. survey
4. zendesk_proxy
5. lang_pref
6. password_policy
7. geoinfo
8. ace_common

[awais786]

@kdmccormick Do the above small Django apps (located in openedx/core/djangoapps/) align with the Hook-Based Plugins initiative in Open edX?

Given their size and scope, would they be suitable for conversion into hook-based plugins ?

[awais786]

I am working on survey app.

[ormsbee]

I'd like to better understand the end goal of this. Is the idea that these would be converted to being hooks-based while staying in edx-platform? Be moved out into a common repo? Separate repos?

[awais786]

The primary objective is to extract them from edx-platform and migrate them to a new repository as hook base plugin. Please let me know if you have any further questions or suggestions.

[kdmccormick]

@awais786 Sorry for not getting back to you. survey seems like a great app to start with, and your approach of extracting into a separate repo sounds right to me.

[ormsbee]

The survey app was built in edx-platform at least partially because it calls into a bunch of things that are not part of any stable APIs or plugin interfaces. I'm worried that we will lift some of these apps out with those functional dependencies in place. If we do that and we're not deprecating them, then we're just making maintenance harder because it will be more difficult to detect regressions and to maintain more repos through upgrade cycles.

There are some things here that could come out easily, like geoinfo and maybe zendesk_proxy (though we should probably see if we can just DEPR Zendesk, because edX built it and I don't think they run it any longer).

[feanil]

@ormsbee can you provide some more context on your thought about the geoinfo app? I agree that it's pretty standalone but if it's still being used, I'm not sure it makes sense to extract it since as you said it just increases the maintenance burden. Perhaps we need to build out a list of apps that we want to deprecate and target extraction of those rather than of items we want to keep?