GraphQL的作用与影响

作者：Rajesh Narayanan

审核及贡献者：OCTO团队及其他人员。

F5首席技术官办公室观点

GraphQL已成为一种现代、高效的API开发方法，突破了传统REST API的局限。尽管REST自Web发展初期便得到广泛应用，但GraphQL为开发者提供了全新的思路和更强的控制能力。借助GraphQL，开发者可以定义强类型架构，使客户端能够准确请求所需数据。GraphQL可避免数据的过度获取和获取不足，从而优化性能，并有助于构建具有复杂数据查询和数据建模需求的现代交互式Web应用。

不过，我们也认识到，采用GraphQL并非没有挑战。本文深入分析了采用GraphQL时面临的安全问题和学习曲线，并探讨了知名企业成功实施GraphQL后获得收益的真实案例。

此外，我们还介绍了对GraphQL的研究，并分享相关经验和发现。我们简要介绍GraphQL，将其与REST进行比较，并深入探讨它所解决的挑战。我们还讨论了安全注意事项，帮助组织做出明智决策。研究结果表明，GraphQL具有推动变革的潜力。我们展示了如何简化测试管理套件的软件架构，使通过GraphQL公开的JSON对象内隐藏数据量增长超过300%。

总之，我们强烈建议在扩展、优化或运营REST API基础设施方面面临挑战的企业，将GraphQL视为一种可行的解决方案。我们的见解可为着手采用GraphQL的企业提供实用指导，帮助其充分发挥GraphQL的优势并有效应对挑战。

GraphQL 入门

为什么选择GraphQL？

REST API的局限性正推动市场对新型API技术方案的需求。

基于REST（表述性状态转移）的方法最初作为一套用于设计Web API的架构原则提出。随着Web 2.0的兴起，REST在21世纪头20年不断发展，相较于通用对象请求代理架构（CORBA）等其他技术，成为实现面向服务的架构（SOA）的一种更优方式。

随着移动设备的普及，客户端数量不断增加，对精准数据的需求也随之增长。然而，基于REST的API往往会导致数据获取过多或不足，造成效率低下。以Facebook等应用为例，这种方式通常需要多次调用REST API才能完成一次更新，不仅增加了网络流量，还会影响性能和用户体验。

GraphQL专为解决这些局限而设计，它提供强类型架构和更高效的数据查询方式。因此，GraphQL非常适合需要获取特定数据以优化网络带宽的用例。此外，GraphQL的架构内省能力有助于改进文档和工具。虽然更加标准化的REST实现或许也具备一定竞争力，但GraphQL凭借其独特的功能和优势，成为分布式、数据密集型现代应用架构中颇具吸引力的选择。

图1展示了REST与GraphQL在实现方式上的拓扑差异。正如REST API与GraphQL对比中所述：“GraphQL与REST API的主要区别在于，GraphQL是一种查询语言，而REST是一种面向网络软件的架构概念。”

图1：REST与GraphQL。改编自《Rest API vs. GraphQL》

META采用GraphQL的动因

Meta于2012年创建了GraphQL（开源于2015年），旨在提升其移动应用的性能和灵活性。在采用GraphQL之前，Meta的移动应用结合使用RESTful API和原生代码构建，因此难以适配应用需要支持的各种设备、屏幕尺寸和网络条件。 

他们面临的主要挑战之一是，RESTful API经常返回数据量不当，有时过多，有时又过少。当API返回大量移动应用不需要的数据时，会导致加载缓慢和性能下降。当API返回的数据过少时，移动应用需要向不同端点发出多次请求，才能获取所需的全部数据，从而增加了延迟和流程复杂性。

Meta开发了GraphQL，使任何应用都能通过单次请求仅获取所需数据。这有助于优化移动应用与后端服务之间的数据传输，从而缩短加载时间并提升性能。此外，GraphQL的强类型和自文档化特性让开发者更容易理解和使用API。

GRAPHQL 的优势

GraphQL提供强大的数据检索和操作能力，与传统API方法相比具有显著优势。

