🚀🔥 PyAA: Django and FastAPI together in the same application, done right

[lofty bridge]

🚀 PyAA: Django and FastAPI in the same application

Over time working with Django, I noticed a recurring challenge that many developers face 🐍. Django is excellent for building full web applications, but when a project starts to require async features, WebSockets, modern APIs and higher performance, the architecture often becomes more complex than expected ⚠️.

I ran into this problem myself.

Django continued to be a solid foundation for web applications, while FastAPI offered native async support, WebSockets and a very efficient API layer ⚡. The difficulty was combining both in a simple and maintainable way, without splitting the project or increasing operational complexity.

That’s why I built PyAA.

PyAA allows Django and FastAPI to run together in the same application, with clear responsibilities. Django handles the website, admin, ORM, authentication and background tasks, while FastAPI focuses on async workloads, APIs, WebSockets and performance 🔌.

This approach results in a clean and scalable architecture 🌍. The API layer currently has around 99% test coverage, which helps ensure stability and confidence as the project evolves 🧪.

PyAA is open source and designed to be a practical foundation for web applications, APIs and SaaS projects built with Python.

📦 Repository:
https://github.com/paulocoutinhox/pyaa

If you work with Django and care about async features and performance, this project may be useful to you 💡

[delicate bone]

Very nice Paulo, good job. I have some questions if you don't mind.

• What are the problems you face with websockets in django?
• What are modern APIs?
• When we're talking about performance, against what scale are we measuring?

[lofty bridge]

In my specific case, the main problem with using WebSockets and async features directly in Django appeared when the application started to rely heavily on AI workloads 🤖. The system makes constant calls to LLMs, generates embeddings, processes vectors, handles long-running I/O operations and keeps multiple connections open at the same time. In a Django-only setup, even with async views and Channels, performance degraded quickly and resource usage became unpredictable 😕⚠️.

Modern APIs, in this context, are not just REST endpoints returning JSON 🚀. They need to efficiently handle async I/O, long-lived WebSocket connections, streaming responses, background AI processing and high concurrency without blocking. When dealing with LLM calls, vector databases and external AI services, the architecture must be lightweight and async-first to avoid unnecessary overhead ⚡🧠.

When we talk about performance here, we are measuring against real-world AI-driven workloads, not simple CRUD operations 📈. This means many concurrent users, multiple parallel AI requests, vector generation, embedding calculations and constant network I/O. In Django-only architectures, this quickly led to high latency and poor scalability. After moving this layer to a FastAPI-based API, the application became noticeably lighter and more stable, likely due to FastAPI and Starlette being designed from the ground up for async execution and high-performance I/O 🔥🏗️.

[lofty bridge]

With Django Channels, you’re not strictly forced by the framework to use Daphne, but in practice you almost always end up relying on it 😕. Daphne is the officially supported and most documented ASGI server for Channels, which means it’s the safest choice and the one most examples and production setups are built around. While other ASGI servers may work, using them often involves more uncertainty, less documentation, and higher operational risk. This effectively reduces flexibility, especially when you already have well-optimized and battle-tested ASGI setups like Gunicorn with Uvicorn workers available ⚡🚀.

[rough crest]

(FWIW, these responses read highly as potentially AI-generated text, so this is just a reminder that we would much rather discussions with real people than AI. Apologies if this is just your personal writing style—unfortunately it is one that has been mimicked heavily by most GPT chat bots recently.)