GraphQL 和 Apollo 为什么能帮助你更快地完成开发需求？

在大前端应用的开发过程中，如何管理好数据是一件很有挑战的事情。后端工程师需要聚合来自多个数据源的数据，再分发到大前端的各个端中，而大前端工程师需要在实现用户体验好的视图 (optimistic UI¹) 的基础上，需要考虑如何管理端上的状态。

在团队中使用 GraphQL 能够很好的解决数据管理的痛点。本文接下来会介绍 GraphQL 声明式(declarative)获取数据的方法，这将简化数据管理的难度，并且提升网络性能。还会介绍 Apollo² 如何通过一系列对开发者体验好的工具，提高工程师的开发效率。

译注1：optimistic UI 是一种 UI 设计模式。例如，你在微信上发送消息会直接显示，而不用等到消息的网络请求成功或失败后再显示。optimistic UI 的数据管理很复杂，需要先显示模拟数据，再等待网络请求成功或失败后，再显示真正的数据。通过 Apollo 可以轻易地实现 optimistic UI。
译注2：Apollo 是实现，GraphQL 是标准，和 JS/ECMA 的关系一样。

开发者体验

Apollo 可以帮助团队更快地实现功能上线，因为它对开发者的体验非常好。Apollo 目标是"让各端的数据管理变得简单"(simplify data management across the stack)。通过 Apollo Client、Apollo Server 和 Apollo Engine，以前需要花上一些功夫实现的功能，比如全栈缓存、数据规范化、optimistic UI，现在变得很简单。

请求你所要的数据

GraphQL 强类型查询语言的特性，使得开发者可以利用牛逼的工具来请求 GraphQL 接口。借助 GraphQL 内省系统(introspection system)，开发者可以查询 GraphQL schema ³信息，包括字段和类型。内省系统拥有一些非常炫酷的功能，比如自动生成的文档、代码自动补全等等。

译注3：schema 用于描述你所要数据的结构和字段，如：

 {
   dogs {
     id
     breed
     image {
       url
     }
     activities {
       name
     }
   }
 }

GraphQL Playground
Prisma 团队开发的 GraphQL Playground 工具是一款非常优秀的 IDE，它可以把自定义的 schema 和查询历史自动地生成文档。只要看一下，你就知道 GraphQL API 中有哪些能获取到的数据，而不用研究后端代码或了解数据来源。

Apollo Server 2.0 内置了 GraphQL Playground，更方便你浏览 schema 和执行查询命令。

Apollo DevTools
Apollo DevTools 是 Chrome 的扩展程序，可以查询 Apollo 的前端缓存(Cache)，记录查询(Queries)和变更(Mutations)。你还可以使用 Apollo DevTools 中的 GraphiQL 来方便地测试前端查询。

简化前端代码

如果你使用过 REST 和状态管理库，如 Redux，为了发一个网络请求，你需要写 action creators、reducers、mapStateToProps 并集成中间件。使用 Apollo Client，你再也不用关系这些东西。Apollo Client 解决了一切，你只需要专注于查询，而不需要写一堆状态管理的代码。

import ApolloClient from "apollo-boost";

const client = new ApolloClient({
  uri: "https://dog-graphql-api.glitch.me/graphql"
});

有团队声称他们切换成 Apollo Client 后，删除了上千行状态管理代码和一堆复杂逻辑。这得益于 Apollo Client 不仅支持远程数据管理，还支持本地数据管理， Apollo 缓存就是当前应用全局状态的单一事实来源。

现代化的工具

Apollo platform⁴ 可以让团队使用现代化的工具，帮忙他们快速发现错误、查看 API、开发具有挑战的缓存功能。

译注4：Apollo platform 是云平台。Apollo 在本文中有两层含义，首先 Apollo 是 GraphQL 的一个开源实现，其次 Apollo 是开发 Apollo platform 、Apollo Client 、Apollo Server 等产品的公司。

Apollo Engine 是 GraphQL 生态系统中唯一可以为你的 API 提供监控和分析的工具。Engine 可以显示每个 resolver⁵ 的埋点指标，可以帮忙你定位错误， 可以分析 schema 中请求的每个字段的分布频率。 你还可以将这些数据传输到你正在用的其他分析平台，如 DataDog，并在某些数据超过报警阙值设置时进行报警。

译注5：resolver 处理返回字段的函数

声明式数据获取

使用 GraphQL 的一个主要优点是它有声明式数据获取的能力，不需要前端请求多个接口，不需要手动的聚合数据，只需要你精确地描述你所要的数据，然后 GraphQL 就会将你要的数据返回给你。而使用 REST ，你需要调用每一个接口，并过滤出你要的数据，然后将过滤后的数据构造成组件所需要的结构。

GET /api/dogs/breeds
GET /api/dogs/images
GET /api/dogs/activities

REST 的方法不仅不好使，而且容易出错，难以跨平台重用逻辑。对比一下 GraphQL 声明式的方式：

const GET_DOGS = gql`
  query {
    dogs {
      id
      breed
      image {
        url
      }
      activities {
        name
      }
    }
  }
`;

