RFC: Pass custom context dict to resolve method

[MaartenUreel]

Is this related to an existing feature request or issue?

#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

[boring-cyborg]

Thanks for opening your first issue here! We'll come back to you as soon as we can.
In the meantime, check out the #python channel on our AWS Lambda Powertools Discord: Invite link

[heitorlessa]

Hey @MaartenUreel thanks a lot for this! I like this idea more than an actual Dependency Injection mechanism ala FastAPI, since that would increase the bar to entry and over-complicate things.

Question: How are you envisioning route_context cleanup to prevent stale objects? Destroy route_context at the end of every request resolved?

If you have the bandwidth, feel free to start a draft implementation and a test. I'd expect route_context to be an empty dict by default to prevent basic TypeErrors when accessing, and help customers use sentinel values if a given context key isn't available.

[heitorlessa]

@walmsles @gwlester @benbridts - I'd be interested in your thoughts here.

[benbridts]

Would getting access to the original event (new feature, I think) also solve this (you could also add middelware instead of doing it in the handler?

I don't think this is necessarily better than the original proposal (as it's a bit more of a hack), but might be used for other things too.

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

# ...
@router.get("/todos")
def get_todos():
    return app.orignal_event["_extra_context"]["some_custom"]

My first reaction was "I might want this as a decorator instead of something in the handler - potentionally a middelware function"

# not sure if this is possible

@router.get("/todos")
@extra_context   # middelware you have te create yourself, fills in extra_context based on the original event
def get_todos(extra_context=None):
    pass

[gwlester]

My read is this is a request to add "user data" object to pass around with some application-specific (not event-specific) information.

Seems reasonable.

The workaround I've seen is to create a singleton class that has the "user data" in it and get the instance every place you need it.

Of course, I could be off in left feel and missing what is being asked for.

[heitorlessa]

What @gwlester said. This opens the door for a newer future we couldn't make progress yet (middleware support), so you could add additional context (user data) on a before/after request basis.. typically used in AuthZ, validation, etc.

@benbridts for event access, we provide that feature since launch ;)

[gwlester]

From the router we have access to the resolver. From the resolver don't we already have access to the event and context??

[heitorlessa]

Yes, you do. Both resolver and router inherit from BaseRouter, allowing you to access both app.current_event, app.lambda_context: https://github.com/awslabs/aws-lambda-powertools-python/blob/develop/aws_lambda_powertools/event_handler/api_gateway.py#L238. This RFC would implement a third class attribute to access "user data" (route_context, whatever naming we end up with)

[MaartenUreel]

My read is this is a request to add "user data" object to pass around with some application-specific (not event-specific) information.

Seems reasonable.

The workaround I've seen is to create a singleton class that has the "user data" in it and get the instance every place you need it.

Of course, I could be off in left feel and missing what is being asked for.

I was aiming at event-specific data, e.g. in my use case a dataclass.

[heitorlessa]

@MaartenUreel from the initial discussion you had, @gwlester is saying the same thing.. it's just the word "event-specific" that is confusing the intent.

One thing is to mutate the incoming event a Lambda receives (available at app.current_event). Another is to pass your CallContext you shared earlier within route_context -- technically, that would be "user data", not mutating the event.

[walmsles]

@heitorlessa, have been thinking about this and agree with @benbridts with the middleware/decorator approach rather than polluting the resolver.resolve() method with additional overhead. This feels like a custom use-case and today it's a dict, tomorrow it could be something different - middleware kind of resolves the ambiguity without opening that maintenance doorway.

Providing an easy mechanism to create route middleware I feel would be an approach that is more usable and is a utility that is useful for AWS Lambda powertools to provide.

I kind of played today at "rolling my own" and came up with the following (excuse the messy code):

from aws_lambda_powertools.event_handler import APIGatewayRestResolver
from aws_lambda_powertools import Logger
import functools

app = APIGatewayRestResolver()
logger = Logger()

def route_decorator(route_func):
    """Define route decorator middleware function to add my user data"""
    @functools.wraps(route_func)
    def wrapper(*args, **kwargs):
        kwargs["user_data"] = {"param1":"value1"}
        logger.info("calling route_decorator")
        return route_func(*args, **kwargs)
    
    return wrapper

@app.get("/hello")
@route_decorator
def hello_world(user_data=None):
    return {"message": "Hello World", "user_data": user_data}

@logger.inject_lambda_context(log_event=True)
def lambda_handler(event, context):
    return app.resolve(event, context)

The decorator has to sit after the route definition and at this point, the app.current_event object is populated so can do custom processing across this to parse parameters or other things. This also achieves the DRY principle and enables different processing for different routes which adds more flexibility IMO.