CN107817996A

CN107817996A - 一种GraphQL请求的优化方法及系统

Info

Publication number: CN107817996A
Application number: CN201710953435.1A
Authority: CN
Inventors: 朱凯强; 苗辉
Original assignee: Guizhou White Cloud Technology Co Ltd
Current assignee: Guizhou White Cloud Technology Co Ltd
Priority date: 2017-10-13
Filing date: 2017-10-13
Publication date: 2018-03-20
Anticipated expiration: 2037-10-13
Also published as: CN107817996B

Abstract

本发明提供一种GraphQL请求的优化方法及系统，在加载GraphQL请求时，通过系统的环境变量分为线上环境与测试环境；在线上环境中采用按需加载的方式对GraphQL请求中所需执行的Fields进行解析；在测试环境中采用全部加载的方式，加载服务端配置文件中全部的Fields以及Type。由于全部加载的方式直接加载了配置中所有的Fields，导致解析的Fields的过程效率明显低于按需加载。且全部的Fields解析后封装成的Schema明显大于按需加载，从而导致底层对Schema进行解析时效率再次降低。按需加载的方式明显小于全部加载的方式，提高了线上环境时的请求效率。

Description

一种GraphQL请求的优化方法及系统

技术领域

本发明涉及API交互技术领域，尤其涉及一种GraphQL请求的优化方法及系统。

背景技术

GraphQL是facebook研发的一种为了解决restful交互缺陷的另一种API(应用程序编程接口)交互规范。截至目前，客户端与服务端API交互大多是基于folklore/GraphQL去实现；

但是，随着项目业务的增长，在线上环境时folklore/graphq的性能变得很低，对项目后期非常不利。这是因为folklore/graphq在服务端解析GraphQL请求时会将服务端配置文件中已注册的全部的Fields以及全部的Type进行加载，使得经过解析、封装后的Scheam过大，导致在GraphQL底层解析时响应GraphQL请求的速度大幅度延缓；不仅如此，folklore/graphq在延缓GraphQL响应速度的同时还会使得在线上环境时GraphQLIQL查询平台接口的全部暴露严重降低了GraphQL的安全性；

在日新月异的互联网时代，类似于“facebook”的大型交流网站的项目业务的增长是为满足客户所需的必要趋势，因此如何在满足项目业务增长趋势的同时又提高GraphQL的响应速度以及安全性是目前急需解决的。

发明内容

本发明的目的在于克服现有技术存在的不足，一种GraphQL请求的优化方法,，包括以下步骤：

S1，发起GraphQL请求；

S2，判断所述框架的运行环境是否为线上环境，是，则进入S3；

S3，关闭GraphQLIQL接口平台，对所述请求参数进行AST语法树解析，获取所述请求参数中需执行的Fields树、各层级Fields以及其层级关系,将最高层级的Fields与服务端配置文件中的Fields进行匹配，并加载所述请求参数所需执行的Fields以及type；

S4，将所述最高层级Fields以及其对应的Type进行解析，得到满足Schema格式的第一关系树，将所述第一关系树封装成Schema；

S5，解析所述Schema以及所述GraphQL请求，进行响应。

作为进一步改进，在步骤S4中，所述将最高层级Fields以及其对应的Type进行解析的步骤包括：

S41，根据所述请求参数所需执行最高层级的Fields以及type，得到低一级的Fields；

S42，再根据所述低一级的Fields对应的type，得到再低一级的Fields，直至最低等级的Fields。

作为进一步改进，在步骤S2中，否，则执行以下步骤：

S3’，不关闭所述GraphQLIQL接口平台，加载所述服务端配置文件中全部的Fields及其对应的Type，然后进入S4’；

S4’，提取所述全部的Fields以及其对应的type进行解析，得到满足所述Schema格式的第二关系树，将所述第二关系树封装成Schema；

S5，解析所述Schema以及所述GraphQL请求，进行响应。

作为进一步改进，所述GraphQL请求参数中包括有模块参数；所述配置文件中包括不同的模块集，且所述配置文件中的Fields分类入不同的模块集中，在步骤S3中，所述将最高层级的Fields与服务端配置文件中的Fields进行匹配的步骤包括：

通过所述模块参数匹配对应的模块集，将所述最高层级的Fields与所对应的模块集中的Fields进行匹配。

