...
- Pagination tuning. The default page size of 20 will result in an unnecessary large number calls to the Catalog API since production currently has over 3200 courses in the CourseOverview table. Will need to determine a good approach to find the ideal value. Making the page size dynamically configurable (e.g., via django admin) will help with tweaking this number. (Note that ECOM-6834 will allow the page size to be changed dynamically, per-request.)
- CCX courses. It's unclear whether the Catalog service's course-marketing URL API will return the correct value for CCX courses. If it doesn't, the management command will have to explicitly get the parent course of each CCX course before sending the request to the API. Handling CCX courses can be implemented as an iterative change and need not be included as part of the initial rollout of this change, but should be handled.
- Course overview invalidation. As currently implemented, a course's entry in the course-overview table is immediately deleted upon course publish. This was fine until now since there was only a single source for the cache: the modulestore. But by introducing another source of data (Catalog service), this logic should be revisited. When the entry is deleted and re-created, any previously synchronized data from the catalog service will automatically get wiped out - and will be re-populated only when the background synchronization process is next run. A few solutions to this would be: (1) no longer delete upon course publish - only update, or (2) make a blocking call (with graceful degradation) to the Catalog service to populate the CMU when the entry is re-created. The issue with option 2 (currently) is that this sometimes happens in a user-facing web-worker process.
- Inter-team dependencies. An early conversation and support with an edx/devOps member and ECOM is recommended to help this project go faster.
- Pagination bug (fix in progress). Currently, the LMS has not done a bulk query of the Catalog service in production. We found a pagination issue in our previous attempt at this feature, that is now being fixed by ECOM.
- Mobile enrollment-list API performance (orthogonal bug created). In writing this document, I noticed that the Mobile enrollment-list API is currently not making bulk SQL queries where it should. So the expected SLA of under 2-seconds is not being met (NewRelic link). However, this is an orthogonal issue and should be fixed separately.
...