LINUX.ORG.RU

Django в 2017 году и его подводные камни

 , ,


1

5

Осваиваюсь понемногу в питоне и появилась неоднозначность в выборе django как основного инструмента. Да он еще популярен, но насколько актуален сейчас? Не мало народу хейтят его, говоря о чем-то стронем типа flask...

Есть люди, которые долгое время пользовались django и могли бы поведать его подводные тайны? Можно любые недостатки и вообще свое мнение по нему (хочу сразу окунуться в то, с чем могу столкнуться и понять насколько это критично вообще).

Не мало народу хейтят

не мало народу хейтят что угодно, ткни пальцем в любую технологию и найдешь тонны хейта (не забудь помыть палец после)

Но вообще актуален для работы, хотя бы потому что на нем много проектов надо поддерживать. Для пет-прожектов я бы брал flask ибо он сииильно проще и в нем нет такого количество всего подрят как в django.

Dred ★★★★★
()

Зарабатываю на Upwork $25-$30 в час, пишу 90% проектов на Django, длительность от 1 мес. Раньше было работ не очень много - сейчас каждый день есть 1-2 неплохие работы. Используем в связки с Vue/Angular 1.5, sass, pug. Т.ч Джанга кормит и стала раза в 2 популярнее рельс, если не в 3.

menangen ★★★★★
()
Ответ на: комментарий от Dred

не мало народу хейтят что угодно, ткни пальцем в любую технологию и найдешь тонны хейта (не забудь помыть палец после)

А если тыкнуть в руби - то палец лучше вовсе ампутировать.

Siado ★★★★★
()
Ответ на: комментарий от Siado

не мало народу хейтят что угодно, ткни пальцем в любую технологию и найдешь тонны хейта (не забудь помыть палец после)

А если тыкнуть в руби - то палец лучше вовсе ампутировать.

Лучше положить в рот радикальным питонистам - они с удовольствием откусят.)

Virtuos86 ★★★★★
()

Бери Django, только крайнюю версию и python 3.6

На фласке работы мало, да и работников мало.

ggrn ★★★★★
()

Подводные камни — неумение в нормальную асинхронность (django-channels убог) и, следовательно, костыльность вебсокетов. Ну и джанга сделана с оглядкой на рендеринг html, в 2017 многим это не нужно. Но жить можно.

Подводные камни поприземлённее — да хотя бы i18n для js, но их не слишком много и все описаны в интернетах.

x3al ★★★★★
()
Последнее исправление: x3al (всего исправлений: 1)

Есть люди, которые долгое время пользовались django и могли бы поведать его подводные тайны? Можно любые недостатки и вообще свое мнение по нему (хочу сразу окунуться в то, с чем могу столкнуться и понять насколько это критично вообще).

Когда тебе надо чуть более чем самый простой запрос к базе данных сделать, ОРМ тебе начинает мешать.

Нет хорошей интеграции с новомодными жабоскриптовскими фреймворками. Хрен знает, есть ли она где-то.

anonymous
()
Ответ на: комментарий от Virtuos86

Не стОит. За лето даже не отдохнул, да и лето Г то ещё выдалось, тупо меняю своё время на бабло.

menangen ★★★★★
()
Ответ на: комментарий от wist512

и что ты рекомендуешь тогда?

Вали из веб-разработки нафиг, пока не засосало.

Ничего, кроме джанги я ни во что толком не писал. Сейчас на торнадо поглядываю краем глаза.

anonymous
()

Подводные камни в том, что оно на скриптовом языке с динамической типизацией.

Deleted
()
Ответ на: комментарий от x3al

https://github.com/ezhome/django-webpack-loader хватит всем, кому не нужно SSR.

Где автоматическое подхватывание джанговских моделей вместе с валидацией в клиенте?

Проблема этих самых новомодных жабоскриптовских фреймворков в том, что они себя мнят пупом земли. Сраный gcc-кросс-тулчейн под арм проще собрать, чем написать начисто конфигурацию webpack под какой нибудь реакт. А интеграции с остальным миром - не, пускай крутятся как хотят.

