“节省了四周的工程。”

“淘汰了7,500行客户端代码和测试。”

“线上数据减少16倍。”

“更快的移动版本。”

这些是Nike团队使用了GraphQL以后出现的一些令人兴奋的成就。GraphQL于2015年正式发布，是一个开源规范，为前端Web和移动体验提供了一种更高效，更强大，更灵活的REST替代方案。GraphQL为客户团队提供了两种范式转换。

首先，它支持客户端 - 服务器REST模型的翻转。客户团队不是在程序上拼凑出大量的端点和模式本身，而是简单地在声明性查询中跨服务定义他们的确切数据模式需求。这减少了领域模型学习曲线，昂贵的客户端 - 服务器网络请求的数量以及数据的过量和不足。

其次，GraphQL的声明性接口以及我们不断增长的API图表促进了客户端的可重用性。利用相同的共享解析器和API模式的团队不再需要实现自己的聚合层，从而大大加快了产品上市时间。这几乎消除了自定义的一次性聚合代码，否则需要由每个客户端平台和体验团队进行冗余开发，测试和维护。

耐克不断创新和探索GraphQL，专门的GraphQL团队被称为“盛大”的跨组织工作组，目标在耐克的数百个微服务API之上提供一套通用的无状态聚合网关。此外目标是：

• 通过减少网络呼叫和数据编排，缩小客户端，缩短产品上市时间; 不再需要构建和支持一次性聚合层的开销
• 通过可重用的GraphQL架构和解析器提供共享功能
• 通过减少客户端应用程序所需的网络调用次数来提高客户端性能

Nike通过GraphQL创新的团队包括Checkout，Cart，Wishlist，Nike App，CMS，Nike By You（NikeID），仅举几例。以下是团队使用开源API查询语言的经验的简要说明。

Nike.com Checkout

Checkout团队于2017年底开始了他们的GraphQL之旅，为消费者提供最佳的Nike.com云结账体验。团队需要在众多微服务中聚合数据。早期的GraphQL概念证明很快证明了他们希望的价值。

当Nike.com购物车和收藏单也需要聚合时，很明显是时候将GraphQL POC发展成一个可以重复使用的通用无状态网关。而不是为每个功能单独开发和维护自定义各自一套GraphQL实现。

GraphQL工作组和Checkout团队开始合作，提供一组水平可伸缩的无状态GraphQL聚合网关。一旦Nike微服务被一个团队整合，它就成为Nike更大图表的一部分，可以被所有耐克的网络和移动体验重复使用。

使用相同的底层模式后，Cart和Checkout团队能够通过Web存储共享数据，以允许用户在Web应用程序之间导航时跳过冗余的API调用。这大大提升了用户的性能。

这项初步工作为生产GraphQL网关奠定了基础，该网关在2018年末被几个额外的云体验所利用。

GraphQL网关提供了许多好处，包括：

• 可重用性：GraphQL API集成不是为每种新功能体验构建自定义的一次性聚合层，而是跨经验重用。这大大加快了上市时间，更快地为消费者服务。
• 体验优先的API：Checkout团队能够以声明方式定义他们在微服务中所需的精确数据。这可以提高客户端性能，因为客户端和服务器之间传输的数据更少，往返次数更少
• 更轻松的客户：随着越来越多的服务变为无状态，客户变得更有条理。这导致更厚的客户端将更多代码推送到前端。GraphQL简化了Checkout的前端状态管理，加速了他们的团队并使连续更新变得更加容易。
• 可观察性：计划的GraphQL工具允许一定程度的深入分析和可视化。团队可以轻松地观察底层服务如何执行到客户端请求的各个数据字段。服务团队也将更清楚地了解如何以及谁在呼叫他们。
• 自动化：开源社区工具允许基于GraphQL模式自动生成模拟和测试。该计划还将从我们的微服务OpenAPI 3 Swagger文档中自动生成GraphQL架构。（机器人来了！）

耐克APP

Nike App团队利用相同的共享解决方案快速集成下游API，Nike App及其本地化产品推荐的目标是根据消费者的实时位置附近提供个性化的上下文建议。

网络调用特别昂贵，并且移动应用程序的电池寿命也在不断消耗。最佳做法是减少API调用的数量，以尽可能少的网络请求提供所需的用户体验。在微服务领域，这是一个挑战。

