Consider using typed DI for Litestar instead the current one

[sobolevn]

Right now Litestar features a DI based on names. There might be different opinions about it, but I would say that many people would prefer to have a DI based on types.

I propose this idea:

• v3 will feature a new DI system based on types
• old DI would continue to work as-is and will be "soft deprecated" (no warning will be produced, only docs will state that it is deprecated)
• future releases will deprecate old DI with a proper warning
• eventually we will remove old DI in v4 or v5

First alternative

We can create our own implementation. It is not really hard to do in the very basic form. Good reference example is punq: https://github.com/bobthemighty/punq

import punq

container = punq.Container()

class ConfigReader:
    def get_config(self):
        return {"greeting": "abc"}

container.register(ConfigReader)

class Greeter:
    def greet(self): ...

class ConsoleGreeter(Greeter):
    def __init__(self, config_reader: ConfigReader):
        self.config = config_reader.get_config()

    def greet(self):
        print(self.config['greeting'])

container.register(Greeter, ConsoleGreeter)
container.resolve(Greeter).greet()

It is basically a single file, quite easy to read and maintain.
Writing some basic functionality will be quite easy.

Second alternative

But, getting all the features right is quite hard. I would advocate for trying to ship a default integraion for some existing DI provider.

The best one is https://github.com/reagento/dishka

It supports sync and async providers, cleanups, scopes, etc. Basically anything that any real-world production app can require.

It already has a working integration with Litestar: https://github.com/reagento/dishka/blob/develop/examples/integrations/litestar_app.py

But, we can make it even easier by removing explicit @inject decorator requirement and setup_dishka call.

Right now I would say that Dishka is already the most popular DI framework to be used with Litestar anyway.

CC @Tishka17

Third alternative

We can create an abstract API for using any DI you wish. It is the most complex and the most flexible solution.

We can call it "slots" DI.

I am open to hear opinions about it :)

Conclusion

This is a very early discussion about a very complex topic, please join and share your opinions / ideas :)

cc @provinzkraut

[Sehat1137]

Litestar will look great with the dishka

[Solarmove]

Да, дишка топчик. Спасибо Tishka)

[Peopl3s]

Dishka’s a great pick—it just works, already plays nice with Litestar, and ditches string-based magic for clean, type-driven DI.

[Danipulok]

Sounds really nice! I would like to migrate from FastAPI, but when I read about DI in litestar, it looked not so good to me. Dishka sounds like the best option!

[Evalve3]

Dishka is best option

[GiperBoreipy]

тащим дишку

[skarndev]

I would consider abstracting a DI framework into a separate API a better alternative. I would prefer to have DI working based on names, yet providing type checking capabilities.

For example:

class UserController(Controller):
    path = "/user"
    dependencies = {"user": Provide(retrieve_db_user)}

    @patch(path="/{user_id:uuid}")  
    async def get_user(self, user: User) -> User: ...

with dishka would become:

class UserController(Controller):
    path = "/user"

    @patch(path="/{user_id:uuid}")
    async def get_user(self, user: FromDishka[User]) -> User: ...

What if we need to inject two different "User" objects? I know this example is a bit out of this world with this naming, but could be applicable in other cases.

For example, dependency-injector offers a way to explicitly inject a dependency from an IOC container:

class UserController(Controller):
    path = "/user"

    @patch(path="/{user_id:uuid}")
    @inject
    async def get_user(self, user: User = Provide[SomeIOCContainer.user]) -> User: ...

This way we know exactly which user we inject while keeping the type checking.

[N1ntek]

You can use FromComponent in dishka, if I understood you right

[provinzkraut]

What if we need to inject two different "User" objects?

imo you should use NewType then. That would also generally be required if you've got two semantically distinct user objects that you want to differentiate within the type checker

[wimble3]

Punq is the best, dishka is too much, I don't need so complicated DI lib for DI =)

[Skorpyon]

Punq

• no dep lifecycle (no scopes)
• no async
  -> 🗑

[goduni]

Dishka really cool choice to implement it here

[ApostolFet]

Dishka x Litestar: rewriting the playbook.

[provinzkraut]

All those who would like to see Dishka integrated, could you explain a bit more what specifically you like about dishka and what features you'd want from it in Litestar?

[Skorpyon]

@provinzkraut

How would a typed-based system handle cases like this: https://github.com/orgs/litestar-org/discussions/4212?

from pretend import raiser, stub


class Prince:
    def new_session() -> Any:
        ...


