GraphQL:PayPal结账的成功案例

18-10-17 banq
                   

在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产品。如果你在美国,那么你很有可能使用我们的新产品。它快得多。

PayPal也正在风暴使用GraphQL。一年后,我们有超过30个应用程序/团队构建API或使用API​​。这不是所有的阳光和彩虹。我们在一路上犯了一些值得分享的错误。

 

                   

2