了解AWSAppSyncJavaScriptSDK中的Apollo客户端缓存和开放式UI

我正在尝试使用AWS AppSync Javascript SDK在Apollo客户端中实现缓存，但我一直在努力了解首先要使用缓存的最佳方法，其次是如果需要进行任何更改以适应Apollo V2教程以与AppSync配合使用，该如何做？ SDK。

关于使用缓存，我有一个对象列表，然后我想从该列表中查看和修改单个对象。关于如何更新列表中的某些内容的教程很多，但是我宁愿运行第二个查询，该查询通过其ID获取单个对象，以便该页面始终可以工作，而不必先浏览列表。

缓存是否足够聪明，以至于知道通过查询Y和Z获得的对象X是同一个对象，并且将同时进行更新？如果没有，是否有任何文档说明如何编写将同时更新列表中的对象和本身的更新？

如果没有文档，那么我将自己尝试并发布代码（因为它很可能无法工作）。

关于第二个问题，我已使应用程序正常运行，并使用Amplify进行身份验证来查询API，但不确定如何正确实现缓存。创建客户端时是否需要指定缓存，或者SDK具有内置缓存？如何访问缓存？是否只是像这些教程中那样通过查询客户端？https://www.apollographql.com/docs/react/advanced/caching.html

我将首先回答你的第二个问题：

关于第二个问题，我已使应用程序正常运行，并使用Amplify进行身份验证来查询API，但不确定如何正确实现缓存。创建客户端时是否需要指定缓存，或者SDK具有内置缓存？如何访问缓存？是否只是像这些教程中那样通过查询客户端？

好。所以这里有点毛茸茸的-似乎是在GraphQL的主要客户端库（Apollo，Relay等）进行全面检查的时候部署了AppSync，因此AWS实际上围绕Apollo Client创建了一个包装器（可能出于稳定的API目的），然后公开自己的处事方式。只需快速浏览一下代码，就好像它们具有处理Websocket，其身份验证协议，redux存储，脱机功能，ssr等的专有和未记录的处理方式。因此，如果此处或此处未明确说明，则您处于未知领域。

幸运的是，他们提供的所有东西（以及更多东西）现在已经以文档记录的方式在基础Apollo客户端中实现。更幸运的是，看起来AppSync客户端将大多数与GraphQL实际相关的东西直接转发到内部Apollo缓存，并允许您在下传递config选项cacheOptions，因此您可以使用Apollo Client进行的大多数配置AppSync客户端（更多信息请参见下文）。

不幸的是，您无法直接使用AppSync客户端访问缓存（它们已将其隐藏以确保其公共API在瞬息万变的生态系统中保持稳定）。但是，如果您确实需要更多控制权，则可以轻松地在自己的Apollo客户端实例中复制在AppSync客户端中实现的大多数内容，从而可以完全控制（您可以使用开源的AppSync代码作为基础）。由于GraphQL前端和后端是解耦的，因此没有理由不能使用自己的Apollo Client与AppSync服务器连接（对于大型，严肃的项目，这就是我要做的，因为Apollo Client有很多文档记录并处于积极发展中）。

缓存是否足够聪明，以至于知道通过查询Y和Z获得的对象X是同一个对象，并且将同时进行更新？如果没有，是否有任何文档说明如何编写将同时更新列表中的对象和本身的更新？

第一部分与Apollo客户端和AppSync客户端有关。

是! 那是Apollo客户端的一大优点-每次查询时，它都会尝试更新缓存。高速缓存是规范化的键值存储，其中所有对象都存储在顶层，该键是对象的__typename和id属性的组合。Apollo客户端将自动添加__typename到您的所有查询中（尽管您将不得不id手动添加到您的查询中-否则，它会退回到查询路径本身作为关键字[这不是很可靠]）。

该文档提供了对该机制的很好的概述。

现在，您可能需要做一些更高级的工作。例如，如果您的GraphQL模式使用以外的一些唯一对象标识符id，则必须向dataIdFromObject映射到它的函数提供一些功能。

此外，有时在进行查询时，缓存很难在发出网络请求之前准确地知道您要查询的内容以检查缓存。为了缓解此问题，它们提供了缓存重定向机制。

最后，也许是最复杂的，是如何处理分页查询中的东西顺序（例如，有序列表中的任何东西）。为此，您必须使用@connection指令。由于这是基于中继连接规范的，因此建议您略读一下。

奖励：要查看运行中的缓存，我建议使用Apollo客户端开发工具。这是个小问题，但至少可以使您了解本地缓存实际发生的情况-如果使用AppSync，则无法使用。

因此，除了以上所有有关设置和配置缓存的信息外，您还可以在应用程序运行期间控制数据和对缓存的访问（如果直接使用Apollo Client而不是AppSyncClient）。

该直接高速缓存访问文档指定的可用方法。但是，由于大多数更新仅根据您进行的查询自动发生，因此您不必经常使用这些更新。但是，它们的一种用途是进行复杂的UI更新。例如，如果进行突变以从列表中删除一个项目，而不是重新查询整个列表（这将更新缓存，但是会花费更多的网络数据，解析和规范化），则可以定义一个自定义缓存使用readQuery/ writeQuery和updatemutation选项进行更新。这与optimisticResponse配合使用也很不错，如果您正在寻找开放式UI，则应该使用它。

此外，您可以使用fetchPolicy或errorPolicy选项之一选择是使用还是绕过缓存（或更高级的策略）。