在上面，我们定义了我们想要从服务端获取的对象的结构。GraphQL 负责组合和过滤数据，同时返回我们想要的数据字段和结构。

如何使用 GraphQL 查询？Apollo Client 构建了 GraphQL 声明式请求数据的方法。在 React 应用中，获取数据、跟踪加载和错误状态以及更新 UI 的所有逻辑，都封装在一个 Query 组件中。这种封装方式使数据获取组件和展示组件很容易的组合在一起。让我们看看，如何在 React 应用中使用 Apollo Client 获取 GraphQL 数据：

const Feed = () => (
  {/* 数据获取组件 Query*/} 
  <Query query={GET_DOGS}>
    {/* 展示组件：由 Error、Fetching、DogList 等组成的函数组件 */}
    {({ loading, error, data }) => {
      if (error) return <Error />
      if (loading || !data) return <Fetching />;
    
      return <DogList dogs={data.dogs} />
    }}
  </Query>
);

Apollo Client 管理整个请求的周期，从请求开始到请求结束，包括为你跟踪加载和错误状态。这里不用设置中间件，不用写模板代码，不用重构的数据结构，不用关心请求缓存。你所需要做的就是描述你组件要的数据，然后让 Apoolo Client 去完成那些繁重的工作。

当你使用 Apollo Client 时，你会发现你能删除很多不需要的数据管理方面的代码。具体能够删除多少行代码，要根据你项目的情况来判断，但有些团队声称他们删除了数千行代码。要了解更多 Apollo Client 的牛逼功能，例如 optimistic UI、重新获取、分页获取，请查看我们的状态管理指南。

提升网络性能

在许多情况下，在现有的 REST 接口层之上增加 GraphQL API 层，可以提高你 App 的网络性能，特别是在网络差的情况下。虽然，你应该通过网络性能监控来衡量 GraphQL 如何影响你的 App，但大家通常认为 GraphQL 通过避免客户端与服务端的往返通讯(round trips)，和减少请求数据的大小来提升网络性能的。

更少的请求数据

因为从服务端返回的响应中只包含你指定的查询数据，所以 GraphQL 相对于 REST 可以显著地减少请求数据的大小。让我们看看前面文章中的例子：

const GET_DOGS = gql`
  query {
    dogs {
      id
      breed
      image {
        url
      }
      activities {
        name
      }
    }
  }
`;

GraphQL 服务响应中只包括 dogs 对象的 id、breed、image、activities 字段，即便 REST 层的接口 dogs 是带有 100 个字段的对象也是如此，所有多余的字段都将在返回给客户端之前过滤掉。

避免往返通讯(round trips)

由于每个 GraphQL 请求只返回一个响应，使用 GraphQL 可以帮助你避免客户端到服务端的往返通讯。使用 REST，请求一个资源就是一次往返通讯，往返通讯会快速地增加。如果你请求要列表中的每一项，每一项都需要一次往返，每一项中的每个资源也需要一次往返，总次数就是二者的乘积⁶，这就导致了请求时间过长。

译注6：极端 REST 例子，列表长度 N，每一项 3 个资源，请求次数就是 3*N

GET /api/dogs/breeds
GET /api/dogs/images
GET /api/dogs/activities

使用 GraphQL，每个查询代表一次往返通讯。如果你希望进一步的减少往返，你可以实现查询批处理(query batching)，将多个查询封装到单个请求中。

产品案例

虽然 GraphQL 规范是由 Facebook 在 2015 年公布的，但是自 2012 年以来，GraphQL 就是 Facebook 移动应用开发的重要组成部分。

在 Apollo 团队，我们发现 GraphQL 为我们现有方案中遇到的很多问题提供了出色的解决方案，现在我们用它来优化我们的技术基础设施。几年来，我们和开源社区、客户、合作伙伴一起，为开源项目 Apollo 带了了诸多创新。我们很骄傲，Apollo 适用于各类公司，从创业公司到大型企业。

除了我们自己的经验，我们还收到了积极地在生产环境中使用 Apollo GraphQL 的企业客户的广泛反馈、贡献和支持。一些最值得借鉴的案例是：

• The New York Times(https://open.nytimes.com/the-...: 学习 The New York Times 如何从 Relay 切换到 Apollo，实现他们 App 的 SSR 和持久化 queries。
• Airbnb(https://medium.com/airbnb-eng...: Airbnb 在 Apollo 平台上下了重注，去强化他们微服务的数据层。
• Express(https://dev-blog.apollodata.c...:使用易上手的 Apollo 分页功能，优化我们团队的关键应用。
• Major League Soccer(https://dev-blog.apollodata.c...: 团队的数据管理工具从 Redux 切换到了 Apollo，帮忙他们删除了几乎所有的 Redux 代码。
• Expo(https://dev-blog.apollodata.c...: 使用 Apollo 开发 React Native App 使得团队可以专注于改善产品功能，而不是写数据抓取的逻辑。
• KLM(https://youtu.be/T2njjXHdKqw): 学习 KLM 团队如何使用 GraphQL 和 Apollo 扩展他们的 Angular app。