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

Можно использовать алхимию с django. По крайней мере как-то так https://github.com/Deepwalker/aldjemy

jinja2 из коробки поддерживается.

Если выбирать между Pyramid и Django, то думаю что Django будет лучшим выбором.

Как вариант, почему не переписать это всё на Go?

С другой стороны, от Django получу целостный стек

Да целостная башенка из детских кубиков.

больше специалистов на рынке

Тупейшая дичь. Специалисты по джанге нужны только для одного — фиксить баги и дорабатывать фреймворк. А в приложениях фреймворк это достаточно тонкий слой, основной код мало на него завязан (не правда ли?). Так какого хрена ты надеешься что тупые личинки (прочитавшие джангобук) будут эффективнее для твоего продукта, чем такие же личинки, которые джангобук еще не читали.

Ладно бы еще с нуля брал джангу, но только одном переписывании с SQLAlchemy на DjangoORM погоришь.

Как вариант, почему не переписать это всё на Go?

И какую проблему это решит?

Были такие мысли. До вот любой веб-интерфейс - это костыть на костыле: сессии, куки, обработка хедеров, CSRF - не хочется это всё писать самому. Существующие библиотеки достаточно убоги. Да и реализаци бизнес-логики на нём - то еще счастье.

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

Ладно бы еще с нуля брал джангу, но только одном переписывании с SQLAlchemy на DjangoORM погоришь.

Это да. Кода с SQLAlchemy там очень много. А переходной этап обеспечивает всё равно только Pyramid.

Tornado/Flask?

А по теме, бери Flask. Он тупо не позволяет мешать фреймворк с бизнес логикой, в отличие от Джанги. И не лезет дальше http слоя. Чистая архитектура, все дела. За 15ти летний опыт еще ни разу не видел нормального проекта на джанге, постоянно адовая лапша.

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

В ассинхронщину не хочется лезть пока. Уж лучше тогда aiohttp

А по поводу Flask: очень много негативных отзывов. Субьективных и обьективных. От организации обьектов до проблем с большими проектами. Правда у меня нет опыта работы с ним, но пишут и говорят, что для больших проектов он не годится

https://youtu.be/jqU8l9EBQ54?t=42m16s

http://asvetlov.blogspot.com/2014/10/flask_20.html

Вообще много примеров, может конечно это личная неприязнь.

И хорошего кода на Flask я почти не видел :)

В ассинхронщину не хочется лезть пока.

Так не пиши асинхронно. Пиши синхронно. Торнадо просто удобен. Не влезал вглубь Flask, но то, что render в торнадо - метод объекта мне нравится больше.

У Светлова в бложике исключительно вкусовщина. Напоминает мое мнение о фласке лет пять назад. Но Армин на голову умнее и Cветлова и всех разработчиков джанги вместе взятых.

А по поводу Flask: очень много негативных отзывов. Субьективных и обьективных. От организации обьектов до проблем с большими проектами.

У больших проектов всегда большие проблемы.

Джанга решает некоторые организационные проблемы для работе в команде, но оно тебе надо? Оно ещё кучу батареек содержит которые лично не нафиг не сдались. Зато в вебсокеты, по-моему, до сих пор по-нормальному не научилось (страшные костыли с гитхаба не в счёт).

Вообще, писать про выбор фреймворков можно до бесконечности. Но это тебе ничего не даст. Тебе нужно сначала определиться с требованиями. А иначе разницы никакой, на любом фреймворке можно достигнуть успеха, разница «лишь» в трудозатратах.

И хорошего кода на Flask я почти не видел

Это не проблема flask. Хотя, я его не люблю, но я за микро-фреймворки.

По поводу твоих ссылок. Видео не смотрел, а по второй ничего особенного нет. Если threadlocal variables это самая большая проблема то тут и думать нечего, надо использовать.

Вообще, я бы не так подходил к проблеме. Мы последний год рефакторил одно старое говно, так вот начали мы с end-to-end тестов. Потом потихоньку модуль за модуль портировали на новые либы, убирали баги, итд. Писали документацию, проводили бенчмарки, пробовали разные подходы, делали прототипы. И потом выбирали то что нам больше подходило. И не всегда очевидный выбор был самым удачным.

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

Ссылка на ютубике: докладчик перешел на aiohttp.web, потому что захотел попробовать, технических аргументов не привел. Какие проблемы у него решились не рассказал. Тотально biased доклад. ЧТД.

Вообще, писать про выбор фреймворков можно до бесконечности. Но это тебе ничего не даст.

