Какие уникальные фичи есть в django-modern-rest?
Иногда, когда я добавляю какие-то фичи в мой https://github.com/wemake-services/django-modern-rest (можно ставить ⭐), то я думаю про себя: почему таких фичей больше нет нигде?
Давайте сегодня посмотрим на них. А вы мне расскажите свое мнение в комментах.
Семантическая схема
Допустим, вы навесили на какой-то свой endpoint auth:
class UserController(Controller[MsgspecSerializer]):
@modify(auth=[JWTAsyncAuth()])
async def get(self) -> User: ...
В OpenAPI автоматически появятся все коды ошибок, которые могут случиться в auth (401).
Ничего не надо допом писать. И так происходит со всеми частями фреймворка: добавил throttling=[SyncThrottle(1, Rate.minute)]? Теперь у тебя в ответах автоматом 429. Если нужно, можно отключить любые семантические статусы.
Не должно ли такое быть дефолтом везде?
Умные типы ошибок
Не уходя далеко: как кастомизировать формат ошибки, например, в FastAPI? Через боль. Как поменять в спеке формат? Руками.
В DMR мы просто добавили везде error_model как параметр. Можно заменять любые ошибки, все автоматом сконвертится и покажет правильную схему. Зачем? Хочешь Problem Details - используешь. Хочешь свой формат - реализуешь. Можно даже content negotiation на ошибки навесить.
Почему никто о таком не думает в других фреймворках?
Нормальный throttling
Фича, которая принесла мне больше всех боли. Я прочитал throttling реализации во всех фреймворках. В Litestar даже фиксы присылал.
1. Почти нигде из коробки нет поддержки разных алгоритмов, бекендов, иногда даже cache-keys. Очень жаль, есть только обычный counter с бекендом в памяти
2. Нигде (пришлите в комменты контр-пример) нет разделения на throttling до auth и после. Почему такое вообще важно? Чтобы не заддосить auth. И чтобы иметь возможность выдавать per-user правила. Нужны и важны оба варианта
3. Кастомизация заголовков ответа? Ха!
Что? Почему?
Простое переиспользование кода
Когда я смотрю на АПИ разных DRF проектов или FastAPI, мне становится больно. FastAPI строит все на view функциях, которые нельзя нормально кастомизировать. А DRF строит все на импортах строк внутри настроек. А как на счет классов и наследования?
У нас подобное сделано как абстрактные generic классы. Например: получить JWT. Можно выбрать любой сериализатор, можно выбрать любые модели для запроса и ответа:
class RequestPayload(pydantic.BaseModel):
username: str
password: str
class ResponsePayload(pydantic.BaseModel):
access: str
refresh: str
class ObtainAccessAndRefreshSyncController(
ObtainTokensSyncController[
PydanticSerializer,
RequestPayload,
ResponsePayload,
],
): ... # надо еще переопределить 2 метода
Все типизировано, документировано, очевидно.
Как вы думаете, почему так больше никто не делает?
Внешние вьюхи
Интегрировать один фреймворк в другой - крайне сложно. Вот мы недавно даже стрим проводили, потому что не могли использовать dj-rest-auth из DRF. Так быть не должно.
Теперь в DMR можно использовать любые внешние Django View. Хоть DRF, хоть django-ninja, хоть ванильные вьюхи. И отображать любой внешний OpenAPI. Вот настолько просто:
raw_schema = read_openapi_yaml('openapi.yml')
router = Router(
urls=[
external_path(
'number/', number, name='number',
openapi=load_schema(raw_schema['paths']['/api/number'], PathItem),
),
],
)
Почему другие фреймворки не стараются вписать существующие решения?
Одной строкой
- Больше подобного у меня в тегеграм канале "Находки в опенсорсе": https://t.me/opensource_findings
- У нас есть еще куча других крутых фичей! Заглядывайте в наш чатик по DMR
- Релизнули django-stubs@6.1 с поддержкой django@6.1
- Сделали папку с крутыми каналами ребят из нашего Python сообщества. Смело можно закидывать коллегам как базовую папку "на кого подписаться в тг по питону". Внутри все мои друзья и коллеги, советую!
