Deploy lambda layers

[trsrm]

I didn't find the ability to deploy lambda layers via Arc.
But this is a useful feature and it is already available in Serverless: https://www.serverless.com/framework/docs/providers/aws/guide/layers

[ryanblock]

It is correct that currently Architect does not concern itself with publishing Lambda layers. Some quick background:

• See this discussion re. shared code as layers
• Citing what other frameworks do or don't do (aka the bandwagon fallacy) is not a winning argument; we endeavor to approach all problems with clear first principles reasoning

So, Lambda layers. They're great! We love them and use them. We have first class support for them in global config (apparently not documented right now, will fix that) and per-function config.

Layers are great for consuming and making use of pre-compiled binary tools or other highly-specific use cases. We do not think layers are very good for everyday business logic. In fact quite the opposite, I think folks looking to use layers for core application business logic will have a harder (and longer) time trying to publish and debug their applications.

All that said, I can see building an Architect plugin for publishing layers – we are indeed working on some custom binary / runtime stuff that nay necessitate. But as a core part of Architect, I'm not currently seeing it.

So back to you: what are you looking to do with Lambda layers in Architect, and why? This may help guide how we think about an eventual layer publishing plugin.

[trsrm]

I'm looking to move the node_modules directory to a layer. I have a simple "hello-world" lambda with only 2 NPM packages installed: apollo-server-lambda, and graphql.

"dependencies": {
  "apollo-server-lambda": "^3.5.0",
  "graphql": "^15.7.2"
}

But, during the deployment I've got a warning about too big lambda size (over 13Mb):

✓ Hydrate Successfully hydrated dependencies
⚬ Deploy Created deployment templates
⚬ Deploy This Lambda should ideally be under 5MB for optimal performance:
  | src/graphql (13 024KB)

The output of npx cost-of-modules:

┌──────────────────────┬────────────┬───────┐
│ name                 │ children   │ size  │
├──────────────────────┼────────────┼───────┤
│ graphql              │ 0          │ 2.02M │
├──────────────────────┼────────────┼───────┤
│ apollo-server-lambda │ 0          │ 0.02M │
├──────────────────────┼────────────┼───────┤
│ 2 modules            │ 0 children │ 2.04M │
└──────────────────────┴────────────┴───────┘

So, my idea was to move dependencies to a layer, as they don't change too often.

[ryanblock]

Yeah, so if you go back to that thread I posted above, this is exactly the kind of thing I strongly advise against. You aren't making the Lambda smaller, you're just moving the code from one place to another, while increasing the brittleness of your deployment chain, and decreasing the ability to debug on the fly.

Semi-related: does that cost-of-modules module look at dependencies? I think you're getting a false report there. With dependencies, apollo-server-lambda is actually >22MB.

[trsrm]

Yeah, so if you go back to that thread I posted above, this is exactly the kind of thing I strongly advise against. You aren't making the Lambda smaller, you're just moving the code from one place to another, while increasing the brittleness of your deployment chain, and decreasing the ability to debug on the fly.

I read that conversation, thanks for the clarification. But, I suppose it may speed-up the deployment time of a single lambda function, isn't it?

Semi-related: does that cost-of-modules module look at dependencies? I think you're getting a false report there. With dependencies, apollo-server-lambda is actually >22MB.

Yeah, it looks to be broken (unmaintained for 5 years). Just realized how much time has passed since I last used it 😦