Use Deno cache to hydrate the deno dependencies, so they're pre-cached #136

hicksy · 2021-05-27T19:06:31Z

Hi 👋

This PR would work alongside this one in Sandbox - architect/sandbox#585

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

I've not worked up any tests yet, to feedback you could test with this basic repo - https://github.com/hicksy/deno-arc-example-login-flow - before the change the lambda will prob time out, with these PRs it'll hydrate during sandbox start and invoke promptly.

Thank you for helping out! ✨

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:

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

Learn more about contributing to Architect here.

Thanks again!

…d on invocation

ryanblock · 2021-05-27T21:05:40Z

src/actions/install-update.js

@@ -34,6 +34,7 @@ module.exports = function hydrator (params, callback) {
  let isJs = file.endsWith('package.json')
  let isPy = file.endsWith('requirements.txt')
  let isRb = file.endsWith('Gemfile')
+  let isDeno = file.endsWith('deps.ts') || file.endsWith('index.js') || file.endsWith('index.ts') || file.endsWith('index.tsx') || file.endsWith('mod.js') || file.endsWith('mod.ts') || file.endsWith('mod.tsx')


I feel like we can tidy this up with an array + a some() check

Yep, cool. No probs. Will push some amends later

ryanblock · 2021-05-27T21:07:28Z

src/actions/install-update.js

@@ -43,7 +44,9 @@ module.exports = function hydrator (params, callback) {
        if (isJs) dir = join(cwd, 'node_modules')
        if (isPy) dir = join(cwd, 'vendor')
        if (isRb) dir = join(cwd, 'vendor', 'bundle')
-        rm(dir, callback)
+        if (isDeno) callback()


Why would we skip Deno? We definitely need a fresh function when hydrating, we don't know when the last time dependencies were pulled or what state they're in, this prevents a lot of transient dependency issues (and enables Sandbox symlinking).

Maybe I've misunderstood - I thought the rm of those dirs was because for the other runtimes the shared & view folders are symlinked into the dependency folder? So like in node you can
let sharedFunc = require('@architect/shared/function.js)

I was thinking because in Deno vendor is just a standard dir it wouldn't need cleaning up?

ryanblock · 2021-05-27T21:08:58Z

src/actions/install-update.js

@@ -103,6 +106,12 @@ module.exports = function hydrator (params, callback) {
        exec(`bundle update`, options, callback)
      }

+      // cache deno deps.ts
+      else if (isDeno) {
+        // should --reload be added? That would force re-caching everytime, so maybe not?


Hydrate is responsible for deterministic deploys, prob not a bad idea to use --reload but I'm not sure what the re-caching operations are in Deno-land – can you speak to that at all?

A little, so my understanding of Deno's cache is that any remote URL that's imported is cached, and the cache is stored as a reference to the URL. A file with a filename hash (of the pathname I think) stored in $DENO_DIR/deps/<http|s>/<hostname>

So (I think) it works like this:

is the import a remote URL. If so, it'll be downloaded and cached (unless it's already cached, in which case its imported from the cache location)

If the --reload flag is supplied to either deno cache or deno run then regardless of whether the file is in the cache already, the remote URL will be downloaded and cached prior to import

If it's a local import, that doesn't get cached.

I guess the downside of always using --reload will be the wasteful nature of downloading the same files over and over (slightly unavoidable on the first sandbox start as we're using discreet DENO_DIR local to the lambda).

But the downside to deno cache is it works great when your URL is pinned to a specific version, but if it's a generic like https://esm.sh/react-helmet then that URL will be cached even though over time that may be serving v2, v3, etc

So maybe it is best to take the hit, at least pre-caching like this keeps the invocations nice and fast

Yeah, damn, bummer about the import-URLs-with-no-version. With that in mind I guess it makes sense to --reload all the time. As was said, we take the performance hit up-front at author time during hydrate (and thus before a deploy or sandbox run) in order to keep runtime performant.

OK, sure. Latest commit takes that approach

You'll see Deno's cache output in stdout, can add --quiet to the cache command to prevent that

Also, as we're caching the lambda handler, this doesn't quite follow the format of the logging

✓ Hydrate Successfully hydrated dependencies ⚬ Hydrate Hydrating dependencies in 1 path ✓ Hydrate Hydrated frontend/home//home/

Hydrate Hydrated frontend/home//home/ should really be Hydrate Hydrated frontend/home/index.tsx

Think that uses dirname somewhere?

ryanblock · 2021-05-27T21:15:54Z

src/index.js

@@ -69,6 +70,30 @@ function hydrator (inventory, installing, params, callback) {
    if (viewsDir && file.includes(viewsDir)) return false
    return true
  })
+
+  // Add deno cacheable files if they exist and we're hyrdrating a Deno runtime


I'm not sure this change would be the right approach. How about adding these to the glob pattern, and then filter for Deno by entry files on Deno Lambdas?

Yep, cool. No probs. Will push some amends later

Does the latest commit work better?

Use Deno cache to hydrate the deno dependencies, so they're pre-cache…

6eb5cfc

…d on invocation

hicksy mentioned this pull request May 27, 2021

Deno hydrate using deno cache architect/sandbox#585

Open

10 tasks

ryanblock reviewed May 27, 2021

View reviewed changes

hicksy added 2 commits May 31, 2021 17:53

various improvements linked to CR

66bebb6

Merge branch 'master' into hydrate-deno

1eca862

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use Deno cache to hydrate the deno dependencies, so they're pre-cached #136

Use Deno cache to hydrate the deno dependencies, so they're pre-cached #136

hicksy commented May 27, 2021

ryanblock May 27, 2021

hicksy May 28, 2021

ryanblock May 27, 2021

hicksy May 28, 2021 •

edited

Loading

ryanblock May 27, 2021

hicksy May 28, 2021 •

edited

Loading

filmaj May 28, 2021

hicksy May 31, 2021

hicksy May 31, 2021

ryanblock May 27, 2021

hicksy May 28, 2021

hicksy May 31, 2021

Use Deno cache to hydrate the deno dependencies, so they're pre-cached #136

Are you sure you want to change the base?

Use Deno cache to hydrate the deno dependencies, so they're pre-cached #136

Conversation

hicksy commented May 27, 2021

Thank you for helping out! ✨

We really appreciate your commitment to improving Architect

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hicksy May 28, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hicksy May 28, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hicksy May 28, 2021 •

edited

Loading

hicksy May 28, 2021 •

edited

Loading