It is the most important handler for the light-proxy to call Lambda functions deployed to the AWS. By putting this handler at the end of the request/response chain, the light-proxy will address all the cross-cutting concerns before invoking the lambda function mapped to the endpoint.
The following is the config file for this handler. It will be generated from the OpenAPI specification file with the light-codegen.
# The aws region that is used to create the LambdaClient.
# The LogType of the execution log of Lambda. Set Tail to include and None to not include.
# mapping of the endpoints to Lambda functions
/[email protected]: PetsGetFunction
/[email protected]: PetsPostFunction
In the above config file, the region defines which region the lambda functions are deployed.
The logType is set to Tail by default, and it shouldn’t be changed. It allows the logs from the lambda function to be tailed in the light-proxy log file.
The mapping between the endpoints to Lambda functions is generated to allow the lambda-invoker handler to find the target function to call. You can use the full ARN or use the function name only.
When the handler is constructed, a LambdaClient object is created. In the handleRequest method, we get method, request path, query parameters, path parameters, headers and body from the exchange. Find out the mapped Lambda function from the path and method combination and invoke the lambda function.
To ensure that the Lambda function is invoked the same way from AWS API Gateway, we use APIGatewayProxyRequestEvent to invoke the function and expect APIGatewayProxyResponseEvent in return.
To allow the light-proxy to invoke Lambda functions, you need to create a AWS role with access to the lambda function. Once you have the role created, you can create a key and secret and put them into the environment variable.
The following environment variables should be passed to the Docker container.