Currently, we store external data in our cache folder with different expiration dates. The current approach works well except that we flush the whole cache at each deployment of the app so we loose data that has to be refetched and that makes some views slower than they could be as well as some views not doable in a web request if they make dozens or hundreds of external requests. This is particularly true with hg changelog of past releases that we flush.
I should investigate how to not loose immutable data stored in cache, either by modifying the Cache class (store long term data in a different sub folder or add a prefix to the items like immutable-sha1.cache…) or by modifying how we deploy on heroku in the post-install script of composer.json.
pascalchevrel
commented
2 years ago
Currently, we store external data in our cache folder with different expiration dates. The current approach works well except that we flush the whole cache at each deployment of the app so we loose data that has to be refetched and that makes some views slower than they could be as well as some views not doable in a web request if they make dozens or hundreds of external requests. This is particularly true with hg changelog of past releases that we flush.
I should investigate how to not loose immutable data stored in cache, either by modifying the Cache class (store long term data in a different sub folder or add a prefix to the items like immutable-sha1.cache…) or by modifying how we deploy on heroku in the post-install script of composer.json.