It would be really nice to have a place where to put your own dependency solver

@tiangolo sorry for ping, but you asked to create such discussion. Could you spend some of your attention here?

Hello! @YuriiMotov made me aware that the latest release had incompatible changes with FastStream and pointed me here.

I came to read and try to understand the use case better, but I'm struggling to see what the benefit of having a FastAPI integration would be. 🤔

The FastAPI dependency system is super simple, and coupled with the HTTP request data, as you have noted.

And I see you have your own internal Depends in FastStream. I would think it would be better and simpler to tell people something like:

You can use many of the same dependency functions with FastStream, as long as they don't require anything from the request, for example:

import fastapi
import faststream

def some_dependency() -> int:
    return 1

FastAPIDep = Annotated[int, fastapi.Depends(some_dependency)]
FastStreamDep = Annotated[int, faststream.Depends(some_dependency)]

And then you could use the FastAPIDep in FastAPI functions and FastStreamDep in FastAPI functions.

Or alternatively, you could also support:

FastAPIDep = Annotated[int, fastapi.Depends(some_dependency), faststream.Depends(some_dependency)]

The thing is, FastAPI dependency functions are normally defined in a way that is quite tightly coupled with FastAPI HTTP stuff, so I would imagine they wouldn't be able to just re-use the same dependency functions. And if they do, then those are probably very simple dependency functions (e.g. to get a DB session), and they can re-use the function with the new dependency as in the example above.

I struggle to see the benefit of bending how FastAPI works to solve dependencies for something that is not related to FastAPI or HTTP in general, and that also has its own equivalent way to achieve the same. 🤔

Could you share some examples of why people need this?

@tiangolo Hi! Thank you for your feedback. It's really valuable and I agree with you that this solution should work. I have the same opinion as you, but not all users. About 50% of users use our integration instead of native FastAPI + FastStream applications together. The main advantage of this integration is the ability to seamlessly use FastAPI's serialization, DI and BackgroundTasks mechanisms in endpoints to consume messages from RabbitMQ/Kafka/etc. In addition, it adds an AsyncAPI documentation section for these endpoints to the main application. You can check all features in the doc - https://faststream.ag2.ai/latest/getting-started/integrations/fastapi/

Since the current FastAPI syntax encourages people to create dependencies separately using the Annotated Dep = Annotated[type, fastapi.Depends()] mechanism, adding a FastStream endpoint to the same application for message consumption does not allow for native reuse of previously declared dependencies. Instead, you'll need to go through each one and change it by adding Dep = Annoated[type, fastapi.Depens(), faststream.Depends()]`. Also, although faststream depends are a copy of fastapi depends, the behavior may differ in certain details (for example, I haven't yet implemented or am unsure about whether I will add the scope feature from 0.121). Therefore, it would be more convenient and predictable for users if they could reuse all their previous FastAPI experience and existing Depends when working with event-driven endpoints, as if they were using the same framework.

For example, the Nest framework from NodeJS allows users to declare endpoints for any protocol - HTTP/AMQP/Kafka/MQTT/etc. - and the user loves it. I believe that this kind of integration with FastAPI can significantly enrich its ecosystem. Thus, it could be not just an "HTTP microframework", but the core of an entire ecosystem of ready-made modules where you can simply pip install AMQP / scheduler / authorization / S3 / etc and reuse all your experience from FastAPI without the need for additional learning of tools.

I want to apologize for being so intrusive earlier. I understand how difficult it is to maintain such a large framework. I admire your work and just cannot imagine how I could support my tool if overwhelmed by such flood of demands and requests. I do not want to be intrusive, but I am inspired by FastAPI and want its ecosystem to be richer. However, we need some coordination for this.