Use dependencies outside route handlers

[mje-nz]

What's the feature you'd like to ask for.
It would be useful if we could use dependencies from middlewares, guards etc.

I'm not sure it makes sense for them to be magic like they are for route handlers, but if there were a method on Starlite that takes a top-level dependency name, collects that dependency's dependencies (if any), and returns a context manager for it that runs cleanups at the end (if any), it would help us keep things DRY.

Additional context
I'm trying to implement authentication with JWTAuth. Until now, I had my application structured such that the database interaction is abstracted into repositories, there is a module which sets up the SQLAlchemy plugin and injects a dependency for each repository, and the rest of the application uses only high-level interfaces and types.

However, I can't see how to access these dependencies from JWTAuth.retrieve_user_handler, so now I have to un-separate my concerns and repeat some of the database setup in the auth module. Currently I'm using connection.app.state.db_engine and getting a session and a user repository from there.

[provinzkraut]

It would be useful if we could use dependencies from middlewares, guards etc.

I'm afraid this isn't possible. Starlite's dependency injection mechanism isn't general purpose; It's tied closely to route handlers and requests. So the only solution is to place whatever you need somewhere in the dependency tree.

As for your concrete problem, I think this is in fact a bit of a design flaw. retrieve_user_handler will rely on a database connection probably 99% of the time, but since it's being called in a middleware it has to be restricted to what's available in that scope.

I think a solution could be offer an interface on the app to retrieve plugin instances, and for the SQLAlchemyPlugin to provide a more convenient method to create an ad-hoc session.

@starlite-api/maintainers I'd like some more input on this. This particular issue "how to get a db session in retrieve_user_handler has been brought up many times now, and we currently don't have a canonical solution for this basic use case, and the ones we do have are not very ergonomic.

[provinzkraut]

To work around this issue you could define your Engine and sessionmaker outside the SQLAlchemyPlugin and then just get your session from there.

[odiseo0]

I've always done it this way:

from __future__ import annotations

from contextlib import contextmanager
from typing import TYPE_CHECKING, AsyncGenerator

from .session import AsyncSessionFactory


if TYPE_CHECKING:
    from sqlalchemy.ext.asyncio import AsyncSession


async def get_db() -> AsyncGenerator[AsyncSession]:
    """Dependency that yields an `AsyncSession` for accessing the database."""
    async with AsyncSessionFactory() as db:
        yield db


@contextmanager
async def session() -> AsyncSession:
    async with AsyncSessionFactory() as db:
        return db

I use session outside the scopes of route functions, and if you want to use dependency injection, you should take a lot to di libraries. The one I use: di

[peterschutt]

I do have a recent experience to add to this. I haven't had to do a lot of work with authn at the starlite layer as we handle it at the network layer for the most part. However, I did need to do something recently that needed it.

I reached for a guard first, and then realized that I couldn't inject the session dependency into the guard, so I just used a regular dependency and do the auth in the __init__() of the service object.

Dependency provider looked something like this:

def provides_service(
    provider_id: UUID = Parameter(header="X-PROVIDER-ID"),
    api_key: SecretStr = Parameter(header="X-API-KEY"),
    db_session: AsyncSession = Dependency(),
) -> Service:
    """Constructs repository and service objects for the request."""
    return Service(provider_id=provider_id, api_key=api_key, session=db_session)

...I raise a generic unauthorized at the service layer, and then use exception handlers in starlite to translate that into a http 401 exception.

An advantage I see of doing it at the service layer is that the auth logic can be leveraged by cli and workers as well, but if there was a canonical way to access dependencies via guards or middleware at the time, I probably would have ended up just using that in this case.

[provinzkraut]

but if there was a canonical way to access dependencies via guards or middleware at the time, I probably would have ended up just using that in this case.

I think we can support dependencies in guards. Maybe we can redesign them a bit in general for 2.0?

If we add guards into the dependency graph, it would allow them to receive the same kwargs as dependencies as well, making them more convenient to use since they can opt to receive things such as query params, cookies and headers as needed, without having to go through the ASGIConnection.

Making the same data available in route handlers, dependencies and guards also makes for a better DX imo, since it's a bit more intuitive.

[peterschutt]

Making the same data available in route handlers, dependencies and guards also makes for a better DX imo, since it's a bit more intuitive.

Agreed!

[Goldziher]

but if there was a canonical way to access dependencies via guards or middleware at the time, I probably would have ended up just using that in this case.

I think we can support dependencies in guards. Maybe we can redesign them a bit in general for 2.0?

If we add guards into the dependency graph, it would allow them to receive the same kwargs as dependencies as well, making them more convenient to use since they can opt to receive things such as query params, cookies and headers as needed, without having to go through the ASGIConnection.

Making the same data available in route handlers, dependencies and guards also makes for a better DX imo, since it's a bit more intuitive.

Open in issue?

[mje-nz]

This particular issue "how to get a db session in retrieve_user_handler has been brought up many times now, and we currently don't have a canonical solution for this basic use case, and the ones we do have are not very ergonomic.

So to be clear: is the canonical way to implement retrieve_user_handler now "configure your own Engine and sessionmaker, provide them to SQLAlchemyPlugin, and store them in global variables or similar", or is that still up for discussion?

[provinzkraut]

@mje-nz Yes, it's either that or what @peterschutt suggested.