Deno hydrate using deno cache

[hicksy]

Thank you for helping out! ✨

Hi 👋

This PR would work alongside this one in Hydrate - https://github.com/architect/hydrate/pull/136

Together they enable hydration for deno runtime arc functions by setting the DENO_DIR to vendor/.deno_cache within each lambda and using deno cache to pre-cache the remote dependencies

This massively speeds up individual invocation and stops issues where the lambda times out while Deno is caching the remote dependencies.

Also could prove to be a handy pre-cache that could be used by the Deno lambda layer, moving the .deno_cache to /tmp to deploy pre-cached / hydrated Deno functions

We really appreciate your commitment to improving Architect

To maintain a high standard of quality in our releases, before merging every pull request we ask that you've completed the following:

• [ ] Forked the repo and created your branch from master
• [ ] Made sure tests pass (run npm it from the repo root)
• [ ] Expanded test coverage related to your changes:
  • [ ] Added and/or updated unit tests (if appropriate)
  • [ ] Added and/or updated integration tests (if appropriate)
• [ ] Updated relevant documentation:
  • [ ] Internal to this repo (e.g. readme.md, help docs, inline docs & comments, etc.)
  • [ ] Architect docs (arc.codes)
• [ ] Summarized your changes in changelog.md
• [ ] Linked to any related issues, PRs, etc. below that may relate to, consume, or necessitate these changes

Please also be sure to completed the CLA (if you haven't already).

Learn more about contributing to Architect here.

Thanks again!

[ryanblock]

Sorry this has lingered, this is an absolutely necessary problem for us to solve.

The current Deno runtime bootstrap is DENO_DIR=/tmp/deno_dir deno run..., as you mentioned assuming that DENO_DIR is in the writable filesystem. That's not tenable for the reasons you mentioned, as it's going to kill coldstart.

These PRs make sense to merge, but only once we can update that runtime, otherwise it won't be looking in the correct place. Any reason we should use ./vendor/.cache instead of the default $HOME/.cache/deno? Then we can just remove the DENO_DIR env var entirely.

Additionally: as I'm looking into it, our Deno runtime is extraordinarily old. Do you have a preferred target version you feel we should have Deno pinned at for a little while?

[hicksy]

No probs.

our Deno runtime is extraordinarily old. Do you have a preferred target version you feel we should have Deno pinned at for a little while

Personally, I would pin to v1.10.3

There were a number of changes introduced to v1.11.x, which have a few breaking affecting dependencies to Deno's stdlib 0.97... (This affects functions-deno, which I've almost revolved now that the 3rd party AWS lib has been updated)

Any reason we should use ./vendor/.cache instead of the default $HOME/.cache/deno? Then we can just remove the DENO_DIR env var entirely.

If you mean locally in sandbox, then doing so would give you the benefit of Deno's cache, but it wouldn't help with the remote function coldstart as your cache would be in $HOME/.cache/deno and therefore outside of the deployed directory.

Using ./vendor/.cache each function's discreet cache would be deployed, allowing you to move the cache to /tmp/deno_dir prior to invoking the lambda layer's bootstrap DENO_DIR=/tmp/deno_dir deno run

If we didn't have it in ./vendor/.cache the cache would have to be rebuilt on each coldstart invocation

Does that help? sorry if I've misunderstood the question