Стоит ли выбирать Django под real-time?

Здравствуйте форумчане.
Пытаюсь определиться с движком для веб-приложения.
На Python пишу пару лет, но в основном мелкие скрипты автоматизации, решил вот недавно заняться чем-то посерьезнее и как-раз подвернулся мой давнешний проект, написанный на php еще будучи студентом.
Ни один из веб-фреймворков я на данный момент не знаю (имею в виду - на Python), и встал перед выбором - на чем собирать сайт.
По диагонали прочитал пару книжек по Django, слегка погуглил, разобрался в тестовых примерах. Не уверен, что мне подойдет.
По сути это не столько сайт, сколько приложение для постоянной работы, что означает:
- Real-Time. А значит 80% нагрузки - запросы Ajax.
- Все, что можно спихнуть в JS должно быть там. Серверу оставляю - отдачу статики, обслуживание ajax, разруливание прав ну и БД.
- Модель и часть вьюшек уже есть + есть вполне себе работающая версия на голом php, хотя исходники даже смотреть не хочется - не сам бы писал - убил бы.. ^_^, осталось проработать controls и выбрать наконец движок.

Выводы после первого знакомства с Django (другие фреймворки пока не смотрел):
- Про работу с ajax в одной книжке ничего, в другой одна небольшая статейка с примером. В тырнете говорят, что не очень Django с ajax стыкуется (а это основной функционал сайта).
- Не очень понравилась работа с SQL-запросами - даже "SELECT `name` FROM `table` WHERE `id`='{id}'".format(id=my_id) показалось мне удобнее, придется сперва придумывать SQL-запрос, а уже потом переводить его в ООП представление. Ну это дело привычки.
- Админка с первого взгляда показалась не слишком удобной, хотя отдельные элементы я бы из нее себе утащил. Возможно со временем пойму, за что её так хвалят.
- Не нужного мне явно больше, чем нужного - а значит придется пилить самому.. Впрочем это от фреймворка не зависит.
+ Вещь популярная, а значит будет кого спросить, наткнувшись на очередной косяк (на этом форуме даже отдельный подраздел создан)
+ Есть литература, справка, готовые решения.

Посоветуйте - стоит ли продолжать разбираться с Django и начинать переделывать сайт на ней, или лучше пока отложить и присмотреться к другому фреймворку (следующий на очереди - Pyramid, ещё есть парочка на первый взгляд годных. Zopа не понравилась, но совсем уж по верхушкам пробежался..)?

0

Урра, вышел Django 1.5, с поддержкой Python3. Можно не возвращаться к 2.7 - Возня с кодировками достала когда-то..

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

0

Django, наверное, самый развитый
это так, в инете нашёл

1

accept, Большое спасибо, как раз, то, что нужно.

Решил все же остановиться на django, хотя pyramid с первого взгляда больше понравился, но документации меньше.
А значит, теперь я тут частый гость, буду доставать тупыми вопросами ^_^..

0

Сообщение от sKotenok - Про работу с ajax в одной книжке ничего, в другой одна небольшая статейка с примером. В тырнете говорят, что не очень Django с ajax стыкуется (а это основной функционал сайта).

С ajax'ом никаких проблем нет. У самого сайт с ajax работает. Да и к джанго это не относится, в общем, так как, клиентская сторона - сделать запрос и обновить данные. Есть dajax для джанго. Но предпочитаю без него работать. Хотя, с ним все в порядке тоже.

Сообщение от sKotenok - Не очень понравилась работа с SQL-запросами - даже "SELECT `name` FROM `table` WHERE `id`='{id}'".format(id=my_id) показалось мне удобнее, придется сперва придумывать SQL-запрос, а уже потом переводить его в ООП представление. Ну это дело привычки.

Это только дело привычки. Работать с объектами ничуть не тяжелее, чем с SQL. Апи там хороший. Главное, что получится независимым от бэкэнда. К тому же, никто тебе не запрещает делать SQL запросы напрямую.

Сообщение от sKotenok - Админка с первого взгляда показалась не слишком удобной

Хммм...она настраиваема. Модели свои пропиши, как следует для админки. Добавить фнукционал в админку тоже не проблема.

Я б на Django сделал.

Добавлено через 2 минуты

Сообщение от sKotenok Про работу с ajax в одной книжке ничего

Потому что ajax не серверная технология и к django отношения не имеет. А django - серверная. То, что про нее не написано в книжке - это нормально.

