Enhancements to single-function tRPC API.

[JoshuaToth]

Description

While the default behavior for the TRPC API is to have one lambda per API endpoint, it's common to only have a single lambda proxy handler for the API, reducing the infrastructure overhead and centralizing the API. There is instructions on how to achieve this within the documentation by editing the generated API construct. But it would be great to:

• Be able to vend this with an option without requiring additional changes to support this behavior.
• Fix the policy overload issue caused by this code here where the single handler function policy becomes too large ones a set amount of API endpoints has been reached.

Motivation

I personally have a strong preference for these sorts of API's to be single proxy functions, and very much dislike having 50+ individual lambdas for a single API. I would appreciate it being officially supported.

Suggested Implementation

No response

Contribute to feature

• I'd be willing to implement this feature

[cogwirrel]

Had a quick look at this - it's nice and easy to swap out to a single lambda by modifying the defaultIntegrations but the tricky part is working around the policy overload issue. It's tracked in CDK here: aws/aws-cdk#9327

The simplest workaround I could come up with was the below:

1. Update defaultIntegrations to create a single handler:

  public static defaultIntegrations = (scope: Construct) => {
    const handler = new Function(scope, `ApiRouterHandler`, {
      runtime: Runtime.NODEJS_LATEST,
      handler: 'index.handler',
      code: Code.fromAsset(
        url.fileURLToPath(
          new URL(
            '../../../../../../dist/packages/api/bundle',
            import.meta.url,
          ),
        ),
      ),
      timeout: Duration.seconds(30),
      tracing: Tracing.ACTIVE,
      environment: {
        AWS_CONNECTION_REUSE_ENABLED: '1',
      },
    });
    Api.handler = handler;

    return IntegrationBuilder.rest({
      operations: routerToOperations(appRouter),
      defaultIntegrationOptions: {},
      buildDefaultIntegration: () => {
        return { handler, integration: new LambdaIntegration(handler) };
      },
    });
  };

2. In the Api construct's constructor, after calling super which instantiates the RestApi and binds all the integrations, remove the individual method CfnPermission and add a single one for the entire api:

    this.api.node
      .findAll()
      .filter((c) => c instanceof CfnPermission)
      .map((c) => c.node.scope?.node?.tryRemoveChild?.(c.node.id));
    Api.handler!.addPermission('ApiPermission', {
      principal: new ServicePrincipal('apigateway.amazonaws.com'),
      scope: this,
      sourceArn: this.api.arnForExecuteApi(),
    });

Needs a bit of thought about how to support this neatly, perhaps some router/proxy type option which just registers a proxy method at the root of the API with a single integration, rather than individual ones.

[cogwirrel]

FYI my PR to CDK was merged which gets rid of the need to do the hacks: aws/aws-cdk#36021

Docs here: https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_apigateway-readme.html#lambda-integration-permissions

This means you can update the defaultIntegrations method to something like:

public static defaultIntegrations = (scope: Construct) => {
    const handler = new Function(scope, `ApiRouterHandler`, {
      runtime: Runtime.NODEJS_LATEST,
      handler: 'index.handler',
      code: Code.fromAsset(
        url.fileURLToPath(
          new URL(
            '../../../../../../dist/packages/api/bundle',
            import.meta.url,
          ),
        ),
      ),
      timeout: Duration.seconds(30),
      tracing: Tracing.ACTIVE,
      environment: {
        AWS_CONNECTION_REUSE_ENABLED: '1',
      },
    });

    return IntegrationBuilder.rest({
      operations: routerToOperations(appRouter),
      defaultIntegrationOptions: {},
      buildDefaultIntegration: () => {
        return { handler, integration: new LambdaIntegration(handler, {
          scopePermissionToMethod: false,
        }) };
      },
    });
  };

Now it'd be fairly straightforward to add this as an option to the API generators :) The main consideration is whether to include Router vs Individual Functions in the computeType or to have it as a different property. computeType means you have to define all the permutations and might be slightly more confusing for users, but would also mean it's not possible to select a combination that doesn't work - eg NLB + ECS would always be a "router" style pattern.