Questions regarding the API Gateway Event Handler

[bb-rrogers]

Hey All,

Been trying to dive in and use these cool tools but am struggling to understand how they fit. At the moment we have three Lambda's that support 3 different functions (GET, PUT, PUT('s)). I'm unsure whether we should be using the API Gateway Event Handler vs using the Event Parser/Event Source Data Classes.

We want to keep this micro, and are not wanting to really use the monolithic approach. Based on this, I feel like the API Gateway Event Handler is more for that monolithic approach, but maybe I have misunderstood it's intent. Ultimately we are just trying to achieve a way of getting path params/query params/payload throwing 400 errors if the incoming request isn't valid. I wonder if we should just be looking at using the incoming_request validation process?

Handling exceptions also seems to be the hardest part biggest hurdle with the pydantic implementation in that we want certain exceptions to be translated to varying http status codes and translate ValidationErrors from pydantic to something that that is more inline with our API standards where we expect the message to be something like "field X is required" or field Y is empty" etc.

Looking for others who may have had issues here, or potentially more documentation that might help indicate whether we should use the event handler vs the non-core utilities. And if there are any real-world examples in there that would be bonus++.

Appreciate any help or assistance provided. This is a tool that looks super promising and cannot wait to use it on more projects.

[michaelbrewer]

There are some improvements I want to make to this. To make handling errors (like form validation type of errors) easier to manage and customerize. And for validation to be built in.

[michaelbrewer]

Maybe we can prototype some of these issues.

[bb-rrogers]

Sorry. Not really following, when you refer to 'this' you mean the API Gateway Handler?

Are you advocating that it should be used vs the other utilities for micro lambdas?

[michaelbrewer]

'this' you mean the API Gateway Handler

Correct.

And i am not really advocating for anything really. Personally i use and developed the API Gateway Handler due to the time spent setting up even just a simple endpoint (especially around cors, rest api handling, errors, binary types etc..).

There are some things they Bryson also mentioned in his usage that would be a nice thing to add around custom validation and error responses.

[brysontyrrell]

👋 Hey there.

I had a chance to talk with @michaelbrewer during re:Invent and walked through how we were using Powertools. We ran into challenges with how we wanted to handle API Gateway event sources with input/output schema validation.

What we ended up doing was using the aws_lambda_powertools.middleware_factory.lambda_handler_decorator to create a middleware that merged together the ideas of the API Gateway event handler and the JSON schema input/output validator.

Here's the interface:

from aws_lambda_powertools.utilities.data_classes import APIGatewayProxyEventV2

from api_common import api_middleware, ApiResponse


@api_middleware(
    event_data_class=APIGatewayProxyEventV2,
    input_validator=Draft7Validator("ConfigurationCreate.json"),  # validator class psuedo-code
    output_validator=Draft7Validator("Created.json"),  # validator class psuedo-code
)
def lambda_handler(event, context) -> ApiResponse:
    # Do stuff
    return ApiResponse(201, {"message": "Success"})

Setting event_data_class injects that dataclass into the event of the handler just like the built in Powertools handler.

We're using jsonschema and not fastjsonschema (which Powertools uses) for two reasons:

1. We didn't want default values to be set on the input after schema validation.
2. We wanted more control over the error responses.

The error response we standardize on looks like this:

{
    "id": "20554228-97b1-46ce-9236-a70dc58f8b6e",
    "code": "ValidationError",
    "description": "The request body failed validation",
    "details": {
        "validationErrors": [
            {
                "path": "$",
                "description": "'name' is a required property"
            }
        ]
    }
}

Here details is any arbitrary context data we want to include. By using Draft7Validator.iter_errors() we get back all validation errors and can return everything to the client in the 400 response.

We have standardized ApiResponse and ApiError that this middleware uses. It the ApiResponse object is also used by the ApiError type objects to once the middleware has finished it is able to return the appropriate response to API Gateway based upon the event data class that was set. ApiError will return the response in the format above automatically. Much like the API Gateway event handler in Powertools, you can raise ApiError and any of the subclasses of it anywhere within the Lambda Function handler to return a standardized error with or without added context.