作为进一步改进，在所述步骤S1与所述步骤S2之间进一步包括S11，加入JWT认证。

作为进一步改进，在步骤S5中，所述解析所述Schema以及所述GraphQL请求的步骤包括：

S51，对所述请求参数进行AST语法树解析；

S52，将经过所述AST语法树解析后的GraphQL请求以及所述Schema进行匹配，得到其二者之间均才在的Fields以及Type。

作为进一步改进，在步骤S5中，所述进行响应的步骤包括：

S53，判断所述Schema是否有语法错误异常，是，进入S54；否，进入步骤S55；

S54，所述服务端生成错误的GraphQL响应，至所述客户端；以及

S55，所述服务端生成正确的GraphQL响应，至所述客户端。

本发明提供一种GraphQL请求的系统，包括客户端、服务端；所述服务端包括环境判断单元、第一解析单元、封装单元、第二解析单元、第三解析单元以及配置文件；

所述服务端用与接收所述客户端的GraphQL请求；所述环境判断单元用于判断所述客户端的GraphQL请求的运行环境；所述第一解析单元用于解析所述GraphQL请求中需执行Fields，随后加载所述配置文件中与所述需执行Fields以及与其对应的Type，所述第二解析单元用于解析所述需执行Fields以及所述与气对应的Type，所述封装单元用于将所述需执行Fields以及所述与气对应的Type封装成Schema；所述第三解析单元用于解析所述Schema以及所述GraphQL请求，进行响应。

作为进一步改进，所述第三解析单元包括异常报错子单元。

作为进一步改进，所述配置文件包括若干模块子文件，所述模块子文件用于将所述配置文件中相同类别的Fields及其对应的Type归类。

相较于现有，本发明的有益效果为：

本发明通过判断Laravel及Lumen框架的环境变量判断框架的运行环境，在线上环境时采用按需加载的方式对GraphQL请求进行AST语法树解析，获取GraphQL请求参数中需执行的Fields树、各层级关系及其各层级Fields，减少了加载配置文件中全部Fields以及type时间并且减少了封装成Schema后Schema中的信息量，在S5解析所述Schema以及所述GraphQL请求参数时节省了Schema与GraphQL请求参数的匹配时间，大幅度加快了在线上环境时GraphQL请求的响应速度，适应了目前大型交流网站的项目业务的增长的趋势。

附图说明

图1为本发明实施例的总体流程示意图；

图2为本发明的Fields树示意图；

图3为本发明S4中GraphQL请求中需执行的Fields树与配置文件中的Fields的匹配流程。

图4为本发明S4、S4’中解析的示意图。

图5为本发明独立权利要求的中的总体流程示意图。

具体实施方式

为使本发明实施方式的目的、技术方案和优点更加清楚，下面将结合本发明实施方式中的附图，对本发明实施方式中的技术方案进行清楚、完整地描述，显然，所描述的实施方式是本发明一部分实施方式，而不是全部的实施方式。本发明中的实施方式，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施方式，都属于本发明保护的范围。因此，以下对在附图中提供的本发明的实施方式的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施方式。本发明中的实施方式，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施方式，都属于本发明保护的范围。

此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的哪些步骤或单元，而是可以包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其他步骤或单元。

这里，对本发明中出现的名词做出释意，

其中，Fields中文名为可查询字段，意为可查询的字段；

Type中文名为，字段的数据类型，意为规定字段查询后可返回的数据类型，

Schema为一种数据的格式类型。

请参阅图1，本发明实施例提供了一种GraphQL请求优化的方法,其包括以下步骤：

S1，客户端发起GraphQL请求，所述GraphQL请求包括请求参数。

所谓GraphQL请求，可理解为用户需要的操作，在GraphQL交互规范中，这种用户需要的操作一般分为“查询”以及“修改”两大类。

S2，服务端根据Laravel和Lumen的框架的环境变量判断框架的运行环境，当所述框架的运行环境是线上环境时进入S3；当所述框架的运行环境是非线上环境时则进入S3’。

