Comments 12
Мне кажется это писала нейросеть... Но промпт был очень креативный.
Да ладно вам мужики, че минусуете, даже если и ии писала, статья то забористая получилась
Да, тут не любят нейросети, как я заметил.
Статья прикольная, но пока не погрузился еще. Заманчивая либа, обязательно попробую
Сленг, конечно, интересный... Но по сути библиотеки как-то никаких понятных примеров.
Ps на работе у нас есть авто генерация ts api и интерфейсов dto, на основе тех, что используются в эндпоинтах. Как я понял либо из статьи делает что-то похожее
Чет какая-то стремная нетестируемая шляпа получилась, хотя подано с пафосом.
Лажа изо всех щелей. Как в коде, так и в подходе. Например:
В первом месте:
Zero-config TypeScript & Python client generator for Django REST Framework
Python 3.9+
Django 3.2+
Во втором:
Prerequisites
- Python 3.8+
- Django 4.0+
В третьем:
Requirements
Python 3.9+
Django 4.0+
В четвертом:
Environment:
- Python: 3.11.0
- Django: 4.2.0
В пятом
python = ">=3.10"
django = "^5.2.4"
Ну вы как-нибудь определитесь что ли: на 50 .py файлов пять раз сменили версию python или Django. И это я только про попытку понять в каких условиях это работает.
Многое в коде завязано на парсинг pyproject.toml, которого в сотне в недавних моих проектов уже нет, по причине ненужности или устаревания. В итоге - только по этому признаку подойдет лишь ограниченному набору проектов.
Ну и если идти дальше по каждой идее в репозитории - либо лютая велосипедина, поскольку уже есть в самой Django, либо овер-инжиниринг простейшей фичи.. которая скорее всего давно есть в Django.
@markolofsen - в любом случае спасибо, прикольно было посмотреть. Код бампинга версии стырю и впихну себе на предкоммит. Это понравилось, у меня сделано кривее.
Cпасибо за разбор. Ты прав в одном - несогласованность версий есть. Это не production-ready релиз, и некоторые части действительно требуют приведения к одному формату. Мы это знаем и уже правим.
Что касается остального - тут, видимо, просто разный уровень ожиданий и понимания задачи. Revolution не претендует на замену Django, DRF или какого-то там OpenAPI tooling. Он решает конкретную задачу: унифицированная и типизированная генерация клиентского кода из зон API в монорепо. Это не про "сделать то же самое, что и Django", а про то, чтобы убрать боль там, где Django сам по себе ничего не предлагает.
Зоны, декларативная настройка, pydantic-конфигурация, автоматическое подключение схем, генерация клиентов с учётом версий - ни одна из этих штук в Django или DRF в чистом виде не реализована. Если ты видишь тут "велосипеды", возможно, ты просто не сталкивался с такими требованиями в реальных проектах, где фронт, бэкенд и CI живут в одной связке.
Что касается pyproject.toml - это источник метаданных, не обязателен, но удобен. Если ты сознательно его не используешь - ок, твой выбор. Но это не делает его "устаревшим". Fallback под другие форматы будет.
Насчёт пафоса - ну, это для стиля. А суть - в коде. Если покопаешься нормально - полезного там чуть больше, чем кажется по диагонали. Но это, конечно, не обязательно.
Просветление через Код: Суть Django Revolution