Комментарии 22
Слишком однобоко, я бы минимум добавил связку FastAPI + SQLAlchemy + Alembic. А раз упомянуты инструменты разработки, то рассказать про управление установкой пакетов poerty, pipenv + еще вроде какие-то появились, проверку кода flake8, mypy и особенно ruff, ну и как же без pytest.
скажите, а зачем упоминать FastAPI если в данной подборке я выбрал Django, как рекомендованный мною фреймворк?) в таком случае нужно было и про Flask и Pyramid сюда пихать)
а на счет управления установкой и прочего: читайте ВНИМАТЕЛЬНО каждое слово, прежде чем давать мнение и комментарии))
я ясно выразился, что перечислил ТОЛЬКО стек для входа в веб разработку, если человек никогда не ставил сторонние либы, спрашивается: зачем он смотрит такую статью? по-моему менеджеры пакетов учат раньше чем ООП какое-нибудь)
насчет pytest: тестировать API можно и на django rest framework tests, и она довольно неплохо с этим справляется)
а что касается flake8 и подобного: линтинг также учится раньше чем веб)
скажите, а зачем упоминать FastAPI если в данной подборке я выбрал Django, как рекомендованный мною фреймворк?) в таком случае нужно было и про Flask и Pyramid сюда пихать)
я сразу назвал причину зачем - "Слишком однобоко" и чтобы минимум знать хотя бы одну альтернативу
я ясно выразился, что перечислил ТОЛЬКО стек для входа в веб разработку
почти во всех статьях для новичков, я вижу упоминание виртуального окружения и остановки пакетов, про docker вы же сразу упомянули
а что касается flake8 и подобного: линтинг также учится раньше чем веб)
их не надо учить, надо сразу использовать когда появляется код, можно сразу отловить кучу ошибок и опечаток
а не однобоко требовать от джуна питониста только бек? может быть ему стоит еще и React какой-нибудь выучить, если новичок начнет вариться в этой теме - после Django сам уже решит, учить что-то еще или нет, для старта джанги с головой хватает, с учетом того, что на нем пишутся большие проекты и сервисы, в отличии от FastAPI
почти во всех статьях для новичков, я вижу упоминание виртуального окружения и остановки пакетов, про docker вы же сразу упомянули
так, внимательно прочитайте мой комментарий: статься НЕ для новичков в разработке на питоне, а для тех, кто хочет начать писать бекенд, если человек не работал ни разу с пакетными менеджерами, то он еще не знает даже самых основ, а если он их не знает, то смысла читать про бек тоже нету, с такими мыслями сюда можно еще и ООП приписать, функции, основные алгоритмы, массивы и так далее. статься заточена под бек для тех, кто уже и имеет опыт в нативном питоне и работой хотя бы с одной сторонней либой, я думаю это и так понятно по написанному, при чем, я подчеркнул этот момент в итогах
их не надо учить, надо сразу использовать когда появляется код, можно сразу отловить кучу ошибок и опечаток
опять отвечаю на одно и тоже: статься для тех, кто уже делал что-то, а не только сел за питон, подобное учится как вы сказали "когда только появляется код", а не тогда, когда уже сел бек учить
Яростно плюсую)) не надо нам новичкам пихать всего да побольше, только ради "альтернативы". Мне и этой однобокости за глаза хватает. А есть ли рекомендации в очередности изучения этих инструментов? Или все сразу учить надо, параллельно? Меня это больше всего напрягает в учебе. Когда много технологий, они ещё связаны друг с другом, и в итоге пока одно изучаешь, второе уже забываешь. И не дай бог случайно углубишься во что-то одно))) страдают остальные 4-5 направлений.. а ведь теорию ещё закрепить практикой надо... Брр
по очередности я бы учил так:
Django + DRF + Docker и БД
уже на существующих опыт и проект добавить Celery и Redis
ну а потом уже все остальное, git, js и так далее
такая очередность даст нормальный выхлоп, по первому пункту возьмете фреймворки и сразу на них накатите контейнера, потом к этому всему уже добавите асинхронность
Раз уж речь зашла про однобокость.
FastApi+Alchemi+Alembic - а с чего такая рекомендация а не, напрмер, Litestar+PonyOrm ?
почему предложен Poetry - a не Rye?
Почему Pipenv а не conda?
Почему Pytest а не Unittest
C чего flake8 а не pylint?
@denis_py предложил универсальный набор для старта и я согласен, что с этого можно начать. Это в продолжение можно начать искать альтернативы, после осознания, что вырос из предложенного стека технологий, которых многим хватит за глаза на много лет вперед.
p.s. Я, например, давно перерос FastApi, пройдя его элегантность на старте, и встретив лютые костыли, когда стало надо делать что-то более сложное в проекте на over 300 000 строк кода. Можно посмотреть мои issues в проектах Pydantic v2 и FastApi. В конечном итоге мы в проекте переехали на Sanic. А чуть позже - на Litestar.
Потому что половина из этого очень малоизвестные библиотеки, еще странно сравнивать стандартный unittest с pytest, а про установку пакетов, я сразу написал, что есть варианты, вот почему вы conda захотели, а не, например uv (почему вообще сравнение Poetr с Rye и Pipenv с conda, это отдельные пункты)? так же с другими, flake8 как пример, вот я же упомянул тот же ruff, он сейчас уже может заменить кучу из подобных.
А про "лютые костыли", так это часто проблема не библиотеки, а именно конкретного приложения.
Возьмем Litestar, я про него только сейчас узнал, зачем сейчас мне тащить его в свой стек разработки? С тем же FastAPI такой вопрос был года два назад (а может и раньше, точно не скажу), но он доказал свою эффективность. Возможно с Litestar так же будет, а может и нет.
Малоизвестные кому? Малоизвестные кто? PonyOrm? Pylint? Conda? Ладно, вместо Litestar возьмем Sanic, а вместо Rue возьмем pipx. Сойдут за "более известные" библиотеки?
Ruff появился недавно, Flake8 в 2010, Pylint в 2001 - кто более проверен, кто более известен, у кого больше звезд и наработок?
И кстати, а что не так с unitest и почему его не надо сравнивать с pytest?
Я к тому, что у всех свое болото, и то, что неизвестно мне, не означает, что это неизвестно никому. Потому выбор предложения для альтернативы примерам в статье пока считаю не обоснованным.
Сейчас малоизвестные - Litestar, PonyOrm, Rye, а мерятся звездами вообще последнее дело. Болото у всех свое, но я точно могу сказать, что про FastAPI больше знают, чем даже про упомянутый Sanic, про Litestar уже молчу.
А с unitest всё не так, как и с threading, им не очень удобно пользоваться, обычно проще concurrent.
Unittest пока имеет очень существенное преимущество перед pytest. Скорость выполнения тестов. На удобство становится пофиг, когда на precommit висит test all, и 1200 тестов. ..в качестве примера возьмем Shoop. Мы его на новую django переезжали, можно найти мой issue об этом. 1200 тестов в 4 потока на pytest 22 минуты. На unittest - около 7.
То что FastAPI знают больше Sanic, не объясняет выбор, поскольку непонятен сам выбор "малоизвестности". Если звезды не катят, тогда что? Я признаю, что Marcelo Trylesinski вкладывается на 100% в маркетинг FastAPI. Но FastAPI это просто wrapper к Starlette. Тогда почему не просто Starlette.
потому что, зачем нам писать свою обертку для Starlette, когда уже есть FastAPI
Все что делает FastAPI - это прикручивает валидацию входящих данных через Pydantic. У Marcelo есть хороший доклад на PyConIT 2023 о том, что именно делает FastAPI.
Если мне не нужна валидация, поскольку я пишу endpoints для второй части приложения с CQRS-архитектурой, то выбор FastAPI выглядит очень спорно, я писал на хабре про низкую скорость работы FastAPI на выдачу данных.
Что я хочу сказать - выбор технологии должен быть согласован с задачей. FastAPI из коробки решает малую часть задач, как и Sanic, LiteStar ... Предлагать FastAPI, как альтернативу Django, это, на мой взгляд, более чем недальновидно, поскольку Django из коробки без дополнительных батареек решает намного больший спектр задач и довольно эффективно, чем FastAPI даже с батарейками.
Для пруфов - реализация мультиязычности, реализация GEO, классы представлений. Напрмер для работы с классами представлений в FastAPI - либо ставить FastAP utils, либо написать свой. А в таком случае зачем мне враппер враппера?
@asedoy Предлагаю закончить этот holy-war тут. Мне кажется, что лучше написать статью про свое Альтернативное видение стека для питониста‑джуна 2024, чем спорить в комментах.
не нужно вечно приписывать обучение FastAPI, складывается такое ощущение, что кроме него Вы ничего не знаете)
на Django пишутся большие сервисы, в то время как FastAPI подойдет, если нужно быстро сотворить небольшой рабочий бекенд
если новичок поймет все тонкости и фичи Django и научиться его совмещать с другими технологиями - выучить Ваш любимый FastAPI для него будет не проблема
новичку нужно давать не то, что Вам нравится, а то, где ему будет легче учить и есть большое комьюнити для этого, а тут FastAPI с Django даже рядом не стоит
мыслите очень как Вы говорите "однобоко", хотите дать джуну лишь бы что, но не думаете насколько ему будет быстро и легко взять предложенный стек
в этом и заключается суть статьи: дать быстрый и универсальный стек для старта, после которого можно переучиться хоть на что, но суть в том, что комментатор этого не понимает и хочет навесить новичку миллиард технологий от которых он впоследствии посыпется
Статья из бекэнда плавно перетекла в фулстек. Но это ее даже украсило. Спасибо очень четко разъяснили, что к чему. Пишите ещё, читать Вас очень интересно и познавательно!
Что стоит добавить до мидлла?
не могу дать конкретный и точный ответ, так как на мидла уже обычно стек разветвляется больше чем у джунов
но могу сказать пару моментов, на которые стоит обратить внимание:
по-любому нужно понять и иметь опыт в веб-сокетах
добавить к Celery и Redis еще знания по RabbitMQ/Kafka
потрогать еще различные БД по типу: MySQL, MongoDB или что-то в этом духе
обязательно поработать с облачными хранилищами AWS, Google Cloud и тому подобных
нужно понять принципы CI/CD
конечно обязательно знать на хорошем уровне принципы REST, HTTP, HTPPS и т д
можно еще и Nginx попробовать, хотя даже лучше и попробовать)
ну и конечно было бы неплохо знать два фреймворка для бека, один очень хорошо, а второй хотя бы на базовом уровне, можно взять Django + FastAPI
но опять-таки, все это может меняться в зависимости от стека компании, но такой список само часто встречаемый
Спасибо автору за статью. Мне, как новичку, достаточно сложно разобраться со стартовым стеком и, соответственно, с первоначальными приоритетами, а здесь коротко и по существу. Добавила себе в ДК пару пунктов)
Лучший стек для питониста-джуна 2024 (2 часть)