GraphQL：PayPal结账的成功案例

在PayPal，我们最近将 GraphQL 引入了我们的技术堆栈。如果您还没有听说过 GraphQL ，它是REST API的一种广受欢迎的替代方案，目前正在风靡开发人员世界！

在PayPal，GraphQL对我们思考数据，获取数据和构建应用程序的方式进行了彻底的改变。

这篇博文简要介绍了 PayPal Checkout， 并解释了我们从REST到Batch REST到GraphQL的历程，以及沿途的经验教训。

PayPal的Checkout产品分布在许多网络和移动应用程序中，支持约200个国家/地区的数百万用户，并且可以随时运行数百个实验。这些应用程序利用相同的REST API套件来获取构建UI所需的数据。

大约4年前，我们就都在REST。我们的API很干净，小而且原子。一开始事情很棒。REST具有广泛理解的严格设计原则。REST是为领域设计和实现API的好方法。

但是，REST的原则并未考虑Web和移动应用及其用户的需求。在像Checkout这样的优化交易中尤其如此。用户希望尽快完成结账。如果您的应用程序正在使用原子REST API，那么您经常会从客户端到服务器进行多次往返以获取数据。通过Checkout，我们发现每次往返的网络时间（第99百分位数）至少需要700毫秒，不包括在服务器上处理请求的时间。每次往返都会导致渲染时间变慢，用户受挫更多，Checkout转换率也会降低。不用说，往返是邪恶的！

当然，您可以构建一个业务流程API来返回您需要的所有数据，但这需要权衡利弊。你叫什么名字？GET /login？现在这看起来像一个JSON API，而不是REST API。使用编排API，您的客户端将耦合到您的服务器。每次添加新功能或实验时，都会将其添加到API中。这有问题。

当新的需求出现时，开发人员面临一个选择：我们应该创建一个新的端点并让我们的客户再次请求该数据吗？或者我们应该用更多数据重载现有端点？

开发人员通常会选择第二个选项，因为它更容易添加另一个字段并阻止客户端到服务器的往返。随着时间的推移，这会导致您的API变得沉重，笨拙，并且不仅仅会承担一项责任。

开始时，我们的API返回了用户信息，送货地址和资金选项。构建Checkout应用程序所需的一切。随着时间的推移，用例堆积起来。即使他们不需要，每个用户也要支付这些字段的费用。

编排API(将很多字段功能塞入API称为编排)起初看起来很棒，但我们总是后悔。

Batch REST

REST不适用于我们，所以我们构建了一个Batch REST API来解决其中的一些问题。它是一个动态编排API，允许客户端确定响应的大小和形状。Batch允许我们组合原子REST请求并减少往返。

以下是批处理请求和响应的示例。该请求包含REST操作的映射，您可以在其中指定动词，端点，参数和它们之间的依赖关系。

{
"user": {
"method": "get",
"urt": "/apt/user"
},
"createCheckout": {
"method": "post",
"urt": "/api/checkout/EC-1234",
"params": {"total": "10.00", "currencyCode": "USD"}
},
"getCheckout": {
"method": "get",
"urt": "/apt/checkout/EC-1234",
"dependencies": ["createCheckout"]
}

使用Batch，我们喜欢客户端控制数据的大小和形状，而不是服务器。这使我们无需在每次客户端的要求发生变化时调整编排API。我们不喜欢客户必须非常了解底层API的工作原理。请求结构痛苦得足以让开发人员不使用它。我们还希望能够获取特定字段，而不是大型资源或对象。许多拥有批量产品的公司（如Facebook和Google）都存在同样的问题。它被视为一种优化但不是获取数据的正规的首要方法。

批处理REST是朝着正确方向迈出的一步，但不是游戏规则改变者。

GraphQL 去年，我们的经理（ Brian Crescimanno ）向我们提出了两个问题：

摘录

“2018年构建应用程序的最佳方法是什么？”

我们知道性能是一个问题。我们觉得我们没有像我们想要的那样富有成效。我们知道我们没有花足够的时间来构建出色的UI体验。

当我们仔细观察时，我们发现UI开发人员花费的时间不到实际构建UI的1/3。剩下的时间用于确定在何处以及如何获取数据，过滤/映射数据以及编排许多API调用。撒上一些构建/部署开销。

那时，我们开始越来越多地了解GraphQL。我们花了一周的时间仔细研究GraphQL并给我们留下了深刻的印象。幸运的是，我们推出了一款新产品，为想要将PayPal Checkout集成到他们的应用程序中的开发人员提供Mobile SDK。我们有6个星期发货，3个开发商用它来构建它。

“让我们使用GraphQL！” - 有人

随着团队构建UI，我们正在并行构建API。尽管API尚未准备好供他们使用，但我们 仍然 提前完成功能/代码，几乎不需要PayPal专业知识。开发人员不必发现要调用的内部API，如何调用它并将数据转换为可以使用的内容。他们检查了我们的模式以找出可能的内容，为他们需要的东西写了一个GraphQL查询（JSON，没有双引号），并继续在UI上进行迭代。

我们意识到我们正在做点什么。我们的开发人员很有效率，我们的应用程序很快，我们的用户很高兴  我们全力投入GraphQL。

我们有一些很大的开发人员经验和性能问题。GraphQL解决了这个问题以及更多问题。

性能  -   您只能获得所要求的数据。不多也不少。 单程往返。您也可以查询突变的一部分！

灵活性 -  客户确定数据的 大小 和 形状 ，而不是服务器。

开发人员的生产力 -  立即 富有成效 ，没有部落知识。 如果你了解JSON，你就知道GraphQL。 令人难以置信的工具！

演进 - 使用GraphQL，API开发人员 确切地 知道客户正在使用哪些 字段， 并且在弃用或开发其API时能够做出更好的选择。使用REST，这是不可能的，因此您可以扩展并永不删除。

只是开始

Mobile SDK只是一个开始。我们现在在GraphQL和React之上重新推出我们的旗舰PayPal Checkout产品。如果你在美国，那么你很有可能使用我们的新产品。它 要 快得多。