Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Frontend Plugin Framework. A framework that allows dynamic configuration and injection of custom widgets onto web frontend experiences. These frontend customizations are configured by users (e.g., course teams) without the need for operational changes to the platform instance (i.e., no backend installations or updates are required). Possibly implemented in relation to LTI. (4 dev2 squad-month)

  • Frontend Replatforming Completion. The edX architecture team developed the infrastructure and runways to separate the frontend from the complex core in modern frontend technology (our React-based micro-frontend re-platforming effort). While we rewrote a few existing pages to this new model, to feel the full impact of this effort, we need to complete the re-platforming effort and remove the old frontend technologies from the core. (300 dev-month?)

  • months)

  • Platform Frontend API Framework. An API abstraction layer externally exposed from the monolith platform that enables more rapid frontend development of platform features. Possibly implemented using GraphQL. (4 dev2 squad-monthmonths)

  • Platform Backend API Framework. API abstraction layers (in Python) internally within the monolith that enable sustainable maintenance of Backend Plugins. (4 dev2 squad-monthmonths)

  • (Real-time) Eventing API Framework. Standardized event-driven APIs that provide learning events to permitted external services as described in OEP-26. (6 dev3 squad-monthmonths)

  • Data Reporting API Framework. API abstraction layers externally exposed from data-marts (downstream of a data warehouse) that provide domain-based data. For example, data about users, courses, and enrollments. These may be in the form of batch asynchronous reports. (4 dev2 squad-monthmonths)

  • xBlock v2 Framework. Redesigning and updating the xBlock framework so it is further advanced to the latest technological trends in frontend development and supports offline mobile use cases. Possibly implemented based on learnings from the Frontend Plugin Framework implementation. (4 squad-months)

  • Frontend Replatforming Completion.(12 dev-month The edX architecture team developed the infrastructure and runways to separate the frontend from the complex core in modern frontend technology (our React-based micro-frontend re-platforming effort). While we rewrote a few existing pages to this new model, to feel the full impact of this effort, we need to complete the re-platforming effort and remove the old frontend technologies from the core. (3 squad-years?)

Specific API enhancements:

  • Catalog Integration API. Support the pluggability of different marketing catalog implementations so the platform’s discovery service can be readily used by other Open edX instances. (2 dev1 squad-month)

  • Course Blocks API. Make this API further extensible so updates (supporting additional block transformers and additional fields) do not require modifications to the core platform. (2 devsquad-weeks)

Development Standardization & Efficiency

...

  • Toggles. Improve feature toggle sustainability and discoverability by annotating our toggles and implementing automated reporting as described in OEP-17. (2 dev1 squad-month)

  • Platform Direction. Direct the future state of the platform by documenting (in the form of ADRs) and aligning on technical decisions of how the platform should be (its structure, tests, APIs, etc). (2 dev1 squad-month)

  • API Practices. Improve the speed of API creation and usage by aligning on API standards and technologies. (4 dev1 squad-month)

  • Inter-service Communications. Provide guidelines for communicating between micro-services and synchronizing data across services. Possibly introduce an eventing architecture, such as Kafka. (3 dev2 squad-monthmonths)

  • Authentication. Improve speed of API creation and usage by providing a consistent JWT+OAuth authentication framework across all of our microservices, with updates to all Django middlewares and Django APIs. (3 dev1 squad-month)

  • Authorization. Improve performance of permission checking and developer speed of permission management by implementing the Permissions ADR and updating has_access calls in this sheet. (4 dev2 squad-monthmonths)

Delightful Developer Experience & Efficiency

...

  • Tests. Improve the testing experience so testing doesn’t take ¾ of developer time. (? dev-month)

  • Devstack. Improve the speed of local development by decomposing the current implementation into distributed subdomains using Docker orchestration technology. (2 dev1 squad-month)

  • Documentation. Improve onboarding documentation, including architecture onboarding, feature how-tos, etc. (1 dev3 squad-month weeks + ongoing)