LINUX.ORG.RU
решено Форум — Web-development  

Портирование веб-приложения на Python3 с современным фреймворком

 , , ,


0

3

Приветствую,

Есть достаточно большое веб-приложение для внутреннего использования, написанное на Pylons+SQLAlchemy+Jinja2+WTForms. Начинал писать еще лет 10 назад, потом оно расширялось, обростало модулями, а потом даже появилось API на Go.

Как известно, Pylons давно в maintenance mode, скоро закончится поддержка Python2. Все используемые сторонние библиотеки давно портированы на Python3.

Нужно двигаться к возможности работы приложения на Python3, а с ним и выбрать новый фреймфорк. И вот не могу определиться: Pyramid или Django?

С одной стороны, при портировании на Pyramid можно оставить связку SQLAlchemy+Jinja2+WTForms, и переписывать по модулям или даже контроллерам используя интересную технику подстановки старого приложения вместо not_found хэндлера.

https://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/porting/in...

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

Django ORM по прежнему ужасна, да.

Есть ли у вас опыт портирования старого веб-приложения на Pylons и какие итоги?

★

Последнее исправление: paganmind (всего исправлений: 1)
← Nginx + uWSGI + virtualenv + Django на Debian
Управление зависимостями зависимостей npm →
  1 2 →
Ответ на: комментарий от true_admin

Вообще, речь изначально была о веб-приложениях.

Современное веб-приложение - это считай два разных модуля:
1. HTML+JS на каком-нибудь асинхронном AngularJS и подобном
2. Правильный бекэенд

И генерация html на беке это простой способ сделать большую часть из них.

Речь о js-библиотеках на фронтенде.

Лучшее решение проблемы — это не иметь ее изначально, не так ли?

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

И генерация html на беке это простой способ сделать большую часть из них.

Я живу в мире где html «рисуется» из js. Даже если это server-side rendering. Поэтому никакие проблемы отрисовкой на бэкенде не решить. Я бы даже сказал это добавляет проблем т.к. надо держать ещё и дополнительный сервис на node для этого (если я правильно представляю как это работает, пардон за ошибки, я далёк от фронтенда).

Лучшее решение проблемы — это не иметь ее изначально, не так ли?

В смысле отказаться от js? :)

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

Займитесь чем-нибудь полезным лучше

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

надо держать ещё и дополнительный сервис на node

Да, что ж вы так зафиксировались то на ноде в качестве бека. Нет конечно, этот вариант — худшее что может быть.

В смысле отказаться от js? :)

Бинго, файнали.

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

В смысле отказаться от js? :)

Бинго, файнали.

Ага, а лучше сразу вернуться на cgi. Или BBS (мне, кстати, нравились их ascii-интерфейсы).

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

Пардоньте, месье, но с той скоростью, с которой вебобезьянки пишут переписывают свои фреймворки, поддержка слишком дорого стоит. Как минимум ещё 10 лет будет jquery.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 →
← Nginx + uWSGI + virtualenv + Django на Debian
Web-development
Управление зависимостями зависимостей npm →