这里提到的线上环境与测试环境可以理解为情况相对的两种环境，其中测试环境是为方便后台维护人员进行维护，得到配置文件中全部的Fields以及全部的Type之间的对应关系；而线上环境是针对客户、访问者所使用的，若是也如同测试环境加载配置文件中全部的Fields以及全部的Type得到它们之间的对应关系，那么不仅降低了加载的速度也将不必要的信息(全部的Fields、全部的Type以及它们之间的对应关系)暴露，降低了安全性。由此可看出线上环境与测试环境各有长处，本实施例充分运用这种优缺点，根据不同情况的不同需求，将后续分为S3以及S3’。

所述GraphQL请求的格式包括Json格式；通过$request->isJson()判断json请求，使str_replace(["\n","\r","\t"],'',$content)进行请求过滤，相比于采用post格式的参数信息，可以使得GraphQL的请求参数更加的贴近GraphQL固有的请求格式。

在所述步骤S1与所述步骤S2之间以进一步包括S11，加入JWT用户认证，实现JWT用户认证的认证方式，具体的将token通过Url的jwt_token参数或者请求头Authorization参数进行Token传输，服务端在路由解析获取该参数后进行JWT TOKEN解析。

S3，关闭IQL查询平台；对所述GraphQL请求中的请求参数进行AST语法树解析，获取所述GraphQL请求中需执行的Fields树、所述需执行的Fields树中各层级Fields以及所述各层级Fields的层级关系,将所述各层级的Fields中最高层级的Fields与所述服务端配置文件中的Fields进行匹配；加载所述GraphQL请求所需的Fields以及type，进入S4。

所谓最高层级的概念，在上述S1中提到用户需要的操作分为两大类，其一是“查询”、其二是“修改”，在GraphQL请求的固定格式中，每个GraphQL请求只能存在一种类别，结合需执行的Fields树、Fields树中各层级Fields以及所述各层级Fields的层级关系,可以看出查询Fields、修改Fields就是最高层级的Fields。

在步骤S3中，所述对GraphQL请求参数进行AST语法树解析的步骤包括：

根据GraphQL的请求格式对GraphQL请求参数进行AST语法树解析。因为GraphQL的请求格式是固定的并且是通过Fields树的表达方式表现，所以获取GraphQL请求中需执行的Fields树、所述需执行的Fields树中各层级Fields以及所述各层级Fields的层级关系更加方便。

进一步的，请参照图2，在所述GraphQL请求参数中包括有模块参数；所述配置文件中包括不同的模块集，且所述配置文件中的Fields分类入不同的模块集中，在步骤S3中，将所述需执行的Fields树中最高层级的Fields，与服务端配置文件中的Fields进行匹配的步骤包括：通过所述模块参数匹配对应的模块集，将所述Fields树中最高层级的Fields与所对应的模块集中的Fields进行匹配。不同的项目整合为不同的模块，例如图2中的“人”、“汽车”“地区”，将原本随机在配置文件中的Fields以及Type，按模块整理，根据GraphQL请求参数中的模块参数，在匹配的过程中就可以快速的找到请求中执行所需的Fields对应的模块，提高了与配置文件中Fields的匹配速度，也方便了项目的拆分与项目的扩展。

具体的，通过Url访问不同模块名进而读取对应的模块配置。

S3’，不关闭IQL接口查询平台；加载所述服务端配置文件中全部的Fields以及全部的Type，进入S4’。

请参照图2，假设本次GraphQL请求查询的是白种人Tom的眼睛信息，在S3中，只需在配置文件中找到查询Fields的对应的Type进行加载即可；而在S3’中，需要将全部的Fiedls例如人、汽车、地区、黑种人、白种人、黄种人等全部的Fields以及其对应的Type进行加载。

值得注意的是在配置文件中只需注册最高层级的Fields即可，假设本次GraphQL请求的类别是查询，配置文件中只注册有查询Fields以及修改Fields及其二者对应的Type，那么在S3中只需加载查询Fields以及查询Fields对应的Type，而在S3’中需加载查询Fields、查询Fields对应的Type、修改Fields以及修改Fields对应的Type；这里值得注意的配置文件中注册有Fields以及Fields对应的Type，其中配置文件的Fields与Type是通过配置文件中的Type参数指定配对的。

S4，提取所述GraphQL请求中最高层级Fields以及及其对应的Type进行解析，得到满足Schema格式的第一关系树，将所述满足Schema格式的关系树封装成Schema。

S4’，提取所述全部的Fields及其对应的Type进行解析，得到满足所述Schema格式的第二关系树，将所述满足Schema格式的关系树封装成Schema。

