про "неоптимизированные вьюхи" можно подробнее?

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

а пример есть? я не понимаю про: "либо же создаешь пустой сериализатор и во въюхе вкладываешь"

Ну как форму создаешь и после чего используешь его в своих целях независимо от модели

Чем-то смахнуло на интерфейс

А есть примеры?

в доках же есть
https://www.django-rest-framework.org/api-guide/serializers/#declaring-serializers

Там и json field можешь использовать, что может облегчить работу если что-то добавить нужно независимо модели

так не понятно что может делать вьюхи "неоптимизированными". Что может сильно влиять на производительность?

1. Большое кол-во запросов во въюхе в базу данных
2. Логика загрузки данных в ендпоинтах, то есть если нужно залить данные в базу, то лучше использовать какие то отдельные загрузчики или импортеры с celery к примеру

Ну это при условии что база у нас большая

Установите django-silk, поставьте процент отслеживания запросов 1-5%

мне просто стало интересно, о чем говорит парень и попросил раскрыть мысл 😄

мне показалось что я вообще не в тему сейчас сказал про это

меня интересовал ответ в контексте первого твоего сообщения про сериализаторы, а не в общем смысле)

Я так и не понял, что ты там имел ввиду про не оптимальность использования)
Но ладно. Спасибо за дискусию

Он скорее всего, о том как и откуда брать данные, из скольких баз, сущностей, которые ты потом сериализируешь в один ответ
Мне так кажется

вот сейчас думаю: наверно про кол-во запросов, которое делает сериализатор чтоб достать данные для всех FK & m2m полей, чтоб сохранить 🤔
*если их много

А тут не сериализатор запросы готовит, а ты, и пропускаешь их через сериализатор, ну я так его слова понял
Хотя, блин, бред же есть

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

а сериализатору нельзя скормить свой queryset с уже подгружеными данными (prefetch|select_related)?
Я просто маловато с drf работал)

вот тут не скажу, чтобы не слукавить, не делал так