Давайте поможем разработчикам разобраться, подходит ли фреймворк 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.
Комментарии (37)
legatdestr
27.04.2019 21:01+2Отличный фреймворк для веб-разработки. Но для меня вопрос из заголовка статьи так и остался не раскрытым. Всё что написано в главе "… когда использовать Django", с тем же успехом можно написать и про Laravel (PHP), к примеру.
asvechkar
27.04.2019 23:06Полностью согласен. Поддался хайпу вокруг Python, написал пару проектов на Django и Flask. Flask с подключением SqlAlchemy, Click даже поудобней Django. Последний проект начал на Django, плюнул и переписал на Laravel. Otwell, гад, столько сахара добавил, что Laravel подкупает скоростью и удобством разработки :). Ну повторите команду php artisan migrate:fresh --seed на другом фреймворке. Опять же фронт с webpack на выбор. Тот же rails добавил поддержку webpack, но всё равно без бубна не заведешь. Буквально вчера проект на rails 6 rc1 делал. Надеюсь, Django 4 будет использовать новые технологии из коробки.
Насчет валидации в Laravel: свои Requests более гибче, чем сериалайзеры в DRF: напишите сериалайзер для восстановления записи из soft delete если есть уникальные поля.
И еще момент: пишем, например, в проекте API для мобильного клиента. В Laravel включили Passport, аутентификация с JWT готова. И вот момент:
$users = User::orderBy('name')->get(); return response($users);
Всё! Возвращается нормальный JSON. В Django и Flask, к сожалению, так не прокатит. В Django будь добр напиши сериалайзер. В Flask подключи, например, пакет Marshmalow и напиши схему.
Django админка хороша, согласен. Описал в [Model]Admin поведение модели в админке и всё, грубо говоря. А для Laravel сделали Nova. Не менее удобная и более функциональная.
Самому не очень нравится синтаксис PHP со стрелками и точкой для конкатенации (после лаконичности Ruby). Но именно для веб приложений PHP на данный момент самый подходящий язык, ибо изначально создавался именно для обработки веб-запросов.
Извините, написал сумбурно. Материала хватит на статью о сравнении Laravel, Django, Rails :).LizardWizzard
29.04.2019 09:54напишите сериалайзер для восстановления записи из soft delete если есть уникальные поля.
Не думаю что сериализаторы должны заниматься чем-то кроме сериализации и валидации данных, соответственно логика восстановления из soft delete просто не их зона ответственности. Я предложил бы реализовать эту логику в кастомном менеджере модели.
$users = User::orderBy('name')->get(); return response($users);
На мой взгляд лучше иметь четкую схему ответа на запрос, чтобы пользоваться всеми преимуществами swagger/openapi и предоставлять контракт для клиентских приложений, что как раз подходит под описанный вами кейс API для мобильного приложения. Еще замечу, что этот пример не предполагает разных представлений модели User для разных View. Соответственно чтобы получить такую возможность все равно придется что-то дописывать. При желании в Django можно написать похожий код (для соответствия вашему примеру все же придется написать обертку в несколько строк над встроенной возможностью сериализации моделей)
P.S. С PHP и RoR не знакомasvechkar
29.04.2019 11:14Не думаю что сериализаторы должны заниматься чем-то кроме сериализации и валидации данных,
Так и я про валидацию. В Laravel пишем Request, где проверяем, нет ли текущих (не помеченных на удаление) записей с такими же значениями полей, какие передали в Request. Если есть, возвращаем сообщение об ошибке. Например,
class UserController extends Controller { ... public function restore(UserRequest $request) { // валидация происходит до выполнения действия. } ... }
Вполне возможно, что в Django такая проверка делается не в сериализаторе, а в менеджере модели.LizardWizzard
29.04.2019 12:38Мы с вами немножко о разной валидации говорим. Я считаю, что сериализатор должен проверять только корректность формата запроса, но не его логическую правильность по отношению к текущему состоянию БД. DRF позволит написать любую логику касающуюся моделей в сериализаторе (например ваша проверка могла бы быть в методе FooSerializer.validate()) и я периодически вижу, что люди пишут подобный код, но я бы не сказал что это что-то хорошее. На мой взгляд задача сериализатора проверить, что в запросе есть список идентификаторов (или любой другой набор полей) записей которые пользователь хочет восстановить. А уже менеджер модели занимался бы всем, что касается БД в процессе восстановления.
Также всегда в ситуации, когда мы что-то проверяем по БД, а потом на основе этого что-то изменяем появляется вероятность, что между этими двумя событиями результат проверки может измениться, в данном случае проблему можно решить используя SELECT FOR UPDATE. В случае проверки в сериализаторе, а выполнения действия восстановления где-то еще мы размазываем знание об обработке этого запроса по разным частям кода (не говоря о том, что транзакцию придется начать в сериализаторе а закрыть где-то еще), что на мой взгляд не есть хорошо.
Zanak
29.04.2019 12:02Ни то, чтобы я с вами был сильно несогласен, но с примерами нужно быть аккуратнее. Например здесь:
будь я настроен менее критически, я бы решил что лара сама разбирается, когда отдавать вью с формой, а когда json. Обращение к документации снимает этот мистический момент.$users = User::orderBy('name')->get(); return response($users);
Здесь правда возникает желание вступится за flask. Отдавать json подобным образом умеет и он. Потребность в дополнительной прослойке обусловлена не умением/неумением отдавать json, а потребностью отдавать только те поля, которые нужно, скрывая, например, поля с информацией о правах или связанные с аудитом. Flask изначально позиционировался как микрофреймворк, и логично, что этот функционал оформлен в виде батарейки.asvechkar
29.04.2019 12:48будь я настроен менее критически, я бы решил что лара сама разбирается, когда отдавать вью с формой, а когда json.
Нет, конечно :). Я пример как раз для JSON и написал. Если бы я хотел вернуть вью, а бы написал:
$users = User::orderBy('name')->get(); return view('users.index', compact('users'));
IamG
27.04.2019 23:12Django отличный инструмент, единственная проблема с которой я столкнулся это то, что переход на новые версии требует переделывать мой код. У меня один проект на django-1.6 работает по моему года 4+. Но я не могу его перевести на django 2 поскольку объём кода который нужно править пугает.
Поэтому для новых проектов использую flask, в котором за счёт того что нужные «батарейки» подбираешь сам эта проблема не так сильно проявляется.
immaculate
28.04.2019 05:53Ух, я недавно портировал большой серьезный проект с Django 1.7 на Django 2.2. Соответственно, в процессе также с Python 2 на Python 3, и с
django-haystack(никогда не используйте — кажется, что удобно, но на самом деле мертвый и очень корявый инструмент!) на голые запросы к ElasticSearch (elasticsearch-dsl).
Работа заняла около 6 месяцев, работал в основном один. Изначально кодовая база была разработана австралийской компанией. После этого проекта, мое мнение о качестве австралийских программистов упало ниже нуля. Это заслуживает отдельной статьи, а статьи я писать не имею права на этом сайте из-за кармы. Хотя понимаю, что это отдельно взятый случай, но все же там было такое, что волосы много раз на голове шевелились. И
git blameпоказывает, что это не индусы, не китайцы, не вьетнамцы — чистокровные австралийцы, получившие образование в Австралии, многих я потом нашел на LinkedIn, чтобы в этом убедиться.
После миграции размер кода уменьшился приблизительно на 40%, но это потому что австралийцы очень любили методологию copy-paste.
Самое сложное было не миграция c py2 на py3, и даже не миграция между версиями Django — все это заняло процентов 20-30% времени. Сложнее всего было переписать весь адский код django-haystack на
elasticsearch-dsl. Ну и поскольку переход длился долго, то неизбежно пришлось во время перехода еще и добавлять множество новой функциональности, так что отделить чистое время портирования, конечно, уже невозможно.
Тут пишут в комментариях критику Django, что в нем, дескать, то же самое, что есть и в других фреймворках. Не могу ответить из-за кармы всем. Но я уже очень давно пишу на Django, и при этом периодически поглядывал по сторонам.
Так вот, все то, что есть в других фреймворках, оно там появилось после того, как было реализовано в Django. А какие-то вещи до сих пор не реализованы.
Теперь то конечно удобно говорить: «Да это и в моем фреймворке есть». А вот было оно там 3 года назад? 5 лет, 10 лет назад? То-то и оно.
VolCh
28.04.2019 10:47Навскидку, если мне память не изменяет, отладочная панель была портирована в django из Symfony. Ну и в целом, symfony и django вышли в свет в одном 2005 году, а symfony не первый php-фреймворк
asvechkar
28.04.2019 11:15+1Ruby on Rails — December 13, 2005
Symfony — October 18, 2005
Django — July 21, 2005
Плодотворный был год :).
MrBinWin
28.04.2019 14:53Так не важно же, как оно было 10 лет назад, пишем код-то сейчас, на том, что есть сегодня (и возможно будет завтра). И древность библиотеки — не показатель качества.
immaculate
29.04.2019 06:59Одновременно отвечу вам и VolCh:
Django — также совсем не первый веб-фреймворк на Python. Еще до Django писались вещи, которые на десятилетия опередили все остальное, но по какой-то причине не завоевали мир (Zope и Plone, например).
К тому же, он не древний, продолжает активно развиваться.
И вот тут надо бы иметь какое-то полноценное сравнение, но честно говоря, сомневаюсь что хоть что-либо сравнится с Django по количеству батареек и скорости разработки (и отладки). Буквально для любой мыслимой задачи в Django уже есть либо встроенная функциональность, либо 1-5 решений сторонних разработчиков, которые включаются простым выполнением
pip install module. Причем это очень часто качественный код, к которому прилагается настолько же качественная документация.
Провести полноценный анализ того, что доступно для Django и других фреймворков — очень трудоемкая задача, у меня не будет на это времени. Но интуитивно мне кажется, что Django заткнет за пояс практически любого конкурента. А это сэкономленное время на разработку и отладку. Не приходится постоянно переизобретать велосипед.
MrBinWin
29.04.2019 10:44Не заткнет. Ни PHP фреймворки (тот же Yii 2), ни Ruby on Rails.
Django не хуже, но и ничего экстраординарного он не предлагает: у всех есть из коробки ORM, миграции, админки, шаблонизаторы, формы, документация и сотни расширений.
VolCh
29.04.2019 13:33Насколько я помню, под Django довольно сложно писать основной код приложения, минимально привязіваясь к Django, писать в так назіваемом framework agnostic стиле. Прежде всего речь о бизнес-логике, о независимости бизнес-модели от фреймворка вообще и от его ORM в частности. Грубо говоря, чтобы такие сущности как User, Company, Account, Order, Contract и т. п. не были наследниками каких-то классов фреймворка, были обычными python классами, равно и как классы типа User(Repository|Store). Чтобы при необходимости, например, не представляло большого труда перейти с Django+Postgres на Tornado+Mongo
k4ir05
30.04.2019 04:29Это всё бичь паттерна Active record. В Rails то же самое. Да все популярный фреймворки придерживаются этого паттерна. Из известных мне, только в Hanami другой подход (отдельно entity и repository).
VolCh
30.04.2019 11:18Ну в Python есть (и можно прикрутить к Django) SqlAlchemy или как-то так, который DataMapper реалиизовівает, но там оно тоже через базовые классы, насколько я знаю.
И беда обычно не столько в самом AR паттерне, сколько в том, что фреймворки, с одной стороны, сильно завязываются на конкретную реализацию AR, а, c другой, сама реализация AR завязывается на «родной» фреймворк, беря на себя какие-то дополнительніе ответственности кроме и так имеющихся двух в AR, например валидацию (не путать с соблюдением бизнес-инвариантов) или сериализацию.
andreymal
27.04.2019 23:59-1Вам требуется разработать веб-приложение или серверную часть API.
Очевидно, возможно не только на Django
Требуется быстро работать, быстро развертывать и вносить изменения в проект по ходу работы.
Не скажу за других, но лично мне Django в этом лишь мешает
По умолчанию приложение должно быть защищено от наиболее распространенных уязвимостей и атак, в частности: CSRF, SQL-инъекции, XSS, кликджекинг, etc.
Есть в любом другом фреймворке/шаблонизаторе/ORM, Django здесь ничем не выделяется
В любой момент в приложении может потребоваться масштабирование: как наращивание, так и сокращение.
Django никак не способствует этому сам по себе
В перспективе вы планируете интегрировать новейшие технологии
Django сам по себе весьма устаревший
Вам нужно использовать надежный фреймворк, который активно разрабатывается, используется многими топовыми компаниями и ведущими веб-сайтами во всем мире.
Вот с этим действительно не поспорить
Требуется, чтобы и веб-приложение, и серверная часть API находились в одной и той же базе кода, согласовываясь с «единым источником истины» (принцип DRY)
Непонятно, при чём тут Django
Вы не хотите работать непосредственно с запросами к базе данных, и вам нужна поддержка ORM.
Берём любую ORM, а Django тут зачем?
Вы собираетесь пользоваться свободным ПО.
Все другие популярные фреймворки тоже в целом свободное ПО
Если застрянете – то решение придется искать самостоятельно, поэтому вам понадобится хорошая документация и отзывчивое сообщество разработчиков.
И с этим тоже не поспорить
Необходимо написать простейшее приложение, в котором не требуется работать с базой данных, выполнять операции с файлами или делать что-либо хоть немного сложное.
Вот не надо мне тут Flask обижать, я переводил один немаленький и «сложный» Django-сайт на Flask и полностью доволен, всё «сложное» там отлично делается
В Django, возвращаясь к вышеприведенному коду, если вам когда-нибудь придется заменить
max_lengthполя на что-нибудь другое – просто сделайте это здесь.И потеряйте логины старых пользователей, потому что max_length был уменьшен, и в базе после миграции всё обрезалось. Модели НЕЛЬЗЯ использовать для валидации (и вообще они весьма негибкие в этом плане) — для этого есть формы. (Но формы мне тоже не нравятся, поэтому я вкрутил себе сторонее решение Cerberus)
h0w4rd
28.04.2019 07:47Мне лично больше нравится Express.JS в связке с Typescript-ом и Gulp-ом, написал одну команду и все само скомпилировалось и запустилось. Достаточно лишь настроить и все. Да и на JavaScript-е есть много прекрасных вещей таких, например как Pug и Less.
Но все-же огромный минус, это 40-50 мегабайтная node_modules…
Вроде только самое нужное, а там 20.000 файлов, сотни папок и очень, очень, много библиотек. Но сама экосистема очень хорошая выходит, пару конфигов в корне, код в «scr», все (Less, клиентский JS код и пр.) компилируется в «dist». И это все одной командой!
В Django все явно не для маленьких проектов, что думаю не особо хорошо. Ведь все-же Django неплохой, много всего из коробки, но мне лично сложно понять, что там к чему.
Хотя я не отрицаю большее удобство и/или возможности других экосистем, фреймворков.
P.S. Да, хоть и статья про Python фреймворки, но упоминание Express.JS было, думаю хоть чуток все-же в тему.andreymal
28.04.2019 12:33Но все-же огромный минус, это 40-50 мегабайтная node_modules…
Так-то среднестатистический virtualenv в питоне с лёгкостью переваливает за сотню мегабайт :)
Anshi85
30.04.2019 14:28Но согласитесь, что сравнивать ExpressJS и Django не совсем корректно? Express это фреймворк который относительно быстро поможет сделать бекенд, у него нет готовой админки как у Django, нет встроенной работы с пользователями, аутентификации и т.д, я считаю что корректно сравнить Keystone c Django, но не Express, Express больше сравним с Flask.
dopusteam
28.04.2019 07:48Мне особенно нравится, что Django не идет на послабления по поводу безопасности, чтобы ускорить темп разработки. Функции безопасности активируются по умолчанию, поэтому совершенно не важно, ленивы вы или нет.
Что это за вода? Распишите детально, что это за 'функции безопасности', которые автоматически активируются, раз уж упомянули
bashkadove
28.04.2019 09:12Не планирует ли издательство «Питер» выпустить книги по Python веб фреймворкам?
VolCh
28.04.2019 10:49Давно django не смотрел (1.4 кажется поставил на одном проекте внутреннем). Как там сейчас с возможностью безболезненно следовать принципам SOLID, техническим принципам DDD и т. п.?
Stan_1
Хм… проверил себя по чек-листу в начале статьи — и понял, что выбираю Rails по совокупности всех пунктов списка (ну может, за исключением машинного обучения). И так и не понял — чем хорошо Django?
Fly3110
Я тоже, пока читал, сравнивал с рельсами, но в рельсах нет некоторых функций, например встроенной админки, шаблонизатора итд.
Stan_1
ActiveAdmin. Позволяет делать админку практически только настройками. То, что формально он не пакете Rails, вряд ли является ключевым преимуществом Django над Rails. Да и в принципе ниже написали, что и Lavarel все умеет.
Касательно темы статьи — просто на мой взгляд, в контексте «быстрых проектов» вообще говорить о преимуществах фреймворков бессмыслено. Это скорее важнее клиенту с точки зрения стоимости владения и дальнейшего сопровождения. А так… Django, Rails, Elexir, Yii, Lavarel — пусть каждый делает на чем хочет, и не уходит обиженный :)
asvechkar
Насчёт шаблонизатора в RoR: кажется он apidock.com/ruby/ERB.
А вот такого сахара (https://github.com/rails/jbuilder) я в других фреймворках не встречал.
Fly3110
JBuilder удобен, да, особенно, когда API разрабатываешь.
А про erb не подумал что-то, действительно. Давно вьюхи на рельсах не делал :)
MrBinWin
Шаблонизатор Django стоит отнести к недостаткам фреймворках. Там с производительностью полное фиаско. В итоге придется либо полностью кэшировать страницы, либо переписывать все на jinja2. https://tomforb.es/just-how-slow-are-django-templates/
sim3x
Mar 13, 2013
acmnu
Что-то я смоневаюсь в необходимости шаблонизатора в современном SPA мире. Во всяком случае давненько я ужене писал на Django html, только API.
andreymal
Лично я принципиально пишу сайты, способные работать при отключенном js, например.
OnYourLips
После прочтения заголовка я ожидал увидеть его сравнение с корпоративными фреймворками вроде Spring или Symfony и описание случаев, когда Django объективно плох, а увидел лишь предвзятую хвалебную оду.
k4ir05
Видимо, это статья из параллельного мира без ruby. Он вообще даже не упоминается.