Да, абсолютно все будет помечено @client но какая разница :D

Лучше чем тот мой костыль с ApolloLinkSchema :) Который тащит гораздо менее легковестный GQL рантайм на клиент :)

а прокси не сервер ? )
если rest-api сделано на swagger\openapi то есть готовые решения, на сервере можно и кеш самих rest путей сделать и авторизацию сделать.

link-client может и удобен, прост для начала, если просто попробовать, но обвязывать даже три типа я бы не рискнул

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

Если все оборачивать в свои fetch\axios запросы
- на каждую мутацию нужно будет делать самом запрос в кеш, менять ее
- помнить о том как он ключи кеша обьектов\фрагментов делает
- плакать когда обещанной магии не выходит.

яб запутался после третьего типа с локальными резолверами

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

а вот это в разы удобней link-rest будет,
Спасибо за линк

в общем пока нужно доку просмотреть всю, может что то в понимании прибавится

Привет всем, не подскажет кто как сделать схему, если я не знаю будет поле доступно или нет?

Допустим у меня есть поле 1, но я не знаю будет ли существовать поле 2 или поле 3. Как в таком случае делать схему?

не знаю как правильно, но у нас сервак возвращает null в поле, даже если у него есть вложенные поля. и дальше идет проверка на клиенте

У меня идет допустим:
stage_1: {},
stage_2: {}

Что если я не буду знать сколько ступеней может быть? Если бы я написал их пять к примеру, то при случае когда меньше там будет null, а как предусмотреть какое угодно коилчество?

Используй массив объектов

Точно, благодарю

Ой, не мешали бы вы локальный стейт (@client) с серверным кешом. Жуткая идея, череватая в будущем солидным рефакторингом.

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

Резюме: используйте два стора. Аполло/Релей для кеша серверных данных. И там какой-нить Redux, EventEmitter, React.State/Hook – для клиентского состояния.

Вобщем аккуратно с этим @client, наверное есть вещи где он будет хорош, но в целом по больнице его лучше не использовать.

Паша, ну как бы ApolloLinkSchema по сути тот же клиентский кэш.

Я и не говорю, что надо исопльзовать Аполло для UI стейта

Но как клиентский графкюель сервер пойдет лучше, чем Apollo Link Schema которая тяжелая.

Например вам надо облагородить прилетевшие данные с сервера - то @client будет хорошо.

Но не храните клиентское состояние в кеше аполловском.

Да, но если у вас там только данные и больше ничего, то ок :) Т.е. GraphQL сервер на клиенте, то ок, ибо лучше чем ApolloLinkSchema костыль.
Но для глобального UI стейта юзайте редакс 7.1 версии (хуки завезли сегодня), или обычный, прекрасный, нативный React Context API :)

А ну и Mobx c MST.