值得注意的是这里所提及的第一关系树、第二关系树，仅仅是为区分所述Schema中的内容，第一关系树：包括请求中所需执行的Fields及其对应的Type；第二关系树：包括配置文件中全部的Fields及其对应的Type。

请参阅图3-4，在步骤S4中，所述提取所述GraphQL请求参数中需执行的Fields及其对应的Type进行解析的步骤包括：根据所述GraphQL请求所需的Fields以及所述GraphQL请求所需的Fields对应的Type，得到下一级的Fields，在根据所述下一级的Fields对应的type，得到再下一级的Fields，直至最下级。

在步骤S4’中，提取所述全部的Fields及其对应的Type进行解析的步骤包括：根据每一Fields对应的Type，得到下一级的Fields，在根据所述下一级的Fields对应的Type，得到再下一级的Fields，直至最下级，在这里并未对S4’做出图示。

由于S4封装的Schema只包含解析后的GraphQL请求中最高层级的Fields以及GraphQL请求中最高层级的对应的Type；而S4’封装的Schema包含解析后配置文件中全部的Fields以及type，由此可见，在项目越多的情况下，S4封装的Schema信息量远小于S4’封装的Schema的信息量。

在S4与S4’中，既可以采用创建文本的方式建立低一级Fields对应的type，也可以采用Make type；

Maketype的方式，是将上述配置文件中Fields中的Type参数编写为已有对应层级关系的Fields以及Type，这里的对应关系是指“根据每一Fields对应的Type，得到低一级的Fields，在根据所述低一级的Fields对应的Type，得到再低一级的Fields，直至最低级的Fields，

而不采用Maketype时，需根据Type参数不断新创Type文本，注册配置文件中，导致分两次，执行同样的命令时也需要建立两次相同的Type文本，如此累积易出现Type的重名报错。

故在本实施例中，优选采用Make type的方式已实现快速构建Type，避免Type的重名报错，这里距离具体的Maketype方式为：Make type：通过读取\GraphQL\Type\Definition\命名空间下的所有可用的Type，快速构建Type。

S5，解析所述Schema以及所述GraphQL请求，进行响应。

在步骤S5中，解析所述Schema以及所述GraphQL请求，进行响应的步骤包括，

S51，对所述GraphQL请求中的请求参数进行AST语法树解析,这里的解析方式与S3中相同，得到本次请求需要执行的Fields树、Fields树中各层级Fields以及所述各层级Fields的层级关系。

S52，将经过所述AST语法树解析后的GraphQL请求以及所述Schema进行匹配，得到在经过所述AST语法树解析后的GraphQL请求以及所述Schema均存在的Fields以及Type。

在上述分析中得到S4封装的Schema信息量远小于S4’封装的Schema的信息量，固在进行匹配时，S4封装的Schema匹配速度明显高于S4’封装的Schema，大幅度的提升了匹配的速度。

在所述Schema解析中加入详细的PHP报错机制。在步骤S5中，将Schema进行响应的步骤包括：

S54，所述服务端生成错误的GraphQL响应，至所述客户端；以及

S55，所述服务端生成正确的GraphQL响应，至所述客户端。

上述提到的详细的PHP报错机制可提供详细的异常形成路径，并且将所述异常转换为更便于清晰阅读的json格式。

具体的，通过getPrevious捕获原生异常信息路径，生产环境自动隐蔽，避免暴露代码，同时响应的数据支持对所有数据直接Json化，无需进行返回type声明。

本实施例提供了在线上环境时与测试环境两种加载方式的速度对比数据：

测试环境：

测试代码说明：

为与GraphQL尽量保持一致

返回数据使用GraphQL的返回数据

统一采用post请求方法

统一发送同样的请求数据：

{"query":"queryFetchUsers{users{id,email}}"}

所以请求都是直接返回PHP数组数据，未使用ORM或查询构造器查询数据库

18个query和12个mutation和30个type，一个查询返回数据。S3’加载结果(全部加载)：

Server Software:Apache/2.2.15

Server Hostname:bhummer.dev

Server Port:80

Document Path:/GraphQL/query

Document Length:105bytes

Concurrency Level:100

Time taken for tests:1.179seconds

Complete requests:200

Failed requests:0

Write errors:0

Total transferred:65000bytes

Total POSTed:44600

