Вы не утилизуете Django, а создаете свои объекты и классы.
Простите, я не понял сути вопроса :)
Я же буквально создаю подкласс django.views.View, почему я не утилизирую Джангу?
Есть такой концепт “Django-Forms” и “Django-ModelForms”.
Но ведь формы нужны для html страничек. Они потому и называются: формы :)
Формами парсить json или xml - довольно сложно, если вообще возможно. У вас есть какой-то публичный пример, как вы такое делаете? Если есть, можно сделать сериализатор-плагин для DMR. Нам все равно, что и откуда парсить. В том и суть дизайна.
FastApi стиль - вкатить Pydantic для валидации.
Для валидации - мы его не советуем использовать. Валидация должна быть частью бизнес логики. А не частью фреймворка.
Тем кто работает с Django - понять как работает Django Serialization Framework.
Так в том и штука, вы можете его использовать с DMR, еще раз: нам все равно что и откуда парсить. Мы не навязываем никаких подходов. Пишите свой плагин с 4 методами. И все, используете!
Нет, permissions - не часть фреймворка :( Permissions - часть вашей бизнес логики. Она довольно сильно связана с ролевой моделью, владением объектов и прочим. Такое куда удобнее делать в "сервисном" или "usecase" слое. Тащить логику во фреймворк - мы 100% никогда не будем.
Но в целом - проверка доступа останется одной строчкой внутри вашей логики, так что сложностей не будет :)
Я не считаю DRF прямым конкурентом, потому что данным поделием пользоваться просто невозможно. Скорее просто легаси технологией, переход с которой мы автоматизировали и забыли.
Более того, сам по себе encode тоже мертв. Истории с httpx и starlette его добьют.
Откройте документацию по ненавистной DRF, которая утилизирует полностью компоненты Django
зачем мне Pydantic, если мои данные уже описаны в django models?
Ваши данные не описаны в моделях. В моделях описаны ваши модели - структура таблиц в БД :)
Данные, которые мы передаем по АПИ, ортогональны моделям. Да, иногда часть полей и схем совпадает изначально. Но дальше начинается: совпадает, да не совсем, требует дополнительно логической или структурной валидации, какие поля начинают быть зависимы друг от друга, какие работают только на запись, какие-то только на чтение, какие-то поля меняются отдельно от модели, какие-то поля модели меняются отдельно от слоя сериализации, какие-то модели требуют разного представления в разных апишках. А потом появляется версионирование. Суть вы уловили.
Сериализаторы "немного напоминают" модели в самом начале приложения. Потому люди почему-то их ошибочно смешивают. Мы такой ошибки не совершаем. Мы даем вам возможность создавать любые удобные сериализаторы для ваших моделей.
Согласен со всеми пунктами (кроме пожалуй типов в параметрах путей). DI мы переделаем к 3.0 версии. К сожалению, там поменялись ключевые разработчики несколько лет назад. И проект немного подвис. Он мог бы быть прям одним из лучших фреймворков, но пока - скорость развития оставляет желать лучшего :(
Да, вы правы. Можно писать по-другому. Но и от себя я ничего не придумывал. Ссылка на доку, откуда я взял пример - прямо там. На мой взгляд явные разные модели лучше анонимных, где все идет вперемежку: тело, заголовки, пути. Но на вкус и цвет - все оголенные провода разные :)
Спасибо за интересное мнение! У меня пара практических вопросов: как разделить мейкфайл, если вы используете одну прямую зависимость с большим количеством транзитивных зависимостей, в которых сложно разобраться? На основе каких фактов вы вынесли вердикт, что ДСЛ для проекта "неподдерживаемый, незадокументированный и непредсказуемый"? Всегда интересно услышать критику!
Так и есть!
Валидация != Сериализация. Пример: валидация = проверка уникальности email в БД. Такое только в бизнес логике.
А фиг его знает, как оно правильно на русский переводится. Кто-то говорит "разработчик ядра", но я как-то не фанат такого перевода :(
Простите, я не понял сути вопроса :)
Я же буквально создаю подкласс
django.views.View, почему я не утилизирую Джангу?Но ведь формы нужны для html страничек. Они потому и называются: формы :)
Формами парсить json или xml - довольно сложно, если вообще возможно. У вас есть какой-то публичный пример, как вы такое делаете? Если есть, можно сделать сериализатор-плагин для DMR. Нам все равно, что и откуда парсить. В том и суть дизайна.
Для валидации - мы его не советуем использовать. Валидация должна быть частью бизнес логики. А не частью фреймворка.
Так в том и штука, вы можете его использовать с DMR, еще раз: нам все равно что и откуда парсить. Мы не навязываем никаких подходов. Пишите свой плагин с 4 методами. И все, используете!
Выглядит прикольно! Спасибо, что поделились
Нет, permissions - не часть фреймворка :( Permissions - часть вашей бизнес логики. Она довольно сильно связана с ролевой моделью, владением объектов и прочим. Такое куда удобнее делать в "сервисном" или "usecase" слое. Тащить логику во фреймворк - мы 100% никогда не будем.
Но в целом - проверка доступа останется одной строчкой внутри вашей логики, так что сложностей не будет :)
Я же сам пригласил всех в комментарии обсуждать, какой фреймворк самый лучший :) Мы все тут, чтобы вдоволь понабрасывать!
Я не считаю DRF прямым конкурентом, потому что данным поделием пользоваться просто невозможно. Скорее просто легаси технологией, переход с которой мы автоматизировали и забыли.
Более того, сам по себе
encodeтоже мертв. Истории сhttpxиstarletteего добьют.В том-то и проблема, что нет :(
DRF для всего требует свой отдельный АПИ; простой пример: https://github.com/carltongibson/django-filter?tab=readme-ov-file#usage-with-django-rest-framework Вон даже отдельная страничка доки есть. А нам такое не нужно, мы можем просто использовать
django-filtersнапрямую.Ваши данные не описаны в моделях. В моделях описаны ваши модели - структура таблиц в БД :)
Данные, которые мы передаем по АПИ, ортогональны моделям. Да, иногда часть полей и схем совпадает изначально. Но дальше начинается: совпадает, да не совсем, требует дополнительно логической или структурной валидации, какие поля начинают быть зависимы друг от друга, какие работают только на запись, какие-то только на чтение, какие-то поля меняются отдельно от модели, какие-то поля модели меняются отдельно от слоя сериализации, какие-то модели требуют разного представления в разных апишках. А потом появляется версионирование. Суть вы уловили.
Сериализаторы "немного напоминают" модели в самом начале приложения. Потому люди почему-то их ошибочно смешивают. Мы такой ошибки не совершаем. Мы даем вам возможность создавать любые удобные сериализаторы для ваших моделей.
Хотите сделать явный мапинг из модели в сериализатор для примера hello world приложения? Пожалуйста: https://django-modern-rest.readthedocs.io/en/latest/pages/integrations.html Такая фича тоже есть. Просто она не является основной приложения, а скорее редким кейсом.
Нет, я как раз поностью сохранил Django подход. https://django-modern-rest.readthedocs.io/en/latest/pages/components/files.html Буквально внутри используется стандартный
request.FILES. Все дефолтные настройки загрузки файлов работают.Аналогично с парсингом кук, сама логика на 1 строку: просто возвращаем
request.COOKIEShttps://github.com/wemake-services/django-modern-rest/blob/b31ade395e4ac6491728dd49e6b5510d290dfb3a/dmr/components.py#L727
По скорости, гибкости, корректности, качеству спеки, продвинутости инструментов тестирования.
Согласен со всеми пунктами (кроме пожалуй типов в параметрах путей). DI мы переделаем к 3.0 версии. К сожалению, там поменялись ключевые разработчики несколько лет назад. И проект немного подвис. Он мог бы быть прям одним из лучших фреймворков, но пока - скорость развития оставляет желать лучшего :(
Да, вы правы. Можно писать по-другому. Но и от себя я ничего не придумывал. Ссылка на доку, откуда я взял пример - прямо там. На мой взгляд явные разные модели лучше анонимных, где все идет вперемежку: тело, заголовки, пути. Но на вкус и цвет - все оголенные провода разные :)
Какой хороший троллинг, посмеялся :)
Кстати, комрад @fenrir1121 - сделал очень много крутого для нашей доки! Спасибо большое! <3
через CSS можно убирать части объектов. но да, можно скрывать правой кнопкой.
Пока нет, но всегда готовы приехать поддержать, если вы что-то будете там делать :)
<3
Спасибо за интересное мнение! У меня пара практических вопросов: как разделить мейкфайл, если вы используете одну прямую зависимость с большим количеством транзитивных зависимостей, в которых сложно разобраться? На основе каких фактов вы вынесли вердикт, что ДСЛ для проекта "неподдерживаемый, незадокументированный и непредсказуемый"? Всегда интересно услышать критику!
Мы точно про один проект говорим? Последний релиз 22.07.2025: https://github.com/easyp-tech/easyp/releases/tag/v0.7.15 Я проглядел доку, вроде бы все основные моменты там есть. Чего вам не хватило?
Шикарная статья, спасибо!
Нет, у меня нет статусбара :)
Но для тех, кто пользует статусбар - прикольная идея! Спасибо!
я не согласен, но у всех у нас есть право пользоваться тем, чем нам нравится, как нам нравится :)