强类型架构

GraphQL采用强类型架构，可确保清晰、准确地定义可从API查询的数据结构和类型。假设有一个图书馆API，其中包含图书、作者和出版商。

a) GraphQL架构：在GraphQL中，强类型架构如下图2所示：

图2：GraphQL架构示例

GraphQL中的强类型架构可实现输入验证，防止数据过度获取或获取不足，提供清晰的文档和工具支持，便于版本控制，并有助于实施授权和访问控制，从而带来安全方面的优势。这些功能可降低常见漏洞的风险，并确保妥善处理数据和管理访问权限，从而增强API安全性。

在所示示例（图2）中，该模式定义了图书、作者和出版商的数据类型及其相互关系。该模式为强类型，这意味着每个字段都有特定的数据类型，客户端可以轻松内省该模式，以了解可用字段及其类型。

b）REST模式：在REST中，模式定义采用松散类型，如下方图3所示：

图3：REST架构示例

这些端点返回表示图书、作者和出版商的JSON对象，但并未明确定义架构本身，而是由程序员根据自身能力进行解读。客户端必须依靠文档来了解数据结构。

超越REST

GraphQL的发展已不再局限于作为REST的更优替代方案。对于希望优化数据策略的企业而言，GraphQL有望成为优先考虑的方法。除了克服REST的局限性外，还有其他多种因素推动GraphQL发展成为一种新的API设计方法。虽然表格（图4）展示了GraphQL相较于REST的优势，但更恰当的理解是，GraphQL是为适应互联网和各类应用的发展而产生的，而非仅仅为解决REST本身的问题。

图4：GraphQL相较于REST的优势

GRAPHQL面临的挑战

虽然与传统RESTful API相比，GraphQL具有诸多优势，但在使用过程中也面临一些挑战。常见挑战包括：

1. 学习曲线：由于大多数开发人员更熟悉REST，计划采用GraphQL的组织需要为团队预留时间，以便他们学习如何有效使用GraphQL。GraphQL要求以不同的思维方式构建和使用API，采用GraphQL可能需要调整底层应用架构。开发人员可能需要学习架构、解析器和类型等新概念，以及新的工具和库。使用GraphQL时，客户端对可访问的数据拥有更大的控制权，这可能会增加API安全防护的难度。输入验证、身份验证和授权等技术的应用方式可能需要与RESTful API有所不同。
2. 缓存：使用GraphQL时，缓存可能更为复杂，因为客户端每次查询都可以请求不同的数据，因此更难缓存和复用响应。
3. 性能：虽然GraphQL允许客户端仅请求所需数据，但也可能产生更复杂、资源消耗更高的查询。GraphQL API可能会出现性能问题，尤其是在查询大型数据集或并发请求数量较多时。开发人员需要采取限制查询深度等策略，或确保客户端仅获授权访问所需的特定数据。
4. 错误处理：GraphQL可能会增加错误处理的复杂性，因为错误可能作为响应的一部分返回，而不是通过单独的HTTP状态码返回。
5. 测试：使用GraphQL进行测试面临多项挑战，包括查询复杂、缺乏标准化测试方法、模式演进，以及运行时查询验证。开发人员需要投入时间寻找合适的测试框架和工具来应对这些挑战。开发人员需要选择适当的工具并考虑模式演进，以确保全面的测试覆盖率，从而有效测试GraphQL API，确保其功能正常且稳定。
6. 监控：由于查询复杂、缺乏标准化的日志记录和指标，并且可能出现性能问题，监控GraphQL API可能颇具挑战。GraphQL查询具有动态特性，因此更难预测和监控所请求数据的结构和大小。由于缺少专用于GraphQL API的标准化监控工具，很难深入了解GraphQL查询性能、错误跟踪和API运行状况。开发人员需要采用能够应对GraphQL独特特性的专用监控工具和实践，以确保高效的性能和可靠的运行。

GraphQL使用模式

GraphQL是一款功能强大的工具，应用范围广泛，既可用于构建API，也可为移动应用提供支持。凭借灵活性和统一数据源的能力，它非常适合多种使用模式。