anonymous
()
Ответ на: комментарий от wist512

Из python фреймворков самый адекватный это pyramid

anonymous
()
Ответ на: комментарий от Deleted

А какая нормальная альтернатива есть на статик. языков? Го он удобен для небольшого проекта, в крупном даже отсутствие перегрузки функции превращает один только модуль в лапшу из полу-названий.

Джава ЕЕ это ад нулевых, Spring Boot тот же монстр завернутый в обертку от конфетки (и пока не разворачиваешь ничего сложно и все хорошо), с нуля писать свое на embedded серверах, можно, но толком доков и модульных решений нет (потому что подход не популярный и все дрочат то спринг mvc, то сервлеты)

wist512
() автор топика
Ответ на: комментарий от wist512

Джава ЕЕ это ад нулевых

Есть пачка других фреймворков, помимо ЕЕ и Spring, о них мало говорят, потому что стандарт Спринги и ЕЕ.

Вот hello world на Spark. Не сказать что какой-то ад из нулевых. В общем смотри на Spark, Ninja, Play, JavaLite, etc..

И это еще можешь глянуть - https://www.techempower.com/benchmarks/

import static spark.Spark.*;

public class HelloWorld {
    public static void main(String[] args) {
        get("/hello", (req, res) -> "Hello World");
    }
} 
ertgblasd ★★
()

Есть люди, которые долгое время пользовались django и могли бы поведать его подводные тайны?

Фреймворк как фреймворк. Веб писать можно.

Deleted
()
Ответ на: комментарий от Jopich1

Django сложно иногда «надеть» на существующую БД со сложными связями. Если уже такая есть, то лучше SQLAlchemy не найти. А если новый проект, то вполне можно мириться с недостатками.

paganmind
()
Ответ на: комментарий от Jopich1

Чтобы использовать Django, очевидно же. Что в нашем новом проекте по накалыванию дров не может быть 5-метровых брёвен? Может, но если у нас топор, то мы возьмём только 0,5-метровые.

paganmind
()
Ответ на: комментарий от Jopich1

Джанго это же не только ORM, а вообще: для простого CRUD'а (коего полно в обычном приложение), использовать ORM, для всего сложного чистый SQL.

wist512
() автор топика
Ответ на: комментарий от wist512

Зачем вам сейчас custom sql? Не будет хватать возможностей ORM или упрётесь во что-то, тогда уже и можно будет пару запросов на нём дописать.

Про составным primary - это скорее по описанию модели, а не по запросам.

paganmind
()
Ответ на: комментарий от ggrn

Фреймворк - это одни только ORM? И я как раз и писал что можно юзать ORM + SQL (а не упарываться на CRUD голым sql).

Хотя по хорошему, все равно лучше обернуть в DAO

wist512
() автор топика
Ответ на: комментарий от wist512

И я как раз и писал что можно юзать ORM + SQL (а не упарываться на CRUD голым sql).

Можно, можно. Это сильно раздражает, потому что ORM абстрагирует от конкретной базы данных, фильтрует входные параметры и всё такое. Но можно и на чистом SQL.

Хотя по хорошему, все равно лучше обернуть в DAO

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

anonymous
()
Ответ на: комментарий от anonymous

Насколько я помню, нет возможности полностью объектной моделью (ORM) покрыть возможности реляционной базы данных. Есть конечно полный бред, когда люди описывают на псевдо-синтаксисе тот же SQL, который еще и не покрывает всех возможностей SQL. Но на самом деле, единственно что важно во всем этом - это автоматический маппинг, а писать на голом SQL даже удобнее (если не разворачивать руками столбцы в SELECT).

Что касается прослойки между БД и твоим кодом, то никакой прослойки нет потому, что нет стандарта ORM (например как JPA), поэтому единственным - реально гибким слоем между бизнес логикой и БД это DAO-интерфейсы, которые ты можешь действительно подменить налету, вне зависимости ORM там у тебя или вообще даже не база данных (например текстовый файл).

