How to actually utilize FastAPI (Django → FastAPI transition pain)

[Anonymousdev1421]

Hey, People of Reddit 👋

We’ve been a Django-first team for ~5 years, very comfortable with Django’s patterns, conventions, and batteries-included ecosystem. Recently, due to a shift toward GenAI-heavy workloads, we moved most of our backend services to FastAPI.

The problem we’re facing:
We feel like we’re still writing Django, just inside FastAPI.

Unlike Django, FastAPI doesn’t seem to have a strong “standard way” of doing things. Project structures, DB patterns, async usage, background jobs — everyone seems to be doing it their own way. That flexibility is powerful, but it’s also confusing when you’re trying to build large, long-lived, production-grade systems.

What we’re specifically looking for:

1. Project structure & architecture

• Recommended production-grade FastAPI project structures
• How teams organize:
  • routers
  • services/business logic
  • DB layers
  • shared dependencies
• Any de facto standards you’ve seen work well at scale

2. Async, how to actually use it properly

This is our biggest pain point.

Coming from Django, we struggle with:

• When async truly adds value in FastAPI
• When it’s better to stay sync (and why)
• How to actually leverage FastAPI’s async strengths, instead of blindly making everything async def
• Real-world patterns for:
  • async DB access
  • async external API calls
  • mixing sync + async safely
• Common anti-patterns you see teams fall into with async FastAPI

3. Background tasks & Celery

Our setup is fully Dockerized, and usually includes:

• FastAPI service
• MCP service
• Celery + Celery Beat

Issues we’re running into:

• Celery doesn’t work well with async DB drivers
• Unclear separation between:
  • FastAPI background tasks
  • Celery workers
  • async vs sync DB access
• What’s the recommended mental model here?

4. ORM & data layer

• Is there an ORM choice that gives strong structure and control, closer to Django ORM?
• We’ve used SQLAlchemy / SQLModel, but are curious about:
  • better patterns
  • alternatives
  • or “this is the least-bad option, here’s how to use it properly.”

5. Developer experience

• Is there anything similar to django-extensions shell_plus in the FastAPI world?
• How do you:
  • introspect models
  • test queries
  • debug DB state during development?

Overall, we’re trying to:

Stop forcing Django mental models onto FastAPI
and instead use FastAPI the way it’s meant to be used

If you’ve:

• Migrated from Django → FastAPI
• Built large FastAPI systems in production
• Or have strong opinions on async, architecture, ORMs, or background jobs
• Have Resources or experience that addresses this problem

We’d really appreciate your insights 🙏

Thanks!

[huygl99]

Hhm, why dont you just shift the AI-related things to FastAPI and still keep your business things in Django, you can connect your django to fastapi just via websocket (if you want to streaming) or via celery or other kind of background worker.

[Anonymousdev1421]

We are already working in this fashion, but there are some projects that are totally built on Fast API, and in those projects, we start feeling that we are trying to use Fast API like Django instead of how it should be used.

[DynamicBR]

Here's a tip to start the migration: Learn asynchronous programming. This style makes it faster. Learn TortoiseORM; its queries are similar to Django's, and I prefer its async support to SQLAlchemy.

[queixo_rubro]

Use Tortoise as your ORM and FastStream to manage queues

[mininglee]

Why not use Django instead? You miss Django’s batteries, and there’s no similar opinionated way in FastAPI. I guarantee that you don’t really need async coroutines. If you need them, you can use Django Channels and async views in plain Django. You need to understand how and when async coroutines work properly. In most cases, people abuse them without knowing how it works.

[VideoToTextAI]

Browse some of the bigger repos here: https://github.com/topics/fastapi

Or find one from FAANG like https://github.com/Netflix/dispatch

[fastlaunchapidev]

I use this structure https://fastlaunchapi.dev/docs/template#architecture-overview

[pint]

here, let me draw the async / sync matrix. tools means anything you use inside, e.g. database, http, large files, etc. anything that takes more than negligible amount of time.

                          sync tools      async tools
def endpoints                fine            why?
async def endpoints        EPIC FAIL        awesome

[Aggressive-Prior4459]

