Неофициальный и консервативный FAQ по Django

Django быстр, многофункционален, безопасен, масштабируем, гибок. Он хорошо взаимодействует с различными рабочими потоками, инструментами, платформами и библиотеками.В этом FAQ вы найдёте ответы на часто возникающие вопросы, которых нет в официальном FAQ. Конечно, универсальных ответов нет, но, возможно, этот FAQ сможет немного прояснить обстановку.

Flask или Django?

В большинстве случаев — Django.

Но, если у вас маленькое приложение или скрипт, и вы просто хотите добавить HTTP API, то, конечно же, используйте Flask.
Но в других случаях, с усложнением ваших приложений, вам нужно будет внедрять всё больше и больше функциональности, вы будете использовать всё больше и больше библиотек, и с Flask’ом вы просто запутаетесь. Поэтому для больших проектов используйте Django.

Нужно ли разбивать свой код на отдельные приложения?

Скорее нет.

Разделение полезно при многократном использовании повторяющихся функций. Когда вы делаете своё собственное приложение, а особенно, если вы только новичок, организовать всё в одном месте будет намного лучше. В какой-то момент вам, возможно, захочется разделить всё на отдельные модули, и в этот момент у вас уже будут намечены чёткие границы, где и что разделять. Это лучше, чем сначала создать структуру, а потом бороться с последствиями изменений.

Стоит использовать DTL (Django’s default template language) или что-нибудь другое?

Используйте DTL.

По умолчанию он уже есть в пакете Django, и в принципе может выполнять всё, что вам нужно.

DTL не делает то, что мне нужно, могу я использовать Jinja2?

Всё равно используйте DTL.

Наиболее частая претензия: “DTL недостаточно гибкий”. Но нужно учитывать, что есть определённые алгоритмы, реализовать которые на шаблонном языке невозможно.

Запомните, все “мозги” вы содержите во Views, а шаблоны выступают в роли визуализаторов.

Что использовать для запуска Django — uWSGI или Gunicorn?

Однозначно Gunicorn.

Gunicorn — автономный WSGI HTTP сервер, довольно неплохой, развёртывание происходит быстро и просто.

uWSGI предоставляет полный стек для построения хостинг-сервисов, если это то, что вам нужно — используйте его.

Где мне стоит разворачивать своё приложение?

В качестве примера посмотрите, как написать Telegram-бот на Python и задеплоить его на Heroku.

Если вам нужно больше управляемости или вы привязаны к AWS, то используйте AWS Elastic Beanstalk.

Вы, конечно, можете взять простенькую VM, установить туда nginx и настроить всё сами. Но зачем, если для этого уже существуют готовые решения?

Создать свою собственную платформу то же самое, что написать новую ОС. Зачем возиться?

Что использовать для обслуживания статических файлов?

Whitenoise.

Amazon S3, Nginx, Apache — все они хороши, но Whitenoise относительно маленькая библиотека, которая помогает обслуживать статические файлы без использования сторонних сервисов.

Я пытаюсь заставить панель администратора сделать …

Может быть, не надо? Панель администратора Django — хорошая штука, но ссылаясь на официальную документацию:

Возможности панели ограничены. Она не предназначена для того, чтобы в неё ещё что-нибудь добавляли.
У панели администратора есть много возможностей для кастомизации, но не переусердствуйте. Если вам нужен более процессо-ориентированный интерфейс, который абстрагирует базы данных, поля и таблицы, время задуматься о написании своей панели.

Если вы до сих пор ломаете голову, как подстроить администратора под себя, — перестаньте. Пойдите и попробуйте сделать что-нибудь с generic views.

Какую базу данных использовать?

PostgreSQL.

Она просто работает.

Стоит ли разделять файл конфигурации между разработкой и продакшном?

Нет, не стоит.

Twelve-Factor App охватывает ряд причин, по которым файлы конфигурации в приложении для каждой среды могут быть проблематичными, и почему вместо этого стоит использовать переменные окружения. django12factor и другие приложения помогут вам получить конфигурацию из окружения.

Стоит ли использовать кастомную модель пользователя?

Из официальной документации:

При запуске нового проекта настоятельно рекомендуется настроить модель пользователя, даже если вам достаточно установок по умолчанию. Эта модель будет вести себя идентично модели по умолчанию, но вы сможете модифицировать её в будущем, если возникнет необходимость.

Если вы находитесь посреди процесса разработки, всё немного сложнее…

Это изменение не может быть сделано автоматически и требует ручной работы, перемещения данных из старой таблицы пользователя и, возможно, ручного повторного применения некоторых миграций.