Какой то бек странный. Наоборот же лучшая практика разделять данные

Я о том и говорю, ему лень разбить жирный запрос, а я должен на клиенте весь шлак хранить, который не нужен. Странное дело…

Выглядит так что в проекте нет менеджера проекта.

Так он сам себе в ногу стреляет. На беке объединяя данные

Формально он есть, но в целом да, можно сказать нет

Так позови сюда бекендера. Может его точка зрения прольёт правду)

Момент

Но кстати, разве через графкл нельзя запросить только нужную тебе часть данных?

Я позвал бекэнд

Все можно, он для этого и придуман:))

status 417

Добрый день всем.

🖖

Точка зрения заключается в том что при отправке запроса в граф действительно ходит не маленькая модель данных, но ситуация осложнена не тем что бы на графе экономить на времени на запрос, а уменьшить количество запросов к базе. Так же используется репозиторий. Где непосредственно и происходит сам запрос. Роман не уточнил некоторые вещи: 1.(на мой взгляд самая важная)  это легаси проект. И DB не 1 а 21. 2. Один запрос должен собирать информацию с 4 баз и с 16 таблиц. При этом если мы условно разделим всю модель на 3 части и как Роман говорит будем делать 3 запроса. То при каждом из этих запросов мы будем обращаться так же к 4м базам и 16 таблицам.

Можно. Он так и делает. Но время на исполнение запроса непосредственно к базе остаётся неизменным

Ну так это все равно не меняет того, что правильнее получать части данных. Когда нибудь настанет пора, разного уровня кеша, даталоадеры и пагинации по частичным данным

Вообще даже немного смешно.

Решать это все в рамках объединенного запроса - убийство

Уже настало

Но Роман не понял когда я ему это  сегодня раза 4 сказал. На данный момент даталодеры и внедряются