PayPal：如何在你的公司扩展GraphQL？

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 也不是一件容易的事。它们每每包含许多编排逻辑，其中你须要从 五、十、15 个不一样的服务中获取数据，规范化这些响应，丢弃其中 95％的响应，而后将数据映射、过滤、分类为所需的样子