作为全球旅游平台，Expedia 集团管理着超过 200 个预订网站和包括 Brand Expedia、Orbitz、Travelocity、Vrbo、Hotels.com 和 Egencia 在内的 25 个品牌上的客户体验。不断提高这些体验需要数千名开发人员和数十个后端服务团队的创造力和精心编排。由于如今的旅客在规划、购物和旅行时越来越多地使用多个接触点，因此，确保在不断增长的团队、地理位置和能力中提供无缝衔接的体验对 Expedia 集团而言构成了一个真正的挑战。
Expedia 集团杰出产品经理 Dan Boerner 表示：“正如您对我们历史和规模的公司所期望的那样，我们运营着多个技术堆栈，其中大部分是在内部构建的，一些是在收购过程中增加的，还有一些可以追溯到互联网时代。”“随着时间的推移，这种架构复杂性开始渗入客户体验，团队发现自己需要在各个平台上重复工作，并管理不断发展的服务 API，而不是为我们的客户创建下一代旅行解决方案。”
必须采取一些措施。因此，Brand Expedia 内部的一个团队着手将雄心勃勃的愿景与敏捷的方法相结合，以彻底改变他们构建和提供客户体验的方式。
在摆脱与 REST API 紧密绑定的重型客户端的同时采用通用图形界面已经发生了巨大改变。功能的推出速度更快，而且在各个客户端平台提供出色的客户体验所需的工作量也大大减少。
一个大型而复杂平台的挑战
在过去十年中，品牌 Expedia 集团为其本机和网络客户端构建了一组广泛的传统 REST 服务。在此模型中，每个客户端前端都直接连接到大量底层服务。
虽然此方法奏效，但它降低了客户端团队的工作效率，因为每个团队都必须了解每个 API、进行预置，然后配置特定端点。由于这些 API 不断演进、改进并迁移到云端，因此客户端和服务团队需要花费越来越多的时间才能共同取得进展。
原生移动客户端的兴起增加了更多复杂性。专门针对移动设备的 API 被创建出来，以服务于那些移动应用程序，但这要求在每次向核心服务添加新功能时添加额外步骤。结果，原生应用程序最终会等待访问最新功能，并且客户体验开始在客户端之间出现分歧。此外，由于服务 API 未设计为传递显示就绪的内容，因此每个客户端平台都必须重复核心业务逻辑。该逻辑中的细微差异以及特定于客户端的实验都导致客户体验分歧和工作重复。
BEFORE ADOPTING A GRAPH: CLIENT AND SERVICE COMPLEXITY
正如 Boerner 所解释的那样，“移动应用程序团队的大部分工作与为客户创造体验无关，因为他们一直在想出要调用哪个 API、预置这些 API 以及处理版本和端点更改。所有这些干扰都需要额外的资源，并减慢了我们的功能交付。”
尽管投入了专门资源，但基本问题仍然存在，并持续影响客户体验。Boerner 补充说：“客户端服务复杂性已成为真正的瓶颈”。“要求一个原生应用程序团队跟踪几十个服务团队，以便他们能升级生产问题，已成为真正的挫折源，并真的会分散一个专注于创造卓越客户体验的团队的注意力。”
“移动应用程序团队的大部分工作与为客户创造体验无关，因为他们一直在想出要调用哪个 API、预置这些 API 以及处理版本和端点更改。”
Dan Boerner Expedia 集团杰出产品经理
后端到前端的试验
当品牌 Expedia 集团为 Expedia，Travelocity 和 Orbitz 品牌构建了他们的第一个渐进式网络应用程序 (PWA) 时，他们遵循了后端到前端 (BFF) 的模式。一般方法产生了希望：让 BFF 直接与服务对话，并向前端提供一个干净、非特定于服务的 API。在该模式中，客户不再需要包括业务和编排逻辑，并且可以享用专门为他们构建的 API。它最初运作良好，但团队很快了解到 BFF 只是未设计为可扩展的。由于 BFF 专门针对单个客户端（在此情况下是网络），使其随处可用，Expedia 集团必须为每个客户端平台编写一个 BFF，并且在每个平台中包含重复的逻辑和自定义的代码。
EXPERIMENTING WITH BFF FOR A PROGRESSIVE WEB APP
如 Boerner 所解释的，“当我们的原生应用程序团队尝试用他们自己的 BFF 替换遗留的移动 API 时，他们发现很难跟上在 Web BFF 中进行的所有测试和学习试验。最终，我们决定为每个客户端和域创建自定义的前端服务会太耗费时间。”
那是团队开始使用 GraphQL 和 Apollo 探索图方法的时候。
转向一个图
凭借他们在 BFF 方面的经验，以及将剩余的网站页面移至新 PWA 平台以及在所有客户端平台之间统一功能和体验的双重目标，团队开始探索使用 GraphQL 将整个组织的应用程序数据和服务连接成一个中心图。他们的目标：一个图，所有团队都能够理解和发现，旨在打造一套新的、连贯的客户体验。
客户连接到多个服务只需要一个接入点，因此客户团队无需直接连接到多个服务或管理多个扩展团队之间的通信。与此同时，服务所有者可以通过客户使用简单查询检索所需数据的特定部分的架构轻松公开其数据。
AFTER ADOPTING A GRAPH: A FEDERATED SERVICES ARCHITECTURE TO SCALE
Expedia Group 将此努力转化为一项正式举措，该举措现已成为其全新且现代的应用程序开发堆栈的基础，并支持其为所有客户平台创造无缝客户体验的策略。
Boerner 说道：“当你的客户端代码无需得知提供数据的底层服务时，就会对客户团队和服务团队产生各种好处。”“客户团队无需再管理复杂性，服务团队只需要维护一个合同，这便能让他们更快地发展其后端，且风险更低。”
尽管团队获得了广泛的授权，但从一开始他们就明白需要采用迭代方式来构建和运营这个单一图谱。它需要具有单一图谱的所有好处，但无需单一的中央团队管理这样庞大的架构。因此，Brand Expedia Group 与 principledgraphql.com 中所述的“单一图谱、联合实施”架构保持一致，着手分配图谱的所有权。
“Apollo Federation 将允许我们以更安全、更声明式的方式实施现有架构链接，同时为整个企业带来全新层面的更广泛的联合机会”。
Dan Boerner
该团队做出的第一个努力是开发一个利用 Apollo Server 的架构拼接器，称为 Loom”，它与他们的开源graphql-kotlin一起为每个域架构拼接 GraphQL 服务，构成一个单一图谱。Loom 还允许常见架构对象（如地理）之间进行简单的架构链接。虽然这个最初的拼接实施有效，但架构链接需要为每个链接制定自定义代码。当 Apollo 宣布推出 Apollo Federation（一种将多个 GraphQL 服务组合成单一图谱的新架构）时，该团队立即产生了兴趣。
Boerner 解释道：“Apollo Federation 将允许我们以更安全、更声明式的方式实施现有架构链接，同时为整个企业带来全新层面的更广泛的联合机会。”
迁移至 Apollo 图谱管理
大规模方面，该团队了解到，在团队内跨团队扩展图需要强大的管理能力，以提升开发体验并保护该图。
Boerner 说：“随着我们最初的 GraphQL 推出开始显现希望，这一技术方法的强大之处也变得明晰起来。我们同样清晰地认识到，我们将所有强大的监视、管理和运营能力构建到平台中，以便支持数十个团队和数百名开发人员，这是一个刚需。”“当我们了解到 Apollo 的数据图平台和 Apollo 图管理器时，这对我们来说就成了一个经典的构建与购买决策。Apollo 为我们提供了我们所没有的工具，同时让我们能够与我们的现有运营基础设施集成起来。”
对于 Expedia Group 来说，借助 Apollo 的工具和技术，团队可以摆脱其他优先事项的束缚。正如 Boerner 所说：“如果我们的小型平台团队必须构建我们从 Apollo 平台上使用的所有技术，那么我们就几乎没有时间来帮助新团队进行入职培训、宣扬我们的设计原则，或者最终解决客户问题。”
“我们的新 PWA 客户端只有我们较早前的客户端商业逻辑的一小部分，因为我们已经将其转移到所有客户端共享的图后方……”
Dan Boerner
Apollo 为 Expedia Group 提供了一套完整的图管理解决方案，让他们能够大规模监视、检测和预防模式中断，以及对该图进行运营。它还通过在团队之间共享管理和可移植代码、查询和修复来实现统一图。
自采用 Apollo 以来，代码复杂性已经大幅度降低。“我们的新 PWA 客户端只有我们较早前的客户端商业逻辑的一小部分，因为我们已经将其转移到所有客户端共享的图后方，”Boerner 说。“这也意味着，在共享层中进行修复，所有客户端都将选择这些修复，因此，在减少技术债务并实现我们的使命，为客户创造无缝体验方面，无论采用哪种客户端平台，这都是一个巨大的胜利。
开发人员体验和工作效率得到提升
几乎就在采用 Apollo 平台之后，Expedia Group 目睹了与单个图和 GraphQL 合作的开发人员的速度和效率提升。Expedia Group 原生应用程序 iOS 团队的首席开发人员 Ben Munge 看到了 Apollo 平台如何让开发人员通过他们已经在使用的工具来串连图。
他说：“Apollo 工具能减少开发工作量，确保服务代码始终如实反映模式，因此对我们来说是极佳的选择。”“与手动实现该集成相比，使用生成的代码大幅减少了错误数量，最大程度地减少了开发和测试工作量。我们使用 Apollo GraphQL 插件在 Xcode 中开发查询。我们还利用 GraphQL Playgrounds 来探索模式并开发查询。一旦设置好查询，我们就会使用 Apollo iOS 工具更新我们的模式并重新生成 API。”
Munge 还使用该平台来跟踪问题并监控故障调试期间服务的状态。他补充说：“Apollo 平台有许多优点。”“速度就是其中之一。通过与 Apollo 合作，我们能够大幅缩短创建全新体验以及解决根本原因时间和修复实时问题所需的时间。”
保持图表健康高效
Expedia Group 认识到图表是一个理想的中心位置，用以跨产品团队协作，因此，他们采取了至关重要的一步，成立了一个新团队，来创建和管理他们不断壮大的图表社区。这成为了其敏捷 API 战略的重要部分。
在整个组织内，使用 Apollo 的图表平台，开发人员可以监控图表的健康状态并发现后端服务的使用方式。
伯纳说：“我们可以从 Apollo 中获取图表指标，并将其插入到我们的运营架构、Grafana、Splunk 等中。”“但这些工具设计用于通用目的，我们发现 Apollo 的控制面板提供了一种更好的 360 度 GraphQL 原生视图，包括客户端、操作、模式更改和故障，以便我们的开发人员可以更清晰地了解我们的图表执行情况。我们还看到，在服务中断期间确定根本原因的时间有所缩短，因为 Apollo Graph Manager 让我们能够快速准确地看到受到影响的客户端和查询。”
对管理对底层服务和模式的更改也非常重要，以防止某个团队的任何个别更改中断现有查询或客户体验。
“公关提交中的模式验证改变了游戏规则。我们已经检测到并阻止了许多模式更改，这些更改会导致我们原生应用客户长达一周的服务中断。”
Dan Boerner
“由于客户运行着各种应用程序版本，我们必须确保即使是较旧的客户端仍与我们的图兼容，”伯纳说。“为了保护这些客户端，我们使用 Apollo 的 Github 集成与模式验证相结合，通过验证上周客户端请求的所有模式更改来确保始终向后兼容”。
在过去，团队会代表 web 客户端进行 API 更改，并无意中破坏原生应用程序。正如伯纳所解释的那样，“在 PR 中进行模式验证是一个改变游戏规则的因素。我们已经检测并阻止了许多模式更改，这些更改本来会导致我们的原生应用程序客户的服务中断长达一周。我们对模式验证进行了损失减少建模，并惊讶于这项技术可以如此迅速地自行创造收益。”
正是这些类型的中央操作确保了数据图即使在不断发展的情况下也能成为可靠的资源。
接下来是什么
“GraphQL 正在成为我们所有面向客户的应用程序的标准前端 API，并且团队正在致力于利用 GraphQL 的外部合作伙伴 API，因为我们努力利用创建一致性和简洁性的技术”。
如今，Expedia 集团正在扩大在更多团队中使用该图，这对组织中的每个人来说都是一个很好的机会，可以从真正统一的客户体验的角度来思考。
伯纳说：“随着我们努力在 Expedia 集团中利用和分享更多功能，GraphQL和联合是战略上重要的工具。”
GraphQL 也为跨不同产品类型的对齐创造了机会。高级 iOS 软件工程师本·蒙格说：“在所有业务线中，我们都在确定允许用户执行搜索、浏览和过滤结果、查看详细信息和进行购买的通用功能”。“服务架构需要考虑到这种统一的体验来设计。为什么响应结构会根据我们销售的产品而有所不同？想象一下，如果亚马逊为家居用品、电子产品和书籍提供单独的服务。”
“我们很高兴有机会用我们的统一设计系统连接我们的数据图”。
泰勒·弗莱克Expedia 集团用户体验总监
展望未来，核心团队正在探索先进功能，例如服务器驱动型用户界面，它能根据机器学习模型动态调整所有客户端的用户体验，该功能由一项图谱技术提供支持。
用户体验总监 Tyler Fleck 表示：“我们很高兴有将我们的图谱与我们的统一设计系统连接起来，从而为一系列更具可扩展性的用户体验提供支持的机会，这些体验允许进行服务器端实验。”“无需对任何特定客户端进行更改就能在所有客户端上尝试新想法，这可以加速设计和学习过程，并最终带来更好的客户体验和成果。”
一开始，这是一个自下而上的项目，由一个专注于构建可证明其概念的多租户图谱的小团队负责，随着公司各团队展示出 GraphQL 和 Apollo 平台的价值，该项目开始有意、有机地发展。Expedia Group 目前专注于依托移动网络、iOS 和 Android 的采用热潮构建;引入服务团队来将他们的能力发布到图谱上;并且在公司和客户体验中展示价值。“GraphQL 帮助我们让世界触手可及，让数百万旅行者都有机会踏上旅途，”Boerner 说道。我们相信，对于这项转型将为我们的客户解锁的机会来说，我们还只是触及了皮毛。
下一篇故事
分享文章
