cargo-lambda/cargo-lambda-cdk

CDK Construct to build Rust functions with Cargo Lambda

cargo-lambda

cargo-lambda is a Cargo subcommand to help you work with AWS Lambda.

Get started by looking at the documentation.

License

This project is released under the MIT License.

cargo-lambda-cdk's Issues

[Suggestion]: Derive Architecture for Bundling from Function Architecture

It would be nice to derive the architecture used for bundling from the architecture the lambda runs on. I don't think there should be a use case where these 2 should be different.

Something like this in function.ts should work:

// props?.bundling?.architecture > props?.architecture > default: Architecture.X86_64
const architecture = props?.bundling?.architecture ?
props?.bundling?.architecture :
props?.architecture ?
props?.architecture : Architecture.X86_64;

const bundling: BundlingOptions = { ...props?.bundling, architecture };

With that, it is still possible to set different architectures.

What do you think?

Update README with usage instructions for different languages

The README only talks about TypeScript. It should include examples for all the supported languages.

When a package is published to a repository like Nuget, we should try to find a way to publish a description with the examples for the specific language.

Update runtime to Amazon Linux 2023

Now that it finally released: https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/

Perhaps it could be an optional parameter, to select between provided.al2 and provided.al2023?

DOC: Typeo in variable name

from README.md

To force bundling in a docker container even if Cargo Lambda is available in your environment, set the forceDockerBundling prop to true.

variable name is forcedDockerBundling

Allow passing disableOptimizations to RustFunction.

It seems like adding debug = true to [profile.release] in my workspace Cargo.toml does nothing when using this construct to deploy my Lambda function.

I believe it is because Cargo Lambda ignores profile settings unless the disable-optimizations flag is set [docs, code].

Would it be possible to allow passing an argument to disable optimizations in this CDK construct?

Allow more docker `BundlingOptions`

It would be useful to have more of the BundlingOptions available when configuring the RustFunction using docker bundling. Sometimes I've encountered filesystem issues or permission errors when compiling crates, and options like bundlingFileAccess? or user? would be nice to have as a way around these.

Would it useful to allow all BundingOptions to be configurable, e.g. via an extends cdk.BundlingOptions?

Support all publish targets

It would be nice to be able to use the constructs in CDK projects written in other languages.

Can we use jsii to package for other languages and publish to other registries?

Is this working?

Hello,

I tried to use cargo-lambda-cdk to build a lambda function with API Gateway in front of it. But i was not successful. The build and deployment worked, but you received the following error when executing the function. I am using local builds (no docker since those fail building) on macOS with an M1

Error: Couldn't find valid bootstrap(s): [/var/task/bootstrap /opt/bootstrap]
Runtime.InvalidEntrypoint

When comparing the created lambda function with another function I have, I found the difference that the cargo-lambda-cdk creates a nested structure which leads to the error.

working structure

cargo lambda structure

Bundling environment clarity

I was messing around with deploying my project using the RustFunction construct. I think maybe the README could be more clear on the topic:

Is the bundling.environment separate the from the environment variables the lambda runs with? Based on the README I expected the lambda to run with the environment set from bundling but in reality, there was no extra environment set.

Actual:

Expectation:

Allow specifying glibc version

I really have no idea what I'm doing here, but I'm hitting an issue with rusqlite when cross-compiling to ARM64 (rusqlite/rusqlite#1295) that appears to be resolved by specifying the glibc version as 2.35:

cargo lambda build --target aarch64-unknown-linux-gnu.2.35

Currently the construct limits us to --arm64 or --x84-64, however.

Would it make sense to be able to specify the glibc version? (Or am I trying to solve the problem in the wrong way?)

No artifact uploaded for version with default Runtime AL2023

Version 0.0.17 does not incorporate the runtime property, resulting in the deployed Lambda always being AL2. According to this release, it seems that the latest version has not been uploaded to NPM or other artifact repositories.