Giters

aws / aws-cdk-rfcs

RFCs for the AWS CDK

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

AWS Lambda for .NET Support

vlesierse opened this issue · comments

commented

Description

As a .NET developer I would like to build serverless Lambda application with .NET and deploy this application using AWS CDK. It is painful to design a build process which first need to build/test and package one or more Lambda functions in my project and then use lambda.Code.fromAsset(path.join(__dirname, 'out', 'package.zip')) to point to those packages. This has been beautifully solved with the aws-lambda-go, aws-lambda-nodejs and aws-lambda-python L2 constructs.

Roles

Role User
Proposed by @vlesierse
Author(s) @vlesierse
API Bar Raiser
Stakeholders @vlesierse

See RFC Process for details

Workflow

  • Tracking issue created (label: status/proposed)
  • API bar raiser assigned (ping us at #aws-cdk-rfcs if needed)
  • Kick off meeting
  • RFC pull request submitted (label: status/review)
  • Community reach out (via Slack and/or Twitter)
  • API signed-off (label api-approved applied to pull request)
  • Final comments period (label: status/final-comments-period)
  • Approved and merged (label: status/approved)
  • Execution plan submitted (label: status/planning)
  • Plan approved and merged (label: status/implementing)
  • Implementation complete (label: status/done)

Author is responsible to progress the RFC according to this checklist, and
apply the relevant labels to this issue so that the RFC table in README gets
updated.

commented

I tried this out and it makes .NET Lambda development with CDK soooo much better! It worked great! If there is more testing you need me to do, please let me know.

My stack included this code:

            var helloWorldLambda = new DotNetFunction(this, "HelloDotnetHandler", new DotNetFunctionProps{
                ProjectDir = "src/Lambdas/HelloWorldDotnet",
                Architecture = Architecture.X86_64
            });
commented

It even worked seamlessly with a native AOT .NET project publish to AL2 and automatically built on Docker.

commented

I would recommend for .NET integrating with our Amazon.Lambda.Tools tooling for bundling. We use it under the covers for all of our AWS tooling that supports .NET packaging including SAM CLI and Visual Studio. Happy to contribute where I can.

commented

@normj I don't know if @vlesierse linked it above at all, or if you've seen it, but there is already a working POC that uses Amazon.Lambda.Tools.

https://github.com/xaaskit/cdk-aws-lambda-dotnet

The call to dotnet lambda package is here, although there are other options too: https://github.com/xaaskit/cdk-aws-lambda-dotnet/blob/main/src/bundling.ts#L122

commented

@normj that is exactly how it is implemented. This means that the Lambda Tools need to be installed. If not, it will build from a container which has the tools installed.

There is one thing that might need to adjusted to the Lambda Tool, which is to make the zip creation optional with a command line parameter. The current implementation zips the binaries with the Lambda Tool, unzips it and let CDK zip it again for uploading.

commented

Closing this ticket as this is not a current priority. We don't have the bandwidth to collaborate on design or implementation. We suggest you pursue experimentation in a separate package or a fork if needed. If a successful implementation emerges, reopen the proposal with details on the functionality and how it can be implemented in the core library.

commented

I believe having this feature in the AWS CDK would make the CDK easier and more appealing to use for .NET developers. I have been doing .NET development for many years, and I can certainly recognize the current sub-optimal workflow outlined in issue description. Having to use a "multi step" deployment approach, where you first need to build and package the code yourself, and then trigger the CDK deployment afterwards is sub-optimal.

Looking at the work done in the referenced project: https://github.com/xaaskit/cdk-aws-lambda-dotnet it looks like there is already a solid example of how a DotNetFunction CDK construct could be implemented, which should make the task of integrating a such construct into the CDK project simpler.

Based on the above, I hope the team will consider to re-open this issue. Thank you.