You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently with AWS, using the packageJson option with faast.js causes a new Lambda Layer to be created that can be reused if the same package.json is used by future functions (only if useDependencyCaching is true, which is the default). The layers created for caching are deleted by garbage collection using the same retentionInDays value as other resources. In practice this means that every 24h the packages will be reinstalled from scratch once, which makes function creation slower than needed in most cases.
We could do one of several things to improve this:
Add a separate retention period to the options, which is longer. Say, 30 days.
Use a smarter caching algorithm to keep a small number of layers around. For example, deleting the layer with the oldest creation date after reaching a limit of, say, 20 layers. The limit could be configured.
Note that the longer the packages are cached, the more likely there will be minor version updates that are missed. On the other hand, more frequent updates means longer lambda creation time, and the possibility that code breaks because dependencies are quietly updated that doesn't fully respect semver.
Suggest going with 2. Not sure what to do about the quiet update problem, maybe faast.js should issue a note to the console.
The text was updated successfully, but these errors were encountered:
Currently with AWS, using the
packageJson
option with faast.js causes a new Lambda Layer to be created that can be reused if the samepackage.json
is used by future functions (only ifuseDependencyCaching
istrue
, which is the default). The layers created for caching are deleted by garbage collection using the sameretentionInDays
value as other resources. In practice this means that every 24h the packages will be reinstalled from scratch once, which makes function creation slower than needed in most cases.We could do one of several things to improve this:
Note that the longer the packages are cached, the more likely there will be minor version updates that are missed. On the other hand, more frequent updates means longer lambda creation time, and the possibility that code breaks because dependencies are quietly updated that doesn't fully respect semver.
Suggest going with 2. Not sure what to do about the quiet update problem, maybe faast.js should issue a note to the console.
The text was updated successfully, but these errors were encountered: