Сталкивался ли с ограничениями в Django

Ограничения Django: Реальный опыт

Да, я сталкивался с множеством ограничений Django в production. Расскажу про самые критичные.

1. Синхронная природа Django

Django по умолчанию работает синхронно. Для асинхронных задач требуется Celery или подобные инструменты.

# Проблема: долгая операция блокирует весь worker
def slow_view(request):
    result = process_large_file()  # 10 секунд!
    send_email()  # Это ждёт 5 секунд
    return Response(result)

Решение: Django Channels для WebSocket, Celery для фоновых задач

from celery import shared_task

@shared_task
def send_email_task(email):
    send_email(email)  # Выполнится в отдельном процессе

def view(request):
    send_email_task.delay(request.user.email)
    return Response({"status": "Email будет отправлен"})

2. N+1 Queries Problem

ОРМ легко создаёт множество ненужных запросов:

# BAD: Генерирует N+1 запрос (1 для users + N для каждого profile)
users = User.objects.all()
for user in users:
    print(user.profile.bio)  # Отдельный запрос!

# GOOD: Используем select_related / prefetch_related
users = User.objects.select_related("profile").all()
for user in users:
    print(user.profile.bio)  # Уже загружено

При 1000 пользователей разница: 1 запрос vs 1001 запрос. Это критично.

3. Монолитность

Django — это полноценный фреймворк со своим шаблонизатором, админкой, миграциями. Масштабировать становится сложно:

Django (монолит)
├── models
├── views
├── templates (админка)
└── migrations

Все связано, тяжело переиспользовать

Решение: FastAPI / аlchemy для API, Django для админки:

# FastAPI (быстрее, асинхронный)
from fastapi import FastAPI

app = FastAPI()

@app.get("/api/users/{id}")
async def get_user(id: int):
    user = await get_user_from_db(id)
    return user

4. Производительность ORM

Django ORM удобен, но генерирует неоптимальный SQL:

# Django ORM генерирует сложный JOIN
users = User.objects.filter(
    profile__age__gte=18,
    posts__status="published"
).distinct()  # distinct нужен из-за JOIN

# Реальный SQL может быть неоптимален для больших таблиц

Решение: raw SQL для критичных запросов:

with connection.cursor() as cursor:
    cursor.execute("""
        SELECT u.* FROM users u
        WHERE u.age >= %s AND u.id IN (
            SELECT user_id FROM posts WHERE status = %s
        )
    """, [18, "published"])
    result = cursor.fetchall()

5. Миграции и сложные схемы

Django миграции часто создают проблемы с большими таблицами:

# Добавляем NOT NULL поле к существующей таблице с миллионами записей
class Migration(migrations.Migration):
    operations = [
        migrations.AddField(
            model_name="user",
            name="status",
            field=models.CharField(default="active", max_length=10)
        )
    ]
    # Это "заморозит" БД на несколько часов!

Решение: zero-downtime миграции (аккуратно):

# 1. Добавляем поле с default
# 2. Заполняем данные в background
# 3. Добавляем NOT NULL ограничение
# 4. Удаляем старое поле

6. Ограничение по памяти при querysets

# BAD: Загружает все в память
all_users = User.objects.all()  # Может быть миллион строк!
for user in all_users:
    process(user)

# GOOD: Используем iterator() или chunking
for user in User.objects.all().iterator(chunk_size=1000):
    process(user)  # Загружает по 1000 за раз

7. Модели с множеством полей

class User(models.Model):
    # 50+ полей
    profile_data = JSONField()  # Вся остальная инфа
    metadata = JSONField()
    settings = JSONField()
    # При каждом запросе SELECT * грузим 50+ колонок

# GOOD: Используем only() / defer()
users = User.objects.only(
    "id", "name", "email"  # Грузим только эти поля
).all()

8. Тестирование

Django тесты медленные и требуют БД:

# Каждый тест создаёт БД, что долго
class UserTestCase(TestCase):
    def test_user_creation(self):
        user = User.objects.create(name="John")
        self.assertEqual(user.name, "John")

Решение: Использовать in-memory SQLite, моки, pytest-django:

# pytest-django с --reuse-db флагом
# 100 тестов вместо 2 минут выполняются за 20 секунд
runtime.exec("pytest --reuse-db")

9. Кэширование

Django кэширование простое, но нужно правильно использовать:

# BAD: Кэшируем без ключей, конфликты
cache.set("user", user_data)  # А если пользователей много?

# GOOD: Ключи с id
cache.set(f"user_{user_id}", user_data, timeout=3600)

# Or используем кэширование ORM
from django.views.decorators.cache import cache_page

@cache_page(60)
def user_list(request):
    return Response(User.objects.all())

10. Правильная архитектура

Для избежания проблем:

├── models/          # ORM модели
├── serializers/     # Сериализация (DRF)
├── views/           # Бизнес-логика
├── services/        # Сложная логика отдельно
├── repositories/    # Доступ к данным
└── tasks/           # Celery задачи

Выводы

Django отлично подходит для:

• CMS, админки, внутренних инструментов
• Стартапов с быстрым прототипированием
• Монолитных приложений среднего размера

Django плохо подходит для:

• Высоконагруженных систем (>100k RPS)
• Микросервисов
• Real-time приложений (чаты, games)
• APIs требующих асинхронности

Мой опыт: На production я часто комбинирую:

• FastAPI для основного API (асинхронный, быстрый)
• Django для админки и сложной бизнес-логики
• Celery для фоновых задач
• Redis для кэша и очередей

Этот подход избегает большинства ограничений Django, сохраняя его удобство.