Сначала я отвечу на ваш второй вопрос:
Что касается второго вопроса, у меня есть приложение, работающее и запрашивающее API с помощью Amplify для аутентификации, но я не уверен, как правильно реализовать кеш. Нужно ли указывать кеш при создании клиента или SDK имеет встроенный кеш? Как мне получить доступ к кешу? Это просто путем запроса клиента, как в этих уроках?
Хорошо. Итак, вот где это становится немного странным - похоже, что AppSync был развернут в то время, когда основные клиентские библиотеки для GraphQL (Apollo, Relay и т. Д.) Подвергались капитальному ремонту, поэтому AWS фактически создала оболочку вокруг клиента Apollo. (вероятно, для стабильных целей API), а затем раскрыли свой собственный способ действий Простое краткое изложение кода выглядит так, как будто у них есть собственный проприетарный и недокументированный способ работы , который включает в себя веб-сокеты, их протоколы аутентификации, хранилище с избыточностью, автономную функциональность, ssr и т. Д. ). Таким образом, если это явно не объяснено здесь или здесь , вы находитесь на неизведанной территории.
К счастью, все, что они предоставили (и многое, многое другое), теперь реализовано в базовом клиенте Apollo документированным способом. Еще более к счастью, похоже, что клиент AppSync перенаправляет большую часть фактических данных, связанных с GraphQL, непосредственно во внутренний кэш Apollo и позволяет передавать параметры конфигурации в cacheOptions, поэтому большую часть конфигурации вы можете выполнить с помощью клиента Apollo. можно сделать с помощью клиента AppSync (подробнее ниже).
К сожалению, вы не можете получить доступ к кешу напрямую с помощью клиента AppSync (они скрыли его, чтобы убедиться, что их публичный API остается стабильным в изменяющейся экосистеме). Однако, если вам действительно нужен больший контроль, большая часть того, что они реализовали в клиенте AppSync, может быть легко реплицирована в вашем собственном экземпляре клиента Apollo, в котором вы бы разблокировали полный контроль (вы можете использовать с открытым исходным кодом Код AppSync в качестве основы). Поскольку интерфейсы и бэкэнды GraphQL отделены друг от друга, нет никаких причин, по которым вы не могли бы использовать свой собственный клиент Apollo для подключения к серверу AppSync (для большого серьезного проекта это то, что я хотел бы сделать, поскольку клиент Apollo гораздо лучше задокументирован и в стадии активного развития).
Достаточно ли уместен кэш, чтобы знать, что объект X, полученный через запросы Y и Z, является одним и тем же объектом и будет обновляться одновременно? Если нет, то есть ли документация о том, как написать обновление, которое будет обновлять объект в списке и одновременно одновременно?
Эта первая часть относится как к клиенту Apollo, так и к клиенту AppSync.
Да! Это одна из замечательных особенностей клиента Apollo - каждый раз, когда вы делаете запрос, он пытается обновить кеш. Кэш-память - это нормализованное хранилище значений ключей, в котором все объекты хранятся на верхнем уровне, причем ключ является комбинацией свойств __typename и id объекта. Клиент Apollo автоматически добавит __typename ко всем вашим запросам (хотя вам нужно будет добавить id к своим запросам вручную - в противном случае он будет использовать только сам путь запроса в качестве ключа [который не очень надежен]) .
документы обеспечивают очень хороший обзор механизма.
Теперь вам, возможно, придется сделать что-то более сложное. Например, если ваша схема GraphQL использует какой-то уникальный идентификатор объекта, отличный от id, вам нужно будет предоставить некоторую функцию для dataIdFromObject, которая сопоставляется с ним.
Кроме того, иногда при выполнении запросов кэшу трудно точно знать, что именно вы запрашиваете, чтобы проверить кэш перед выполнением сетевого запроса. Чтобы устранить эту проблему, они предоставляют механизм перенаправления кэша .
Наконец, и, возможно, самым сложным является то, как работать с обновлением порядка содержимого в разбивке на страницы (например, все, что находится в упорядоченном списке). Для этого вам нужно использовать директиву @ connection . Поскольку это основано на спецификации релейного соединения , я бы рекомендовал сделать это.
Бонус: чтобы увидеть кэш в действии, я бы порекомендовал клиентские инструменты разработки Apollo . Это немного глючит, но, по крайней мере, даст вам некоторое представление о том, что на самом деле происходит с кешем локально - это не будет работать при использовании AppSync.
Таким образом, помимо приведенной выше информации, которая касается настройки и настройки кэша, вы также можете управлять данными и доступом к кешу во время выполнения вашего приложения (если вы используете клиент Apollo напрямую, а не AppSyncClient).
Документы Direct Cache Access указывают доступные методы. Однако, поскольку большинство обновлений происходит автоматически только на основании ваших запросов, вам не нужно часто их использовать. Однако, одно использование для них для сложных обновлений пользовательского интерфейса. Например, если вы сделаете мутацию, которая удалит элемент из списка, вместо того, чтобы запрашивать весь список (который будет обновлять кэш, хотя за счет большего количества сетевых данных, анализа и нормализации) Вы можете определить пользовательское обновление кэша, используя readQuery / writeQuery и параметр мутации update. Это также хорошо работает с optimisticResponse , который вы должны использовать, если вы ищете оптимистичный пользовательский интерфейс.
Кроме того, вы можете выбрать, хотите ли вы использовать или обойти кеш (или более продвинутую стратегию), используя один из параметров fetchPolicy или errorPolicy .