Это не тема про выбор фреймворка, а про миграцию конкретно с Pylons. Аргументы в пользу Pyramid такие, что остаются старые формы, запросы, шаблоны. Преимущества Django - только призрачные, что я могу легче потом отдать свой код кому-то на поддержку.

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

У меня основное требование: чтобы всё работало как раньше, только на Python3, чтобы было поддерживаемым.

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

Наверное так и сделаю...

Спасибо

Начинал писать еще лет 10 назад

За это время уже вышло нормальное готовое решение, инфа сотка

Это не проблема flask. Хотя, я его не люблю, но я за микро-фреймворки.

Flask — не настолько уж и микро (за этим к bottle из синхронных), да и он зачастую медленнее джанги. Зачем он вообще?

Pyramid или Django?

flask?

Может быть, но кто его будет покупать, а тем более внедрять? Даже внедрение - это будут те же деньги.

да и он зачастую медленнее джанги.

ОБС? Тот кто видел выхлоп профилировщика на джанге, тот в цирке не смеется.

Бенчмарки с равными middleware.

Flask — не настолько уж и микро (за этим к bottle из синхронных), да и он зачастую медленнее джанги. Зачем он вообще?

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

Но последний проект делал на aiohttp потому что мне нужна была безгеморойная асинхронщина. И сел с ним в лужу из-за лютых багов в yarl (пофиксили спустя месяца 4). И вообще, внутри оно оказалось весьма посредственно написанным, увы.

Tornado очень удобен в плане расширения, захочешь асинхронщину дописать - пожалста в лучшем виде. Синхронщину - после того как разберешься одно удовольствие писать, но это моё субъективное мнение. Из всех фреймворков он занимает уникальное, особое место. Мой совет - изучай его и джанго пойдёт лесом. Инструмент на века.

Но есть и минус, он очень большой и его не сразу можно осмыслить.

Сказал А, говори Б.

Я сказал всё что хотел, дальше уже выбор топикпастера.

Назови, о каком минусе шла речь? Мне самому интересно.

На нём сходу сложно начать писать, ничего о нём не зная... ну это чисто моё мнение...

Можно использовать алхимию с django.

оно еще живо?

ОП переписывай все на python3 + flask, оставишь алхимию и формы, останется чутка переписать контроллеры и апликуху.

На самом деле у Django есть много полезных абстракций (менеджеры моделей, CBV...) и нужно это всё изучить и действительно осмыслить как правильно готовить, а не начинать городить сходу

if request.method == 'POST":
    ...

Сборники best practices помогают.

менеджеры моделей

использую

CBV

что это?

if request.method == 'POST"

@require_POST

или class-based views

CBV

что это?

или class-based views

Никто не говорит, что кто-то это не использует. Речь о том, что не все это используют. И потом сложно рефакторить и поддерживать такой код.

И вот не могу определиться: Pyramid или Django?

Flask конечно же

последний проект делал на aiohttp потому что мне нужна была безгеморойная асинхронщина

Вот это еще зацени https://falconframework.org/

Falcon уже когда-то пробовал. Хороший скелет для API, но не для веб-приложения, в котором не хочется изобретать велосипеды.

Хороший скелет для API, но не для веб-приложения, в котором не хочется изобретать велосипеды.

А мы с точностью да наоборот подумали. Только балансируем между Falcon и Flask. Если уж говорить про современные веб-приложения - то львиная доля возможностей современных фреймворков в принципе отпадает, разве что админка какая-то может пригодиться. Современное веб-приложение - это считай два разных модуля:

1. HTML+JS на каком-нибудь асинхронном AngularJS и подобном

2. Правильный бекэенд

И прослойка между ними в виде API

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

вот тут плюсую люто, бешено. жаль, мало кто это понимает

1. HTML+JS на каком-нибудь асинхронном AngularJS и подобном

И через сколько нужно будет такое приложение переписывать? Переписал я часть интерфейса как-то на Backbone. И где он сейчас? тоже почти в maintenance mode, а новые возможности нужны. Переписывать снова на AngularJS, который тоже подпирает Angular4? Эта вся современность веб-приложений уже комом в горле. А html-шаблоны будут генериться и показываться в браузере через 10 лет. И не хочется разбираться в г-не под названием JavaScript и тратить на него 70% времени на разработку.

Вобщем, попробовал я всё в Pyramid, всё устраивает. Миграция должны пройти легко. Есть пакет pyramid_beaker, с помощью которого я сделаю общие сессии для двух приложений одновременно на переходной этап.

