Наш разработчик советует Python для API — это безопасный выбор или просто привычка?

Если на стороне Python использовать современные асинхронные конструкции, вы не столкнётесь с узким местом при I/O-ориентированной передаче данных. Даже если трафик B2B-платформы вырастет до десятков тысяч запросов в минуту, при правильных индексах базы данных основная нагрузка соберётся не в языке, а в базе. Ваши опасения напрасны.

В нашем собственном сервисе логистики для e-commerce мы управляем 1,5 миллионами API-вызовов в день с помощью микросервисов на Python. Наши месячные расходы на облачные серверы не превышают 65 долларов. Не ведитесь на миф о медлительности языка, реальные затраты идут от плохой архитектуры.

Выбор разработчика, конечно, важен, но что вы будете делать, если завтра этот разработчик уйдёт из команды? Пул Python-специалистов широк, но не каждый умеет чисто писать асинхронную архитектуру. Обязательно убедитесь, что проект построен послойно и проводится стандартная проверка типов, иначе передача дел превратится в настоящий кошмар.

Обязательно внесите в договор 3 технических требования: 1) Документирование всех эндпоинтов по стандартной схеме OpenAPI. 2) Полное и строгое использование тайп-хинтов. 3) Покрытие юнит-тестами основных сценариев минимум на 70 процентов. Если эти три условия соблюдены, никаких скрытых рисков Python за собой не оставит.

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

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

Задайте разработчику один простой вопрос: «Какую архитектуру и асинхронный фреймворк ты будешь использовать и как настроишь пул соединений с базой данных?» Если он ответит без запинки и с четкими техническими аргументами, можете смело с ним работать.

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

Расскажу, что было у меня, вдруг пригодится. Все, кто торопится с разработка api, спотыкаются на одном и том же.

Пишу это, чтобы вы не совершили ту же ошибку. Пытаться сделать это в одиночку — самый дорогой путь.

Прежде чем принимать решение, посмотрите, какие данные у вас есть. Надеюсь, это будет полезно.

Я маленький бизнес, расскажу со своей стороны. Люди защищают не процесс, а привычку. Сопротивление идет оттуда.

Удачи.

Очень актуальная тема.

Этот совет подойдет не всем, на мой взгляд. Самое дешевое предложение обычно самое непродуманное.

Надеюсь, это будет полезно.

Обсуждение размылось, давайте структурируем. Если делаете впервые, начните с малого, масштабирование потом.

Если напишете результат здесь, это поможет и другим.

в этом пункте я с вами не согласен и если делаете впервые, начните с маолго масштабирование потом.

коонечно если ваша ситуация отличается, всё меняется.

Расскажу, как это делается на практике. Самое дорогое в унаследованной системе — неизвестные зависимости.

На этом всё, извините, если затянул.

Сведу тему в кучу, так как ответов было несколько разных. Самое дорогое в унаследованной системе — неизвестные зависимости.

Если не зафиксировать это письменно с самого начала потом возникнут споры. Оставлю как заметку, пригодится.

Отличная работа.