Комментарии 41
Касательно темы статьи — просто на мой взгляд, в контексте «быстрых проектов» вообще говорить о преимуществах фреймворков бессмыслено. Это скорее важнее клиенту с точки зрения стоимости владения и дальнейшего сопровождения. А так… Django, Rails, Elexir, Yii, Lavarel — пусть каждый делает на чем хочет, и не уходит обиженный :)
А вот такого сахара (https://github.com/rails/jbuilder) я в других фреймворках не встречал.
Шаблонизатор Django стоит отнести к недостаткам фреймворках. Там с производительностью полное фиаско. В итоге придется либо полностью кэшировать страницы, либо переписывать все на jinja2. https://tomforb.es/just-how-slow-are-django-templates/
Да, но с некоторых пор в Django можно вполне легально (без костылей, а даже по официальной инструкции) использовать Jinja2.
Что-то я смоневаюсь в необходимости шаблонизатора в современном SPA мире. Во всяком случае давненько я ужене писал на Django html, только API.
Насчет валидации в 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 :).
напишите сериалайзер для восстановления записи из soft delete если есть уникальные поля.Не думаю что сериализаторы должны заниматься чем-то кроме сериализации и валидации данных, соответственно логика восстановления из soft delete просто не их зона ответственности. Я предложил бы реализовать эту логику в кастомном менеджере модели.
$users = User::orderBy('name')->get();
return response($users);На мой взгляд лучше иметь четкую схему ответа на запрос, чтобы пользоваться всеми преимуществами swagger/openapi и предоставлять контракт для клиентских приложений, что как раз подходит под описанный вами кейс API для мобильного приложения. Еще замечу, что этот пример не предполагает разных представлений модели User для разных View. Соответственно чтобы получить такую возможность все равно придется что-то дописывать. При желании в Django можно написать похожий код (для соответствия вашему примеру все же придется написать обертку в несколько строк над встроенной возможностью сериализации моделей)
P.S. С PHP и RoR не знаком
Не думаю что сериализаторы должны заниматься чем-то кроме сериализации и валидации данных,
Так и я про валидацию. В Laravel пишем Request, где проверяем, нет ли текущих (не помеченных на удаление) записей с такими же значениями полей, какие передали в Request. Если есть, возвращаем сообщение об ошибке. Например,
class UserController extends Controller {
...
public function restore(UserRequest $request)
{
// валидация происходит до выполнения действия.
}
...
}
Вполне возможно, что в Django такая проверка делается не в сериализаторе, а в менеджере модели.
Также всегда в ситуации, когда мы что-то проверяем по БД, а потом на основе этого что-то изменяем появляется вероятность, что между этими двумя событиями результат проверки может измениться, в данном случае проблему можно решить используя SELECT FOR UPDATE. В случае проверки в сериализаторе, а выполнения действия восстановления где-то еще мы размазываем знание об обработке этого запроса по разным частям кода (не говоря о том, что транзакцию придется начать в сериализаторе а закрыть где-то еще), что на мой взгляд не есть хорошо.
$users = User::orderBy('name')->get();
return response($users);Здесь правда возникает желание вступится за flask. Отдавать json подобным образом умеет и он. Потребность в дополнительной прослойке обусловлена не умением/неумением отдавать json, а потребностью отдавать только те поля, которые нужно, скрывая, например, поля с информацией о правах или связанные с аудитом. Flask изначально позиционировался как микрофреймворк, и логично, что этот функционал оформлен в виде батарейки.
Поэтому для новых проектов использую flask, в котором за счёт того что нужные «батарейки» подбираешь сам эта проблема не так сильно проявляется.
Ух, я недавно портировал большой серьезный проект с 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 лет назад? То-то и оно.
Навскидку, если мне память не изменяет, отладочная панель была портирована в django из Symfony. Ну и в целом, symfony и django вышли в свет в одном 2005 году, а symfony не первый php-фреймворк
Так не важно же, как оно было 10 лет назад, пишем код-то сейчас, на том, что есть сегодня (и возможно будет завтра). И древность библиотеки — не показатель качества.
Одновременно отвечу вам и VolCh:
Django — также совсем не первый веб-фреймворк на Python. Еще до Django писались вещи, которые на десятилетия опередили все остальное, но по какой-то причине не завоевали мир (Zope и Plone, например).
К тому же, он не древний, продолжает активно развиваться.
И вот тут надо бы иметь какое-то полноценное сравнение, но честно говоря, сомневаюсь что хоть что-либо сравнится с Django по количеству батареек и скорости разработки (и отладки). Буквально для любой мыслимой задачи в Django уже есть либо встроенная функциональность, либо 1-5 решений сторонних разработчиков, которые включаются простым выполнением pip install module. Причем это очень часто качественный код, к которому прилагается настолько же качественная документация.
Провести полноценный анализ того, что доступно для Django и других фреймворков — очень трудоемкая задача, у меня не будет на это времени. Но интуитивно мне кажется, что Django заткнет за пояс практически любого конкурента. А это сэкономленное время на разработку и отладку. Не приходится постоянно переизобретать велосипед.
Django не хуже, но и ничего экстраординарного он не предлагает: у всех есть из коробки ORM, миграции, админки, шаблонизаторы, формы, документация и сотни расширений.
И беда обычно не столько в самом AR паттерне, сколько в том, что фреймворки, с одной стороны, сильно завязываются на конкретную реализацию AR, а, c другой, сама реализация AR завязывается на «родной» фреймворк, беря на себя какие-то дополнительніе ответственности кроме и так имеющихся двух в AR, например валидацию (не путать с соблюдением бизнес-инвариантов) или сериализацию.
Flask довольно хорош, тоже куча либ с качественной документацией:
- SQLAlchemy (flask-sqlalchemy)
- WTForms (flask-wtf)
- flask-auth
- и ещё много других flask-module.
Подход к разработке немного отличается, приходится писать большое количество бойлерплейта, который Django делает под капотом, но в целом довольно интересное решение. Не могу сказать, что этот фреймворк лучше Django, просто было странно не увидеть его в комментариях. Ещё есть Pyramid и Tornado, но про них я ничего не знаю, а говорить о том, в чём не разбираюсь, не привык.
Вам требуется разработать веб-приложение или серверную часть 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)
Но все-же огромный минус, это 40-50 мегабайтная node_modules…
Вроде только самое нужное, а там 20.000 файлов, сотни папок и очень, очень, много библиотек. Но сама экосистема очень хорошая выходит, пару конфигов в корне, код в «scr», все (Less, клиентский JS код и пр.) компилируется в «dist». И это все одной командой!
В Django все явно не для маленьких проектов, что думаю не особо хорошо. Ведь все-же Django неплохой, много всего из коробки, но мне лично сложно понять, что там к чему.
Хотя я не отрицаю большее удобство и/или возможности других экосистем, фреймворков.
P.S. Да, хоть и статья про Python фреймворки, но упоминание Express.JS было, думаю хоть чуток все-же в тему.
Но все-же огромный минус, это 40-50 мегабайтная node_modules…
Так-то среднестатистический virtualenv в питоне с лёгкостью переваливает за сотню мегабайт :)
Мне особенно нравится, что Django не идет на послабления по поводу безопасности, чтобы ускорить темп разработки. Функции безопасности активируются по умолчанию, поэтому совершенно не важно, ленивы вы или нет.
Что это за вода? Что это за 'функции безопасности', которые автоматически активируются?
Давно django не смотрел (1.4 кажется поставил на одном проекте внутреннем). Как там сейчас с возможностью безболезненно следовать принципам SOLID, техническим принципам DDD и т. п.?
В каких случаях стоит использовать Django (а в каких не стоит)