Improvements to Lambda Development Experience

[aripalo]

Now that AWS CDK can build Lambda functions within Docker containers by allowing to define BundlingOptions, it would be cool to have also the possibility to locally test, run arbitrary commands and locally invoke the Lambda function inside Docker as well.

Use Case

Currently one has to come up with a separate toolchain to handle the local testing and locally invoking the Lambda function within Docker. I feel that these are critical steps in developing Lambda functions. Also having the possibility to run arbitrary commands within the build Docker container could be useful at times.

Proposed Solution

Currently one can define the build options like this:

new lambda.Function(this, "MyFunc", {
  runtime: lambda.Runtime.GO_1_X,
  handler: "bin/main",
  code: lambda.Code.fromAsset("path/to/my-func", {
    bundling: {
      // Speficy Docker image:
      image: lambda.Runtime.GO_1_X.bundlingDockerImage,
      // The build command to be executed within the Docker container:
      command: [
        'bash', '-c', [
          `cd /asset-input`,
          `go build -o bin/main`,
          `cp /asset-input/bin/main /asset-output/bin`,
        ].join(' && ')
      ],
      user: 'root',
    },
    // Glob(s) to exclude from deployment package:
    // In most cases with Go, only the binary is needed (unless you depend on external files)
    exclude: ["!bin"],
  }),
});

It would be awesome if one could also specify the following (or something like it):

// ⚠️ IMPORTANT NOTE ⚠️
// This is NOT a working code example!
// Just something I imagined and think would be cool to have in CDK:
new lambda.Function(this, "MyFunc", {
  runtime: lambda.Runtime.GO_1_X,
  handler: "bin/main",
  code: lambda.Code.fromAsset("path/to/my-func", {
    // Removed the "building" config shown above for brevity
    testing: {
      // Speficy Docker image:
      image: lambda.Runtime.GO_1_X.bundlingDockerImage, // Could probably use the same from "building" if none specified? Maybe also support providing own Dockerfile?
      // The test command to be executed within the Docker container:
      command: [
        'bash', '-c', [
          `cd /asset-input`,
          `go test`,
        ].join(' && ')
      ],
      user: 'root',
    },
  }),
});

And then I could also imagine a CLI commands to be available after synth something like:

• cdk lambda test to run tests for all functions
• cdk lambda test MyFunc to run tests for specific function
• cdk lambda invoke MyFunc --event some-payload.json to build and then locally invoke the function code

Of course the above example assumes all CDK construct ID's regarding Lambda functions would be unique, which may not be the case. Then maybe one could use the Construct "path": SomeConstruct/MyFunc and AnotherConstruct/MyFunc.

Reasoning

Since CDK already has a lot functionality regarding running things inside the Docker container, it feels "unnecessary" to define totally separate toolchain for the testing/invocation; Having those essential development flows available via CDK would make CDK super powerful tool for building serverless projects.

• 👋 I may be able to implement this feature request (really strong emphasis on the word "may" 😅)
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[aripalo]

Here's also a link to blog post that also reasons about having this kind of feature in CDK directly: https://aripalo.com/blog/2020/building-lambda-functions-inside-docker-containers-with-cdk/

[nija-at]

Thanks for filing this issue @aripalo. This is a very interesting idea, indeed. Building bett
Currently, the AWS CDK is responsible for preparing assets and artifacts for deployment into AWS. However, we've been toying around with ideas to build a better developer experience for our customers when working on the CDK.

To implement your proposal or something similar, we'll need to think a little deeper into the customer experience of the CDK and what changes will be necessary across our toolchain (such as the CLI as you've noted in your blog post).

I'm transferring this issue to our RFC repo, where we track changes and proposals that need deeper consideration.

The RFC repo has a detailed entry on its process and I'm happy to guide you along the way, if you're interested in writing one.

[aripalo]

@nija-at Great to hear! This is definitely something that should not be implemented without thoughtful consideration first on how it should actually work; I just wanted to at least through the idea out there! I'll get in touch, if I'll hopefully get a change to think about this more soon and if I'd be able to contribute on the RFC more!

[mrgrain]

Marking this RFCs as stale since there has been little recent activity and it is not currently close to getting accepted as-is. We appreciate the effort that has gone into this proposal. Marking an RFCs as stale is not a one-way door. If you have made substantial changes to the proposal, please open a new issue/RFC. You might also consider raising a PR to aws/aws-cdk directly or self-publishing to Construct Hub.