Emulate API Gateway payload in event object

[ndavies-om1]

We run our lambdas behind an API Gateway. The event object in the lambda when we run locally does not have the same structure as the event object when running behind an API Gateway.

For example, if I want to post to a path with the /{model} parameter, I need to post with this wrapping my payload

{
    "pathParameters": {
        "model": model
    },
    "body": { .. json payload ...}
}

When I call my API Gateway endpoint I do not need to wrap the payload, as this is created by API Gateway as it passes the payload off to the lambda.

What I would really like is to be able to set an ENV var such as LAMBDA_MODE which when set to API_GATEWAY RIE wraps the event to mimic the event passed by the API Gateway. It would need to work the same for response objects too. If not set, then it would work in the default mode which is how it works today.

[ndavies-om1]

I know I could solve this problem by running a second container that actually takes the API call on another port, wraps the payload and passes it on to RIE. This could be done by a container running nginx + lua

[mnapoli]

I built this project to solve this problem (partially): https://github.com/brefphp/local-api-gateway

[OlivierKessler01]

This also exists : https://github.com/eagletmt/aws-lambda-rie-gateway

Hoping the project doesn't die

[skyzyx]

As @ndavies-om1 wrote:

I know I could solve this problem by running a second container that actually takes the API call on another port, wraps the payload and passes it on to RIE. […]

I solved it by writing a simple reverse proxy in Go using Gin.

https://github.com/northwood-labs/devsec-tools/blob/605872a0285acd392670e7dba7cafc33e767ee7d/cmd/serve.go

I send my requests to this proxy (running as localhost:8080). The proxy will read any request headers, request body, query string parameters, etc., then create a new request in the shape of API Gateway.

Once I have the new request that is shaped like API Gateway, I make a new request from inside the reverse-proxy to the RIE endpoint running in a Docker container (as localhost:9000).

On the way back, the reverse-proxy reads the RIE response (status code, response body), and constructs a new response in the shape of what the Lambda function would be sending back. Then the reverse-proxy returns that.

It's pretty lo-fi, but it works remarkably well.

But I agree — it would be great if AWS offerings were less like IKEA furniture, and more solution-oriented for the 80–90% of use-cases that are most common. But they're just not. GCP, Cloudflare, and others are far better at this than AWS is.