Cпасибо за разбор. Ты прав в одном - несогласованность версий есть. Это не production-ready релиз, и некоторые части действительно требуют приведения к одному формату. Мы это знаем и уже правим.
Что касается остального - тут, видимо, просто разный уровень ожиданий и понимания задачи. Revolution не претендует на замену Django, DRF или какого-то там OpenAPI tooling. Он решает конкретную задачу: унифицированная и типизированная генерация клиентского кода из зон API в монорепо. Это не про "сделать то же самое, что и Django", а про то, чтобы убрать боль там, где Django сам по себе ничего не предлагает.
Зоны, декларативная настройка, pydantic-конфигурация, автоматическое подключение схем, генерация клиентов с учётом версий - ни одна из этих штук в Django или DRF в чистом виде не реализована. Если ты видишь тут "велосипеды", возможно, ты просто не сталкивался с такими требованиями в реальных проектах, где фронт, бэкенд и CI живут в одной связке.
Что касается pyproject.toml - это источник метаданных, не обязателен, но удобен. Если ты сознательно его не используешь - ок, твой выбор. Но это не делает его "устаревшим". Fallback под другие форматы будет.
Насчёт пафоса - ну, это для стиля. А суть - в коде. Если покопаешься нормально - полезного там чуть больше, чем кажется по диагонали. Но это, конечно, не обязательно.
Cпасибо за разбор. Ты прав в одном - несогласованность версий есть. Это не production-ready релиз, и некоторые части действительно требуют приведения к одному формату. Мы это знаем и уже правим.
Что касается остального - тут, видимо, просто разный уровень ожиданий и понимания задачи. Revolution не претендует на замену Django, DRF или какого-то там OpenAPI tooling. Он решает конкретную задачу: унифицированная и типизированная генерация клиентского кода из зон API в монорепо. Это не про "сделать то же самое, что и Django", а про то, чтобы убрать боль там, где Django сам по себе ничего не предлагает.
Зоны, декларативная настройка, pydantic-конфигурация, автоматическое подключение схем, генерация клиентов с учётом версий - ни одна из этих штук в Django или DRF в чистом виде не реализована. Если ты видишь тут "велосипеды", возможно, ты просто не сталкивался с такими требованиями в реальных проектах, где фронт, бэкенд и CI живут в одной связке.
Что касается pyproject.toml - это источник метаданных, не обязателен, но удобен. Если ты сознательно его не используешь - ок, твой выбор. Но это не делает его "устаревшим". Fallback под другие форматы будет.
Насчёт пафоса - ну, это для стиля. А суть - в коде. Если покопаешься нормально - полезного там чуть больше, чем кажется по диагонали. Но это, конечно, не обязательно.
Не любят, но активно пользуются судя по всему. Двойные так сказать стандарты.
удалено
А что у вас за решение используется? Самописаное?
ясно, великие минусователи))
а что по теме статьи?)