class PrinceProvider(Provider):
    scope = Scope.REQUEST
    
    @provide(when=Has(Environment.PROD)
    def provide_prince() -> Prince:
        return Prince()

    @provide(when=Has(Environment.TEST)
    def provide_test_prince() -> Prince:
        # Create a mock prince that raises an error
        ps = stub(
            render_document=raiser(
                PrinceError("err", ["bad JSON in job chunk"])
            ),
        )
        fp = stub(new_session=lambda: ps)
        return fp


@post("/simple", media_type=MediaType.TEXT)
async def simple_handler(
    body: bytes,
    prince: Inject[Prince],
) -> Response[bytes]:
    ...


class Test:
    def test_render_failed(self):
        """
        Return 400 with error message if rendering fails.
        """
        with create_test_client(
            route_handlers=[simple_handler],
        ) as client:
            resp = client.post("/simple", content="yolo")

            assert 400 == resp.status_code
            assert "Rendering failed" in resp.json()["detail"]

[provinzkraut]

@Tishka17

@provinzkraut not yet. We were thinking about implementing this, but, actually you normally do not have I/o during dependencies creation. (Again, dependencies is not data you need to get and process. Create gateways and do I/o when it is needed). Or, at least, have it very rarely. So, positive effect of concurrent creation is very low, and the price of synchronization (you might reuse transitive dependebcies) and just task creation is comparable

I think the usage of DI in web frameworks differs a bit from this. It's fairly common to have IO in dependencies, things like "fetch user from database", "check permissions against DB", things like that. Another common pattern is to do something like this:

async def proivde_db_connection() -> Connection:
    async with connect(...) as conn:
        try:
            yield conn
            await conn.commit()
        except Exception:
           await conn.rollback()
           raise

here, you would also have significant IO occurring in the teardown phase of the provider.

I think this would be a must for us in order to adopt dishka, since it's a feature that has been a part of Litestar for a long time now and a lot of users (myself included 🙂) rely on it. Of course you can make do without it, but that might mean reconstructing your data flows.

[provinzkraut]

@Skorpyon so you would be forced to mix prod and testing code? I know it's not super uncommon to have testing code right beside the implementation, but I also know that a lot of people do not like this at all.

[Skorpyon]

@provinzkraut I just answer your question about concrete example. My opinion that it is not good to mix prod and testing. In my project I using dishka and I have two DI containers, prod one and one with mocked deps. So I just change one param for App(container=test_container).

Mainly my example was more about how to force DI solve deps for you instead of granular override in each test.

[Tapeline]

@Skorpyon so you would be forced to mix prod and testing code? I know it's not super uncommon to have testing code right beside the implementation, but I also know that a lot of people do not like this at all.

No, you can extract the test dependency into another provider:

class AppProvider(Provider):
    # prod dependencies 

class TestProvider(Provider):
    # test dependencies 

# when creating prod environment:
container = make_container(AppProvider())

# when creating test environment:
container = make_container(AppProvider(), TestProvider())

[Tishka17]

It's fairly common to have IO in dependencies, things like "fetch user from database", "check permissions against DB"

It is definitely not a dependency, but logic. Moreover, it often requires context data to work (for example, to check permission we might want to know which item is modified)

In fastapi world the mix dependencies and just data processing or even request parsing. I do not think it is a good idea.

[Tapeline]

but we have no mechanics to decide when we can parallelize it.

I suppose we can request dependencies simultaneously using something like await asyncio.gather(*(containter.get(dep) for dep in [Dep1, Dep2, DepN])). Question is -- can we finalize them this way too?

If we can, we can do it on Litestar side and not modify dishka's behaviour at all

[Tishka17]

Let's formalize requirements and write down some use cases. Maybe integration should be just a bit more clever than just calling dishka in all cases

[Tapeline]

Another way to organize it is to split injection into to phases:

When we want to run a handler...

1. Get all parameters marked Inject or FromDishka (API to discuss), then retrieve dependencies based on them.
2. Get all parameters marked Depends (the old api), then perform Litestar-side dependency resolution that behaves more or less like it is today, also providing dependencies from dishka.
3. Merge all arguments and pass to handler

Thanks to @Lancetnik for this example:

def get_user(request: Request, idp: Annotated[UserProvider, Inject()]) -> User:
     return await idp.get_user(request)

@get()
def handler(user: Annotated[User, Depends(get_user)]): ...

That is a compromise, because, as initially suggested, we will soft-deprecate old way of doing things in v3. This way we can merge functionalities to gradually deprecate and remove the old DI in v4 alongside with teaching "the right way to do it"

[provinzkraut]

Franky speaking, I know one way to do it - call functions. Yo do not need separate mechanic to call ensure_permission(data), you can just call it.

If you need it - we must specifiy requirements: which problem it solves, how and so on. Usecases are very different from IoC-container and I am not sure what are they.

It's not about a specific problem I have. It's just that this is an extremely common pattern people use DI in web frameworks for. So no matter if it's ideologically proper or best practice, it's the reality of how these things get used, and we definitely have and want to support this use case.

That is a compromise, because, as initially suggested, we will soft-deprecate old way of doing things in v3. This way we can merge functionalities to gradually deprecate and remove the old DI in v4 alongside with teaching "the right way to do it"

I don't think this is feasible for Litestar's use case. We don't want to, teach the whole user base a new "right way to do it". If that isn't something that's available long-term, or not the generally intended use-case of Dishka, then that puts a hard stop on implementing Litestar's new DI on top of Dishka unfortunately.

Maybe that's also not such a bad thing? There's multiple ways we discussed on how to implement the new DI, only one of them is to base it entirely on Dishka. Another option was to make it easier for 3rd party DI-systems to integrate into Litestar, i.e. making our DI pluggable. Perhaps that's the better way forward, because that way, Dishka users could get the full Dishka experience, without Litestar's requirements getting in the way.

[Tishka17]

From my perspective even integrating dishka into litestar we should have clear contract and option to replace it.