📖 Теория: контекст практикума

⚡ Контекст практикума — кратко

  • .env + django-environ: секреты (SECRET_KEY, пароли БД) нельзя хранить в коде; django-environ читает .env-файл и предоставляет типизированный доступ.
  • Приложение vs проект: проект — одна установка Django; приложение — модуль с бизнес-логикой. В одном проекте может быть много приложений.
  • URL → View: request приходит в urls.py, Django находит подходящий path(), вызывает view-функцию, та возвращает HttpResponse.

Зачем выносить конфигурацию в .env?

SECRET_KEY в Django используется для подписи сессий, CSRF-токенов и других криптографических операций. Если ключ попадёт в публичный репозиторий — безопасность приложения скомпрометирована. Та же проблема с паролями базы данных.

Стандартное решение — хранить чувствительные переменные в файле .env и добавлять его в .gitignore. Библиотека django-environ загружает этот файл при старте приложения и предоставляет удобные методы для чтения значений с корректными типами.

Правило: .env файл никогда не коммитится в репозиторий. Вместо него коммитится .env.example с пустыми или демо-значениями.

Структура Django-проекта

После выполнения django-admin startproject config . (точка означает «в текущей папке») создаётся:

myproject/
├── config/
│   ├── __init__.py
│   ├── settings.py      # Настройки
│   ├── urls.py          # Корневые маршруты
│   ├── asgi.py
│   └── wsgi.py
├── manage.py            # CLI Django
└── .env                 # Создаём вручную

Проект vs Приложение

Проект (config/) — точка входа: настройки, корневые маршруты, WSGI/ASGI. Приложение (first_app/) — самостоятельный модуль с моделями, views, urls, тестами. Один проект может содержать несколько приложений.

После python manage.py startapp first_app:

first_app/
├── __init__.py
├── admin.py
├── apps.py              # Класс FirstAppConfig
├── migrations/
├── models.py
├── tests.py
└── views.py

Жизненный цикл HTTP-запроса в Django

  1. Браузер отправляет GET /first/
  2. Django смотрит config/urls.py → находит include('first_app.urls')
  3. Переходит в first_app/urls.py → находит path('first/', views.first_view, ...)
  4. Вызывает функцию first_view(request)
  5. View возвращает HttpResponse → Django отправляет его браузеру

Условный выбор базы данных

Практикум вводит важный паттерн: использовать SQLite для локальной разработки и MySQL для production. Переключение происходит через переменную MYSQL=True/False в .env:

# settings.py
if env.bool('MYSQL', default=False):
    # Production: MySQL
    DATABASES = {'default': {'ENGINE': 'django.db.backends.mysql', ...}}
else:
    # Development: SQLite (по умолчанию)
    DATABASES = {'default': {'ENGINE': 'django.db.backends.sqlite3', ...}}