4 ms·
How do you even handle SPA updates themselves? Apps may reference static resources (JavaScript, CSS, images) which get updated with a new version. Those resourc
by aaronharnly 7y ago
How do you even handle SPA updates themselves? Apps may reference static resources (JavaScript, CSS, images) which get updated with a new version. Those resources could be clobbered by a deploy, or be uglified, or be versioned. Do you keep the old static resources in place forever, or for a period of time? Or force a reload? Or do you just let clients break and make users reload?
- jrockway 7y agoYeah, the tooling around this is pretty bad. For example, you might release a container that has index.html and main.abc1234.js. index.html has to be parsed before the JS bundle is requested. If you do a release in that intermediate time, the javascript will 404 and your site won't load because in the new container, the only bundle that exists is main.def2345.js. I think people additionally assume this never happens, because their error reporting code lives in the javascript bundle and they never get error reports ;) The correct solution is probably to keep a few old versions of the Javascript bundle around, so that in-flight requests succeed even as you update the container hosting the app. I do not know of a tool that does this, but the edge case I describe above worries me, so I might write one someday.
- aaronharnly 7y agoYeah, and if you do dynamic loading of resources (images, templates, etc), I think the window of 404ing is much longer than just the index.html parse time — essentially, the span of a user session...
- moltar 7y agoEdge caching is a solution.
- jrockway 7y agoYeah, I think that's a reasonable solution. It doesn't guarantee 100% accuracy, but it increases the chance that something will load.