20 多年来，PayPal 始终处于数字支付革命的最前沿，现在已有超过 3 亿消费者和商家使用其支付平台。PayPal 工程处于这种领先地位的核心，不断寻找更快迭代的方法，并使用户体验更具响应性、更安全和更便捷。
在系列博文中，PayPal 工程提供了对其最新现代化工作的一瞥，以了解使用 Graph 加速 GraphQL 开发的方式，从设计和验证 Graph 到管理其增长。
转换非常成功，PayPal 现在有超过 50 个产品由 Graph 驱动。
释放生产力收益
PayPal 网络平台高级经理 Mark Stuart 解释了转向 GraphQL 如何大幅提高了开发人员的生产力、灵活性以及终端用户的性能。
随着 PayPal 推出结账产品，他们最初全力投入 REST，但出现了很多开发人员体验和终端用户性能问题。“我们发现用户界面开发人员实际构建用户界面的时间不到三分之一。剩余时间都用在确定从哪里以及如何获取数据、对数据进行筛选/映射以及协调 API 调用上”，Stuart 说。
PAYPAL CHECKOUT
Stuart 解释说，“每次获取数据都要往返一次，这在网络时间上至少花费 700 毫秒，而不包括服务器处理请求的时间。多次往返会导致性能下降，用户更加沮丧，而且对我们的底线产生了重大影响。”PayPal 结账团队使用一款新产品试用了 GraphQL，并立即看到了开发者的生产力和性能的提高。他们决定全力投入 GraphQL。
从后端到 GraphQL
最初，为后端到前端 (BFF) 架构就绪，以便让用户界面开发人员能够使用自己定制的 API 快速迭代。Stuart 解释了现在成为一种相当常见的场景，“各个后端团队开发了核心服务，然后产品团队构建了 BFF API 来协调来自那些底层核心服务的数据”。
尽管 BFF API 是专门的，可以让开发人员更快速地迭代，但 PayPal 发现它们需要大量的低价值样板。
斯图尔特表示，“使用 BFF，我们可以让许多团队不断迭代和构建相同类型的内容。通常，它们包含大量编排逻辑，你需要从 5、10、15 个不同的服务获取数据，对这些响应进行规范化，抛弃其中 95% 的内容，然后映射、筛选和对数据进行排序以获取所需内容。这是一个单调乏味的过程，并不是我们开发人员时间的有效利用。相反，UI 开发人员应该将大部分时间花在构建 UI 上。”
PayPal 正在寻找一种方法，以便摆脱不断编写和重写低价值的编排代码的惯例。随着 GraphQL 在业界的普及，他们试用了一下，并且一试钟情。
实现图
图作为当前基础设施的优雅扩展，将 PayPal 的数据和服务组合在一起，供任何开发人员使用 GraphQL 调用。构建一个图让客户端可以指定他们需要的任何数据，以及任何所需的组合，以支持用户体验。此外，多个客户端都可以执行此操作，所有客户端都由同一个图支持，并且不需要为每个客户端编写新的代码。
图也特别容易实现。PayPal 在其利用现有核心 REST API 的堆栈边缘构建了该图。没有任何内容需要拆除和替换，而且随着时间的推移，他们可以从旧基础设施迁移出来。
最终，图对于在合理的时间内将新的产品体验推向市场，同时不降低客户体验是一个理想的解决方案。
正如斯图尔特解释的那样，“现在，开发人员可以根据字段来考虑问题，而不是端点、域或复杂的联接。例如，他们可以遍历数据图来选取用户的姓名、60x60 个人资料照片、主要送货地址和信用卡，而无需调用 6-10 个不同的服务。
将 PayPal Checkout（等内容）移至图表
验证概念比预期容易。他们正在推出一个新产品，为开发者提供移动 SDK，以便将 PayPal Checkout 集成至其应用。该团队仅用六周就利用图表和三名开发者将其构建完毕。
此体验是图表和 GraphQL 的佐证：“我们意识到我们做出了正确的判断。”斯图尔特说，“我们的开发者工作效率高，我们的应用很快，用户也很满意。”
“我们的开发者工作效率高，我们的应用很快，用户也很满意。”
马克·斯图尔特 网络平台高级经理
这种方法的优点在于，它允许 PayPal 以敏捷的方式过渡到 GraphQL - 随着时间的推移添加服务、维护独立服务所有权，并允许产品团队在准备就绪时使用图表。结果比预期要好。仅在一年之前，PayPal 在少数产品上验证了该方法。现在，他们的图表支持超过 50 种业务产品。
管理图表
由于 PayPal 扩展了图表的使用 - 不仅支持更多产品，而且还与内部系统和流程（例如认证和授权）集成 - 该团队很快意识到他们需要一个团队和适当的工具来管理图表。
斯图尔特的团队成为了图表的内部倡导者，在内部宣扬图表并推出基础设施，帮助团队在图表上进行协作并保持其安全。
该团队认识到，自己构建所有内容将非常昂贵，并会抑制整个组织中平台的增长。
相反，贝宝开始使用 Apollo Graph 平台，该平台提供了一个用于管理其图表的完整系统。特别是 Apollo 的 Graph Manager 提供了他们不必自行构建的核心服务。据 Stuart 称，“Graph Manager 能为我们提供针对字段级别的深度见解、防止重大更改、白名单查询的信心，并通过为每个字段提供缩进和内联 SLA 时序来简化客户端集成。”
“Graph Manager 能为我们提供针对字段级别的深度见解、防止重大更改、白名单查询的信心，并通过为每个字段提供缩进和内联 SLA 时序来简化客户端集成。”
Mark Stuart
Stuart 解释说：“我们可以自行构建这些能力，但它们不会那么完善。中型团队需要一年或更长时间才能构建出同等产品。在构建与购买的决策中，Apollo 平台显然是购买。我们更希望现在而非将来向我们的开发者兑现 GraphQL 的诺言。”
贝宝工程没有回头路。Stuart 说：“GraphQL 正在席卷贝宝。”
您可以在 Stuart 最新的博客文章中阅读有关贝宝经验和具体建议的完整撰写。
下一篇故事
分享文章
