Я понял, что это очень сложно объяснить без кода 🙂

Мы данные получаем с сервера и ничего с ними не делаем. Тупо отправляем запрос на получение например 15 статей. Они уходят в кеш. Потом мы их достаём оттуда через филд резолвер в компоненте статьи.

🤣  все мы практики)

если в атоме, то зачем резолвер для статьи? он же для того что бы изменить данные либо добавить поле например

в компоненте с атома взять данные и смержить со статьей. или я что-то не догоняю?)

Задача у нас не тривиальная:
1. Получаем все айди
2. Делаем атом с адишниками и нужными полями (checked, deleted, etc)
3. По мере скролла запрашиваем с сервера данные  по 15 статей за раз. Т.е. запросы выглядят так - getByIds(ids)
4. Данные просто уходят в кеш
5. Берём атом тот самый атом с айдишниками и полями и рендерим список статей
6. Каждый компонент статьи запрашивает из кеша остальные данные, которые мы получили в пункте 4 через филд резолвер или можно просто через client.readFragment

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

понял, спасибо за разьяснение. у нас практически похожая ситуация) только лист пагинация, есть bulkActions и Select All. тоже есть запрос отдельный за список айди)

только все делаем без филд резолверов. У меня в свое время была трабла с инфити списком, помню дня 2-3 сидел игрался с merge и read, но в каждой имплементации был косяк, в итоге все сделал супер просто без переопределения merge и read

куда копать, чтобы узнать, что такое атом, резолвер и тд?

Точно также и я сначала пытался это сделать 🙂

Атом это из библиотеки Jotai(вообще не имеет отношение к GraphQL).
Резолвер - https://www.apollographql.com/docs/react/local-state/managing-state-with-field-policies/

благодарю

Вот репка с примером из видео

https://github.com/nodkz/example-apollo3

Отличный кейс.
У нас ребята похожим образом обходили проблему через readFragment

Да у нас квери и фрагменты  привязаны строго к компонентам. Это именно то место, гле я ребятам говорю, что copy-paste это хорошо.

Т.е. при редактировании требований к данным к компоненте, мы уверены, что ничего по соседству не сломаем. И не начнем тянуть где не надо лишние данные, когда добавим новое поле для доугой компоненты.

ну там тоже не до конца понятно насколько быстро это все работает, я читал issues, не факт что там все так гладко. вообще что мне написал Павел по этому поводу:
"Все зависит от того насколько сложный у вас бэк. Если моделей не много, то берите graphql-tools. graphql-compose для больших и сложных схем, где нужна генерация типов."

Всем привет. Нужно мнение со стороны. Делаем проект с нуля. Фронтами хотим использовать Apollo. Бэкендеры наши не хотят использовать apollo server и твердять, что у каждого сервиса будет свой уникальный граф, что это уязвимость иметь единый gateway на apollo server. В концепт уникальности графов слабо вериттся, так как между сервисами 100% будут взаимосвязанные данные.

Поправьте если я не прав. Строить такой graph и и спользовать его на клиенте будет фиаско

Выглядить так, что хоять построить restGraphQL

ну GraphQL и без Apolo можно построить, например https://httptoolkit.tech/blog/simple-graphql-server-without-apollo/
только кэшинг будет другой какой-то, SWR или еще что-то

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