То есть, написав в контроллерах или моделях ORM код, ты так же хардкорно говнокодишь как и обычно, так как сменив ORM ты реально офигеешь, что тебе придется руками проделать.

И да, сменить ORM либу приходится чаще, чем сменить базу данных, поэтому рассказывать маркетинговый буллшит об обратном - не стоит. DAO реализованные через интерфейсы - это реально абстрактный слой.

wist512
() автор топика
Ответ на: комментарий от wist512

Ты таки себе из моего ответа чего-то навыдумывал и я не знаю о чем ты споришь. Я с тобой по большей части согласен.

anonymous
()
Ответ на: комментарий от wist512

И да, сменить ORM либу приходится чаще, чем сменить базу данных,

Вот отсюда по подробнее пожалуйста.

ggrn ★★★★★
()
Ответ на: комментарий от wist512

Пфу - я имел ввиду сопрягать custom sql с моделями в Django. Вот например в Catalyst ( под Perl ) это можно было делать. А фигачить курсоры с селектами любой дурак может - зачем тогда ORM вообще ?

Jopich1
()

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

anonymous
()
Ответ на: комментарий от ggrn

Качество и возможности популярных СУБД на голову обходят качество и возможности некоторых ОРМ

wist512
() автор топика
Ответ на: комментарий от x3al

Ну и джанга сделана с оглядкой на рендеринг html, в 2017 многим это не нужно.

С точки зрения разработчика рендеринг на клиенте это конечно вин, меньше сервер грузит, но вот с точки зрения юзера все наоборот. У меня например до сих пор бомбит с нового ютуба, который подгружает интерфейс через 2-3 секунды после видео, да и превьюшки релейтедов грузятся со скорость одна в секунду, при этом насилуя i7 будто там гента компиляется. И таких примеров масса.

Поэтому лучше уж старый добрый сервер рендеринг + кешинг всего возможного чем вот эта тормозная дрысня.

entefeed ☆☆☆
()
Ответ на: комментарий от entefeed

Помню когда-то гнобили флеш за то, что он батарейку кушает, а теперь весь говно-DOM на клиенте собирают и типо норм же все.

wist512
() автор топика
Ответ на: комментарий от entefeed

У меня например до сих пор бомбит с нового ютуба, который подгружает интерфейс через 2-3 секунды после видео

Плюсую, так тормознуто работает. Особенно бесит, когда открываю видео по ссылке на комментарий.

templarrr ★★★★★
()
Ответ на: комментарий от templarrr

Плюсую, так тормознуто работает. Особенно бесит, когда открываю видео по ссылке на комментарий.

Тонны JS-кода!

Deleted
()
Ответ на: комментарий от ggrn

Джанга вполне себе модульная, ты можешь не использовать местный ORM и использовать SQLAlchemy, если тебе местный ORM чем-то не угодил, в том числе функционалом.

Вообще, скатываться на голый SQL необходимости не возникало, а вот использовать некоторую часть продвинутых возможностей PostgreSQL регулярно да - они реализованы дополнительным модулем к ORM:

https://docs.djangoproject.com/en/1.11/ref/contrib/postgres/

Аналогично кто-то бы мог и запилить какие-то продвинутые фичи Firebird модулем к Django ORM, но по понятным причинам (пока) не сделал.

ORM - конечно, абстракция от СУБД, но сохранять эту абстракцию как самоцель - бессмысленно: нормальные проекты не прыгают с SQLite на MySQL, а потом на Postgres, а потом обратно. Берут, например, на хероке PostgreSQL и ведут на ней разработку, вплоть до продакшена.

BigAlex ★★★
()
Ответ на: комментарий от entefeed

С точки зрения разработчика рендеринг на клиенте это конечно вин, меньше сервер грузит, но вот с точки зрения юзера все наоборот.

У некоторых HTML не рендерится нигде. Веб-браузер — не единственный возможный клиент для REST (или graphql) API.

x3al ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.