Thanks - we'll take a look.

What we're exploring is adding an optional parameter to ApiIntegration that will give you more control over the Lambda function:

export interface ApiIntegration {
  readonly id: string;
  readonly existingLambdaObj?: lambda.Function;
  readonly functionVersion?: number;
  readonly lambdaFunctionProps?: lambda.FunctionProps;
}

1. Would this satisfy your requirements?
2. We're assuming you are supplying an existingLambdaObj parameter, because if lambdaFunctionProps is used to create a new function there will be no published versions. Is this correct?
3. Are you strictly using version, or are there alias considerations at this time? (limiting this answer to what you need now, rather than what you might want in the future will help us get you what you need sooner)

Is your Lambda function defined in the same CDK stack as the openapigateway-lambda construct?

We're running into an issue where the number for a newly created version is a token and can't be included in the spec (setting up the gateway from the spec is outside of the CDK and can't process tokens). We're starting to look at aliases as an alternative.

Thanks for the quick response!

Is your Lambda function defined in the same CDK stack as the openapigateway-lambda construct?

Yes it's in the same stack, snippet below (edited a little for confidentiality 🙂 ):

        # DotNet Bundling
        dotnet_bundling_options = {
            "command": [
                "/bin/sh",
                "-c",
                " dotnet tool install -g Amazon.Lambda.Tools"
                + " && dotnet build"
                + " && dotnet-lambda package --package-location /asset-input --output-package /asset-output/function.zip",
            ],
            "image": lambda_.Runtime.DOTNET_8.bundling_image,
            "user": "root",
        }
        # Create the Lambda function to receive the request - dotnet

        api_handler_FooBar_stringdecode = lambda_.Function(
            self,
            f"FooBarStringDotNet-ApiHandler-{environment}",
            function_name=f"{environment}-FooBar-string-dotnet-openapigw_handler",
            runtime=lambda_.Runtime.DOTNET_8,
            code=lambda_.Code.from_asset("./lambda/APIGWHandlerFooBarStringDotNet/src/APIGWHandlerFooBarStringDotNet", bundling=dotnet_bundling_options),
            handler="APIGWHandlerFooBarStringDotNet::APIGWHandlerFooBarStringDotNet.Function::FunctionHandler",
            vpc=vpc,
            vpc_subnets=ec2.SubnetSelection(
                subnet_type=ec2.SubnetType.PRIVATE_ISOLATED
            ),
            memory_size=1024,
            timeout=Duration.minutes(5),
        )

        # Create the API Integration for the OpenAPI Gateway
        FooBar_string_decode_api_integration = ApiIntegration(id="FooBarStringDecodeFunction", existing_lambda_obj=api_handler_FooBar_stringdecode)

1. Would this satisfy your requirements?

Yeah I think that would work, the SnapStart options seem to just require that you link to a published version, not $LATEST, so anything that can point to a specific version should work. I guess in the CDK, we could create the function, then a version separately. Then pass a property of that Version object in as the functionVersion parameter?

2. We're assuming you are supplying an existingLambdaObj parameter, because if lambdaFunctionProps is used to create a new function there will be no published versions. Is this correct?

Originally I was using the aws_lambda_python_alpha.PythonFunction help bundle up the dependencies, so that's why i was using the existingLambdaObj parameter - I've since figured out how to use the bundling options so I could probably just use the lambda Function Props to build it as part of the ApiIntegration instead.

3. Are you strictly using version, or are there alias considerations at this time? (limiting this answer to what you need now, rather than what you might want in the future will help us get you what you need sooner)

I believe requiring a version is a limitation of the SnapStart feature - but you can also use an Alias as it would point to a specific version (I wasn't planning on using an Alias, but would be happy to do that if it was needed):

This is for something that's still in the proof of concept stage for us, so I'm happy to be flexible and try different things out - I don't have anything strict preferences etc. 🙂

The main reason for using the "OpenApiGatewayToLambda" was just to make it so we had to write the OpenAPI yaml file and kind of force us into having that documentation (otherwise it tends to get let behind as you move on to other work), I did however also build a similar stack using the "traditional" way of adding resources and LambdaIntegrations and that worked with an Alias as the "handler" (possibly as that accepts an IFunction rather than Function), so your idea of using Alias rather than Version sounds like it should work well.

As it's still in the proof of concept stage, I may actually end up using the traditional way, or even SAM as that makes some of the API config a little easier if we switch it over to a HTTP API (such as CORS using the x-amazon-apigateway-cors OpenAPI extension rather than adding it manually per endpoint) - I thought the Alias/Version option was something worth bringing to your attention though as it could be possible that other users may want to use SnapStart now that it's a bit more widely supported

As we work on the PR to address this issue, it strikes us that and Alias and a Function are essentially interchangeable - both implement the IFunction interface. Our first implementation of the PR was to accept an Alias in addition to the function when defining the integration:

export interface ApiIntegration {
  readonly id: string;
  readonly existingLambdaObj?: lambda.Function;
  readonly existingFunctionAlias?: lambda.Alias;
  readonly lambdaFunctionProps?: lambda.FunctionProps;
}

But as we learned more, we realized the code only used the Alias - the existingFunction was redundant and opened up a possible error of being a different function. The ideal solution would be to accept an Alias xor an existing Function.

Here's our hesitation. The Construct exposes a list of Lambda functions used for the integration:

  readonly id: string;
  readonly lambdaFunction: lambda.Function;
}

Accepting just an Alias means we would need to make the lambdaFunction an optional attribute:

export interface ApiLambdaFunction {
  readonly id: string;
  readonly lambdaFunction?: lambda.Function;
  readonly functionAlias?: lambda.Alias;
}

This will cause a Typescript transpilation error for any client who accesses the Lambda function in this array. Since any current client is providing a Function (or Props), the value will still be populated - the error will be easily addressed by using an exclamation point to tell Typescript that you are certain the value is populated:

// Typescript error
const arn = construct.apiLambdaFunctions[0].lambdaFunction.functionArn)

// Required fix
const arn = construct.apiLambdaFunctions[0].lambdaFunction!.functionArn)

We're looking for customer thoughts on requiring clients accessing the Lambda function to make this edit? Is the value of avoiding the redundancy worth the disruption?