graphql规范

GraphQL在Gatsby中的应用。总的来讲&＃xff0c;它是一个新潮的技术&＃xff0c;在适宜的使用场景威力无穷。这里我们来讨论一下用/不用GraphQL的理由吧。

简单介绍GraphQL

GrahQL

GraphQL是Facebook2015年开源的数据查询规范。现今的绝大多数Web Service都是RESTful的&＃xff0c;也就是说&＃xff0c;client和server的主要沟通模式还是靠client根据自己的需要向server的若干个endpoint (url)发起请求。由于功能的日渐丰富&＃xff0c;对Web Application的要求变得复杂&＃xff0c;REST的一些问题逐渐暴露&＃xff0c;人们开始思考如何应对这些问题。GraphQL便是具有代表性的一种。GraphQL这个名字&＃xff0c;Graph &＃43; Query Language&＃xff0c;就表明了它的设计初衷是想要用类似图的方式表示数据&＃xff1a;即不像在REST中&＃xff0c;数据被各个API endpoint所分割&＃xff0c;而是有关联和层次结构的被组织在一起。

比方说&＃xff0c;假设这么一个提供user信息的REST API: /users/&＃xff0c;和提供用户的关注者的API&＃xff1a;/users//followers&＃xff0c;以及该用户关注对象的API: /users//followed-users。传统的REST会需要3次API call才能请求出这三份信息&＃xff08;假设/users/ 没有包含followers and followed-users信息&＃xff0c;which will be a definite redundancy if it does&＃xff09;:
1 GET /users/

{"user": {"id" : "u3k2k3k178","name" : "graph_ql_activist", "email" : "graph_ql&＃64;activist.com", "avatar" : "img-url" } }

2 GET /users//followed-users
3 GET /users//followers

然而如果使用GraphQL&＃xff0c;一次API请求即可获取所有信息并且只选取需要的信息&＃xff08;比如关于用户只需要name不要email, followers只要最前面的5个name&＃xff0c;followed-users只要头像等等&＃xff09;:

query {user (id : "u3k2k3k178") {namefollowers (first: 5) { name } followed-users { avatar } } }

我们会得到一个完全按照query定制的&＃xff0c;不多不少的返回结果&＃xff08;一般是一个json对象&＃xff09;。

5个使用GraphQL的理由

使用GraphQL的理由&＃xff0c; 必然是从讨论RESTful Service的局限性和问题开始。

1. 数据冗余和请求冗余 (overfetching & underfetching)
2. 灵活而强类型的schema
3. 接口校验 (validation)
4. 接口变动&＃xff0c;维护与文档
5. 开发效率

1 数据冗余和请求冗余 (overfetching & underfetching)

根据users API的例子&＃xff0c;我们可以想见&＃xff0c;GET用户信息的REST call&＃xff0c;我们就算只是想要一个用户的一两条信息(比如name & avatar)&＃xff0c;通过该API&＃xff0c;我们也会得到他的整个信息。所谓的overfetching就是指的这种情况——请求包含当前不需要的信息。这种浪费会一定程度地整体影响performance&＃xff0c;毕竟更多的信息会占用带宽和占用资源来处理。

同样从上面的例子我们可以看出来&＃xff0c;在许多情况下&＃xff0c;如果我们使用RESTful Application&＃xff0c;我们常常会需要为联系紧密并总量不大的信息&＃xff0c;对server进行多次请求&＃xff0c;call复数个API。

举一个例子&＃xff0c;获取ID为"abc1"和"abc2"的两个用户的信息&＃xff0c;我们可能都需要两个API call&＃xff0c;一百个用户就是一百个GET call&＃xff0c;这是不是很莫名其妙呢&＃xff1f;这种情况其实就是underfetching——API的response没有合理的包含足够信息。

然而在GraphQL&＃xff0c;我们只需要非常简单地改变schema的处理方式&＃xff0c;就可以用一个GET call解决&＃xff1a;

query {user (ids : ["ab1", "abc2", ...])
}


我们新打开一个网页&＃xff0c;如果是RESTful Application&＃xff0c;可能请求数据就会马上有成百上千的HTTP Request&＃xff0c;然而GraphQL的Application则可能只需要一两个&＃xff0c;这相当于把复杂性和heavy lifting交给了server端和cache层&＃xff0c;而不是资源有限&＃xff0c;并且speed-sensitive的client端。

2 灵活而强类型的schema

