接上篇 —— 如何使用 GraphQL-基础教程：架构 —— 继续翻译How to GraphQL 系列教程。
了解 GraphQL 客户端（例如 Relay 和 Apollo 客户端）及其提供的功能，例如缓存，schema校验和查询/视图协同。
基础和进阶系列翻译已完成：
在前端使用 GraphQL API 对于开发新的抽象层并帮助在客户端实现通用功能很有帮助。考虑一下可能希望在应用程序中拥有的一些“基础架构”功能：
- 直接发送查询和变更而无需构建 HTTP 请求
- 视图（view）层集成
- 缓存
- 基于 schema 的查询的校验和优化
当然，没有什么可以阻止使用纯 HTTP 来获取数据，然后自己转换计算，直到正确的信息出现在 UI 中。但是，GraphQL 抽象化了通常需要手动完成的许多功能，并使开发者可以专注于应用程序真正重要的部分！
在下文中将更详细地讨论这些任务是什么。
目前可用的 GraphQL 客户端主要有两个。第一个是Apollo Client，它是社区驱动的，旨在为所有主要开发平台构建功能强大且灵活的 GraphQL 客户端。第二个称为Relay，它是 Facebook 自主开发的 GraphQL 客户端，该客户端对性能进行了大幅优化，并且只能在 Web 上使用。
直接发送查询和变更
GraphQL 的一个主要优点是允许以 命令式（declarative） 方式获取和更新数据。换句话说，在 API 抽象阶梯上更上一层楼，不再需要自己处理底层网络任务。
以前使用纯 HTTP（例如 Javascript 中的 fetch 或 iOS 上的 NSURLSession ）从 API 加载数据，使用 GraphQL 所需要的只是一个查询，可以在其中声明数据需求并让系统负责发送请求并处理响应。这正是 GraphQL 客户端正在做的。
视图层集成 和 UI 更新
一旦 GraphQL 客户端收到并处理了服务器响应，所请求的数据就需要以某种方式最终出现在 UI 中。根据开发平台和框架的不同，通常会有不同的方法来处理 UI 更新。
以 React 为例，GraphQL 客户端使用高阶组件（higher-order components）的概念来获取所需的数据，并且使它在组件的 props 中可用。通常，GraphQL 的声明特性与函数响应式编程技术相关性较高。两者形成了强大的组合，其中视图仅声明其数据依赖， UI 与选择的 FRP 层连在一起。
缓存查询结果：概念和策略
在大多数应用中，需要维护以前从服务器获取的数据缓存。本地缓存信息对于提供流畅的用户体验至关重要，还可以减轻用户数据计划的压力。
通常在缓存数据时，直觉是将远程获取的信息放入本地 存储（store） ，以便之后可以从中检索信息。使用 GraphQL 时，原始的方法是将 GraphQL 查询的结果简单地放入存储中，并在发送相同查询时简单地返回它们。事实证明，这种方法对于大多数应用来说效率很低。
一种更有效的方法是预先对数据进行规范化。这意味着将扁平化（可能嵌套的）查询结果，并且存储将包含可用全局唯一 ID 引用的单个记录。如果想了解更多有关此的内容，可以查看Apollo blog，对这个主题写的很好。
构建时 schema 校验和优化
由于该 schema 包含有关客户端可以使用 GraphQL API 进行的所有操作的 全部 信息，因此有很容易来校验和潜在地优化客户端希望在构建时发送的查询。
当构建环境可以访问 schema 时，它实际上可以解析项目中的所有 GraphQL 代码，并将其与 schema 中的信息进行比较。在应用进入实际用户的手中之前，会先捕获拼写错误和其他会导致错误后果的内容。
协同视图和数据依赖
GraphQL 的一个强大概念是允许同时满足 UI 代码和数据要求。视图及其数据依赖关系的紧密耦合极大地改善了开发者的体验。节约了浪费在思考数据如何在 UI 的恰当部分中存储上的时间。
协同的工作方式取决于正在开发的平台。例如，在 Javascript 应用中，实际上可以将数据依赖和 UI 代码放入同一文件中。在 Xcode 中，可以使用 助理编辑器（Assistant Editor） 来同时处理视图控制器和 graphql 代码。
前端记事本，不定期更新，欢迎关注！
