RFC: Pass custom context dict to resolve method

Is this related to an existing feature request or issue?

https://github.com/awslabs/aws-lambda-powertools-python/discussions/1546

Which AWS Lambda Powertools utility does this relate to?

Event Handler - REST API

Summary

It would be useful if you could provide an optional dict to the app.resolve() method, that would then be available in the handlers themselves. This would contain generic information that is needed for all requests.

Use case

We are implementing callbacks for Twilio. For every event, we need to:

1. Decode the body
2. Parse the parameters
3. Validate the request

Next, we need the same parameters from step 2 in almost every request.

Proposal

Provide an extra parameter to the resolve() method:

app.py

from aws_lambda_powertools.event_handler import APIGatewayRestResolver
from aws_lambda_powertools.utilities.typing import LambdaContext

import todos


app = APIGatewayRestResolver()
app.include_router(todos.router)


def lambda_handler(event: dict, context: LambdaContext) -> dict:
    some_info = {"some_custom": "data"}
    return app.resolve(event, context, route_context=some_info)

In the handler itself, it could then be accessible via route_context:

todos.py

import requests

from aws_lambda_powertools.event_handler.api_gateway import Router
from requests import Response

router = Router()


@router.get("/todos")
def get_todos():
    some_data = router.route_context.get("some_custom")
   
    todos: Response = requests.get("https://jsonplaceholder.typicode.com/todos")
    todos.raise_for_status()

    return {"todos": todos.json()[:10]}

Out of scope

n/a

Potential challenges

n/a

Dependencies and Integrations

No response

Alternative solutions

Currently I’m passing the data in app.lambda_context.__dict__.

Acknowledgment

• This feature request meets Lambda Powertools Tenets
• Should this be considered in other Lambda Powertools languages? i.e. Java, TypeScript

[walmsles]

LGTM too! Love the clarity of thinking in the writeup, always impressed.

[heitorlessa]

Had more thoughts on this, discussed with @rubenfonseca and @leandrodamascena too. I’d like @MaartenUreel (main customer) and @walmsles final weight in here, before we decide Go/No Go.

Proposal: Add a new method called append_context in App/Router. This would be a Dict available under app.context and router.context. It’s similar to Logger.append_keys to ease cognitive load. It’s flexible enough to hold varying data and typing needs, keys might be overridden/cleared, and it’ll be cleared at the end of each invocation (safety). This keeps app.resolve() clean to its purpose whilst being a stepping stone for Middleware in the future (Progressive tenet).

Why: As you grow your number of related routes for your service (micro-Lambda or mono-Lambda), it’s common to end up with a few hundred lines of code in a single file - not everyone is comfortable with that. As you split, you can end up in a circular import scenario when dealing with global objects, if you’re not careful - testing becomes harder too.

Why not middleware: They complement each other. Context solves simple data passing while a middleware can use or further enrich that contextual data. For example, a fine-grained AuthZ middleware could append context data (e.g., Lambda function URL, not API GW as it’s a problem solved). It also helps isolate incoming event to data related to processing that event, where you don’t want to mix the two for logical or incompatibility reasons (event validation).

If you agree, I can help guide the implementation details for anyone with the bandwidth. I’d also welcome a RFC to support Middleware in Event Handler.

Thanks a lot everyone ❤️