Airbnb 已经成功地将其大部分 API 迁移到了 GraphQL，从而缩短了页面加载时间并提供了更直观的用户体验。在 GraphQL Summit 上的演讲中，Brie Bunge 描述了 Airbnb 多个团队都有使用过的多阶段迁移过程。

在每个阶段完成之后，Airbnb 最终推出了一款基于 Apollo 和 GraphQL 应用程序，该应用程序是 100% 类型安全的，没有过度抓取的问题，并且在整个迁移过程的每个阶段，都能保持着网站的正常运行。因为采用了 Apollo 和 GraphQL 来奠定基础，使 Airbnb 可以尝试新的性能改进，而传统的基于 REST 的架构则无法实现。

在迁移过程开始之前，必须满足两个先决条件。首先，必须在后端设置 GraphQL。Adam Neary 曾写过关于 Airbnb 是如何与 GraphQL 合作的文章。

第二个先决条件是在前端采用 TypeScript。在 Airbnb 中，TypeScript 和类型安全促进了更快的开发，并且团队对他们自己所构建的东西更有信心。TypeScript 类型可以直接从 schema 中生成（使用 apollo client:codegen --target=typescript），这些类型在后端和前端之间创建一个单一数据源（single source-of-truth，SSOT）。

TypeScript 现在是 Airbnb 前端开发的官方语言，在他们 300 万行的代码库中，有一半已经迁移到了 TypeScript。Bunge 之前曾在 JSConf 上发表过关于 Airbnb 采用 TypeScript 的演讲。

Bunge说，转换为 GraphQL 有三个主要选项可选。首先，也是最诱人的，是完全从零开始重写。虽然在某些情况下，这作为其他重大项目的一部分经常发生，但这通常不是一个可行的选项。第二个选项是停机并重构，这在小型或单独的团队中可以很好地运行，但在有许多开发人员一起工作的情况下就很困难了。

Airbnb 推荐的迁移选项是渐进式采用，这是最安全且最可行的方法，特别是在拥有大型团队和庞大的已有代码库的情况下。Bunge 所描述的迁移过程包括五个阶段，每个阶段的目标是发布一个可交付的、功能齐全的、无回归的应用程序版本。

第一阶段是改变数据的来源，而不是数据的使用方式。使用 GraphQL 后端和 TypeScript 后， REST请求就可以与 GraphQL 请求交换。第一个阶段的目标是验证前端到后端的集成是否能正常工作以及 TypeScript 类型生成是否能正常工作。无需变更 React 组件或 API 响应的模型。这需要与 REST 端点匹配的 GraphQL 查询和变异。

Airbnb 早期依赖的两个 GraphQL 特性是别名和适配器。别名实现了 GraphQL 返回的驼峰式属性和旧 REST 端点的蛇形属性之间的映射。适配器用于转换 GraphQL 响应，这样就可以递归地将它与 REST 响应区分开来，并确保 GraphQL 返回与之前相同的数据。这些适配器在后面会被删除，但是它们对于实现第一阶段的对等目标是至关重要的。

第二阶段的重点是整个代码中的传播类型，这将增加后面阶段的可信度。此时，不应影响任何运行时行为。

第三阶段是改进 Apollo 的使用。早期阶段直接使用了Apollo Client，通过Apollo Client触发Redux 操作，使组件能够使用了 Redux 存储。使用 React Hooks（@apollo/react-hooks）重构应用程序可以使用 Apollo 缓存代替 Redux 存储。

GraphQL 的一个主要优点是减少过度抓取。使用大型查询的第一个阶段保留了旧 REST 端点的所有过度抓取行为，但是第四个阶段可以通过引入更细粒度的查询片段来解决这个问题。

首先，只有应用程序的根组件才能感知到 GraphQL ，并且它必须获取树中任何组件可能需要的所有数据。改进过程从组件树的最低叶节点开始，方法是仅为该子组件所需的数据创建一个GraphQL 查询。TypeScript 很有用，因为如果所需的字段不存在，它将抛出编译器警告。然后修改父组件以根据其子组件的片段来获取数据。一个“清洗并重复”的过程会遍历所有的叶子节点，然后沿树向上到达应用程序的根组件，在那里旧的大型查询已经被所有组合的片段所替换。因为所有片段都只请求它们所需要的数据，所以消除了过度抓取。

第五阶段，也是最后一个阶段，是阶段管理。一旦将所有组件都迁移到 Apollo，Airbnb 就可以利用 Apollo 来获取 API 数据、React 本地状态或客户端上下文数据。这为处理客户端数据提供了一个一致的心智模型，并对组合了 React 、Apollo 和 Redux 元素的碎片模型进行了改进。它还消除了 Redux 所需的大量样板代码，并且它处理缓存的方式比手动滚动的解决方案更有效。

有了 GraphQL，Airbnb 现在可以尝试新的技术。Bunge 描述的第一种情况是 service worker 查询预取，它是为了尽早启动 GraphQL 查询，以便用户能更快地看到使用数据呈现的页面。

如果没有 service worker，页面在服务端渲染完毕后，用户还需要等待较长时间间隔才能最终看见最终完整的页面。service worker 允许应用程序外壳立即出现，并提供一个加载阶段，在该加载阶段中，页面将从返回数据时开始填充。由于缓存了许多的 JavaScript，页面加载速度也更快。然后，service worker 可以通过从组件级查询切换到路由级查询来实现进一步的改进。基于设备的限制，在页面完全交互之前，这可能还会导致总时间另外再减少23-50%。

以数据为中心的统一模式是目前正在进行的另一个项目。现有的模式与 Airbnb 面向服务的架构保持一致。由于服务可以通过不同的方式来组合相同的底层数据，因此数据通常是重复的。通过切换到以数据为中心的模式，并在架构中添加数据水化层，可以避免重复的数据请求、删除重复的代码、提高响应效率、并改进缓存。这项工作目前正处于测试阶段，但看起来很有希望，更多的信息将会在明年宣布。

原文链接：

Migrating to GraphQL at Airbnb

创作场景

Airbnb：我们如何将大部分 API 迁移到 GraphQL