解决方案是使用GraphQL聚合网关为Nike App提供单次网络调用，跨三个嵌套微服务检索数据，并为重用使用此无状态网关的其他团队提供的API集成。

这对Nike App来说是三赢：

1. 代码缩减：单个GraphQL API调用减少了在许多微服务中编排调用所需的数百行客户端代码。
2. 可重用性和一致性：iOS和Android Nike应用程序都能够重用相同的网关进行数据聚合。
3. 性能提升：降低了昂贵的客户端网络请求。此外，GraphQL通过定制对其移动体验要求的响应来消除数据的过度获取。Nike App将其有效载荷从500KB减少到11KB！

CMS

CMS团队在将他们的平台从Aurelia迁移到React（另一个流行的Facebook OSS库）时开始使用GraphQL 。由于Nike的微服务架构，之前平台的一个难点是需要多个API调用。该团队知道聚合层可以减少网络呼叫并大大简化前端开发过程。当他们决定迁移到React时，他们也将GraphQL实现为他们的聚合层。

如今，CMS团队使用GraphQL汇集了超过17种微服务，以提供优质的内容创作体验。以前，在具有较少服务的单一体系结构中，CMS团队将管理前端多个API调用的异步性质，调用每个服务并一次处理响应，因为它们在承诺链中解析。使用GraphQL，CMS前端只需要发出一个请求来检索针对前端体验优化的数据模型。

Nike定制团队

Nike的定制团队于2017年开始了他们的GraphQL之旅，以简化定制实验室（一个内部运营Web应用程序）与复杂的后端微服务网络进行通信的方式。

与CMS团队类似，NikeID团队采用GraphQL重构前架构。从包含许多由数百行异步数据编排组成的模块的大型Redux存储转换为基于查询的声明式模型。使用Apollo Client，NikeID团队将GraphQL查询映射到各自的前端组件，并仅在需要时获取数据。

在服务器上，将数十个REST端点组合成一组干净的GraphQL查询和解析器，与过去经常设计的自定义聚合服务相比，感觉自然而直观。过去的自己单独定义的聚合层在它们被部署之前基本上是技术债务，很快成为维护的噩梦。下游服务合同将发生变化，将出现新的业务需求，并且维持它们的带宽有限。借助GraphQL，该团队拥有灵活，可重复使用的界面，可满足他们的数据需求。

耐克 Order Futures Buy，GameDay和API +

发现并确定了这个产品线的数据管理方式中反复出现的问题。多年来，这些团队创建了自己的缓存产品数据数据库。他们一次又一次地遇到数据不一致，导致消费者的负面影响。

团队一致决定使用GraphQL，使用单一，灵活的产品API。

在为GraphQL框架创建了大量概念证明之后，包括Spring Boot / Java实现和Scala / Akka实现，团队开始使用前面团队使用的相同NodeJS Apollo Server实现。由于聚合微服务经常会为客户端引入I / O问题，因为它们必须异步调用许多API，因此NodeJS和JavaScript成为他们的明智选择。

该团队使用GraphQL提供更好的用户体验。GraphQL允许它们通过精确指定所需的数据模式来返回较小的有效负载。他们的UI不再需要维护一组API来获取各种数据点。他们的GraphQL实现聚合了五个REST微服务：他们的图像库服务，复制服务，产品属性服务，视频库和技术表服务。该团队对其第四季度发布感到兴奋，并正在扩展以满足各个团队的需求。

结论

在耐克，我们痴迷于优化消费者之旅 - 旨在为我们的数字生态系统提供优质体验。我们不断评估可能改善这些体验的新技术。随着软件行业每天都在生产新技术，重要的是要仔细权衡任何新技术的优势和采用成本。GraphQL被证明是耐克和我们的消费者的赢家。

跨组织工作组继续使用Nike API的共享图表来促进跨体验的可重用性。随着域微服务API的集成，任何经验都可以毫不费力地检索数据，而无需任何额外的自定义聚合代码。随着耐克的团队继续探索利用GraphQL重新定义全球范围内的耐克购物体验，请继续关注。

作者：JDON

原文：https://www.jdon.com/51167