1. 构建高效的API：GraphQL的主要用途之一是构建可供Web和移动应用使用的API。GraphQL提供灵活而强大的数据定义和访问方式，非常适合构建需要支持各种客户端和用例的API。
2. 数据获取与操作：GraphQL可用于从各种来源获取和操作数据，包括数据库、云服务和其他API。GraphQL提供统一的数据访问方式，有助于简化数据驱动型应用的构建和维护流程。
3. 实时用例：GraphQL非常适合实时用例，因为客户端可以订阅特定数据的更新，并在数据发生变化时收到通知。这可用于聊天、直播、实时仪表板等应用。
4. 微服务：GraphQL可用于构建灵活的松耦合架构，使不同微服务能够以一致且明确定义的方式相互通信。
5. 后端到前端：GraphQL可用于构建服务于前端的后端（BFF）架构，使不同的前端客户端能够以一致且高效的方式访问数据和服务。
6. 移动开发：GraphQL可为移动应用提供支持，使其无论使用何种平台或设备，都能以一致且高效的方式访问数据和服务。

行业采用GraphQL的实践经验（案例研究）

以下行业部署案例清楚地说明了采用GraphQL的必要性：

NETFLIX

Netflix于2020年通过一系列分为两部分的博客文章总结了其GraphQL历程。这些文章值得每位GraphQL从业者阅读。其中介绍的案例是Studio Edge系统，该系统将其工作室API重新构建为GraphQL架构。Netflix的Studio API供其内容团队用于管理和监控电视节目和电影的制作、后期制作及发行。该API支持访问海量数据，包括片名元数据、演职人员信息等。

Studio API最初采用传统的RESTful架构构建，其端点以JSON格式返回数据。然而，随着API规模扩大以及访问该API的客户端数量增加，显然需要一种更高效的解决方案。

Netflix开始探索将GraphQL作为Studio API的潜在解决方案。首先，他们为Studio API构建了一个经过精心设计的图。他们发现了几项主要优势，包括减少网络使用量、简化数据访问，以及允许客户端仅请求所需数据，从而提升性能。

Netflix在为Studio API采用GraphQL时也面临一些独特挑战，尤其是在管理架构复杂性，以及确保客户端只能访问其获授权查看的数据方面。

为应对这些挑战，Netflix开发了一套名为“Netflix GraphQL Federation”的定制解决方案。该方案采用Apollo Federation规范，将Studio API架构拆分为更小、更易于管理的部分。Netflix还实施了一套权限和访问控制管理系统，用于限制客户端仅访问架构中的特定部分。

他们还在博客中介绍了其API架构从单体架构演进到联合网关的过程。图5改编自该博客中的图片。

图5：API架构的演进（改编自Netflix）

我们认为，还缺少另一种方法。这种方法可能已在业内广泛采用，但尚未形成正式规范。

可以将图5中的网关聚合层与联合网关结合起来，如下所示：

图6：F5演进后的API架构，包括临时GraphQL网关参与者

每个齿轮图标实质上代表一个临时的联合GraphQL实例（也称为网关执行单元）。该实例可在边缘实时实例化（甚至可按每笔事务实例化），即部署在拓扑上靠近客户端的位置，并通过安全的API传输连接到微服务。这种组合实质上以分布式网关执行单元取代网关聚合层（即联合层），兼具两者的功能优势。我们将其称为“分布式GraphQL网关执行单元架构”，如图7所示。

图7：分布式GraphQL网关执行单元

其他早期采用者

PayPal

PayPal自2018年起便开始采用GraphQL，当时将其引入了Checkout应用。与Meta类似，PayPal对REST的主要顾虑是，其设计原则并未针对Web和移动应用及其用户进行优化。客户端应用需要在客户端与服务器之间进行多次往返通信，获取数据大约需要700 ms。这导致渲染速度变慢、用户体验受挫以及转化率下降。PayPal发现，在Checkout应用的开发过程中，用户界面（UI）开发人员用于构建UI的时间不到三分之一，其余时间都花在研究如何获取和处理数据上。

