В каких случаях стоит использовать Django (а в каких не стоит)

в 14:54, , рубрики: django, python, Блог компании Издательский дом «Питер», Веб-разработка, высокая производительность, Программирование

В каких случаях стоит использовать Django (а в каких не стоит) - 1
Давайте поможем разработчикам разобраться, подходит ли фреймворк Django для их следующего проекта. Вполне вероятно — подходит.

Не стоит хвататься за определенный язык программирования или фреймворк лишь потому, что вы пользовались им в вашем предыдущем проекте, или просто потому что он вам хорошо знаком. Так дела не делаются.

Прежде чем приступать к новому проекту, следует оценить, какой язык или фреймворк лучше всего подойдет вам для достижения желаемого результата. Что для вас наиболее важно? Безопасность, скорость разработки, масштабируемость, универсальность, поддержка?
Лучше принять информированное решение перед тем как приступать к работе, чем потом раскаиваться в поспешном (или, хуже того, навешивать на проект костыли в процессе реализации – из-за того, что заранее не озаботились его поддержкой).

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

Понимаю, это громкое заявление. Позвольте мне его обосновать.

«На Django основано множество сайтов, используемых самым активным образом, в частности, Instagram и Pinterest. Даже Facebook использует Django для многих своих утилит. Django зародился в издательской среде, поэтому неудивительно, что данный фреймворк используется на таких сайтах как The Washington Post и Smithsonian Magazine.” — Амит Ашвини, Вице-президент по маркетингу @ Zibtek

Общий взгляд: когда использовать Django

Если хотя бы несколько из нижеприведенных тезизов – про вас (и в списке нет тезисов, с которыми вы категорически не согласны), то, вполне вероятно, Django хорошо подойдет для вашего проекта.

  • Вам требуется разработать веб-приложение или серверную часть API.
  • Требуется быстро работать, быстро развертывать и вносить изменения в проект по ходу работы.
  • По умолчанию приложение должно быть защищено от наиболее распространенных уязвимостей и атак, в частности: CSRF, SQL-инъекции, XSS, кликджекинг, etc.
  • В любой момент в приложении может потребоваться масштабирование: как наращивание, так и сокращение.
  • В перспективе вы планируете интегрировать новейшие технологии, например, машинное обучение.
  • Вам нужно использовать надежный фреймворк, который активно разрабатывается, используется многими топовыми компаниями и ведущими веб-сайтами во всем мире.
  • Требуется, чтобы и веб-приложение, и серверная часть API находились в одной и той же базе кода, согласовываясь с «единым источником истины» (принцип DRY)
  • Вы не хотите работать непосредственно с запросами к базе данных, и вам нужна поддержка ORM.
  • Вы собираетесь пользоваться свободным ПО.
  • Если застрянете – то решение придется искать самостоятельно, поэтому вам понадобится хорошая документация и отзывчивое сообщество разработчиков.

Кроме вышеупомянутых факторов нужно учитывать, какими навыками обладаете вы (или ваша команда).

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

Сайты, работающие на фреймворке Django

История Django насчитывает уже около 10 лет. За этот период он использовался в продакшене на множестве топовых сайтов. Вот некоторые выдающиеся примеры:
Pinterest Engineering
Mozilla
Bitbucket
Udemy
The Onion
Disqus
Washington Post
NASA
Spotify
Instagram Engineering
National Geographic
The Guardian
JSFiddle

Вы еще сомневаетесь, стоит ли тратить свое драгоценное время, чтобы напрактиковаться с Django? Для начала давайте обсудим, по каким причинам Django может НЕ ПОДОЙТИ для вашего проекта:

Когда не стоит использовать Django

  • Вы имеете дело с колоссальным приложением, и оно попросту не умещается в одной базе кода. Возможно, лучше будет разбить ваше приложение на микросервисы. С каждым его уровнем качественнее справится специально выделенная команда. Для каждого конкретного сценария использования подойдут иные технологии. В некоторых таких сценариях может пригодиться и Django, но было бы нецелесообразно полностью разрабатывать такое приложение на Django (равно как и на любом другом отдельно фреймворке).
  • Необходимо написать простейшее приложение, в котором не требуется работать с базой данных, выполнять операции с файлами или делать что-либо хоть немного сложное.
    Для таких ситуаций лучше подойдут микрофреймворки. Один из наиболее популярных микрофреймворков – Flask, как и Django, он написан на Python. Подобные микрофреймворки доступны и в рамках других технологий, напр. Slim в PHP, Apache Spark в Java, Express.js в Node.js, т.д.
  • Вы хотите сами написать все с нуля и знаете, что делаете.
  • Вы или ваши коллеги совершенно не знакомы с Django/Python, и у вас нет времени и ресурсов на наработку необходимых навыков.
    Наилучшее решение в последнем случае – работать с тем, в чем вы лучше всего разбираетесь. Если берешься за новую технологию или фреймворк, то шансы напортачить возрастают многократно.

