GraphQL：PayPal结账的成功案例 18-10-17 banq

zehuawong

2018-10-18

关注关注

在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"]
}