PayPal工程团队还考虑了编排API和批量REST。构建编排API会导致过度获取数据，并使客户端与服务器耦合。PayPal认为，随着时间推移，这种方法可能会使API变得臃肿、难以维护，并承担多种用途。他们对批量REST的试验也未能成功。虽然这种方法让工程团队不必再调整编排API，但要求客户端深入了解这些API的工作原理。

PayPal首次使用GraphQL构建新产品，是开发一款用于将PayPal Checkout集成到应用中的移动SDK。评估GraphQL不到一周，工程团队便决定将其用于这款新产品。尽管API尚未就绪，他们仍提前完成了产品开发，而且几乎不需要掌握PayPal特有的知识。开发人员得以快速构建高效且易用的应用，这促使工程团队决定在其技术栈中全面采用GraphQL。

星巴克

Starbucks聘请第三方开发其渐进式Web应用（PWA）。

该团队的任务是创建一个能够高效处理复杂业务逻辑的订购系统。由于客户可以个性化定制订单，开发团队必须确保系统能够处理多个独特的业务逻辑实例，并在正确的时间将正确的数据发送到正确的位置。

借助GraphQL，团队构建了高效的API，并通过服务器端缓存和渲染提升离线功能。团队还使用React加入动画效果，打造生动且富有吸引力的用户体验。

F5中的GraphQL

F5首席技术官办公室的目标是了解如何在F5生态系统中使用GraphQL。目前，我们正在通过两个项目探索GraphQL的应用。

改进数据模型和可见性

F5提供的测试管理套件（TMS）支持客户测试自有系统的端点或客户端，并判断其是真人还是机器人。

这是一个内部项目，旨在帮助简化TMS软件的开发和测试流程。主要目标是从现有SQL数据库中提取难以利用的JSON数据，将其转换为图数据，并实现用于查询的GraphQL API。

之所以需要这样做，是因为当前数据库存在一些问题，其中包括将元数据以JSON对象形式存储在表格数据库中所导致的“JSON大对象问题”。解析和处理这些对象本身就成本高昂且效率低下。此外，由于JSON大对象具有图结构特性，其中包含的宝贵数据可进一步改进F5的产品和安全性。通过迁移到有向图数据库，可以利用有向关系高效解析和管理JSON大对象，从而优化数据传输和利用。

图8：F5 TMS GraphQL项目范围

结果令人鼓舞。通过确定TMS关系数据库中哪些表包含JSON二进制大对象，我们发现，迁移到GraphDB并使用GraphQL可以将系统可见性提升数倍。

图9：实施方案选择

图9展示了该项目可能的演进方向或实施方案。每种选择都会产生相应的影响。

选项1对UI的影响最小，因为客户端无需更改。根据具体情况，选项1或选项2所示的混合模式可能效果良好，尤其是在包含JSON对象的列较少时。此外，每个JSON的派生架构也会较小。

但在规划过程中，我们发现JSON对象所需的上下文存储在SQL数据库的其他列中。此外，每个JSON对象中存储的架构也相当庞大，这会增加代码库的维护工作量。因此，经过慎重考虑，我们决定按照选项3所示，重新设计应用架构，以支持GraphQL和Neo4J。

CLOUDGRAPH 集成

CloudGraph是一款免费的开源通用GraphQL API和云安全态势管理（CSPM）工具，适用于AWS、Azure、GCP和Kubernetes（K8s）。该项目旨在使用CloudGraph构建一个“CloudGraph插件”（图10），用于呈现F5 Distributed Cloud（F5XC）数据，从而更清晰地了解通过F5 Distributed Cloud连接的云资源。

我们的目标是与CloudGraph集成，深入了解相关技术，并在未来为F5XC数据构建CloudGraph集成、洞察功能和GraphQL API。

图10：CloudGraph与F5 Distributed Cloud集成