GraphQL是强类型的。也就是说&＃xff0c;我们在定义schema时&＃xff0c;类似于使用SQL&＃xff0c;是显式地为每一个域定义类型的&＃xff0c;比如说&＃xff1a;

type User {id: ID!name: String!joinedAt: DateTime!profileViews: Int! &＃64;default(value: 0)
}type Query {user(id: ID!): User
}


GraphQL的schema的写作语言&＃xff0c;其实还有一个专门的名称——Schema Definition Language (SDL)。

这件事情的一大好处是&＃xff0c;在编译或者说build这个Application时&＃xff0c;我们就可以检查并应对很多mis-typed的问题&＃xff0c;而不需要等到runtime。同时&＃xff0c;这样的写作方式&＃xff0c;也为开发者提供了巨大的便利。比如说使用YAML来定义API时&＃xff0c;编写本身就是十分麻烦的——可能没有理想的auto-complete&＃xff0c;语法或者语义有错无法及时发现&＃xff0c;文档也需要自己小心翼翼地编写。就算有许多工具(比如Swagger)帮助&＃xff0c;这仍然是一个很令人头疼的问题。

3 接口校验 (validation)

显而易见&＃xff0c;由于强类型的使用&＃xff0c;我们对收到的数据进行检验的操作变得更为容易和严格&＃xff0c;自动化的简便度和有效性也大大提高。对query本身的结构的校验也相当于是在schema完成后就自动得到了&＃xff0c;所以我们甚至不需要再引入任何别的工具或者依赖&＃xff0c;就可以很方便地解决所有的validation。

4 接口变动&＃xff0c;维护与文档

RESTful Application里面&＃xff0c;一旦要改动API&＃xff0c;不管是增删值域&＃xff0c;改变值域范围&＃xff0c;还是增减API数量&＃xff0c;改变API url&＃xff0c;都很容易变成伤筋动骨的行为。

如果说改动API url(比如/posts --> /articles)&＃xff0c;我们思考一下那些地方可能要改动呢&＃xff1f;首先client端的代码定然要改变request的API endpoint&＃xff1b;中间的caching service可能也需要改要访问的endpoint&＃xff1b;如果有load balancer, reverse proxy&＃xff0c;那也可能需要变动&＃xff1b;server端自己当然也是需要做相应改变的&＃xff0c;这根据application自己的编写情况而定。

相比之下&＃xff0c;GraphQL就轻松多了。GraphQL的Service&＃xff0c;API endpoint很可能就只有一个&＃xff0c;根本不太会有改动URL path的情况。至始至终&＃xff0c;数据的请求方都只需要说明自己需要什么内容&＃xff0c;而不需要关心后端的任何表述和实现。数据提供方&＃xff0c;比如server&＃xff0c;只要提供的数据是请求方的母集&＃xff0c;不论它们各自怎么变&＃xff0c;都不需要因为对方牵一发而动全身。

在现有工具下&＃xff0c;REST API的文档没有到过分难以编写和维护的程度&＃xff0c;不过跟可以完全auto-generate并且可读性可以很好地保障的GraphQL比起来&＃xff0c;还是略显逊色——毕竟GraphQL甚至不需要我们费力地引入多少其他的工具。

再一点&＃xff0c;我们都知道REST API有一个versioning: V1, V2, etc.这件事非常的鸡肋而且非常麻烦&＃xff0c;有时候还要考虑backward compatibility。GraphQL从本质上不存在这一点&＃xff0c;大大减少了冗余。增加数据的fields和types甚至不需要数据请求方做任何改动&＃xff0c;只需要按需添加相应queries即可。

另外&＃xff0c;有了GraphQL的queries&＃xff0c;我们可以非常精准地进行数据分析(Analytics)。比如说具体哪些queries下的fields / objects在哪些情况下是被请求的最多/最频繁的——而不像RESTful Application中&＃xff0c;如果不进行复杂的Analytics&＃xff0c;我们只能知道每个API被请求的情况&＃xff0c;而不是具体到它们内含的数据。

5 开发效率

相信上面说的这些点已经充分能够说明GraphQL对于开发效率能够得到怎样的提升了。

再补充几点。

GraphQL有一个非常好的ecosystem。由于它方便开发者上手和使用-->大家争相为它提供各种工具和支持-->GraphQL变得更好用-->社区文化和支持更盛-->... 如同其他好的开源项目一样&＃xff0c;GraphQL有着一个非常好的循环正向反馈。

