Riverfount 
Novo post no blog: injeção de dependência com Dishka e FastAPI.
O sistema nativo de Depends() do FastAPI é ótimo até o momento em que você precisa de ciclos de vida diferentes por dependência, reutilizar serviços num worker Celery ou testar sem depender de banco real. A partir daí, começa a doer.
O artigo mostra como usar o Dishka — um container de IoC que entende escopo — para resolver isso: providers por Scope.APP e Scope.REQUEST, cleanup via yield, integração com FastAPI e testes com container substituto sem app.dependency_overrides.
Injeção de dependência do jeito certo: IoC com Dishka e FastAPI
Você já escreveu algo assim numa aplicação FastAPI? 1 2 3 4 5 6 7 8 9 @router.get("/orders/{order_id}") async def get_order(order_id: int): db = SessionLocal() try: repo = OrderRepository(db) service = OrderService(repo, settings.TAX_RATE) return await service.get_order(order_id) finally: db.close() O código funciona. Mas há um problema sério: cada endpoint é responsável por montar sua própria árvore de dependências. Quando OrderService precisar de um CacheClient e de um EventPublisher, quem vai sofrer é quem escreve — e depois testa — cada endpoint. O FastAPI tem seu próprio sistema de Depends() que resolve parte disso, mas tem limites quando a aplicação cresce e os grafos de dependência ficam complexos. É aqui que entra o conceito de Inversão de Controle e, mais especificamente, uma biblioteca que acerta onde o Depends() tropeça: o Dishka.
Habr