将自定义F5XC提供程序集成到CloudGraph平台并使用平台的关系创建功能后，我们将能更清晰地了解通过F5XC连接的云资源，以及这些资源与其他云中资源的关系。随后，我们可以针对同一租户跨多个云的资源生成复杂查询。这样，我们便能为利益相关方提供全面的F5XC概览，并探索与CloudGraph的进一步集成，以支持更多GraphQL插件，并为与F5及其客户相关的云运营提供自定义洞察。

基于上述举措，我们的初步探索与前文案例研究中所述的经验一致。

GraphQL安全问题

认为GraphQL在安全性方面优于REST的早期观点已被证伪。与其他任何技术一样，如果实施不当，GraphQL也会带来相应风险。需要认识到，GraphQL本身并不比其他技术更安全。正确实施并遵循最佳实践，对于保障GraphQL API的安全至关重要。消除这一误解后，我们可以更客观地认识GraphQL的安全注意事项，并采取适当措施来缓解潜在风险。

内省攻击

GraphQL为开发人员提供了一项名为内省的强大工具，可用于请求获取GraphQL服务所用架构的相关信息。借助此工具，开发人员可以了解服务及其结构。然而，内省也存在风险。在生产环境的GraphQL服务中启用内省后，架构中的敏感信息也可能被访问。这会带来重大风险，因为恶意用户可能利用内省获取敏感数据，并可能造成危害。此外，由于恶意用户可以查看整个架构并确定要执行的查询，因此能够轻易识别可能造成危害的操作。此类泄露可能造成严重后果，具体取决于架构的性质及其包含的数据。

缓解措施：一种缓解内省风险的方法是使用各种框架在生产环境API中禁用内省。禁用内省后，开发者将无法使用其提供的部分便利功能。不过，为了恢复这些功能，开发者可以使用GraphOS等工具注册生产环境API的GraphQL架构，从而保留对该架构及其信息的受控访问权限。

SQL注入

SQL注入是一种广为人知且十分常见的攻击，其风险从数据篡改到彻底删除数据库不等。这种攻击方式较为直接，它利用字符串拼接，使攻击者能够在输入内容中插入可执行代码，从而未经授权访问数据库并进行恶意修改。值得注意的是，这种攻击向量并非仅针对SQL数据库，也可能影响Neo4j等图数据库。Neo4j使用Cypher查询语言，该语言与SQL相似，也继承了SQL的相关漏洞。这类攻击称为Cypher注入。它利用两种查询语言的相似性实施攻击，同时也可以沿用现有解决方案，无需另行开发全新的方案。

缓解措施：应对措施包括清理用户输入以检测并防止漏洞利用，以及使用参数化方法将用户输入与直接创建查询的过程分离。这些措施可有效降低注入攻击的风险。解决GraphQL实现中的这一安全问题至关重要，而目前已有成熟且易于实施的解决方案。

REST代理API攻击

在REST API之上叠加GraphQL API可能会导致服务器端请求伪造（SSRF）漏洞。攻击者可以修改通过GraphQL代理发送到REST API的参数来利用此漏洞。如果两个API都不验证特定调用的参数，攻击者就能控制后端系统。例如，在GraphQL查询的用户ID后附加“/delete”，该参数传递给REST API后可能会导致数据被意外删除。

缓解措施：虽然此漏洞确实值得关注，但可以通过在GraphQL架构中定义类型，并在将参数发送到外部API或服务之前进行全面验证来有效解决。需要注意的是，此漏洞以及与GraphQL相关的其他漏洞源于实现问题，并非GraphQL本身固有的问题。尽管这项技术很有潜力，但如果受短期思维影响而误用GraphQL，就会出现此类问题。

批处理攻击

身份验证漏洞是包括GraphQL在内的各种系统中常见的攻击途径。GraphQL可在单个请求中发送多个查询或变更操作，因此容易遭受采用暴力破解方法的批处理攻击。

第一类攻击是对登录密码进行暴力破解。攻击者发送一个包含大量变更操作的请求，每个变更操作都包含一组登录凭据。由于GraphQL允许在单个请求中执行多个变更操作，此类攻击可以绕过速率限制检查，并通过暴力破解密码来创建会话。

