Description
Is your feature request related to a problem? Please describe.
In previous projects working with API Proxy and Lambda I found myself reusing a lot of repetitive code by copy and pasting. Tasks such as:
- routing different paths to functions
- validating a body against a model
- HTTP status code handling, like 4XX for validation errors, 5XX for generic errors, 2XX for success
- CORS handling
- Handling common set of errors like ResourceNotFound (404), InvalidRequest (400)
This HTTP boilerplate code should be more streamlined to the developer.
PS: I am willing to take this feature with your guidance.
Describe the solution you'd like
A middleware decorator abstracting many of the HTTP boilerplate code.
Describe alternatives you've considered
The before part of the middleware could handle model validation.
The middleware could assume a default correlation id based on the API request id.
The routing part is being handled by a different ticket #325. Maybe the functionality described here could be part of the same class. It could also handle an invalid path (not able to map to a handler function)
If a model is associated with a resource, the routing functionality could provide the validated model to the function as an extra param (or instead of the usual lambda handler params).
PS: Usually we map one resource to a lambda function with different methods. For example a CRUD of an Order resource with GET, POST, PUT and DELETE all go to the same function. It is a general best practice to have lambda functions with a single responsibility, but this could also lead to hundreds of lambda functions. We try to find a balance between LambdaLyth and too many Lambda functions.
The exception handler could expect a set of predefined error classes, like InvalidRequest, ResourceNotFound, etc. These errors might be thrown by the lambda handler implementation (Resource not found) or by the middleware per se (Invalid request, model validation). The errors are mapped to HTTP requests.
The error handlers can add logs with additional metadata like the error name, status code, correlation_id, stack trace and any other data that could be relevant in CW Log Insights or other analytical process.
Any HTTP boilerplate like headers required by CORS are added by the code after execution or error handling. A CORS handling flag could be passed to the decorator.
Additional context
Metadata
Metadata
Assignees
Type
Projects
Status