Ты ещё про GIL вспомни…

запуск завтра считается? 😁

Одно из немногих что с интересом посмотрел до конца за последнее время: DHH рассказывает про новые фичи рельсов, первое видео у него на канале за последние 2 года

https://youtu.be/PtxZvFnL2i0

Если конкретный выпуск, то абсолютно да!)

Спасибо!

Стесняюсь спросить: это Гвидо Ван Россум рубей?)

Рельсов. Руби (сам язык) другой чел придумал

Из последнего что правда за душу взяло: https://youtu.be/6avJHaC3C2U

Ситуация:
- маленькая команда
- много нейронок
- часто пробуем новые подходы, ситуация когда за день рождается пара новых прототипов вполне типична
- openapi принят как стандарт, сервис без сваггера сделанным не считается

Проблемы:
я пришел когда джанга была уже под запретом(отказались из-за слишком большого количества рутинных действий), один сервис на sanic, все остальное на самописной обертке над aiohttp(по идеологии оч напоминала fastapi). Самописный недофреймворк был сырой и с ним было много гемора(примерно как с drf если в доки не смотреть), документации не было, разработчик велосипеда уволился. В каждом сервисе приходилось руками валидировать половину полей, сроки были сжатые так что регулярные рантайм ошибки из-за косяков в данных стали печальной реальностью. За день можно было что-то новое сделать, но только с нудной копипастой похожего сервиса и переименовыванием всего где имя проекта встречается, процесс конечно медитативный но выгореть легко.


Сейчас:
Переехали на fastapi, все описания моделей данных стали делать через pydantic, создание репозитория теперь начинается с запуска cookiecutter. В итоге все проблемы с кривыми данными всплывают сразу на этапе разработки, за счет отсутсвия типичного для джанги большого количества бойлерплейтинга скорость разработки куда выше чем была бы с джангой. Новый микросервис теперь вполне реально за пару часов сделать с нуля и запустить на стейдж(были ситуации когда через сутки после начала сервис уже в проде работал), очень выручает тайпхинтинг. Сейчас смотрим в сторону централизованных schema registry, Gateway API(замена стокового объекта ингресса в кубе), и подумываем backstage развернуть. В планах еще раза в 1.5 ускориться)

GIL и в fastapi стрелять будет

Просто вам были нужны микросервисы, а вы их пытались сделать на Django. Из этого не следует, что Django плохая.

Микросервисы можно делать на базе gRPC, будет в итоге ещё удобнее, возможно

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

Мода на монолиты возвращается вроде

Для микросервисов удобны шины для асинхронной коммуникации (что не про скорость разработки точно) и gRPC. С OpenAPI latency будет выше. Это может не быть важно, впрочем.

На фоне gRPC OpenAPI выглядит как legacy IMHO, а некоторые облачные провайдеры (Google, на тебя смотрю) до сих пор не осилили переезд на 3 версию OpenAPI

а с фронта ты тоже по gRPC ходить будешь?

С фронта GraphQL

#fomo

latency у нас особо роли не играет т.к. сами нейронки не особо шустрые и с этим ничего не сделать

IMHO публичные апи должны иметь OpenAPI спеку, gRPC и GraphQL только как дополнительный вариант