第二类攻击的运作方式类似，但其目标是一种常见的双因素身份验证（2FA）形式，即一次性密码（OTP）。攻击者发送一个包含多个变更操作的请求，每个变更操作都包含一组有效的登录凭据，并分别与不同的OTP组合。如果其中任何一个变更操作包含正确的OTP，请求将通过身份验证，并建立会话。

缓解措施：由于没有万无一失的解决方案，处理这些漏洞需要采取综合方法。开发人员应采用安全编码实践，并重点从业务逻辑角度审视问题，从而发挥关键作用。在Web服务器端，必须采取限制登录尝试次数、验证用户输入等措施。此外，应特别注意扫描包含多个变更的请求，因为合法的登录尝试通常不会涉及多个变更。

拒绝服务攻击

此类攻击通过向GraphQL服务发送过量流量，使其不堪重负，无法处理合法用户的请求，并可能导致服务器崩溃。攻击者可通过递归GraphQL查询或发送大型查询请求来实施DoS攻击。

在递归查询场景中，攻击者会利用GraphQL架构定义的循环特性。例如，如果架构包含作者和图书类型，攻击者可以循环反复查询作者和图书，通过大量递归调用使服务器不堪重负并干扰其运行。

或者，攻击者可以发出查询，从数据库请求大量数据。例如，一项查询可能会检索许多作者及其关联的所有图书。如此庞大的数据请求可能会显著降低系统运行速度，甚至导致系统崩溃。

缓解措施：可通过多种方法缓解此问题。第一种方法是为查询设置超时时间，防止用户发出执行时间超过指定时长的请求。但这种方法可能无法完全解决问题，因为在规定时间内仍可能造成损害。另一种方法是限制查询深度和复杂度。对于超出指定深度或复杂度、偏离架构定义的查询，可以予以拒绝。最后，实施用户限流也可能有效。如果用户发送大量或连续的请求，可以暂时拒绝其访问服务器，直至服务器能够处理更多请求。

GraphQL部署模式

如图所示，GraphQL有多种部署模式，每种模式都有各自的权衡因素和注意事项。常见模式包括：

单体式部署

这是部署GraphQL API最简单、最常见的模式。在单体部署中，GraphQL服务器、数据库及其他所有必要服务均作为一个整体部署。这种方式便于快速开始使用GraphQL，但随着应用不断发展，扩展和维护可能会变得困难。

图11：简单单体架构

组合式单体架构

组合式单体是指这样一种架构：使用单体和微服务相结合的方式构建单体应用，并由GraphQL充当API层（图12）。在这种模式下，应用最初被开发为多个独立的单体，而不是将整个系统拆分为彼此独立的微服务。每个单体都封装了所有业务逻辑和数据访问层。

图12：组合式单体架构

在这种单体结构中，GraphQL作为API层实现，使客户端能够请求和检索来自不同底层微服务的数据。这意味着，尽管从部署角度看，应用仍采用单体架构，但它利用GraphQL组合来自各项服务的数据，并以灵活高效的方式将数据提供给客户端。

此模式不仅可以简化开发和部署，还能充分利用GraphQL强大的查询和数据获取能力。开发人员可以逐步采用微服务架构，同时继续受益于GraphQL提供的灵活性和易用性。

联合子图

在GraphQL部署模式中，联合图是指将多个称为子图的GraphQL服务组合成一个统一的GraphQL模式。每个子图代表一个独立的领域或微服务，并拥有自己的数据和功能。此架构使用中央网关，根据请求的字段将客户端查询路由到相应的子图。通过联合这些子图，开发人员可以创建一个连贯的图，使客户端能够跨不同服务无缝查询和遍历。

图13：联合子图

这种方法有助于实现模块化、可扩展性和服务的独立开发，从而提升构建GraphQL API时的性能和灵活性。联合子图（图13）提供了一种有效方式，可组合来自不同服务的数据，并构建分布式、可扩展的架构。

