PayPal：如何在你的公司扩展GraphQL？
作者｜Mark Stuart译者｜王强编辑｜王文婧GraphQL 是 REST API 的一种非常流行的替代方案，目前正在席卷开发人员的世界！去年，PayPal 将 GraphQL 引入了技术堆栈，彻底改变了开发人员思考数据、获取数据和构建应用程序的方式。本文作者在一年前曾写过一篇 GraphQL 最佳实践的文章，当时受到了广大读者的欢迎。这篇文章同样也是一篇精彩的总结，可以当作公司部署 GraphQL 的指南。
图源：graphql.org
我们在 PayPal 构建 GraphQL API 时获得了一系列最佳实践和观察总结，这篇文章就是其中之一。
一年前，我们写了一篇《GraphQL：PayPal Checkout 的成功案例》，内容涵盖了我们从 REST 到 Batch REST 再到 GraphQL 的发展历程。自那时以来很多事情都改变了！这篇文章涵盖了我们在 PayPal 扩展 GraphQL 时学到的所有知识，并可作为你在公司部署 GraphQL 的指南。
《GraphQL：PayPal Checkout 的成功案例》：https://medium.com/paypal-engineering/graphql-a-success-story-for-paypal-checkout-3482f724fb53
一年前，使用 GraphQL 的产品很少。虽然我们在 PayPal Checkout 上取得了成功，但那时还没有相关的基础架构、工具、培训或支持。尽管存在这些缺陷，但 GraphQL 的发展仍像火箭一般一飞冲天。在撰写本文时，我们已经有 50 多个不同的产品在使用 GraphQL！
短短 2 年内，PayPal 使用 GraphQL 的产品从 3 种增加到 52 种。
这项新技术的应用速度 很快，我们仍在努力跟上步伐。与其他技术变革一样，企业级扩展的重点并不在于水平扩展，或为服务器 / 云计算投入大量资金。扩展人员、工具链和流程是最具挑战性的。
了解自己在部署 GraphQL 之前，重要的是要深入了解你所在的公司，理解你们的身份，你们在做些什么，以及你们的长处与不足。
在 PayPal，我们的产品使用 JavaScript 构建。前端采用 React，后端则是 Node.js。技术栈中还有数百个 Java REST 服务和一些 C++ SOAP 之类的服务。
PayPal 是最早使用 Node 的公司之一，并通过 NodeDay 之类的活动，以及与 The Node Firm 和 NodeSource 的合作，在业界打响了 Node 的品牌。
2014 年，PayPal 的首个 NodeDay。
2013–2015 年，PayPal 迁移到了 Node。Node 改变了整个公司，改善了我们制造和运输产品的方式。过去，一项简单的内容更改需要数周时间才能部署为单个单体 C++ 应用。如今，开发人员只需要几分钟时间就可以实验、迭代和推出新的产品功能。
https://vimeo.com/82577994
这不是一夜之间发生的转变，也不是偶然的结果。在 Node 融入 PayPal 之前，Bill Scott 提出了使用 LeanUX 构建产品的愿景，其中迭代和学习是核心要素。在 LeanUX 中，UI 数据是实验性、一次性的。如果实验效果不佳，那就不断迭代！Node.js 是其成功的关键所在。
Kraken.js
2014 年，我们推出了 Kraken，这是 Express 上的一组库，旨在通过可配置的中间件、默认安全设置、一个 dust.js 渲染器和内容本地化来为你的应用“提供一些帮助”。自那以来，Kraken 的大部分武器都消失了。我们仍使用可配置的中间件和默认安全设置，但与 Web 应用程序相关的所有内容自 2014 年以来发生了很多变化。现在，团队正在构建客户端 React 应用，应用程序是部署到 CDN 的静态文件包，而不是在服务器集群中运行的代码。
对于 API 而言，我们使用 BFF Schema。尽管它们都是专用的，并且允许开发人员迭代，但是它们紧密耦合在一起，并且不能很好地复用。结果是我们有很多团队在反复迭代和构建相同的事物！构建 BFF API 也不是一件容易的事。它们往往包含许多编排逻辑，其中你需要从 5、10、15 个不同的服务中获取数据，规范化这些响应，丢弃其中 95％的响应，然后将数据映射、过滤、分类为所需的样子
