спасибо всем

Мне кажется самое время смотреть в сторону фастапи)

Я по прежнему использую model bakery, хех, меня устраивает :)
Там пару вещей надо с генераторами починить в рецептах, но у меня руки не доходят.
К сожалению так и не довелось попробовать factory_boy, ничего не скажу как они там нынче и чем лучше-хуже

Я уже глянул :), но бегло
Мне показалось, что там будут те же проблемы
Думаешь CRUD REST на fastapi websockets будет piece of cake?
(без сарказма)

Пока кажется что да) а какие проблемы? Там то оборачевать не нужно все асинхронное из коробки

Не, ну вопрос в том, что пока там чатики всякие пилишь - это одна история, все легко
но у тебя есть джанго приложение, для упрощения представим просто API эндпоинт и ты хочешь его сделать async
чтобы 2 юзера могли редактировать один объект в риалтайм и это красиво работало ( т.е. если юзер 1 обновил данные, юзер должен получить их без дополнительного запроса)

и тут проблемой становится почти все, включая сам протокол WS
Предположим ты натянул http протокол over WS - можно такое намудрить
Но как бы дальше?

Как устроить маршрутизацию?
У тебя в DRF сформированы урлы, но в сокетах на каждый урл же не будешь создавать новый канал?

т.е. в самой простой реализации нужна прослойка между API эндпоинтом и WebSocket каналом который будет между сервером и пользователем, которая будет транслировать это все туда-сюда

@amureki, а ты не подскажешь?
Возможен ли псевдо REST over django channels/web sockets  в принципе и в частности в рамках джанго?

Как связаны апи эндпоинты и сокеты

Они отдельно живут вроде бы

А, перечитал, понял

Мне просто интересно как тогда реализовывают крупные компании shared редактирование
Google sheets/google docs обновляет данные у тебя на странице в риал-тайм, если кто-то их поменял на другом конце
неужели дергают сервер постоянными запросами? (впрочем, это легко проверить)

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

я изначально где-то также и представлял XD

У меня пятница началась, а голова закончилась.
Вообще, тут видимо основной вопрос про conflict resolving когда у тебя двусторонняя синхронизация, нужно смотреть на диффы, modified, ну и в конце концов определить четко, как в худшем случае будет резолвиться конфликт, если не удалось мирным путем решить.
Для инспирации можешь в эти свои сервисы зайти, где ты видишь такую работу и попробовать с двух машин или аккаунтов одновременно редактировать одно и то же место и посмотреть что там в бекграунде происходит (dev tools)

Ну видимо мне нужно серьезный проект попробовать на нем реализовать чтобы ощутить проблемность своей ж, пока то что сделал на фастапи было не сильно сложнее хэллоуворлда)

Я о конфликтах уже думал, но до них еще дойти надо :D
Я пока на старте: есть API на DRF, хочу его обернуть в WebSockets (пока больше абстрактно)
и пока даже не представляю как это сделать :)

* с пометкой - не написав его чуть ли не заново и с кучей головной боли

Factory boy брал. Вполне устраивает

костыль на 10/10, как написать правильно({{ MEDIA_ROOT }} не работает по неизвестным мне причинам

{% get_media_prefix %}?