Мобильная версия для Django-проекта
С каждым днем пользователи смартфонов занимают все большую долю интернета. По данным LiveInternet доля российских пользователей OS Android уже превысила долю Windows7. В выходные дни пользователи мобильных платформ пользуются интернетом значительно чаще. Та же тенденция наблюдается и в мире. Все это еще раз доказывает необходимость адаптации сайта для смартфонов и планшетов.
О том, как можно адаптировать ваш Django-проект для мобильных устройств, я расскажу в этой статье. Но сначала давайте разберем, какие есть варианты создания мобильной версии сайта.
1. Варианты мобильной версии сайта
1.1 Адаптивная верстка
В этом случае мы отдаем одинаковое количество данных для большой и мобильной версии сайта. Этот подход самый простой для backend разработки, все решается версткой.
1.2 Мобильная версия на поддомене
По сути, это два отдельных сайта. Такой подход решает проблемы лишнего трафика, дает больше гибкости и возможностей в разработке версии для мобильных устройств. Однако при этом вопрос, какую версию показывать пользователю, решается сервером, а не браузером. Также нужно дать возможность пользователю выбрать, какая версия сайта ему нужна, и «подружить» обе версии сайта редиректами и альтернейтами.
Разные URL одной страницы приводят к недостатку этого способа: относительные ссылки в материалах сайта могут вести на страницы, отсутствующие в мобильной версии. Поэтому приходится указывать абсолютные ссылки на основной домен и потом редиректить пользователя на нужную версию. Решением этого недостатка будет полностью соответствующие большая и мобильная версии, но в этом случае правильнее идти третьим способом.
1.3 Мобильная версия на том же домене
Это доработка первого подхода и решение его минуса с трафиком и лишней нагрузкой. Реализуется он так же как с поддоменом: вы определяете, какая версия нужна клиенту, и отдаете нужное количество данных в нужный шаблон. Одинаковый URL для обоих версий сайта — безусловно плюс. Хотя проблема организации контента для обоих версий еще остается, но решать ее уже проще, так как ограничения на одинаковые данные уже нет.
1.4 Наш опыт
В отделе контентных проектов Mail.Ru Group мы используем второй подход, хотя и плавно движемся в сторону третьего. Проекты Дети Mail.Ru и Здоровье Mail.Ru написаны на Django, оба имеют мобильные и/или тач версии. Несмотря на то, что проекты под капотом немного отличаются, механизм создания мобильных версий у них одинаков. Об этом я хочу с вами поделиться.
2. Исходные соглашения
2.1 Все роуты мы именуем
И обращаемся к ним всегда по этому имени.
Мы никогда не собираем URL’ы сами в контроллерах или шаблонах, они указаны только в urls.py. DRY.
2.2 Используем django-hosts
Об этой библиотеке уже упоминали на Хабре. Изначально мы ее использовали на «детях» для форума на поддомене, сейчас форум переехал у нас на основной хост, и эта библиотека используется только для мобильный версий.
2.3 Отдельные контроллеры для большой и мобильной версии
Несмотря на то, что порой контроллеры большой и мобильной версий сайта отдают в контекст одинаковые данные, мы их разделили на отдельные функции/классы. Да, между ними есть дублирование, но зато код становится понятней без лишних абстракций и проверок, когда какие функции нужны и в каком виде.
3. Разработка мобильной версии
Мобильная версия должна решать следующие задачи:
3.1 Определение версии сайта
С какого устройства пользователь зашел на наш проект мы определяем с помощью нашего модуля nginx. Выглядит это примерно вот так:
Модуль опредеяет тип версии, которую нужно показать (m или touch), но если у пользователя стоит кука mobile, мы игнорируем это. Результат передается в виде http заголовка на бэкенд.
Дальнейшая обработка запроса происходит в middleware.
3.2 Переход на большую версию сайта
К сожалению, иногда страницы мобильной версии отличаются от основной. Та информация, которая легко помещается на большой версии, в мобильной разделяется на 3 страницы. Поэтому отбрасывать поддомен и редиректить на тот же URL, было бы неправильно. Мы выбрали следующий алгоритм:
Атрибут go_url_name назначается через декоратор
А декоратор never_use_mobile ставит куку mobile для отмены автоматического редиректа
К сожалению, тач версии развиваются после основных разделов и не всегда соответствуют страницам на большой версии, поэтому такой код приходится держать.
Атрибут go_view_name просто подменяет имя роута для страницы-аналога. Это довольно ограниченное решение, но его пока хватает.
3.3 404 для мобильной версии
Вы можете не просто сообщать пользователю о том, что страница не найдена, но и указать, что такая страница есть в полной версии сайта. При этом проверить URL по схеме URL’ов недостаточно: запрос /news/foo/ соответствует схеме URL’ов, а новости такой нет. Поэтому надо попытаться выполнить функцию контроллера в основной схеме урлов. Есть еще одна тонкость: надо подменять текущую схему URL’ов для большой версии, так как она нужна функциям reverse и тегу url. Иначе вы будете рендерить страницу большой версии в схеме URL’ов мобильной.
3.4 Мета теги alternate и canonical
Эти URL’ы строятся с помощью функций или шаблонных тегов приложения django-host.
Мобильная версия для Django-проекта
С каждым днем пользователи смартфонов занимают все большую долю интернета. По данным LiveInternet доля российских пользователей OS Android уже превысила долю Windows7. В выходные дни пользователи мобильных платформ пользуются интернетом значительно чаще. Та же тенденция наблюдается и в мире. Все это еще раз доказывает необходимость адаптации сайта для смартфонов и планшетов.
О том, как можно адаптировать ваш Django-проект для мобильных устройств, я расскажу в этой статье. Но сначала давайте разберем, какие есть варианты создания мобильной версии сайта.
1. Варианты мобильной версии сайта
1.1 Адаптивная верстка
В этом случае мы отдаем одинаковое количество данных для большой и мобильной версии сайта. Этот подход самый простой для backend разработки, все решается версткой.
1.2 Мобильная версия на поддомене
По сути, это два отдельных сайта. Такой подход решает проблемы лишнего трафика, дает больше гибкости и возможностей в разработке версии для мобильных устройств. Однако при этом вопрос, какую версию показывать пользователю, решается сервером, а не браузером. Также нужно дать возможность пользователю выбрать, какая версия сайта ему нужна, и «подружить» обе версии сайта редиректами и альтернейтами.
Разные URL одной страницы приводят к недостатку этого способа: относительные ссылки в материалах сайта могут вести на страницы, отсутствующие в мобильной версии. Поэтому приходится указывать абсолютные ссылки на основной домен и потом редиректить пользователя на нужную версию. Решением этого недостатка будет полностью соответствующие большая и мобильная версии, но в этом случае правильнее идти третьим способом.
1.3 Мобильная версия на том же домене
Это доработка первого подхода и решение его минуса с трафиком и лишней нагрузкой. Реализуется он так же как с поддоменом: вы определяете, какая версия нужна клиенту, и отдаете нужное количество данных в нужный шаблон. Одинаковый URL для обоих версий сайта — безусловно плюс. Хотя проблема организации контента для обоих версий еще остается, но решать ее уже проще, так как ограничения на одинаковые данные уже нет.
1.4 Наш опыт
В отделе контентных проектов Mail.Ru Group мы используем второй подход, хотя и плавно движемся в сторону третьего. Проекты Дети Mail.Ru и Здоровье Mail.Ru написаны на Django, оба имеют мобильные и/или тач версии. Несмотря на то, что проекты под капотом немного отличаются, механизм создания мобильных версий у них одинаков. Об этом я хочу с вами поделиться.
2. Исходные соглашения
2.1 Все роуты мы именуем
И обращаемся к ним всегда по этому имени.
Мы никогда не собираем URL’ы сами в контроллерах или шаблонах, они указаны только в urls.py. DRY.
2.2 Используем django-hosts
Об этой библиотеке уже упоминали на Хабре. Изначально мы ее использовали на «детях» для форума на поддомене, сейчас форум переехал у нас на основной хост, и эта библиотека используется только для мобильный версий.
2.3 Отдельные контроллеры для большой и мобильной версии
Несмотря на то, что порой контроллеры большой и мобильной версий сайта отдают в контекст одинаковые данные, мы их разделили на отдельные функции/классы. Да, между ними есть дублирование, но зато код становится понятней без лишних абстракций и проверок, когда какие функции нужны и в каком виде.
3. Разработка мобильной версии
Мобильная версия должна решать следующие задачи:
3.1 Определение версии сайта
С какого устройства пользователь зашел на наш проект мы определяем с помощью нашего модуля nginx. Выглядит это примерно вот так:
Модуль опредеяет тип версии, которую нужно показать (m или touch), но если у пользователя стоит кука mobile, мы игнорируем это. Результат передается в виде http заголовка на бэкенд.
Дальнейшая обработка запроса происходит в middleware.
3.2 Переход на большую версию сайта
К сожалению, иногда страницы мобильной версии отличаются от основной. Та информация, которая легко помещается на большой версии, в мобильной разделяется на 3 страницы. Поэтому отбрасывать поддомен и редиректить на тот же URL, было бы неправильно. Мы выбрали следующий алгоритм:
Атрибут go_url_name назначается через декоратор
А декоратор never_use_mobile ставит куку mobile для отмены автоматического редиректа
К сожалению, тач версии развиваются после основных разделов и не всегда соответствуют страницам на большой версии, поэтому такой код приходится держать.
Атрибут go_view_name просто подменяет имя роута для страницы-аналога. Это довольно ограниченное решение, но его пока хватает.
3.3 404 для мобильной версии
Вы можете не просто сообщать пользователю о том, что страница не найдена, но и указать, что такая страница есть в полной версии сайта. При этом проверить URL по схеме URL’ов недостаточно: запрос /news/foo/ соответствует схеме URL’ов, а новости такой нет. Поэтому надо попытаться выполнить функцию контроллера в основной схеме урлов. Есть еще одна тонкость: надо подменять текущую схему URL’ов для большой версии, так как она нужна функциям reverse и тегу url. Иначе вы будете рендерить страницу большой версии в схеме URL’ов мобильной.
3.4 Мета теги alternate и canonical
Эти URL’ы строятся с помощью функций или шаблонных тегов приложения django-host.
10 пакетов Django, которые вы должны знать
Вы вскоре собираетесь начать проект на Django? Вероятно, вам любопытно, есть ли какие-нибудь полезные пакеты, которые могли бы вам помочь. Мы составили список самых нужных пакетов Django. Приложенные короткие описания и ссылки на сами пакеты помогут вам начать работать с ними как можно скорее. Все пакеты, которые мы выбрали, поддерживают Python 3 и находятся в стабильной версии.
Готовы ли вы исследовать мир пакетов Django? Погружаемся!
Но прежде всего — является ли Django библиотекой?
В мире инструментов Python легко заблудиться, ведь сегодня в его экосистеме доступно так много новых фреймворков и библиотек. Но все же стоит уточнить: Django — это не библиотека, а фреймворк.
Django — бесплатный высокоуровневый фреймворк с открытым кодом для разработки веб-приложений на Python, позволяющий ускорить разработку и создавать более чистый дизайн. Он был создан избавить программистов от лишних хлопот, связанных с разработкой веб-приложений, без необходимости заново создавать велосипед. А значит – писать меньше строк кода!
Благодаря своей невероятной скорости, высокой безопасности, гибкости и масштабируемости Django быстро набирает обороты и сегодня является одной из самых популярных технологий для веб-разработки на Python.
Разница между модулями и пакетами в Django?
Модули и пакеты иногда путают друг с другом, поэтому, прежде чем перейти к нашему списку, давайте рассмотрим разницу между ними.
Модуль — это один файл Python, а пакет — это каталог таких модулей. В отличие от простых директорий, содержащих скрипты Python, пакет содержит еще и дополнительный файл — _init_.py.
Лучшие пакеты Django
Примечание: поскольку есть несколько веских причин, по которым написание фронтенда при помощи Django является не лучшей идеей, мы решили сосредоточиться на пакетах для бэкенд-проектов.
1. Sentry-sdk
Описание:
Sentry-sdk — обязательный инструмент для любого проекта Django, так как он позволяет нам быть в курсе всех связанных с кодом проблем в приложении.
Во-первых, пакет немедленно предупреждает нас обо всех ранее неучтенных исключениях, которые проявились в продакшене.
Во-вторых, мы можем сами обнаружить проблему и отправить информацию о ней в sentry, добавив дополнительные данные.
Самостоятельное создание системы предупреждений это, безусловно, нетривиальная задача, а отладка без подобных логов практически невозможна.
Чем полезен этот пакет:
Особенности:
2. Django REST framework
Описание:
Если вы хотите написать API архитектурных ограничений REST, Django REST framework сделает это за вас. Также он автоматически сгенерирует правильную документацию, поддерживающую реализацию пакета в проектах.
Чем полезен этот пакет:
Нет необходимости самостоятельно писать REST API.
Особенности:
3. Django-extensions
Описание:
Django-extensions — набор инструментов, которые помогут вам в вашей повседневной работе. JSONField был впервые представлен в этом пакете еще до того, как он официально стал частью Django 1.9 (для PostgreSQL, конечно).
Чем полезен этот пакет:
Особенности:
4. Django-rest-framework-jwt
Описание:
При использовании DRF для некоторых проектов необходимо добавить JWT-аутентификацию. Для этого и предназначен этот пакет.
Чем полезен этот пакет:
Особенности:
5. Django-rest-swagger
Описание:
DRF предлагает автоматически сгенерированную документацию, а этот пакет делает документацию для ваших проектов более красивой.
Чем полезен этот пакет:
Особенности:
6. Easy-thumbnails
Описание:
Любой веб-сервис, позволяющий загружать и просматривать фотографии, нуждается в возможности создания миниатюр. Easy-thumbnails обеспечивает это.
Чем полезен этот пакет:
Особенности:
7. Django-simple-history
Описание:
Django-simple-history хранит историю изменения записей. Если клиент имеет доступ к базе данных через панель администратора, он может что-то изменить по ошибке и захотеть отменить это изменение или, скажем, вернуться…
Чем полезен этот пакет:
Особенности:
8. Django-adminactions
Описание:
Простой экспорт данных в известные типы файлов, такие как CSV или XLS. Вы также можете экспортировать данные в качестве приспособления на тестовый сервер, и это приспособление может содержать внешние ключи. Django-adminactions также позволяет генерировать графики в панели администратора.
Чем полезен этот пакет:
Особенности:
9. Django-model-utils
Описание:
Django-model-utils — набор полезных утилит для моделей Django.
Чем полезен этот пакет:
Особенности:
10. Django-storages
Описание:
Django-storages позволяет использовать любые облачные сервисы хранения данных в качестве хранилища файлов по умолчанию. Это становится важным, когда вы хотите пересылать в другое хранилище все, что отправляют нам пользователи.
Например, пользователь может отправить нам много существенных данных, таких как фотографии, фильмы или даже резервные копии. Чтобы сделать эти данные доступными для него, не замедляя работу приложения, рекомендуется использовать облачные решения для хранения данных, такие как Google Cloud.
Чем полезен этот пакет:
Особенности:
Дополнительно: что такое Django Allauth?
Приведенный выше список включает в себя самые лучшие пакеты Django, доступные в его богатой экосистеме. Но есть еще один пакет, который, как нам кажется, должен стать частью этого списка в качестве дополнительного пункта..
Django-allauth
Django-allauth предлагает интегрированный набор приложений Django, которые решают такие проблемы, как аутентификация, регистрация, управление учетными записями, а также аутентификация сторонних учетных записей (например, аккаунтов в социальных сетях).
Почему мы включили его сюда:
Большинство существующих приложений Django, которые решают проблему аутентификации в соцсетях, фокусируются только на этом функционале. Для поддержки аутентификации через локальный аккаунт, разработчикам, как правило, приходится интегрировать другое приложение. При таком подходе локальная аутентификация и аутентификация в соцсетях аутентификация отделяются друг от друга, и их интеграция становится сложной задачей.
Django-allauth был создан, чтобы заполнить этот пробел. Он предлагает пользователям полностью интегрированное приложение для аутентификации, как локальной, так и в соцсетях.
Вывод
Python стал важным языком программирования для проектов веб-разработки по многим причинам. Одной из них является богатая экосистема библиотек, фреймворков и пакетов, помогающих разработчикам ускорить процесс создания приложений, лучше управлять ими и сосредоточиться на самом важном (например, архитектуре приложений или переводе бизнес-логики).
Мы надеемся, что этот список пакетов поможет вам, когда вы будете создавать свое следующее веб-приложение с использованием Python и Django. Если вы хотите узнать больше о пакетах Django, загляните на этот полезный сайт: https://djangopackages.org/.
Кроме того, не забудьте просмотреть и другие статьи на нашем сайте: в них вы найдете еще больше полезных советов по созданию приложений на Django!
В каких случаях стоит использовать Django (а в каких не стоит)
Давайте поможем разработчикам разобраться, подходит ли фреймворк Django для их следующего проекта. Вполне вероятно — подходит.
Не стоит хвататься за определенный язык программирования или фреймворк лишь потому, что вы пользовались им в вашем предыдущем проекте, или просто потому что он вам хорошо знаком. Так дела не делаются.
Прежде чем приступать к новому проекту, следует оценить, какой язык или фреймворк лучше всего подойдет вам для достижения желаемого результата. Что для вас наиболее важно? Безопасность, скорость разработки, масштабируемость, универсальность, поддержка?
Лучше принять информированное решение перед тем как приступать к работе, чем потом раскаиваться в поспешном (или, хуже того, навешивать на проект костыли в процессе реализации – из-за того, что заранее не озаботились его поддержкой).
Я много лет работал с разными технологиями, имел дело как с мобильной, так и с веб-разработкой, и считаю, что Django предлагает такой полноценный набор возможностей, каких нет ни в одном другом веб-фреймворке.
Понимаю, это громкое заявление. Позвольте мне его обосновать.
«На Django основано множество сайтов, используемых самым активным образом, в частности, Instagram и Pinterest. Даже Facebook использует Django для многих своих утилит. Django зародился в издательской среде, поэтому неудивительно, что данный фреймворк используется на таких сайтах как The Washington Post и Smithsonian Magazine.” — Амит Ашвини, Вице-президент по маркетингу @ Zibtek
Общий взгляд: когда использовать Django
Если хотя бы несколько из нижеприведенных тезизов – про вас (и в списке нет тезисов, с которыми вы категорически не согласны), то, вполне вероятно, Django хорошо подойдет для вашего проекта.
Если вы – веб-разработчик, и уже знаете, как веб устроен, то работа с Django пойдет для вас сравнительно гладко. Необходимо понимать, как структурируется Django, и некоторые другие вещи, конечно, тоже – и считайте, что вы готовы.
Сайты, работающие на фреймворке Django
Вы еще сомневаетесь, стоит ли тратить свое драгоценное время, чтобы напрактиковаться с Django? Для начала давайте обсудим, по каким причинам Django может НЕ ПОДОЙТИ для вашего проекта:
Когда не стоит использовать Django
Причины использовать Django
Фреймворк Django написан на Python:
Знаю, вам это известно.
Поэтому воспользуюсь случаем и подчеркну некоторые ключевые достоинства Django, которые он унаследовал от Python. Буду краток.
Python – один из самых популярных и быстрорастущих языков программирования в мире.
Изучить Python действительно очень просто. Обычно современные разработчики учат первым именно этот язык.
Вышесказанное совершенно не означает, что этот язык – только для начинающих. Python используется и в ультрасовременных технологиях. Python активно применяется в технологическом стеке многих компаний-гигантов, в том числе, Google.
Язык Python отлично подходит для разработки инструментов веб-скрапинга.
Он хорошо взаимодействует с другими языками.
Разработка на Python не означает, что вы будете вынуждены все и вся писать только на Python.
Вы вполне сможете пользоваться библиотеками для многих других языков, в том числе, C/C++/Java.
Python портируемый, его удобно читать.
Python даже может работать на JVM. Познакомьтесь с Jython.
Python широко используется в таких востребованных технологиях как Большие Данные и Машинное обучение.
Вы получаете доступ к огромной библиотеке PyPI.
У Django “Все включено”
“Все включено” означает, что Django «из коробки» оснащен большинством библиотек и инструментов, нужных в распространенных практических ситуациях. Перечислю: Django ORM, промежуточное ПО, аутентификация, HTTP-библиотеки, многосайтовая поддержка, i18n, Django Admin, движок-шаблонизатор, т.д. – и это еще не «все». Ни один другой известный мне фреймворк не предоставляет столь широкой поддержки сразу.
Некоторые считают такое обстоятельство “минусом”, а другие – «плюсом». Каждая сторона права по-своему, и я в некоторой степени согласен с обеими.
Это минус, поскольку в такой ситуации фреймворк превращается в монолит.
Я считаю, что, если вам требуются эти возможности, приводящие к формированию монолита, то вам так или иначе придется воспользоваться какой-то другой библиотекой (или написать ее самостоятельно).
Почему бы в таком случае не воспользоваться инструментом, в котором все это уже есть, проверено в боях, функционирует на крупнейших сайтах, активно разрабатывается и обеспечено поддержкой сообщества?
Если вам не требуется большинства возможностей, предлагаемых в Django, то лучше остановиться на каком-нибудь микрофреймворке.
Не изобретать велосипед – вы помните? Потратьте ваше время на то, что действительно важно, а Django пусть сделает все остальное.
Django Admin
Хотя, я и упомянул этот элемент в предыдущем разделе, он заслуживает более пристального внимания. Во многих фреймворках, в частности, Laravel, Yii, т.д., предпринимались попытки упростить работу с админкой. Мне доводилось разрабатывать множество проектов в разных фреймворках, но ни один из них и близко не сравнится с Django по удобству работы с панелью администратора.
Некоторые считают, что Django Admin недостаточно гибок, и для подстройки любой его части под свои нужды требуется приложить массу усилий. На первых порах работы с Django я склонен был с этим соглашаться, но со временем, разобравшись во фреймворке, разубедился в этом. Да, там присутствует своя кривая обучения, но ни секунды, что вы ей уделите, не будет потрачено зря.
На самом деле, Django Admin очень хорошо структурирован. В некоторых моих проектах я использовал админку Django «как есть», а в других полностью заменял ее собственными шаблонами, которые разрабатывал с нуля. В любом случае, на это потребовалось не больше времени, чем на разработку с любым другим известным мне фреймворком.
Основной плюс? Вы получаете «из коробки» права доступа и аутентификацию. На разработку всего этого с нуля у вас ушли бы недели (или, как минимум, несколько дней).
Принцип DRY (Не Повторяйся)
Мне известно множество фреймворков, сторонники которых утверждают, что те действительно соответствуют принципу “DRY”. Я работал с многими такими фреймворками, но ни в одном из них принцип «DRY» не реализован как следует.
К сожалению, в большинстве фреймворков принципу “DRY” просто не уделяют достаточного внимания. На мой взгляд, если вы пишете приложение, которое собираетесь регулярно обновлять (а это можно сказать о большинстве современных приложений), то вы должны следовать принципу DRY во избежание проблем.
Так, в Laravel приходится писать валидацию для каждой процедуры отдельно. Такова же ситуация и с большинством других фреймворков. Чтобы ваш код соответствовал принципу DRY, нужно потрудиться. Сложно это отслеживать, особенно если вы работаете в команде.
В свою очередь, фреймворк Django спроектирован таким образом, что нарушить принцип DRY там обычно выходит только нарочно.
Так быть не должно, верно? Рассмотрим пример.
Вот как в Django устроена валидация и миграция базы данных
Создаем класс Model с требуемыми полями. Указываем все необходимые нам дополнительные валидации и ограничения.
Миграции генерируются единственной CLI-командой: `python manage.py makemigrations`.
Изменения вносятся в базу данных единственной CLI-командой: `python manage.py migrate`.
Валидации и ограничения автоматически проверяются при каждой CRUD-операции — идет ли речь о Django Admin или о Django REST Framework. Писать валидации заново вам не придется.
Тот же самый класс модели используется для генерации представлений Django Admin CRUD. Не требуется дописывать никаких собственных HTML/CSS.
Сравните эти условия с любым другим фреймворком – и, думаю, вам бы нигде не удалось сделать ничего подобного всего в несколько следующих строк кода:
Здесь речь не только о том, чтобы “не повторяться”. Такой подход уберегает вас от багов в перспективе. Все мы оказывались в ситуациях, когда довелось изменить что-то в одном месте, а в другом месте заменить забыли – и это выяснилось лишь после того, как у множества пользователей начались проблемы.
В Django, возвращаясь к вышеприведенному коду, если вам когда-нибудь придется заменить `max_length` поля на что-нибудь другое – просто сделайте это здесь. Изменение автоматически применится к валидации всех маршрутов и к базе данных.
Объектно-реляционное отображение в Django
Django предоставляет полнофункциональный механизм ORM «из коробки».
Я работал со множеством инструментов ORM в разных технологиях, в том числе, в Eloquent, greenDAO, Yii AR, т.д. Во всех из них простейшие запросы обрабатываются довольно хорошо, но рано или поздно мне приходилось писать те или иные запросы с нуля, поскольку механизм ORM не справлялся с конкретным практическим случаем.
С Django ORM в такие ситуации я пока не попадал. Он сработан настолько хорошо, что вы просто можете забыть, что работаете с запросами к базе данных. Именно таким и должно быть объектно-реляционное отображение. Ниже приведены некоторые примеры Django ORM:
Стремительная разработка
Этим любят похвастаться создатели практически любого веб-фреймворка, и, пожалуй, все они действительно правы – смотря какой смысл мы вкладываем в слово «стремительная».
Правда, с Django некоторые вещи делаются уморительно быстро. Вы уже видели, как легко мы смогли определить UI админки, таблицу базы данных и выполнить валидацию.
Это была всего лишь верхушка айсберга.
В принципе, стремительная разработка – это не фича как таковая, а лишь органичное следствие присутствующих в Django DRY, ORM, шаблонизатора и философии «все включено».
Безопасность фреймворка Django
Давайте признаем, иногда разработчики ленятся. Я – так точно. Время от времени я прокрастинирую, откладывая решение критически важных задач. Тут-то и могут возникнуть различные уязвимости.
Мне особенно нравится, что Django не идет на послабления по поводу безопасности, чтобы ускорить темп разработки. Функции безопасности активируются по умолчанию, поэтому совершенно не важно, ленивы вы или нет.
Опенсорс, отличная документация, огромное сообщество и пр.
Поскольку Django – опенсорсный и безумно популярный фреймворк, вокруг него сформировалось отзывчивое сообщество. Думаю, вы в курсе, каковы достоинства свободного ПО – так вот, все они присущи и Django.
Официальной документации Django более чем достаточно любому разработчику. Если застрянете – найти решение не составит труда.
У вас уже могло сложиться впечатление, что в Django создано множество собственных библиотек, поэтому, возможно, удивитесь, что специальной библиотеки для тестирования здесь не сделано. Нет, не подумайте, что фреймворк Django не поддерживает тестирование – поддерживает, еще как. Просто, следуя принципу «Не повторяйся» было бы бессмысленно разрабатывать библиотеку для тестирования, когда отличная библиотека такого рода уже есть в самом Python. Django отлично с ней взаимодействует. Кроме того, он очень хорошо сочетается и со сторонними библиотеками, например, pytest.
Современное состояние Django и другие популярные фреймворки
Итак, я по максимуму постарался осветить те проблемы, с которыми сталкивался при работе с другими фреймворками и сравнить эти фреймворки с Django. Поработав с Yii, CodeIgniter, WordPress, CS-Cart, Laravel, т.д., я пришел к выводу, что Django гораздо лучше любого из них.
Однако, это только мое мнение.
Если вам нравится статистика, то вот ежегодное исследование Stack Overflow, где Django фигурирует в числе самых излюбленных и востребованных фреймворков:
Кроме вышеупомянутого опыта работы с PHP, я также рапзрабатывал приложения под Android на Java, клиентские приложения на React.js. Во всех этих случаях я потратил изрядное количество времени на рефакторинг базы кода, подыскивая наилучшую архитектуру, через пару месяцев увязая в проблемах с масштабируемостью и вновь принимаясь за рефакторинг.
Недавно я переписал с Laravel на Django одно приложение, которое было у меня в продакшене более года. Мне удалось развернуть новую базу кода менее чем за 10 дней, написав для этого минимальное количество кода (говорю же: сложность уменьшается!) В обратном направлении подобная операция определенно заняла бы более месяца.
Если вы попытаетесь напрямую сравнивать другие фреймворки с Django, это вам ничего не даст.
Контроль производительности может показать, что фреймворк на Java быстрее Django. Вы можете хорошо разбираться в PHP, так что, возможно, разработка приложения на Django пойдет у вас быстрее, чем на знакомом вам PHP-фреймворке. В случае с совсем простым приложением настройка Django может показаться вам слегка утомительной – конечно, гораздо проще написать файл со скриптами. Результаты опросов могут разниться в зависимости от того, среди какой аудитории они проводились.
Однако, здесь мы рассуждаем не только о фреймворках, относящихся к другим технологиям. Даже если вы знакомы c Python, возможно, микрофреймворк Flask покажется вам более удобным и желательным. Придется задуматься, на котором из них остановиться.
Мой совет – просто не сравнивайте их.
Вывод
На мой взгляд, в Django удалось идеально сбалансировать производительность, архитектуру, уровень сложности при разработке, безопасность и масштабируемость.
Если вы начинаете писать проект с нуля – настоятельно рекомендую попробовать сделать его с Django.