-
Notifications
You must be signed in to change notification settings - Fork 74
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
RFC: Use existing Lambda Layers with referenceFunctionLayer
#1549
Comments
Hey @josefaidt, on #1602 I'm trying to build using directly function itself in define function like in RFC #1543, we can use layers in there, I think, after finished this PR, I'll try this. It would be like this:
What are you think about this? Or should we add this directly to amplify-backend as defineFunction |
Hey @MarlonJD 👋 this would be a bit different and built onto the DefineFunctionProps as a way to specify |
So this is purely intended for application dependencies, not extensions such as datadog or the AWS Parameters and Secrets extension? |
This feature would be great! Is there any way we can use this now? If not, what's the current recommended work around for using packages like Sharp? Thanks in advance. |
Closing the issue as support for referencing Lambda layers was released in @aws-amplify/[email protected] |
Hey folks 👋 we’re looking to introduce a mechanism to bind and consume existing Lambda Layers with Functions defined with
defineFunction
. This will not facilitate the creation and management of Lambda Layers, however provides you with a way to consume Node.js packages that require OS-specific addons without requiring a dependency on Docker to build Functions locally. This is a follow-up to the following issues:sharp
that depend on OS-specific addons #1432The primary use case we’re seeking to address with this feature is the ability to use dependencies like
sharp
that require OS-specific addons to function as expected in the Node.js Lambda runtime environment, which requires linux addons. When building Functions locally (i.e. on deploy), Amplify uses esbuild, which will bundle modules that are imported in your source code. With layers, you need to prevent esbuild from bundling your layer code. Using CDK it is possible to force a Function build using Docker, however we would like to avoid requiring this dependency.In addition to the bundler complications, you also need a way to provide a similar type-safe experience that you get when authoring your Function’s handler. For example, if you’re using a layer that provides access to specific npm packages like
sharp
, you should expect to see the same APIs and type-safety you’d see when installing and using the package normally. This is typically accomplished by marking certain dependencies as “external”.The introduction of
referenceFunctionLayer
comes with an addedlayers
prop ondefineFunction
. This object is keyed by the module name hosted on your existing layer. In the example above, we’re binding a layer that simply hosts thesharp
dependency to thesharp
key. When esbuild executes,sharp
will be externalized and available via your layer at runtime.For layers hosting multiple dependencies, you can create multiple key/value pairs with the same layer reference:
Let us know what you think!
The text was updated successfully, but these errors were encountered: