-
Notifications
You must be signed in to change notification settings - Fork 193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support AWS Lambda layers #6761
Comments
I'd like to propose that we solve this for now via |
We can support this initially without making adding surface area to the language by exposing an appropriate API for let fn = new cloud.Function(inflight () => { ... });
aws.Function.from(fn)?.addLambdaLayer("acme.lambda_layer"); To me this feels more robust from an API design perspective since lambda layers are an AWS Lambda specific concept. If you added some kind of metadata to a block of inflight code, you're now pushing responsibility onto other inflight host types (like |
That's not going to work because there are many functions that are created implicitly. For example, the function that hosts the handler of a The decision to take a dependency on the layer is an attribute of the inflight closure code. |
While these functions are created implicitly, I don't think they're meant to be hidden. It wouldn't be too hard to provide access to these resources: let api = new cloud.Api();
api.get("/hello", inflight () => {
c.foo();
});
let fn = aws.Api.from(api)?.getFn("/hello"); // aws.Function? We also have platform providers, right? export class MyPlatform {
preSynth(app) {
for (const c of app.node.findAll()) {
if (c instanceof cloud.Function) {
c.addLambdaLayer("acme.lambda_layer");
}
}
}
} I think these mechanisms could be a good incremental step towards addressing the base use case of "I would like to add lambda layers to new and existing cloud.Function resources in my app." |
Platform providers will work well for blanket type rules (i.e. all lambdas need the layer) but if adding a layer had performance implications, then its challenging to to just specify which ones should get it. |
@Chriscbr how would this work if a layer is needed only by some inflight method implemented by a class? (the |
For the time being, |
For those kinds of use cases you can use the bring aws;
pub class DataDog {
pub inflight publishMetric() {
// implementation
}
pub onLift(host: std.IInflightHost, ops: Array<str>) {
if let fn = aws.Function.from(host) {
fn.addLambdaLayer("datadog-1.2");
}
}
} And then when you are using the class... bring mylib;
let datadog = new Datadog();
pub class MyResource {
pub inflight fly() {
datadog.publishMetric();
}
} ... and you'd be guaranteed that any |
Love it! Great solution. We need to add support for adding lambda layers the And also document this! |
Follow ups:
|
For these cases you can add an if-condition to only call pub class DataDog {
// ...
pub onLift(host: std.IInflightHost, ops: Array<str>) {
if ops.includes("myMethod") {
if let fn = aws.Function.from(host) {
fn.addLambdaLayer("datadog-1.2");
}
}
}
}
The most straightforward way to do this would be to define a helper class once for each lambda layer you want to use, and then you can call it freely in any of your inflight closures. pub class DatadogLayer {
pub static inflight load() {}
pub static onLiftType(host: std.IInflightHost) {
if let fn = aws.Function.from(host) {
fn.addLambdaLayer("datadog-1.2");
}
}
}
let api = new cloud.Api();
api.get("/hello", inflight () => {
DatadogLayer.load();
}); The class is about 8 lines of code, but that's pretty small and easy to maintain. The fact that this didn't require any new language capabilities to support is pretty sweet to be honest (and it's a huge win maintenance-wise). I think the It's also worth weighing the level of the investment we want to put into this feature against the frequency of the use case. It's the first time the issue of supporting lambda layers has popped up as an issue if I understand correctly. There are also credible sources recommending against use of lambda layers which are worth considering. |
The I'd like us to go with the |
Congrats! 🚀 This was released in Wing 0.75.12. |
Use Case
I'd like to be able to define a set of AWS Lambda layers that will be loaded into my
cloud.Function
s:This should also for functions that are implicitly created (e.g. as
cloud.Api
handlers or used by some method:Proposed Solution
No response
Implementation Notes
No response
Component
No response
Community Notes
The text was updated successfully, but these errors were encountered: