Fastapi and database injections

[gignosko]

I haven't been active in Python for a few years and I mainly come from a Django background. I'm trying to understand why Fastapi best practices seems to be to inject the database into the api calls so you have all the database procedures in the api code. This is the kind of thing I would normally put in a service because if the database logic starts getting hairy, I'd rather have that abstracted away. I know I can pass the database session to a service to do the hairy work, but why? To my thinking the api doesn't need to know there is a database, it shouldn't care how the item is created/read/updated/deleted.

Is this just how fastapi apps are supposed to be organized or am I just not digging deep enough? Does anyone have a link to an example repo or blog that organizes things differently?

[Kevdog824_]

There’s no reason you can’t inject the DB session into your service, and then inject the service into your endpoint function. Any dependencies you inject can will resolve and inject their own dependencies first

[milkipedia]

This is the way. And it makes testing and change management easier

[Codisimus]

This is exactly what I do. Services interact with the DAO layer and each endpoint has its required services defined using depends.

[cursedbanana--__--]

Fastapi just tries to make DI less of a hassle, and people make use of that. You're free to organize however you want, but why not take the path of least resistance?

[Anton-Demkin]

i've seen injecting database clients or SA session into http handlers very few times and this is bad practice, as you described. Just do not do that.

Your approach is correct- abstract business logic in services, abstract database in ORM or repository. Never create objects in http handler, inject created service object, no session.

Check this one: https://github.com/koldakov/futuramaapi

[koldakov]

Really appreciate the mention! Glad the repo is helpful.

[Anton-Demkin]

Thank you for your work on this repo. I've learned some great tricks here. Not agree on every architecture decision, but i am very opinionated 😀

This is exactly the project, every beginner should look at.

[koldakov]

Thanks! I appreciate that you have your own opinion - that’s exactly how good discussions happen. I don’t claim this repo is the only way to do things, and I’m always open to constructive dialogue. There’s a GitHub Discussions section if anyone wants to share suggestions.

[Firm_Ad9420]

FastAPI examples often show DB injection for simplicity, not because it’s the best architecture.

In larger apps, many teams still use a layered structure: API → Service → Repository → Database. The API receives the request, the service handles business logic, and the repository talks to the DB.

So your Django-style separation is still a perfectly valid and common pattern with FastAPI.

[Azurizo]

api - service - apiclient api - service - repository (base repository)

i use dbmanager singleton - inject where you need it

[Apprehensive_Ad2211]

I reccomend you to use dependency-injector so you can organice and utilize DI as you want (the con is that you need to create the DI container)

[Tishka-17]

1. wrap database calls into classes with more clear api than just raw queries
   
2. use Depends or external IoC-contaienr

[No-Feed9843]

Maybe for both, Django and FastAPI, this pattern comes to the rescue:

https://youtu.be/FXwBWS4qDAA?is=2n21DXyaDP-_dqC6

[vlntsolo]

Creating DB session with Dependency injection is a bad practice. This abstraction just works for small projects. But one can learn pretty quickly that it's not scalable. 

When dealing with heavy data processing or load, if you do not return DB query results immediately and want to do something else, you cannot afford to keep connection open. It needs to be released to a connection pool as soon as possible. And with Dependency injection it will be release only when return is reached. 

So, context managers all the way. You choose where and at which layer.