fea: add aws-lambda-alb support

[marcogrcr]

🔗 Linked issue

#2072

❓ Type of change

• 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

WHAT?

Add support for ALB lambda function targets.

WHY?

ALBEvent is similar to APIGatewayProxyEvent. However, it has key differences such as:

• Query string parameters are not URL-decoded automatically.
• The events either have headers/queryStringParameters or multiValueHeaders/multiValueQueryStringParameters, but
  not both.
• Headers without values are removed from the event's input.

Without this change, using nitro with Lambda + ALB yields unexpected behaviors like double URL encoding.

RESOLVES?

#2072

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[marcogrcr]

Note: Tests are based on the behaviors observed here.

[pi0]

When work finished, would be nice if we can also setup for nitro-deploys to make sure preset works also in actual environment.

[marcogrcr]

When work finished, would be nice if we can also setup for nitro-deploys to make sure preset works also in actual environment.

I'm not sure how to action this since there doesn't seem to be any workflow in place that deploys to AWS (AWS account, credentials and infra would would be a pre-req). Also, it seems all deployments except alwaysdata.yml are currently disabled.

[pi0]

Thanks for PR.

Considering several differences, i think it would be nicer if we develop a standalone subpreset + entry such as aws-lambda-alb and avoid changes to current aws-lambda (that as linked issue states is purpose built for gateway proxy)

[marcogrcr]

Thanks for the reply @pi0!

Considering several differences, i think it would be nicer if we develop a standalone subpreset + entry such as aws-lambda-alb

Just to confirm, do you mean something like the following?

Update:

nitro/src/presets/aws-lambda/types.ts

Lines 1 to 3 in f982f99

	export interface AwsLambdaOptions {
	streaming?: boolean;
	}

to:

export type AwsLambdaOptions =
  | {
    // backwards compatibility, the presence of `type` overrides this
    streaming?: boolean;
  }
  | {
    /**
     * The Lambda function type:
     *
     * - `alb`: An ALB Lambda target group.
     * - `api-gateway`: An API Gateway REST API Lambda proxy integration, HTTP API Lambda integration, or Lambda function URL.
     * - `function-url`: A synonym of `api-gateway`.
     * - `function-url-stream`: A Lambda function URL with response streaming.
     *
     * @default "api-gateway"
     */
    type?: "api-gateway" | "alb" | "function-url" | "function-url-stream";
  };

And update:

nitro/src/presets/aws-lambda/preset.ts

Lines 10 to 16 in f982f99

	hooks: {
	"rollup:before": (nitro, rollupConfig) => {
	if (nitro.options.awsLambda.streaming) {
	(rollupConfig.input as string) += "-streaming";
	}
	},
	},

to:

hooks: {
  "rollup:before": (nitro, rollupConfig) => {
    if ("type" in nitro.options.awsLambda) {
      if (nitro.options.awsLambda.type === "alb") {
        (rollupConfig.input as string) += "-alb";
      } else if (nitro.options.awsLambda.type === "function-url-stream") {
        (rollupConfig.input as string) += "-streaming";
      }
    } else if (nitro.options.awsLambda.streaming) {
      (rollupConfig.input as string) += "-streaming";
    }
  },
},

[pi0]

I mean making new variant / export in presets (similar to cloudflare/)