1

Vourhey, Вообще-то отличия при работе с ajax и "обычной" отдачей с собиранием странички из вьюшек - существенны.
В 1ю очередь - скорость работы. Если в обычном режиме я могу себе позволить достаточно много излишеств и не сильно напрягаться на счет производительности (пока сайт не станет достаточно нагруженным, но тогда можно будет и ресурсов добавить).. То в режиме real-time предполагается, что каждый клиент шлет в среднем 1 запрос в секунду (данные разных клиентов нужно постоянно синхронизировать) и тут уже чем меньше прослойка между БД и выданными данными (в тактах процессора) - тем лучше (при ~100 открытых окнах мой дешевый VPS доходит до точки и начинает подвисать, но это на голом php+apache+куча тормозных решений, которые давно пора на свалку). Будь это off-line проект, я бы с чистой совестью переделал логику на втроенных процедурах, но выставлять БД "голой жопой" в открытую сеть как-то не рискну + таки веб-морда, а не толстый клиент..

Работа с обьектами тяжелее в том плане, что SQL я уже знаю и относительно неплохо. Т.е. когда нужно сделать запрос к БД, я его выдумываю в SQL-нотации, а уже после могу перевести в ООП-представление. Да, независимость от конкретной БД - вещь хорошая, но разные базы данных имеют свои "особенности" и то, что будет быстро работать на мускуле, в каком-нибудь firebird потребует совершенно другого подхода (просто из опыта).
А вот чем ООП-представления хороши, при чем настолько, что я заставил себя разобраться, как это в djago работает - nosql. Если проект не загнется в середине пути, планирую уйти от мускуля на что-то вроде caché или couchdb и тут мне обьектная модель пригодится (перенести будет проще).

Решение остановиться на джанге уже принято, спасибо за ответ.

0

Сообщение от sKotenok Vourhey, Вообще-то отличия при работе с ajax и "обычной" отдачей с собиранием странички из вьюшек - существенны. В 1ю очередь - скорость работы. Если в обычном режиме я могу себе позволить достаточно много излишеств и не сильно напрягаться на счет производительности (пока сайт не станет достаточно нагруженным, но тогда можно будет и ресурсов добавить).. То в режиме real-time предполагается, что каждый клиент шлет в среднем 1 запрос в секунду (данные разных клиентов нужно постоянно синхронизировать) и тут уже чем меньше прослойка между БД и выданными данными (в тактах процессора) - тем лучше (при ~100 открытых окнах мой дешевый VPS доходит до точки и начинает подвисать, но это на голом php+apache+куча тормозных решений, которые давно пора на свалку). Будь это off-line проект, я бы с чистой совестью переделал логику на втроенных процедурах, но выставлять БД "голой жопой" в открытую сеть как-то не рискну + таки веб-морда, а не толстый клиент..

Вопросы производительности к вопросу о работе ajax'а и django отношения не имеют. Это нужно решать для каждого конкретного сайта. Ajax прекрасно работает и не важно, что на сервере крутится а все остальное - специфика.

Сообщение от sKotenok Работа с обьектами тяжелее в том плане, что SQL я уже знаю и относительно неплохо. Т.е. когда нужно сделать запрос к БД, я его выдумываю в SQL-нотации, а уже после могу перевести в ООП-представление. Да, независимость от конкретной БД - вещь хорошая, но разные базы данных имеют свои "особенности" и то, что будет быстро работать на мускуле, в каком-нибудь firebird потребует совершенно другого подхода (просто из опыта).

В Django об этом можно не задумываться. Никто не мешает sql вызывать напрямую, когда очень сильно захочется

Добавлено через 52 секунды
Ну да ладно, все фигня.

1

Сообщение от sKotenok ... или лучше пока отложить и присмотреться к другому фреймворку ...

Посмотрите ещё на flask

1

Странно, что я его как-то пропустил, пока выбирал. Но уже выбор сделан в пользу Джанги (сравнение как в рекламе росгосстраха, получилось). Уже перенёс часть модели и сижу с темплэйтами играюсь.

Скачал исходники, поглядел. На данный момент для меня - слишком минималистично, по сути это каркас для написания собственного фреймворка. Я бы с радостью, но пока закончу, Python4 наверное выйдет.

В целом - вещь неплохая, вот бы год назад на глаза мне попалась.

0