如今，PayPal 的多个生产运用程序都在利用 GraphQL。现在，利用 GraphQL 构建新的 UI 运用程序已经成为默认模式。许多现有运用程序正在迁移到 GraphQL。GraphQL 正被身份（Identity）、支付（Payment）、合规性（Compliance）等常见平台利用，以在所有 PayPal 产品中供应同等的体验。我们的 API 开拓职员已经开始利用 GraphQL 来构建 API。Braintree 发布了它的公共GraphQL API。
在 GraphQL 的帮助下，我们已经能够弥合面向前端运用程序的后端（BFF，backend for frontend）和后端 API 功能之间的差距，由于 GraphQL 可以作为下贱 API 的编排层，实行后端 API 的功能，并充当 UI 运用程序的 API 接口。我们正朝着统一的 GraphQL 网关迈进，以支持全体公司。
当我们选择 GraphQL 时，我们正在探求一种技能来帮助我们办理以下问题：
图片来源：drmakete lab on Unsplash
为什么我们开始采取 GraphQL？PayPal 有一套弘大的 REST API，支持运用程序核心功能，并且非常靠近数据库。GraphQL 在我们的运用程序中用作编排层。它位于前端 UI 运用程序和后端 API 层之间，充当面向前真个后端（BFF）。这意味着 UI 运用程序与 GraphQL 端点对话，这些端点确定要调用哪个下贱做事。可以直接在 GraphQL 层构建新功能。一些团队选择利用 GraphQL 作为纯编排层，而其它一些团队利用 GraphQL 作为业务逻辑层。
收银台团队是第一个率先利用 GraphQL 的团队。Mark Stuart 在《收银台运用程序详解（Checkout app in this blog post in detail）》等分享了我们采取 GraphQL 的过程。当收银台团队展示他们的运用程序时，我们的工程团队真正感想熏染到了编排和开拓职员生产力提高的好处。这引发了全体 PayPal 的兴趣，团队开始开拓在他们的运用程序中利用 GraphQL 的示例程序。
这是新的吸引人的事情。每个人都对这一宣扬感到愉快，但对团队来说最主要的是，编排下贱 API 和为客户创建统一体验有多随意马虎。利用 GraphQL，所有下贱的繁芜性都可以隐蔽，客户不必担心找出哪一部分连接到了哪里。它为客户供应了更加连贯的体验。
团队开始构建产品，在我们的技能展览中展示，并使其他人也愉快不已。很快，所有人都感到好奇。一旦我们说服了领导，我们就可以真正起飞了。
我们如何扩大 GraphQL 的采取范围？当我们开始扩大 GraphQL 的采取范围时，我们意识到每个运用程序都在试图办理自己的 GraphQL 问题。常日，各个团队都在办理相同的问题并重复发明轮子。我们意识到有必要将这些事情统一到一个框架下，因此，我们成立了一个标准机构。我们为工具、前端和中端示例运用程序、非常处理技能和学习资源供应了支持。
我们构建了有助于支持 GraphQL 采取的工具：
我们建立了 GraphQL 标准，用于在内部定义 GraphQL API。这些标准定义了命名约定、GraphQL 类型、要求头标准、指令标准和非常处理技能。所有 GraphQL 操作都须要指定分外指令，这些指令描述查询、突变和字段的所有授权要求。通用库包括用于日志记录的插件、用于数据分类的指令、Apollo 和 playground 的插件、CLI、非常类和 Apollo graph 变体。前端和后真个模板示例程序。学习资源，用于帮助团队入门 GraphQL。Slack 频道，帮助回答常见问题并创建内部 GraphQL 社区。拥有一个标准机构和工具非常棒，可以帮助团队更快地建立他们的图。然而，我们把稳到有些问题仍旧存在。我们把稳到某个图偏离了精确的操作办法，例如身份验证。我们在单个图中失落去了对认证流程的掌握。我们还认识到，拥有多个图会使 schema 共享更加困难。我们希望供应一个统一的入口点，共同管理 schema，以全局办法对数据建模，并供应一种重用类型的办法。这便是匆匆使我们利用Apollo Federation构建了一个单图网关的缘故原由。
采取 GraphQL 有哪些上风？我们能够折衷周边做事，并将一个 PayPal 子系统的账号转变为一个 PayPal 账户，这很让我们自满。我们最初发布了我们的 Braintree API，我们能够很快完成它。交付速率更快，GraphQL 能够报告利用了 schema 的哪一部分。我们已经看到的 GraphQL 的紧张上风有：
开拓职员生产力：GraphiQL和Playground等工具非常适宜利用 API 的同时浏览文档，而无需借助其它任何工具（如 Postman）。可以访问全体 schema：由于所有操作（查询和变动）都是在同一个端点，因此访问 API 支持的所有操作变得更加随意马虎。团队协作：与 GraphQL API 并行构建 UI 有助于团队协作。由于 GraphQL schema 须要预先构建，后端工程师和前端工程师一起事情，从而减少了信息隔阂。范式转换：由于 GraphQL 哀求采取设计优先的方法，我们在启用业务用例时考虑 GraphQL，并在考虑客户的情形下构建 API。更快的交付速率：我们能够更快地交付功能。我们能够摆脱许多弯道，它们使得供应功能更新和保持功能对等变得更难。以前，我们必须用我们的商户利用的每种措辞交付一个 SDK。现在，我们可以只供应一个 GraphQL 端点，商户无论利用哪种措辞都可以与之集成。简化统一：内部客户端和周边客户端不再须要担心内部系统的繁芜性，也不须要确定调用哪个 API。GraphQL 层将繁芜性隐蔽在幕后。剖析：对特定字段的单个要求花费的韶光进行检测。曝光和招聘：社区中的许多人对 GraphQL 感到愉快，它帮助我们吸引人才加入 PayPal。我们的团队成员很高兴能在社区等分享他们的学习成果，并一贯在会议上发言、撰写博客文章和制作传授教化资源。Vishakha Singh就利用GraphQL在PayPal构建更快的收银台体验进行了演讲。Rohit Basu 谈到了用Kotlin和GraphQL事情。我们在JS @ PayPal公开会上多次谈论了我们是如何在各种运用程序中利用 GraphQL 的。我们面临哪些寻衅？图片来源：Possessed Photography on Unsplash
我们仍在创建一种标准方法来应对 GraphQL 技能中的寻衅，如非常处理、身份认证、文件处理和批处理。
各个团队都在独立地构建他们自己的图，这会导致重复事情、不同的非常处理和呈现办法，以及与处理身份认证标准办法的偏差。
我们仍在整合内部工具。由于这些工具很多依赖于 API 相应的状态码——200、400、500 等等，因此我们很难将 GraphQL 相应（都是 200）映射到这些工具。
PayPal 的 GraphQL 增长非常快。许多团队构建了他们自己的方法来处理非常，办理 GraphQL 问题，并对内部日志系统进行检测。在它发展之后，我们通过添加内部插件和中间件来供应支持，以规范化缺点处理、检测和减少内部网络谈天，但我们希望能够更快地构建支持。
我们对单图方案的采取速率很慢。各个团队必须改变他们目前制作运用程序的许多行为，才能采取单图，增加了交付过程和韶光。寻衅在于见告人们，现在我们有规则可以添加到图中，但要让他们有动力利用单图。Joey Nenni在JS @ PayPal上揭橥演讲，谈到了我们实现单图的方案，以及战胜这一寻衅的潜在办理方案。
我们如何说服我们的工程和领导团队？我们的前端开拓职员立即看到了利用 GraphQL 的好处。说服在 UI 团队中事情的后端开拓职员也很随意马虎。他们理解利用 GraphQL 进行编排的力量。对付核心平台 API 团队，我们还没有完备说服他们。当我们先容 GraphQL 观点时，有时我们被奉告 REST 也可以这样做。是的，它可以，我们也可以利用 REST 复制 GraphQL 所做的事情，但末了，我们只是在重新创建 GraphQL。我们还没有得到所有前端或后端开拓职员的完备认证，但是我们的 REST API 和 GraphQL API 可以共存。我们学会了不操之过急，一点点来。
图片来源：Christoffer Engström on Unsplash
为了说服我们的领导，我们知道仅仅关注 GraphQL API 的性能是不足的。编排的 GraphQL API 的性能取决于它所利用的 API。GraphQL API 的速率仅与最慢的下贱 API 的速率相同。相反，我们将重点放在开拓职员的生产力和交付产品的韶光上。我们演示了利用 GraphQL 可以帮助更快地构建产品，提升团队协作，并使文档更随意马虎浏览。当我们向我们的团队先容 GraphiQL 和 Playground 工具时，他们急速看到了利用 GraphQL 端点和 playground 工具来在浏览文档时发出要求的好处。
我们演示了 GraphQL 如何帮助提高内部和外部开拓职员的生产力，GraphQL 如何帮助减少交付功能的韶光，以及我们如何能够向客户端隐蔽繁芜性。利用 GraphQL，我们不必为每个平台编写多个 SDK。我们构建一次 API 就可以了。没有 GraphQL，我们不知道商户正在利用哪些字段以及调用了哪些端点。我们在 KPI 上没有指标，例如首次集成莅临盆中。通过 GraphQL，我们能够展示我们的学习、工具和字段级别的监测情形。
你如何开始在自己的公司采取 GraphQL？当你第一次推测 GraphQL 是否是精确的技能时，构建一个示例运用程序来演示 GraphQL 如何适宜你的企业架构是很有帮助的。带上团队——演示你的运用程序并展示利用 GraphQL 的好处，你采取 GraphQL 的经历，你所看到的好处，以及你在帮助公司其他人方面所面临的困难。为成功建立机构——成立一个事情组，帮助建立标准。为 GraphQL 建立学习资源、供应辅导、构建工具和支持。让团队参与进来——从生产力的角度展示利用 GraphQL 的上风。每个人都希望更快地发布产品，并使其更随意马虎与 API 集成。GraphQL 恰好供应了这一点。向你的团队成员和领导演示利用 GraphQL 构建新功能是多么随意马虎，向现有客户发送更新是多么随意马虎，而不必发布新版本，同时仍旧向后兼容。特殊鸣谢图片来源：Wilhelm Gunkel on Unsplash
这篇文档是我们宝贵的团队成员的贡献匆匆成的。感谢Mark Stuart、Joey Nenni、Walmik Deshpande和Miriam Goldberg，感谢他们乐意接管采访并分享他们的经历。非常感谢 Mark Stuart 在 PayPal 中领导 GraphQL 的采取，勉励我分享我的 GraphQL 履历，并勉励我们的开拓者社区。
作者先容：
Shruti Kapoor 是 PayPal 的软件工程师、freecodecamp 和 codeburst 的作家，写一些 JavaScript 干系的内容。Twitter：shrutikapoor08
原文链接：
GraphQL at PayPal: An Adoption Story