Если все вышесказанное – не про ваш проект, то, вполне вероятно, Django вам подойдет.

Причины использовать Django

Фреймворк Django написан на Python:
Знаю, вам это известно.

Поэтому воспользуюсь случаем и подчеркну некоторые ключевые достоинства Django, которые он унаследовал от Python. Буду краток.

Python – один из самых популярных и быстрорастущих языков программирования в мире.

Источники:

TIOBE index
Indeed.com Jobs’ data analysis by Coding Dojo
GitHub Octoverse

Изучить 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.

Сравните эти условия с любым другим фреймворком – и, думаю, вам бы нигде не удалось сделать ничего подобного всего в несколько следующих строк кода:

class Employee(models.Model):
    name = models.CharField(max_length=127)
    email = models.EmailField(null=True, blank=True)
    created_at = models.DateTimeField(blank=True, null=True, auto_now_add=True)
    updated_at = models.DateTimeField(blank=True, null=True, auto_now=True)

Здесь речь не только о том, чтобы “не повторяться”. Такой подход уберегает вас от багов в перспективе. Все мы оказывались в ситуациях, когда довелось изменить что-то в одном месте, а в другом месте заменить забыли – и это выяснилось лишь после того, как у множества пользователей начались проблемы.

В Django, возвращаясь к вышеприведенному коду, если вам когда-нибудь придется заменить `max_length` поля на что-нибудь другое – просто сделайте это здесь. Изменение автоматически применится к валидации всех маршрутов и к базе данных.

Объектно-реляционное отображение в Django

Django предоставляет полнофункциональный механизм ORM «из коробки».

Я работал со множеством инструментов ORM в разных технологиях, в том числе, в Eloquent, greenDAO, Yii AR, т.д. Во всех из них простейшие запросы обрабатываются довольно хорошо, но рано или поздно мне приходилось писать те или иные запросы с нуля, поскольку механизм ORM не справлялся с конкретным практическим случаем.

С Django ORM в такие ситуации я пока не попадал. Он сработан настолько хорошо, что вы просто можете забыть, что работаете с запросами к базе данных. Именно таким и должно быть объектно-реляционное отображение. Ниже приведены некоторые примеры Django ORM:

# получает 5 верхних результатов, где rank = 10 и age <= 30
top_young_employees = Employee.objects.filter(rank=10, age__lte=30)[:5]
# вставляет запись с указанными значениями
employee = Employee.objects.create(name=’John Doe’, age=35, country=’IN’)
# выводит на экран значение поля
print(employee.name)

Стремительная разработка

Этим любят похвастаться создатели практически любого веб-фреймворка, и, пожалуй, все они действительно правы – смотря какой смысл мы вкладываем в слово «стремительная».

Правда, с 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 фигурирует в числе самых излюбленных и востребованных фреймворков:

Frameworks, Libraries, and Tools
Most Loved, Dreaded, and Wanted Frameworks, Libraries, and Tools

Кроме вышеупомянутого опыта работы с PHP, я также рапзрабатывал приложения под Android на Java, клиентские приложения на React.js. Во всех этих случаях я потратил изрядное количество времени на рефакторинг базы кода, подыскивая наилучшую архитектуру, через пару месяцев увязая в проблемах с масштабируемостью и вновь принимаясь за рефакторинг.

Недавно я переписал с Laravel на Django одно приложение, которое было у меня в продакшене более года. Мне удалось развернуть новую базу кода менее чем за 10 дней, написав для этого минимальное количество кода (говорю же: сложность уменьшается!) В обратном направлении подобная операция определенно заняла бы более месяца.

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

Однако, здесь мы рассуждаем не только о фреймворках, относящихся к другим технологиям. Даже если вы знакомы c Python, возможно, микрофреймворк Flask покажется вам более удобным и желательным. Придется задуматься, на котором из них остановиться.
Мой совет – просто не сравнивайте их.

Вывод

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

Если вы начинаете писать проект с нуля – настоятельно рекомендую попробовать сделать его с Django.

Автор: ph_piter

Источник

* - обязательные к заполнению поля