Всем спасибо.

И через сколько нужно будет такое приложение переписывать?

А зачем его переписывать?

Бенчмарки с равными middleware.

Хеллоуворлд с пустыми мидлварями:

# flask
~$ wrk -d 10 -t 10 -c 10 http://127.0.0.1:8000
Running 10s test @ http://127.0.0.1:8000
  10 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.63ms  759.68us  21.55ms   92.01%
    Req/Sec   632.63     49.85     1.30k    88.46%
  63310 requests in 10.10s, 5.49MB read
Requests/sec:   6269.17
Transfer/sec:    557.12KB

# django
~$ wrk -d 10 -t 10 -c 10 http://127.0.0.1:8000
Running 10s test @ http://127.0.0.1:8000
  10 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.80ms    1.00ms  18.56ms   91.20%
    Req/Sec   546.77     55.65   720.00     75.45%
  53974 requests in 10.01s, 4.68MB read
  Socket errors: connect 0, read 53974, write 0, timeout 0
Requests/sec:   5391.90
Transfer/sec:    479.20KB

Фласковое приложение скопипащено с главной проекта, джанговский одномодульник:

import os
import json

os.environ['DJANGO_SETTINGS_MODULE'] = 'django_app'

SECRET_KEY = 'boo'
DEBUG = True
ROOT_URLCONF = __name__
MIDDLEWARE = ()


from django.conf.urls import url
from django.http import HttpResponse


def hello(request):
    return HttpResponse('Hello, World!')


urlpatterns = [
    url(r'', hello),
]

from django.core.wsgi import get_wsgi_application
app = get_wsgi_application()

Запуск:

uwsgi --http :8000 --workers=4 --http-keepalive=1 -w flask_app:app --need-app &> /dev/null

uwsgi --http :8000 --workers=4 --http-keepalive=1 -w django_app:app --need-app &> /dev/null

А зачем его переписывать?

Потому что статика уже через джва года не будет собираться. Фронтовые мартышки, которые пишет тулинг, вообще не умеют в обратную совместимость. Ладно на npm ты еще найдешь пакеты, и случится, что версии пакетов запинены в package.json. Но все это не взлетит без бубнов на текущей ноде, хе-хе.

Но все это не взлетит без бубнов на текущей ноде, хе-хе.

А при чем тут нода? Выше я писал что бэк должен быть правильным. А фронт это удел дизайнеров и js программистов. Ничего не мешает сделать локальную копию фронта и заморозить версии жабаскриптов

Хочу генератор angular форм по моделям. От неимения накостылил сам на базе wtf и jinja2 макросов.

А при чем тут нода? Выше я писал что бэк должен быть правильным.

При том что твой правильный бек никому не нужен без кнопочек в браузере.

Ничего не мешает сделать локальную копию фронта и заморозить версии жабаскриптов

А менять и поддерживать как?

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

Во, наш человек!

Ничего не мешает сделать локальную копию фронта и заморозить версии жабаскриптов

А менять и поддерживать как?

А разве тут много вариантов? Тут либо сидеть на старом и страдать, либо обновляться раз в пять лет и страдать, либо периодически обновлять и страдать.

Лично я за плановое периодическое обновление чтобы не было как у нас «ой, наш реакт жутко устарел, но обновляться мы не можем потому что слишком много гемора со сторонними модулями». Разумеется, если нет покрытия тестами то при каждом обновлении что-нить да отвалится. Но обновляться раз в пять лет ещё хуже, имхо.

А при чем тут нода? Выше я писал что бэк должен быть правильным.

При том что твой правильный бек никому не нужен без кнопочек в браузере.

Похоже ты плохо понимаешь о чем вообще идет речь

Похоже ты плохо понимаешь о чем вообще идет речь

Прекрасно понимаю. Большинство инхауз интерфейсов можно было бы сделать на фласкоадминке и это было бы поддерживаемым. Но вместо корячится SPA на текущем модномолодежном и так и застревает на том тулинге, на котором в свое время делалось и поддерживать дорого и больно. В современном мире уже давно забили на решение проблем, каждый пионер хочет попробовать новые технологии, объясняя это техническими нуждами, булшит все это.

А разве тут много вариантов?

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

Похоже ты плохо понимаешь о чем вообще идет речь

Только сейчас понял что ноду ты воспринял как бековую историю. Как ты js будешь собирать без ноды? Сейчас то ты понял причем тут она?

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

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