基于每个客户端授予对图的访问权限,并管理客户端可以访问的内容和方式。
数据图中的授权具有两个同等重要的方面:访问控制,其指示允许用户访问的对象和字段;以及需求控制,其指示允许用户访问这些资源的方式(以及多少)。虽然经常被提及是访问控制,但是也需要注意需求控制,因为它在 GraphQL 的任何生产部署中都至关重要。允许用户执行任何可能的查询而不考虑成本是错误的,这会导致无法管理其对生产系统的影响。无论执行访问还是需求控制都必须在充分了解数据图的语义和性能的情况下才执行。在不分析实际发送的查询的情况下,不应该限制用户的每分钟查询数,因为查询可以访问相当广泛的服务,并且查询的成本可以在多个数量级上变化。
数据图中的鉴权同样有两个方面:请求操作的应用以及使用该应用的用户。虽然访问控制可能以用户为中心,但需求控制至少保证同等的应用级控制和用户级控制,因为特定的查询情形是由是应用的开发者,而不是应用的用户负责的。
需求控制的最佳实践包括:
捕获所有图操作的结构化日志,并以之为主要工具了解图的使用情况。
可以捕获关于在图关系执行的每个操作(读取或写入)的大量信息:哪位用户和什么应用执行了操作、访问了哪些字段、操作的实际执行方式、执行效果等。这些信息非常有价值,应该系统化地捕获以备以后使用。相比较文本日志,它更应该捕获成结构化的机器可读的格式,以便尽可能多地利用它。
图关系操作的记录称为追踪。追踪应该在一个地方汇集有关操作的所有相关信息,包括业务信息(谁执行的操作、访问或更改的内容、由哪位开发者构建的应用的哪一个功能、是否成功、执行效果如何)以及纯技术信息(哪个后端服务被调用、每个服务如何导致延迟、是否使用了缓存)。
因为追踪能捕捉图关系是怎样被使用的,所以它们能被用于广泛的用途:
所有图关系操作的数据应该集中保存,以便有一个权威的追踪流。然后可以再将此流传输到其他观测系统(对于不支持 GraphQL 的现有系统可能需要进行简单转换),或者存储在一个或多个数据仓库中以备今后使用(采样、汇总然后转换成预算、用例和需求规模)。
采用分层架构将数据图功能分解为单独的层,而不是融入到每个服务中。
在大多数 API 技术中,除了开发期之外,客户端都不与服务器直接通信。而是采用分层方法,譬如负载平衡、缓存、服务定位或 API 密钥管理之类的一些问题被单独分层。然后,这些层就可以与后端服务分开设计、运作和扩展。
GraphQL 也同样适用。相比较将完整数据图系统所需的所有功能都整合到每个服务中,大多数数据图功能应该被提取到位于客户端和服务之间的单独层,使每个服务都能专注于处理客户端的具体请求。该层可以由多个进程组成,譬如执行访问控制和需求控制、联邦、追踪收集和缓存等功能。此层的某些部分是 GraphQL 特有的,需要深入了解数据图,而其他功能,如负载平衡和客户端身份验证,可以使用现存系统。
即使在只有一个应用和一个服务的简单场景中,这个单独的层也能发挥价值;否则,本该属于中间层的功能就得在服务器中实现了。在复杂的应用中,此层可能看起来像异地分布式系统:通过多个入口点接收传入查询,利用边缘缓存处理边缘网络的查询,将查询的子组件路由到多个数据中心在公共云、私有云或由合作伙伴运营的云中,最后将这些组件组装成查询结果,同时记录一次包含整个操作的追踪。
在某些情况下,此数据图层将使用 GraphQL 与后端服务进行通信。但是,最常见的是,后端服务保持不变,并继续通过现有 API(如 REST,SOAP,gRPC,Thrift 甚至 SQL)进行访问,再由数据图层的服务器将这些 API 映射到数据图层中去。