XBlocks can declare CSS and JS resources. These assets do not use the CDN and are not cached. Because these assets have to change immediately on deploying new code, we can't take the content approach and assume a 1 hour cache life is good enough (or we might end up with broken deploys).
We have to run properly in a mixed deployment mode where some servers have old code and some servers have new, implying different URLs for different versions of the XBlock assets.
We need to work correctly in devstack environments, where nginx is not involved.
We have some freedom to change where these URLs get loaded from, since the runtime is the thing generating the links on demand.
There are very broadly two paths that come to mind:
1. Keep it inside the Django app at runtime and use mechanisms similar to the contentserver to manipulate headers. Might get awkward for running multiple versions at once.
2. Plug it into the current static collection phase, and rely on nginx to serve it. We could potentially get some things "for free" in this scenario, but we have to accommodate the devstack use case as well. Maybe make custom static file finder to plug into XBlocks?
Acceptance criteria: A set of estimated stories necessary to implement.
After chatting with Andy, there was an existing Hackathon project to incorporate XBlocks into the asset pipeline. After reviving the PR, it seems to mostly pass all of the tests. Since this appears to be a very viable route to take, I'm going to pursue using the existing PR.
Work will be happening in PERF-303.