y
я не могу так вернуть реф с данными и @client поле?
Size: a a a
2021 April 06
y
мне элементарную штуку нужно сделать. Тупо проверять первый элемент в массиве входящих данных и менять стейт в зависимости от данных внутри. Потом на основе этого стейта делать fetchMore. Я уже неделю с этим мучаюсь.
𝘂
В теории наверное можно прослойку кеширования запросов поставить перед передачей запроса в сам apollo-server, скажем на уровне express/другого веб сервера
D
Блин, сорри, я немного заработался и подумал, что изначально ты ответил нетна мой ответ тебе, а на мой вопрос про кэши
Вот скинули, возможно Вы это и искали
AD
Неа, это не то. Это полное кэширование всех запросов по умолчанию без возможности изменять параметры кэширования для отдельных запросов при использовании code-first
AD
Я уже все исходники неста с ног до головы изучил, изучил механизм работы apollo-server плагинов, и написал свое кэширование)
y
а насколько вообще норм использовать cache.writeFragment прям в typePolicies merge? не одного такого примера не нашёл, кто-нибудь так делает вообще?
n
добрый день, читал про graphql , не понял вообще выгоды в сравнении с обычными json пейлоадами и их конвертов в объект через тот же gson.
а минусы - прозрачного конверта в объекты из json (и работы с полями) нет или не нашел и писанины схем (текста) в коде, когда для этого есть доки.
а минусы - прозрачного конверта в объекты из json (и работы с полями) нет или не нашел и писанины схем (текста) в коде, когда для этого есть доки.
n
кратко - как замена json пейлоадов это, на мой взгляд "шило на мыло", ибо добавляется писанина в код софта, что может уйти спокойно в апи доки + парсинг через жопу (судя по докам в инете в сравнении с gson-json)
ОЛ
Две ключевые фичи - строгая схема, легкость в получении только нужных данных. Вы со стороны бека можете понимать какие данные хочет клиент, относительно схемы и запрошенного.
n
так и в случае с gson схема строгая, описана в полях объекта.
что до получать выборочные данные - можно отправлять что нужно, а клиент сам разберется. == хотя это, согласен удобно.
получается лишь выборочные данные его основная фишка?
что до получать выборочные данные - можно отправлять что нужно, а клиент сам разберется. == хотя это, согласен удобно.
получается лишь выборочные данные его основная фишка?
n
если раньше добавляли "noimages=true", то теперь можно лишь схему без картинок, и клиент получит только товары?
ОЛ
Ну gson это просто строгий сериализатор, graphql, нечто больше чем просто json на выходе.
ОЛ
Можно и с помощью скаляра картинку отправить
n
для клиента, понятно. Выборочные данные. А для бека? лишь новый метод парсинга + бОльше текста?
ОЛ
Так и с бека будет также выборочные данные. Так как клиент сервер существуют совместно, удобно кешировать и инвалидировать данные.
n
смотрю доки + статьи с гугла.
просто заливка схем и запросов.
именно чтобы можно было выборочно получить данные, как гвоздь в rest api.
но в плане endpoint и кинуть json туда (забыли про rest) лишь выборочные данные для клиента и все.
просто заливка схем и запросов.
именно чтобы можно было выборочно получить данные, как гвоздь в rest api.
но в плане endpoint и кинуть json туда (забыли про rest) лишь выборочные данные для клиента и все.
n
цена выборочных данных - новый фреймворк, больше писанины (в том числе и текстовые схемы, везде их описывают).
плюсы - замена rest, но повторюсь, как замена json пейлоадов по старым тропинкан для меня это сомнительно
плюсы - замена rest, но повторюсь, как замена json пейлоадов по старым тропинкан для меня это сомнительно
n
убийца rest - тут согласен