Cale: It’s pretty uncommon for devs to run tests in edx-platform locally, unless they’re adding new tests. So, they end up shipping it off to CI.
who-tests-what could be helpful here.
Cale: What he sees slowing down devs is the sheer conceptual weight of LMS
It’d be good to separate tricky stuff (xmodule, etc) from day-to-day Django REST-endpoint-esque things
Cale: If we were to extract everything required to render xblocks into its own plugin, how could we do that?
Dave: The runtime services are pretty tightly coupled with edx-platform
The purpose of this would be to stop normal, dumb LMS Django code from querying the modulestore, or doing other hairy things that slow the site down.
Dave: The direction we want to go is keeping using of the modulestore within certain specific contexts where we can make guarantees about its performance impact. In other places, we want to stick to read-optimized versions of the data.