feat(event-handler): Add support for HTTP APIs (API Gateway v2)

[svozza]

Summary

This PR adds support for HTTP API (API Gateway v2) to the event handler utility. It also adds the framework for adding other event sources like function URLs, ALB and VPC lattice.

Edit: after some testing, I've realised that as function URLs and HTTP APIs share the same event type, which means function URLs also work.

Changes

• The public resolve method now has overloads to support both APIGatewayProxyEvent and APIGatewayProxyEventV2 events. New overloads can be added for new event types. I attempted to do this with conditional types but was unable to make it it work, furthermore, the type signatures were much harder to read than simpler overrides.
• The #resolve method in the Router class now returns the entire request context object. We use reqCtx.res now as the canonical representation of the response to be returned. As the request is now always represented as a web Response object, converting the response required for different event sources is simpler. We also save the type of response required in the request context using the ResponseType type.
• The handlerResultToProxyResult function has been removed now that all response are converted to Web Response objects.
• I have removed the ad hoc base64 encoding functionality. The change to the #resolve method will allow us to handle this is a more principled way by using the request context to indicate whether a response should be encoded or not. I plan to do this work when implementing Feature request: first-class support for binary responses #4514.
• A new type guard to identify APIGatewayProxyEventV2 objects has been added.
• A function to convert APIGatewayProxyEventV2 events to Web Request objects has been added.
• A function to convert Web Respsonse objects to APIGatewayProxyReultV2 objects has been added.

Testing

• Most of the tests now run using both v1 events and v2 events. The pattern established is easily extended to use additional event types. One suite I have not done so is the middleware tests. These use the exact same mechanisms as the other tests so I have decided to only add some additional v2 specific tests. I am open to persusion as to whether these should follow the other tests.
• I have used the same lambda function to integrate with an API Gateway REST API and an HTTP API and verified using curl that requests will be fulfilled by the same code with no changes required.
• Tested a lambda function URL with streaming enabled and it also worked.

Issue number: closes #4713

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[sdangol]

Tested it out and looks good

[svozza]

Nice!

[svozza]

@swopnildangol I made a change to how we calculate what response to return. Rather than passing the event around and using type guards, I save the response type once in the request context with a type called ResponseType that can only have the value v1 or v2. This allows us to remove a bunch of overloads in the conversion functions and just use conditional types.

[sdangol]

@swopnildangol I made a change to how we calculate what response to return. Rather than passing the event around and using type guards, I save the response type once in the request context with a type called ResponseType that can only have the value v1 or v2. This allows us to remove a bunch of overloads in the conversion functions and just use conditional types.

So, with this, as we add on support for more handlers, we'd be adding options to the ResponseType? Would it make more sense to have maybe ApiGatewayV1 or ApiGatewayV2 rather than just v1 and v2?

[svozza]

Good point, I've changed it.

[sdangol]

There are some unintended changes from v1 to ApiGatewayV1 in the code base

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
12.4% Duplication on New Code

See analysis details on SonarQube Cloud