Исторически сложилось так, что где-то 90% легаси кода сейчас синхронного и только вот пару лет как внедряют FastAPI с асинхронкой, а роуты соответственно переносились еще с Flask как есть.
Я понимаю желание все взять и переписать на асинхронный код, но к сожалению продакшен в компаниях так не работает: когда проблему можно решить меньшими затратами, ее так и решают. Ну и глобально, разницы для производительности между запуском чекера в треде от FastAPI, в loop.run_in_executor или полным переписыванием на асинхронный вариант для остальных ручек не будет. Там не такие объемы запросов, чтобы чувстовалась разница между отдельным тредом и корутинами.
ну и в конце небольшую цитату классика:
Мы должны не вспоминать о мелких усовершенствованиях около 97% времени. Преждевременная оптимизация — корень всех зол. (Кнут)
Вот в том-то и дело, что при "правильном подходе" получится производительное, а при неправильном, например, будут глобальные engine и session_maker объявлены где попало и не будут закрываться транзакции нормально.
Плохо можно сделать на любом стеке, к сожалению. А у Django есть своя определенная ниша задач, где он себя очень хорошо показывает. Как заметил другой комментатор "Надо выбирать инструмент по задачи")
Стандартная история про методологию разработки обговорена со всех сторон по 100 раз, захотелось высказать что-то, что мне лично показалось не очевидным, т. к. не вижу 100500 статей об этом. Может быть именно к TDD притянуто за уши, но впервые с этой идей столкнулся именно там. И мне понравилось, как другие советы и правила методологии эту идею дополняют.
Я не хочу сказать, что соблюдать хорошие практики не надо (я за них обеими руками), лишь только, что мне легче работать с проектами, у которых есть хорошее покрытие тестами и эти тесты можно быстро прогнать.
Просто в реальной корпоративной разработке я повидал очень много разного и хорошей архитектуры, и SOLID и скрипты на 1.5к строк и оверинженерной архитектуры, где у каждого класса был свой абстрактный родитель, который даже мог быть пустым, но на всякий случай его создавали. Не всегда работаешь в идеальных условиях ¯\_(ツ)_/¯.
Я согласен, что тесты тестам рознь и бывают такие случаи, что лучше бы их не было, потому что становятся или очень хрупкими, или так обмазанные моками, что уже непонятно выполняется ли там хоть что-то реальное. Поэтому я и оговорился про хорошее покрытие. Эмпирически с чем работал, если > 70%, то уже все не так плохо в проекте. Такой код можно более менее спокойно рефакторить или пилить новые фичи.
Про хорошие практики тестов по крайней мере на Python еще точно поговорим в будущем.
Исторически сложилось так, что где-то 90% легаси кода сейчас синхронного и только вот пару лет как внедряют FastAPI с асинхронкой, а роуты соответственно переносились еще с Flask как есть.
Я понимаю желание все взять и переписать на асинхронный код, но к сожалению продакшен в компаниях так не работает: когда проблему можно решить меньшими затратами, ее так и решают. Ну и глобально, разницы для производительности между запуском чекера в треде от FastAPI, в
loop.run_in_executorили полным переписыванием на асинхронный вариант для остальных ручек не будет. Там не такие объемы запросов, чтобы чувстовалась разница между отдельным тредом и корутинами.ну и в конце небольшую цитату классика:
Вот в том-то и дело, что при "правильном подходе" получится производительное, а при неправильном, например, будут глобальные engine и session_maker объявлены где попало и не будут закрываться транзакции нормально.
Плохо можно сделать на любом стеке, к сожалению. А у Django есть своя определенная ниша задач, где он себя очень хорошо показывает. Как заметил другой комментатор "Надо выбирать инструмент по задачи")
Уточнить нельзя)
И поняли неправильно)
Стандартная история про методологию разработки обговорена со всех сторон по 100 раз, захотелось высказать что-то, что мне лично показалось не очевидным, т. к. не вижу 100500 статей об этом. Может быть именно к TDD притянуто за уши, но впервые с этой идей столкнулся именно там. И мне понравилось, как другие советы и правила методологии эту идею дополняют.
Я не хочу сказать, что соблюдать хорошие практики не надо (я за них обеими руками), лишь только, что мне легче работать с проектами, у которых есть хорошее покрытие тестами и эти тесты можно быстро прогнать.
Просто в реальной корпоративной разработке я повидал очень много разного и хорошей архитектуры, и SOLID и скрипты на 1.5к строк и оверинженерной архитектуры, где у каждого класса был свой абстрактный родитель, который даже мог быть пустым, но на всякий случай его создавали. Не всегда работаешь в идеальных условиях ¯\_(ツ)_/¯.
Я согласен, что тесты тестам рознь и бывают такие случаи, что лучше бы их не было, потому что становятся или очень хрупкими, или так обмазанные моками, что уже непонятно выполняется ли там хоть что-то реальное. Поэтому я и оговорился про хорошее покрытие. Эмпирически с чем работал, если > 70%, то уже все не так плохо в проекте. Такой код можно более менее спокойно рефакторить или пилить новые фичи.
Про хорошие практики тестов по крайней мере на Python еще точно поговорим в будущем.
Для всяких CI скриптов и админам на серверах будет супер удобно. Осталось всем на uv перейти, чтобы этот стандарт поддержать
Идея: Таймер помодоро - чтобы всегда был перед глазами и можно было быстро настроить по кнопкам