我们通过构建收银台体验开启了我们的 GraphQL 采用之旅。当 我们用 GraphQL 构建收银台应用程序 时,我们看到了采用 GraphQL 的巨大好处,这成为我们的指路明灯。我们构建了更多的应用程序,提供了基础设施支持,发布了一个公共 GraphQL API,并在全公司提供了培训和学习材料。我们还建立了一个标准机构,提供了一个 GraphQL 工具 fanny pack,并构建了示例应用程序来帮助团队开始使用 GraphQL。
如今,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 网关迈进,以支持整个公司。
2 为什么 PayPal 需要 GraphQL?
当我们选择 GraphQL 时,我们正在寻找一种技术来帮助我们解决以下问题:
/getProfileById/{id}
,我们必须预先请求调用其它端点,例如getUser{username}
来返回id
等参数。这是一个问题,因为我们为了获取一条信息进行了多次往返请求。GraphQL 帮助解决了这个问题,因为它允许我们在一次往返中获取所需的一切。username
, 使得理解 API 变得更加困难。使用联邦 GraphQL,所有团队共享同一个 schema,因此更容易识别重复项并使变量命名一致。图片来源:drmakete lab on Unsplash
3 为什么我们开始采用 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,所有下游的复杂性都可以隐藏,客户不必担心找出哪一部分连接到了哪里。它为客户提供了更加连贯的体验。
团队开始构建产品,在我们的技术展览中展示,并使其他人也兴奋不已。很快,所有人都感到好奇。一旦我们说服了领导,我们就可以真正起飞了。
4 我们如何扩大 GraphQL 的采用范围?
当我们开始扩大 GraphQL 的采用范围时,我们意识到每个应用程序都在试图解决自己的 GraphQL 问题。通常,各个团队都在解决相同的问题并重复发明轮子。我们意识到有必要将这些工作统一到一个框架下,因此,我们成立了一个标准机构。我们为工具、前端和中端示例应用程序、异常处理技术和学习资源提供了支持。
我们构建了有助于支持 GraphQL 采用的工具:
拥有一个标准机构和工具非常棒,可以帮助团队更快地建立他们的图。然而,我们注意到有些问题仍然存在。我们注意到某个图偏离了正确的操作方式,例如身份验证。我们在单个图中失去了对认证流程的控制。我们还认识到,拥有多个图会使 schema 共享更加困难。我们希望提供一个统一的入口点,共同管理 schema,以全局方式对数据建模,并提供一种重用类型的方式。这就是促使我们使用 Apollo Federation 构建了一个单图网关的原因。
5 采用 GraphQL 有哪些优势?
我们能够协调周边服务,并将一个 PayPal 子系统的账号转变为一个 PayPal 账户,这很让我们自豪。我们最初发布了我们的 Braintree API,我们能够很快完成它。交付速度更快,GraphQL 能够报告使用了 schema 的哪一部分。我们已经看到的 GraphQL 的主要优势有:
6 我们面临哪些挑战?
图片来源:Possessed Photography on Unsplash
我们仍在创建一种标准方法来应对 GraphQL 技术中的挑战,如异常处理、身份认证、文件处理和批处理。
各个团队都在独立地构建他们自己的图,这会导致重复工作、不同的异常处理和呈现方式,以及与处理身份认证标准方式的偏差。
我们仍在整合内部工具。由于这些工具很多依赖于 API 响应的状态码——200、400、500 等等,因此我们很难将 GraphQL 响应(都是 200)映射到这些工具。
PayPal 的 GraphQL 增长非常快。许多团队构建了他们自己的方法来处理异常,解决 GraphQL 问题,并对内部日志系统进行检测。在它发展之后,我们通过添加内部插件和中间件来提供支持,以规范化错误处理、检测和减少内部网络聊天,但我们希望能够更快地构建支持。
我们对单图方案的采用速度很慢。各个团队必须改变他们目前制作应用程序的许多行为,才能采用单图,增加了交付过程和时间。挑战在于告诉人们,现在我们有规则可以添加到图中,但要让他们有动力使用单图。Joey Nenni 在 JS @ PayPal 上发表演讲,谈到了我们实现单图的方案,以及克服这一挑战的潜在解决方案。
7 我们如何说服我们的工程和领导团队?
我们的前端开发人员立即看到了使用 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,我们能够展示我们的学习、工具和字段级别的监测情况。
8 你如何开始在自己的公司采用 GraphQL?
9 特别鸣谢
图片来源: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
原文链接:
https://medium.com/paypal-tech/graphql-at-paypal-an-adoption-story-b7e01175f2b7
点击底部阅读原文访问 InfoQ 官网,获取更多内容!