HTML transferred:21000bytes

Requests per second:169.67[#/sec](mean)

Time per request:589.374[ms](mean)

Time per request:5.894[ms](mean,across all concurrent requests)

Transfer rate:53.85[Kbytes/sec]received

S3加载结果(按需加载)：

Server Software:Apache/2.2.15

Server Hostname:bhummer.dev

Server Port:80

Document Path:/GraphQL/query

Document Length:105bytes

Concurrency Level:100

Time taken for tests:0.604seconds

Complete requests:200

Failed requests:0

Write errors:0

Total transferred:65000bytes

Total POSTed:44600

HTML transferred:21000bytes

Requests per second:331.10[#/sec](mean)

Time per request:302.026[ms](mean)

Time per request:3.020[ms](mean,across all concurrent requests)

Transfer rate:105.08[Kbytes/sec]received

通过对比按需加载与全部加载的time per request(平均请求等待时间)可以明显的看出，在线上环境采用S3按需加载的方式响应速度提高了2倍左右。

另外结合上述方法步骤，本实施例还提供了具体的GraphQL请求的化系统，包括客户端、服务端；所述服务端包括环境判断单元、第一解析单元、封装单元、第二解析单元、第三解析单元以及配置文件；

所述服务端用与接收所述客户端的GraphQL请求；所述环境判断单元用于判断所述客户端的GraphQL请求的运行环境；所述第一解析单元用于解析所述GraphQL请求中需执行Fields，随后加载所述配置文件中与所述需执行Fields以及与其对应的Type，所述第二解析单元用于解析所述需执行Fields以及所述与气对应的Type，所述封装单元用于将所述需执行Fields以及所述与气对应的Type封装成Schema；所述第三解析单元用于解析所述Schema以及所述GraphQL请求，进行响应，在本系统中，客户端仅做出发送GraphQL请求，其余步骤均有服务端完成。

所述第三解析单元包括异常报错子单元，用于解析错误时，进行报错响应，若无错误则提供正确的响应信息。优选的，异常报错子单元采用的是详细的PHP报错机制。

所述配置文件包括若干模块子文件，所述模块子文件用于将所述配置文件中相同类别的Fields及其对应的Type归类，在匹配的过程中就可以快速的找到请求中执行所需的Fields对应的模块，提高了与配置文件中Fields的匹配速度，也方便了项目的拆分与项目的扩展。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims

1.一种GraphQL请求的优化方法,其特征在于，包括以下步骤：

S1，客户端发起GraphQL请求；

S5，解析所述Schema以及所述GraphQL请求，进行响应。

2.根据权利要求1所述的方法,其特征在于，在步骤S4中，所述将最高层级Fields以及其对应的Type进行解析的步骤包括：

3.根据权利要求1所述的方法,其特征在于，在步骤S2中，否，则执行以下步骤：

S5，解析所述Schema以及所述GraphQL请求，进行响应。

4.根据权利要求1所述的方法，其特征在于，所述GraphQL请求参数中包括有模块参数；所述配置文件中包括不同的模块集，且所述配置文件中的Fields分类入不同的模块集中，在步骤S3中，所述将最高层级的Fields与服务端配置文件中的Fields进行匹配的步骤包括：

5.根据权利要求1所述的方法，其特征在于：在所述步骤S1与所述步骤S2之间进一步包括S11，加入JWT认证。

6.根据权利要求1所述的方法,其特征在于，在步骤S5中，所述解析所述Schema以及所述GraphQL请求的步骤包括：

S51，对所述请求参数进行AST语法树解析；

7.根据权利要求1所述的方法,其特征在于，在步骤S5中，所述进行响应的步骤包括：

S54，所述服务端生成错误的GraphQL响应，至所述客户端；以及

S55，所述服务端生成正确的GraphQL响应，至所述客户端。

8.一种GraphQL请求的系统，其特征在于，包括客户端、服务端；所述服务端包括环境判断单元、第一解析单元、封装单元、第二解析单元、第三解析单元以及配置文件；

9.根据权利要求8所述的GraphQL请求的系统，其特征在于，所述第三解析单元包括异常报错子单元。

10.根据权利要求8所述的GraphQL请求的系统，其特征在于，所述配置文件包括若干模块子文件，所述模块子文件用于将所述配置文件中相同类别的Fields及其对应的Type归类。