Alternative to decorators that uses dependency injection

[trashdid]

I have a route that essentially returns a single level BOM for a part. I want to validate that the user requesting the data has access to the top level part and that requires me to call a service function. Originally, I had the two service calls in the router function to validate that the user can see the part, then get the BOM data. I wanted to abstract it out so I can use the same logic on other parts. My first thought was to use a decorator:

def can_user_see_part(func):
    @functools.wraps(func)
    async def wrapper(*args, **kwargs):
        part_number = kwargs.get("part_number")
        part_service: PartService = cast(PartService, kwargs.get("part_service")

        await part_service.can_user_see_part(part_number)
        return await func(*args, **kwargs)

    return wrapper

This will throw an error if the user cannot see the part, and will not execute the function.
In my controller, the function its being used in looks like this:

@get(
        operation_id="GetBom",
        path="/{part_number:str}/bom",
        media_type=MediaType.JSON,
        raises=[NotFoundException],
    )
@can_user_see_part
async def get_part_bom(
     self,
     part_number: str,
     part_service: PartService,
 ) -> list[PartBomComponent]:
     return await part_service.get_part_bom(
        part_number=part_number
    )

My concern with this approach is that it might be an anti-pattern in the litestar framework. I have been trying to look at other approaches like a guard or the before request, but my understanding, which may be wrong, is the dependency resolution occurs after the guard and before requested are executed. Since the Service is resolved via the dependency injector, I have to execute the check after that occurs. Does anyone have any ideas on if there are other ways to achieve this? Is this the best approach? The only other way that I can think of is by using the dependencies and have it look like this:

def can_user_see_part(part_number: str, part_service: PartService) -> str:
     await part_service.can_user_see_part(part_number)
     return part_number

@get(
        operation_id="GetBom",
        path="/{part_number:str}/bom",
        media_type=MediaType.JSON,
        dependencies={"part_number": Provide(can_user_see_part)}
        raises=[NotFoundException],
    )
async def get_part_bom(
     self,
     part_number: str,
     part_service: PartService,
 ) -> list[PartBomComponent]:
     return await part_service.get_part_bom(
        part_number=part_number
    )

Any insights or thoughts on this would be greatly appreciated.

[vinicq]

Your second approach (the Provide dependency) is the idiomatic Litestar pattern for this. Your instinct is right.

A few clarifications on why the decorator fights the framework.

Litestar's handler resolution uses signature-based DI. When you wrap the handler in a decorator that does *args, **kwargs, you lose the signature inspection Litestar relies on. Your snippet works because Litestar has already resolved the parameters before the decorator runs, but you're now leaning on internal call shape. If injection threading changes (sync vs async dispatch, middleware-level wrapping), the decorator silently breaks.

On guards, they run before dependency resolution, not after, so they have the connection scope but not the resolved services. That makes them right for cheap checks (does the request have a header? is this under /admin?) and wrong for "I need PartService to answer this".

So the dependency you wrote is the cleanest expression of "this check runs after services are resolved, before the handler body":

async def assert_user_can_see_part(
    part_number: str,
    part_service: PartService,
) -> str:
    await part_service.can_user_see_part(part_number)
    return part_number

@get(
    path="/{part_number:str}/bom",
    dependencies={"part_number": Provide(assert_user_can_see_part)},
)
async def get_part_bom(
    part_number: str,
    part_service: PartService,
) -> list[PartBomComponent]:
    return await part_service.get_part_bom(part_number=part_number)

Small naming tweak. Name it as an assertion (assert_user_can_see_part or check_user_can_see_part) so the call site reads as a precondition. The fact that it returns part_number is incidental, the side effect is the contract.

For broader reuse across many routes, lift the dependency to the controller or router level instead of repeating it on each handler.