对于一套REST API&＃xff0c;哪怕只是其使用者(consumer)&＃xff0c;新接触的开发者需要一定时间去熟悉它的大致逻辑&＃xff0c;要求乃至实现。然而GraphQL使用者甚至不需要去看类似API文档的东西&＃xff0c;因为我们可以直接通过query查询query里面所有层级的type的所有域和它们各自的type&＃xff0c;这不得不说很方便&＃xff1a;

{__schema {types {name}}
}


&＃61;&＃61;> 我们可以看到query所涉及的所有内容的类型&＃xff1a;

{"data": {"__schema": {"types": [{"name": "Query" }, { "name": "Episode" }, { "name": "Character" }, { "name": "ID" }, { "name": "String" }, { "name": "Int" }, { "name": "FriendsConnection" }, { "name": "FriendsEdge" }, { "name": "PageInfo" } { "name": "__Schema" }, { "name": "__Type" }, { "name": "__TypeKind" }, { "name": "__Field" }, { "name": "__InputValue" }, { "name": "__EnumValue" } } ] } } }

对于GraphQL&＃xff0c;我还有个非常个人的理由偏爱它&＃xff1a;对于API的测试&＃xff0c;相比于比较传统的Postman或者自己写脚本进行最基本的http call&＃xff08;或者curl&＃xff09;&＃xff0c;我更喜欢使用insomnia这个更为优雅的工具。而在此之上&＃xff0c;它还非常好地支持了GraphQL&＃xff0c;这让我的开发和测试体验变得更好了。&＃xff08;Postman至今还不支持GraphQL&＃xff0c;虽然本质上我们可以用它make GraphQL query call&＃xff09;

5个不用GraphQL的理由

1. 迁移成本
2. 牺牲Performance
3. 缺乏动态类型
4. 简单问题复杂化
5. 缓存能解决很多问题

1 使用与迁移成本

现有的RESTful Application如果要改造成GraphQL Application&＃xff1f;

hmmm...

我们需要三思。首先我就不说RESTful本来从end to end都有成熟高效解决方案这样的废话了。迁移的主要问题在于&＃xff0c;它从根本上改变了我们组织并暴露数据的方式&＃xff0c;也就是说对于application本身&＃xff0c;从数据层到业务逻辑层&＃xff0c;可能有极其巨大的影响。所以它非常不适合现有的复杂系统“先破后立”。一个跑着SpringMVC的庞大Web Application如果要改成时髦的GraphQL应用&＃xff1f;这个成本和破坏性难以预计。

并且&＃xff0c;尽管我们说GraphQL有着很好的社区支持&＃xff0c;但本质上使用GraphQL&＃xff0c;就等于要使用React与NodeJS。所以如果并不是正在使用或者计划使用React和Node&＃xff0c;GraphQL是不适合的。

2 牺牲Performance

Performance这件事是无数人所抱怨的。如同我们前面所说的&＃xff0c;GraphQL的解决方案&＃xff0c;相当于把复杂性和heavy lifting从用户的眼前&＃xff0c;移到了后端——很多时候&＃xff0c;就是数据库。

要讨论这一点&＃xff0c;我们首先要提的是&＃xff0c;为了支持GraphQL queries对于数据的查询&＃xff0c;开发者需要编写resolvers。

比如说这样一个schema:

type Query {human(id: ID!): Human
}type Human {name: StringappearsIn: [Episode]starships: [Starship]
}enum Episode {NEWHOPEEMPIREJEDI
}type Starship {name: String
}


对于human&＃xff0c;我们就需要一个最基础的resolver:

Query: {human(obj, args, context, info) {return context.db.loadHumanByID(args.id).then(userData &＃61;> new Human(userData) ) } }

当然这还没完&＃xff0c;对不同的请求类型&＃xff0c;我们要写不同的resolver——不仅原来REST API的CRUD我们都要照顾到&＃xff0c;可能还要根据业务需求写更多的resolver。

这件事情造成的影响&＃xff0c;除了开发者要写大量boilerplate code以外&＃xff0c;还可能导致查询性能低下。一个RESTful Application&＃xff0c;由于每个API的确定性&＃xff0c;我们可以针对每一个API的逻辑&＃xff0c;非常好的优化它们的性能&＃xff0c;所以就算存在一定程度的overfetching/underfetching&＃xff0c;前后端的性能都可以保持在能够接受的范围内。然而想要更普适性一些的GraphQL&＃xff0c;则可能会因为一个层级结构复杂而且许多域都有很大数据量的query跑许多个resolvers&＃xff0c;使得数据库的查询性能成为了瓶颈。