混合图

GraphQL部署模式中的混合图（图14）通过拼接技术，将联合子图与非联合架构相结合。借助这种方法，组织可以将现有GraphQL API或旧系统与联合微服务集成，形成统一的GraphQL API，并兼具两种方法的优势。混合图架构通过合并架构并解析类型与字段之间的关系，提供灵活性、模块化能力和可扩展性。

图14：混合图

混合图模式使组织能够在利用现有资源的同时，逐步采用联邦架构。该模式可无缝集成联邦子图和非联邦模式，满足多样化需求并提升互操作性。借助这种方法，组织可以构建全面的GraphQL API，并根据不断变化的需求进行扩展和调整。混合图结合了联邦服务与非联邦服务各自的优势，为构建GraphQL部署提供灵活而强大的解决方案。

GraphQL部署中的混合图面临多项挑战，包括管理合并后架构的复杂性、解决潜在的性能开销、确保数据一致性和完整性、处理系统演进和版本控制，以及应对分布式架构中监控与调试的复杂性。要克服这些挑战并确保混合图部署顺畅运行，需要周密规划、持续优化和稳健的开发实践。

无服务器路由

此模式将GraphQL API部署为一组无服务器函数，例如AWS Lambda或Google Cloud Functions。这种GraphQL API部署方式具有成本效益且可扩展，但也可能增加延迟和架构复杂性。

无服务器路由面临诸多挑战。其中一个问题是，随着应用扩展，如何无缝连接分布式子图。协调多个团队和部署可能会变得复杂，难以有效管理和扩展子图。确保这些子图之间的数据一致性和同步也是一项挑战。在分布式无服务器环境中，监控和调试可能更加困难，需要适当的日志记录和错误处理机制。此外，跨多个无服务器函数和子图管理访问控制和授权也存在挑战。解决这些问题对于确保基于无服务器架构的 GraphQL 部署顺畅运行并具备可扩展性至关重要。

边缘部署

在GraphQL API的边缘部署模式中，使用CDN服务将API部署在更靠近客户端的位置。这样可带来多项优势，包括降低延迟以加快响应速度、减轻源服务器负载，以及防御DDoS攻击。

通过将API基础设施分布在全球各地的边缘服务器上，可以更高效地处理流量，并为全球用户提供更好的体验。CDN的缓存和过滤功能有助于提升可扩展性，并确保API的可用性，即使面临高流量或恶意攻击也不例外。边缘部署可利用CDN的服务器网络，优化API的性能和可靠性。

结论

GraphQL技术已足够成熟，可供传统企业采用。尽管Gartner《2022年API技术成熟度曲线》表明距离广泛采用仍需数年时间，但如今已到达关键转折点，所需工具均已就绪。虽然GraphQL仍是一项相对较新的技术，但其发展程度已足以满足成熟大型企业的需求。

GraphAPI技术日趋成熟，源于越来越多的企业开始采用GraphQL及其他图数据库技术。随着采用这些技术的公司不断增加，相关支持工具和资源也日益丰富，其他企业因而更容易跟进。此外，GraphAPI技术在改进数据查询、降低复杂性等方面的优势正得到更广泛的认可，进一步推动了企业对这些技术的采用。

整个行业必须认识到GraphQL等GraphAPI技术的重要性，以及它们突破REST局限的潜力。企业必须重视投资和深入了解GraphQL的迫切需求，尤其是在数据建模、多样性和不透明性方面。GraphQL的功能和潜力固然令人瞩目，但也必须认识到，过高期望达到顶峰后，可能会进入幻灭低谷期。供应商必须优先改进产品，以全面支持GraphQL；企业IT部门（包括供应商）则应确定哪些数据适合通过GraphQL开放，从而提高工作效率。

客户必须优先深入了解自身数据，并认识到普通企业的运营方式不同于最初引入GraphQL的超大规模云服务提供商。让我们携手采用GraphQL这一有效的软件架构模式，推动行业提升生产力并促进创新。