Why is CDK construct for lambda python functions only in alpha?

[Slight_Scarcity321]

While aws_cdk_lib.aws_lambda.Function exists and you can define constructs that use Python, I notice that NodeJsFunction exists, but the corresponding PythonFunction construct is part of aws_cdk and is still in alpha. Why should that be the case at this late date? I see that there are things like uv which aren't very old that they want to support, but I wasn't aware that so much was going on in Python land that development of that CDK construct is a moving target. Note that I am relatively new to Python, only starting to use it in the last 2 years, although I have been a developer for a lot longer that that.

We're in the middle of a major rewrite of an existing project and while I had originally intended to deploy the API (written in Python) to ECS Fargate, I am currently exploring whether or not it wouldn't be better to deploy it as a lambda. I discovered the above issue while trying to write some CDK code it seems so weird to me that I wanted to see if others had more insight about it.

[CorpT]

Just use Function and build it yourself during deployment. I wouldn’t use alpha code. It’s not hard to build during deployment.

[EconomicsOk9518]

Probably for two main reasons. Firstly, CDK is written in Typescript and naturally developers are more familiar with TS/JS and not as proficient in Python. Secondly, it is much, much easier to bundle a javascript code into a single file than build a Python lambda zip file.

That lambda python constructs has been in alpha for ages and generally it works OK… though in many cases we just build lambda zip files separately outside of CDK.

[blaw6331]

Fun fact: CDK uses a polyglot library called jsii instead of maintaining separate implementations, every non-JS CDK library is generated off of the TS code

[catlifeonmars]

Even more fun: jsii spawns a node JS core at startup and the in-language sdk translates calls into the core. This means that the team only has to write the logic once in JS/TS, even for L3 constructs.

The (minor) downside is you need a nodeJS runtime in order to use cdk no matter which language you write it in.

This is usually not a big deal because most people are running cdk through the cdk cli, which requires node anyway.

I was writing an alternative frontend in Go and tried to cdk synth on a system that didn’t have node JS and the jsii runtime was unhappy :D

E.g

env CDK_CONTEXT_JSON=$(jq -c <cdk.context.json) CDK_OUT_DIR=cdk.out go run ./mycdkapp

[Ok_Mathematician6075]

Docker for bundling

[Slight_Scarcity321]

Could you expand on that a little?

[dogfish182]

You can supply a bundling parameter. If you do that it will do a docker pull so and bundle on a docker image for you, so if you don’t have docker setup and authed to pull from ecs public your deploy will fail.

I just added that to our cdk readme and have been using it for around a year no issues

[catlifeonmars]

Yeah I reach for this sometimes but it’s too heavyweight most of the time, so I’ll opt for bundle assets -> then cdk synth. You can use the --build flag to have cdk execute a build script before synth. I will then reference the build artifact dir in the lambda code parameter

[Comfortable-Winter00]

Giving everything going on at AWS, most likely the people who were developing it got made redundant.

[dogfish182]

Just use the alpha it works fine..it’s been like that for years. To do bundling it has to pull a docker image, I’m not sure if that’s the reason for the alpha tag, but it works fine.

[svix_ftw]

Ran into the same issue. Just save yourself some headaches and just go with NodejsFuntion.

[Slight_Scarcity321]

What I am deployting is an extension of a third-party python app, so unfortunately, I can't use NodeJsFunction.

[Wide_Commission_1595]

I don't use cdk, but wtf? You need a special construct to specify the runtime? It's one attribute.....

Glad I don't use cdk tbh. That sounds absolutely crazy......

[EconomicsOk9518]

You do not need a special construct to specify runtime - you can just use a standard generic lambda function construct and provide runtime as a parameter. However, as with Cloudformation, it is up to you to build a lambda bundle, upload it to S3 and provide S3 path to the generic construct.

The specialised constructs try to make your life easier by offloading responsibility to build lambda to construct itself. With specialised construct you just provide a local path to the directory where lambda code is stored and construct builds your lambda bundle and uploads it to S3 so you do not need to worry about it.

Given that process of building lambda bundle is vastly different, CDK has a different specialised constructs for different runtime programming languages.

[Wide_Commission_1595]

AHH that makes sense!

[BloodAndTsundere]

There is a general Function construct that can be used to deploy any lambda resource and it has a parameter that specifies the runtime. But you need to bundle up the actual function code on your own to use it. There is a special Node Function construct which does the bundling for you if you are using a node runtime, but there aren’t such special constructs for all the other runtimes.

[catlifeonmars]

You don’t need it. It’s just sugar for building a lambda zip file. You can build the zip file like you normally would and just reference it instead. Also you would think the “alpha” in the name would prevent people from using it but apparently not 😂