Python-сообщество

Разрабатываю специальное приложение для компании на tornado уже 1.5 года, в начале приложение было маленькое и красивое - всем понравилось, после этого посыпались заказы на расширение и углубление. В настоящее время, приложение превратилось в “портал/платформу” - более 300 типов данных, более 10 приложений в этой платформе, расширение через плагины и хуки. При сохранении какого-нибудь объекта с ним могут поработать 5-15 плагинов (хуков).
Все работает шустро. Проблема вот в чем - это все асинхронное.
На данный момент бизнес логики 80%, и асинхронность тут мешает:
- Более сложный код, высокий порог входа, сложнее работать с ошибками.
- Неудобное использование try..catch, в итоге нет использования.
- Проблема использования синхронного кода.
- Сложнее отлаживать.

В итоге программисты тяжело “входят” в проект, он их “пугает” и медленно развивается.
Плюсы которые дает асинхронность не перекрывает минусы.
Сейчас задумываюсь о миграции (что не быстрое дело) на мульти-потоковый фреймворк, либо попробовать вынести бизнес логику отдельно, а tornado оставить “мордой”, но пока особых плюсов в этом не вижу.

В итоге если перейду на другой фреймворк, для торнадо останется только какие-то узкие вещи типа чата, работа с web-сокетами и т.п.

Если у кого есть комментарии или советы - прошу…

Трудно что-то конкретное писать, не зная деталей.
Первая мысль после фразы “пугает”: нет документации или она не понятна.
Хуки и плагины как сделаны: спагетти колбэков, очередь, …?
Что именно пугает разработчиков?

Отладка - это да. Но к отладке через лог-файлы можно привыкнуть. Это не самый худший момент в истории. Тем более, что для большой системы уже имеет смысл задействовать CI и перенести акцент с отладки на контроль результата выполнения кода (в том числе, анализ результатов в лог-файлах).
Автоматизировав эту часть, вы решите проблему сложности поддержки кода, исправления ошибок и отладки. То, что так не любят делать разработчики - рутину. А значит, сделаете проект привлекательнее для них.

Можно рассмотреть вариант использования Twisted с Торнадо.

try-catch не самая нужная штука в принципе, десятилетиями писали и без этого.
А в асинхронном подходе это вообще естественно - не использовать try-catch - синхронный по своей сути.
Скажу больше, жалобы на отсутствие try-catch понятны в принципе, но их не должно быть, если проект с асинхронностью. Это как жалобы водителя на отсутствие полного привода в формуле 1.

Lexander
Первая мысль после фразы “пугает”: нет документации или она не понятна.

“ajail” проект, документации почти нет, та что есть не вся актуальна.

Lexander
Хуки и плагины как сделаны: спагетти колбэков, очередь, …?

Плагины - питон-пакеты, которые лежат в папке plugins, подключаются/отключаются мышкой через web интерфейс.
Во многие значимые функции можно врезаться (хук), например если нужно врезаться в сохранение объекта: API.save.bind(method, priority=50, async=True) # хуки сортируются по приоритету, могут быть синхронные.
колбеков мало, почти все идет через yield gen.Task, т.к. “нет” try..catche, многие методы возвращают (result, error)

Lexander
имеет смысл задействовать CI

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

Lexander
Twisted с Торнадо

Какие плюсы можно получить?

Lexander
Что именно пугает разработчиков?

Думаю - сложность.

Lexander
try-catch

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

Понятное дело, что все можно побороть и использовать, но минусов много, а плюсов кот наплакал, навскидку только обращение к api 2gis и yandex map, асинхронный доступ к БД (короткие запросы) - это не существенно.
Текущий проект может и не буду конвертировать, он глубоко зашел, а на счет следующих “толстых” проектов наверно буду смотреть в сторону мульти-поточных.

Но если конвертировать проект, рассматриваю только плавный переход, есть 2 идеи:
1) Сделать пул потоков при торнадо и туда заворачивать функционал
2) Переехать на многопоточный фрейворк, все асинхронные вызовы завернуть в tornado-loop, главное что-б они (tornado-loop) не схлеснулись между собой.

o7412369815963
“ajail” проект

Описка прям по Фрейду: a jail вместо agile в контексте сложного проекта :)

o7412369815963
Какие плюсы можно получить?

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

o7412369815963
Думаю - сложность.

Если я правильно понял, сложность системы в целом, а не самого кода.
Причем, из-за размера и отсутствия документации.

Я бы ничего не менял.
Любая большая система со временем разрастается так, что ее становится сложно поддерживать и развивать. Увеличиваются накладные расходы на проект. Это нормально.
Иногда смена архитектуры помогает, но в вашем случае, думаю, пользы будет немного или не будет вовсе, учитывая объем кода.

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

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

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

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

Что на выходе?
Проект большой (круто само по себе), но хорошо документированный, используется автоматизация рутинных операций (легко обслуживать и развивать).
Работа над частью проекта малой командой в составе большой. Есть четкие границы ответственности (а не “куда пошлют”).
Станет не так страшно даже новичкам, повысится производительность.

И да, никто ведь не мешает использовать try-catch в синхронных частях запускаемого асинхронно кода.
Срабатывание таймаута в асинхронных частях проверяете?
Если да, то все ОК.
Статус всегда определен.

Lexander
Срабатывание таймаута в асинхронных частях проверяете?Если да, то все ОК.Статус всегда определен.

Я так понял это для отлова обрыва асинхронной нити,
когда то были проблемы с обрывом и я заюзал механизм отлова exception для асинхронного кода (есть в tornado), после этого все норм, поэтому пока таймауты не внедрял, хотя можно для профилактики.


Спасибо, появились некоторые мысли/идеи.

Всегда пожалуйста.