3 缺乏动态类型

强类型的schema固然很省力&＃xff0c;但是如果我们有时候想要一些自由(flexibility)呢&＃xff1f;

比方说&＃xff0c;有时候请求数据时&＃xff0c;请求方并不打算定义好需要的所有层级结构和类型与域。比方说&＃xff0c;我们想要单纯地打印一些数据&＃xff0c;或者获取一个user的一部分fields直接使用&＃xff0c;剩下部分保存起来之后可能使用可能不使用&＃xff0c;但并不确定也不关心剩下的部分具体有那些fields——多余的部分可能作为additional info&＃xff0c;有些域如果有则使用&＃xff0c;没有则跳过。

这只是一个例子&＃xff0c;但是并不是一个钻牛角尖的例子——因为有时候我们所要的objects的properties本来就可能是dynamic的&＃xff0c;我们甚至可能会通过它的properties/fields来判定它是一个怎样的object。

我们要怎么处理这种问题呢&＃xff1f;一种有些荒诞现实主义的做法是&＃xff0c;往Type里加一个JSON string field&＃xff0c;用来提供其相关的所有信息&＃xff0c;这样就可以应对这种情况了。但是这是不是一个合理的做法呢&＃xff1f;

4 简单问题复杂化

最显著的例子&＃xff0c;就是error handling。REST API的情况下&＃xff0c;我们不需要解析Response的内容&＃xff0c;只需要看HTTP status code和message&＃xff0c;就能知道请求是否成功&＃xff0c;大概问题是什么&＃xff0c;处理错误的程序也十分容易编写。

然而GraphQL的情景下&＃xff0c;hmmm...

只要Service本身还在正常运行&＃xff0c;我们就会得到200的HTTP status&＃xff0c;然后需要专门检查response的内容才知道是否有error&＃xff1a;

{"errors": [{"message": "Field \"name\" must not have a selection since type \"String\" has no subfields.","locations": [{"line": 31, "column": 101 } ] } ] }

Another layer of complexity.

同时&＃xff0c;简单的Application&＃xff0c;使用GraphQL其实是非常麻烦的——比如前面提到的resolvers&＃xff0c;需要大量的boilerplate code。另外&＃xff0c;还有各种各样的Types, Queries, Mutators, High-order components需要写。相比之下&＃xff0c;反倒是REST API更好编写和维护。

5 缓存能解决很多问题

编写过HTTP相关程序之后应该都知道&＃xff0c;HTTP本身就是涵盖caching的&＃xff0c;更不要提人们为了提高RESTful Application的performance而针对缓存作出的种种努力。

对于overfetching和请求次数冗余的问题&＃xff0c;假设我们的整个application做了足够合理的设计&＃xff0c;并且由于REST API的固定和单纯性&＃xff0c;缓存已经能非常好地减少大量的traffic。

然而如果选择使用GraphQL&＃xff0c;我们就没有了那么直白的caching解决方案。首先&＃xff0c;只有一个API endpoint的情况下&＃xff0c;每个query都可能不同&＃xff0c;我们不可能非常轻松地对request分门别类做caching。当然并不是说真的没有现成的工具&＃xff0c;比如说Appollo client就提供了InMemoryCache并且&＃xff0c;不论有多少queries&＃xff0c;总是有hot queries和cold ones&＃xff0c;那么pattern总是有的。针对一些特定的query我们还可以定向地缓存&＃xff0c;比如说PersistGraphQL便是这样一个工具。然而这样做其实又是相当于从queries中提炼出类似于原来的REST API的部分了&＃xff0c;并且又增加了一层complexity&＃xff0c;不管是对于开发还是对于performance&＃xff0c;这都可能有不容忽视的影响。

总结

GraphQL最大的优势&＃xff0c;就是它能够大大提高开发者的效率&＃xff0c;而且最大化地简化了前端的数据层的复杂性&＃xff0c;并且使得前后端对数据的组织观点一致。只是使用时&＃xff0c;需要考察scale, performance, tech stack, migration等等方面的要求&＃xff0c;做合理的trade-off&＃xff0c;否则它可能不仅没能提高开发者效率&＃xff0c;反倒制造出更多的问题。