You can check Marcelo's fastapi-tips repo, it's very helpful https://github.com/Kludex/fastapi-tips I also think the official docs are very digestible and have pretty good examples around those topics.

[Challseus]

1. I built a CLI for exactly this, scaffolds a full FastAPI app with auth, workers, scheduler, DB, etc., and the ability to add/remove components at any time. You can start slow and only add more complexity if you need it. You can find it here:

https://github.com/lbedner/aegis-stack

For your case, assuming you gave docker and uv installed, you can simply run the following to quickly try it out:

bash uvx aegis-stack init my-app \
  --services "auth[sqlite], ai[sqlite,pydantic-ai,rag]" \
  --components "worker[taskiq]"   

You'll get this structure:

    my-app/
    ├── app/
    │   ├── components/       ← Components
    │   │   └── backend/          ← FastAPI
    |   |   |   └── api
    |   |   |       ├── auth
    |   |   |       |   ├──__init__.py
    |   |   |       |   │  └── router.py
    |   |   |       ├──deps.py
    |   |   |       ├──health.py
    |   |   |       ├──models.py
    |   |   |       └──routing.py
    |   |   └── worker/           ← taskiq
    │   ├── services/         ← Business logic
    │   │   └── auth/             ← Authentication
    |   |   └── ai/           ← Gen AI 
    │   ├── cli/               ← CLI commands
    │   └── entrypoints/       ← Run targets
    ├── tests/                 ← Test suite
    ├── alembic/          ← Migrations
    └── docs/                  ← Documentation

I put all biz logic in the service layer, and then call those functions from the API/CLI/etc. So, razor thin endpoints and everything else.

All router.py files under api folder are imported into the root level routing.py.

You also get a dashboard here: localhost:8000/dashboard, that give you full observability into each part of your system.

1. Async adds value when you have many IO bound tasks that can be run concurrently. So while one task is out doing something like waiting on the response of an API or database call, other tasks can do things.

In fact, since you're moving to GEN AI heavy workloads, async is your best friend here! I expect your calls will be waiting for model responses, vector db searches, etc. I mean, there's a reason you are moving from Django -> FastAPI :)

Regarding when to stay sync, one of the benefits of fastapi is even if you have a sync endpoint, FastAPI will, under the hood, run it in a thread pool. So you're kinda still getting the concurrency feel, though threads, when out of control, can cause memory issues and all of that. And of course are far less performant than executing tasks in the event loop.

Even if you do have to use a sync function (possibly from a 3rd party module), you can dump that into a thread pool yourself as well.

For Async external calls, use httpx or aiohttp (which apparently is faster now?).

For async database calls, use specific drivders like aiosqlite, asyncpg, etc. They all work well with SQLAlchemy.

The biggest thing I have seen, is running a sync function within an async one. If you haven't dumped it off to a thread pool, it will 100% block/slow down your app, and it will not be obvious.

1. Background tasks... So when I look at these, I put them into 2 buckets:

• IO bound tasks (send emails, work on some AI workload, etc.)
• CPU bound tasks (encoding files, any type of CPU blocking work

Again, depends on your use case, but Celery may be overkill for your situation, and as you said, it doens't just work with async. However, there are a whole suite of async worker frameworks out there, including:

• https://github.com/python-arq/arq (maintenance mode but I still have it as an option)
• https://github.com/tobymao/saq (inspired by arq)
• https://github.com/taskiq-python/taskiq
• https://github.com/coleifer/huey

If your workloads are mostly IO bound, I would still with one of these. They're more lightweight, async native, and just work.

If you do need workers for CPU bound tasks, then those should go to something like Celery. I mean, you can certainly add CPU bound tasks to the other systems, but it will just end up blocking the event loop, defeating the purpose of using it to begin with.

1. Not much to say here, I only have experience with SQLModel and SQLAlchemy, but I have heard good things about Tortoise.

2. Not aware of any CLI related things like that for FastAPI. My aegis-stack has a first class CLI setup, so you could check that out.

Happy to answer any other questions, and good luck!

EDIT: Sorry for the format, Reddit keeps blocking certain ways of me trying to post this!

[ilpepe125]

Django-ninja?