python_leader 12 сен в 07:30

Какой Python-фреймворк выбрать: Django, Flask или FastAPI?

Простой

9 мин

8.9K

Программирование * Python * Django * Flask *

Обзор

Перевод

Комментарии 16

FFiX 12 сен в 07:51

Мне кажется, вы сравниваете инструменты из разных миров. Никто не будет делать микросервис на django, также как вряд ли кто-то будет делать полнофункциональный монолит-сайт на flask или fastapi. Опять же, в 2025 flask — это скорее обвязка для ML-сервиса, а FastAPI для всего остального ибо асинхронно и быстро.

Но эти инструменты и так на слуху. Было бы круто рассмотреть более широкий спектр инструментов вроде Starlette, Litestar, Sanic, Aiohttp и других.

rSedoy 12 сен в 08:35

хм, а какие специфичные требования в "обвязка для ML-сервиса", из-за которых стоило бы выбрать именно Flask, а не FastAPI?

FFiX 12 сен в 08:45

Из синхронного Flask удобнее общаться с синхронными ML-либами и в условиях куба удобнее крутить лимиты без упора в троттлинг.
В целом, можно и на fastapi, но запускать синхронный код из асинхронного считается плохой практикой плюс это сложнее менеджерить с точки зрения тех же лимитов.

rSedoy 12 сен в 08:49

так в fastapi и синхронные обработчики можно указывать, хотя конечно я не разбирался как они влияют на процесс обработки запроса в ASGI сервере.

DMGarikk 12 сен в 08:36

Никто не будет делать микросервис на django

а ведь делают...drf и вперед ;)) уже несколько раз такое видел

ink_off 12 сен в 13:42

а чем это плохо?

DMGarikk 12 сен в 14:17

джанго тяжеловат для "микро" сервисов

ink_off 12 сен в 14:48

Согласен с Вами в отношении "микро" сервиса в его истинном понимании, но касаемо API через DRF - этож нормальная практика.

Tishka17 13 сен в 23:32

В чем именно выражается эта тяжесть? На самом деле каждый микросервис - это монолит производного размера. Что выбирать для его разработки зависит от ситуации. Мы прекрасно живём на работе с микросервисом на джанге, в том время как другие микросервисы написаны на других фреймворках и языках.

NovoManu 14 сен в 04:58

тяжесть выражается в том, что в Django, как и в любом другом полноценном фреймворке, "все включено", а команда разработчиков какие-то или многие функции фреймворка не использует или они не нужны для текущего микросервиса. И все эти неиспользуемые фичи висят мертвым грузом

das_tier 14 сен в 09:50

И пусть висят, есть не просят

izibrizi2 13 сен в 10:38

Litestar неплохо выглядит - асинхронный с di как fastapi и в то же время имеет батарейки кау джанга

Tishka17 13 сен в 23:33

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

rSedoy 12 сен в 08:29

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

acDev 14 сен в 21:22

Django очень медленный:

https://www.techempower.com/benchmarks/#section=test&runid=e8b36ecc-d623-48bb-936d-d043e9db2c13&l=zik0zj-cn2&a=2&test=json

swcasimiro 29 сен в 00:11

Я как понимаю, что нужно писать всегда на самом быстром? Даже там где эта скорость не нужна? Так почему не rust? Даже go будет в несколько раз быстрее, чем python с асинхронным / синхронным фреймворком. Бред. Нужен сервис с админкой за пару дней - бери Django. Нет ни одной админки для fastapi близко к уровню админки Django. Не во всех проектах нужна скорость, а усложнять написание ради rps где он даже и не нужен - бред. Сразу пиши на rust, разница будет больше, чем fastapi обгоняет django.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий