Как устроен Django: от запроса до ответа

Django в России до сих пор самый частый Python-фреймворк в вакансиях. На собесе ждут, что вы объясните жизненный цикл запроса, роль middleware и знаете, где в Django подводные камни.

Проект и приложения

• Проект это настройки (settings.py), корневые URL (urls.py), точки входа wsgi.py и asgi.py.
• Приложение (app) это модуль с моделями, вьюхами, админкой, миграциями. Подключается в INSTALLED_APPS. Хорошее приложение отвечает за одну предметную область.

Архитектура называется MTV: Model (данные), Template (представление), View (логика обработки запроса). Это тот же MVC, только «контроллером» служит сам фреймворк с роутингом.

Жизненный цикл запроса

1. WSGI или ASGI-обработчик создаёт HttpRequest.
2. Запрос проходит middleware сверху вниз по списку MIDDLEWARE.
3. URL-резолвер сопоставляет путь с urlpatterns и находит вьюху и параметры.
4. Вьюха получает request и параметры, работает с моделями и возвращает HttpResponse.
5. Ответ проходит middleware снизу вверх.
6. Сигнал request_finished, соединения с БД закрываются или возвращаются (по CONN_MAX_AGE).

URL и вьюхи

# urls.py
urlpatterns = [
    path('orders/<int:pk>/', views.order_detail, name='order-detail'),
    path('api/', include('api.urls')),
]

# views.py
def order_detail(request, pk):
    order = get_object_or_404(Order, pk=pk, owner=request.user)
    return render(request, 'orders/detail.html', {'order': order})

Конвертеры пути (int, slug, uuid, path) сразу проверяют и преобразуют параметры. name позволяет строить URL через reverse('order-detail', args=[pk]), а не хардкодить строки.

Вьюхи бывают функциями (FBV) и классами (CBV: ListView, DetailView, UpdateView). CBV дают переиспользование через миксины, FBV проще читать.

Middleware

Middleware это слой вокруг всех запросов: безопасность, сессии, CSRF, аутентификация, локализация, свои метрики и логирование.

class TimingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response      # один раз при старте

    def __call__(self, request):
        start = time.monotonic()
        response = self.get_response(request)
        response['X-Elapsed'] = f'{time.monotonic() - start:.3f}'
        return response

Порядок в MIDDLEWARE важен: SessionMiddleware должен идти раньше AuthenticationMiddleware, потому что пользователь определяется из сессии.

Настройки

settings.py это обычный Python-модуль. Секреты и параметры окружения берут из переменных окружения (os.environ, django-environ), а не из кода. Для прода обязательно: DEBUG = False, ALLOWED_HOSTS, SECRET_KEY из окружения, HTTPS-настройки. Проверка: python manage.py check --deploy.

Сигналы

post_save, pre_delete, m2m_changed позволяют реагировать на события моделей. Удобно, но опасно: логика становится неявной, сигналы не срабатывают при bulk_create и QuerySet.update, и их трудно отлаживать. Часто явный вызов сервиса лучше сигнала.

Админка и management-команды

Админка Django генерирует интерфейс по моделям: огромный плюс для внутренних инструментов. Свои команды (manage.py import_prices) кладут в management/commands/ приложения.

Частые ошибки

• Бизнес-логика в вьюхах и сигналах вместо отдельного слоя сервисов.
• DEBUG = True в проде: утечка настроек и трейсбэков.
• Хардкод URL вместо reverse и {% url %}.
• Тяжёлые запросы в middleware, которые выполняются на каждый запрос.
• Ожидание, что post_save сработает при bulk_create или update().

Что спросят на собесе

• Опишите жизненный цикл запроса в Django.
• Что такое middleware, как написать своё, почему важен порядок.
• Чем FBV отличаются от CBV.
• Что такое сигналы, когда их не стоит использовать.
• Что обязательно настроить перед выкладкой в прод.