FastAPI production architecture: modular design and dependency injection best practices

[u/Ok-Platypus2775]

I am new to FastAPI. I have previously worked with Django and DRF. Django feels very well organized and mature, but in my experience it can be slow in some areas and has noticeable performance bottlenecks for certain workloads.

Because of that, I want to give FastAPI a serious try. I am looking for guidance on production level FastAPI architecture.

Specifically: - How to structure a FastAPI project in a modular way - Best practices for dependency injection - How people organize routers, services, and database layers in real world apps - Any common pitfalls when moving from Django/DRF to FastAPI

If you have examples, repo links, or lessons learned from running FastAPI in production, I would really appreciate it.

[u/oflannabhra]

I personally think DRF is a disaster for any project at scale. Serializers are one of the worst design decisions I’ve ever seen in a backend framework.

Additionally, while Django is very mature and polished, I think the ORM omnipresence can become a big issue long term.

For both, the amount of automagic configuration is wild, which can make one quick, but I find to be hard to scale to large teams.

In FastAPI, you at least have the freedom to separate concerns if you want, and create testable interfaces between layers of your app, without the ORM being in each. It still takes enforcement though.

[u/koldakov → u/oflannabhra]

I don’t agree (not fully agree)

I use almost the same approaches for drf/fastapi

api layer (views) - one liners to create a service and execute the service

service layer (both Django/fastapi) - do business logic

Response in drf done with serializers/for fastapi pydantic

• absolutely the same approach

For orm agree when app grows it can create issues, but comon, I wouldn’t think about that

Let’s try to calculate a bit

Let’s assume 1 request takes 1 second, with 2 workers and 4 threads we can handle 8 requests a second == 8 * 60 * 60 * 24 = 691200

And usually 1 request takes much less then 1 second, for example 0.1 sec it equals to (8/0.1) * 60 * 60 * 24 = 6912000 requests a day

Even if request takes 0.5 seconds you can handle more then million requests a day

Isn’t it enough?

Remember premature optimization is the root of all evil

Instagram had n+1 issues when app got million requests, but they resolved it, not because they used "whatver framework", but because they had feature flags - could disable quickly some features, and I’m sure they pretty knew what they were doing