GraphQL 从入门到放弃系列

使用 GraphQL，你可以将你所有的业务建模为图。
中文官网：http://graphql.cn/

REST是一种古老的面向服务端和用户端的架构风格。它定义了一系列严格的构建API的准则，用简单的方式形容资源，并认为大部分时候违反这些准则会让软件的扩展性受限。随着服务端SOA和用户端Ajax的崛起，通信扩展问题变得越来越重要，REST得以广泛被运用。

在MicroService逐步流行的今天，RESTful API已经成为主流。不过随着前台和手机端的迅猛发展，REST也面临严峻挑战。

REST API存在问题：

1. 资源分类导致性能受限。前台的效率主要来源于http请求

2. 在现代场景中难于维护。尽管REST的目标是易于维护和扩展，但在Web前台/用户端领域，它的体现并没有想象得那么好。我们经常说最显著的Code smell就是重复。

3. 缺乏束缚。对REST来说，不同版本之间的兼容能力非常弱小。

4. 严格，笼统，但并不能处理用户端问题。我们经常可以在网上看到互相指责的文章和探讨，基本上都是一方列举出自己使用RESTful API遇到的实际问题，而另一方认为前者实际应用违背了哪条REST准则，因而不是RESTful API。

GraphQL是什么？

image

GraphQL是一个查询语言，由Facebook开发，用于替换RESTful API。服务端可以用任何的语言实现。

GraphQL优势：

1. 需求驱动。可以减少了沟通成本。

2. 一次请求复杂数据。

3. 静态类型。

4. 兼容多版本。

GraphQL也存在少量潜在的问题，如安全问题，需要重新思考Cache策略等。

那么 GraphQL 与 RESTful 的具体区别有什么呢？我觉得主要是两点。

• 入口 (entry point)

RESTful 的核心理念在于资源 (resource)，且讲究一个 RESTful 接口仅操作单一资源；因而在你使用 RESTful 时，会设计出大量的接口。

GraphQL 是单一入口，一般配置在 [host]/graphql/，所有的资源都从该入口通过 GraphQL 的语句获取或者修改（当然 GraphQL 亦支持多入口，但显然多入口的数量也远小于 RESTful）。

• 所见即所得

查询的返回结果就是输入的查询结构的准确映射

查询：

{

hero {
name
}
}

返回：

{

“data”: {
“hero”: {
“name”: “R2-D2”
}
}
}

• 减少网络请求次数

假如设计的数据结构是从属的，直接就能在查询语句中指定。

{
hero (id: “10”){
name
# 查询可以有备注！
friends {
name
}
}
}

查询结果：

{
“data”: {
“hero”: {
“name”: “R2-D2”,
“friends”: [
{
“name”: “Luke Skywalker”
},
{
“name”: “Han Solo”
},
{
“name”: “Leia Organa”
}
]
}
}

}

即便数据结构是独立的，也可以在查询语句中指定上下文，只要要一次网络请求，就能取得资源和子资源的数据。

query {
hero {
name
}
droid(id: “2000”) {
name
}
}

4 代码即文档

GraphQL会把schema定义和相关的注释生成可视化的文档，从而使得代码的变更，直接就反映到最新的文档上，避免RESTful中手工维护可能会造成代码、文档不一致的问题。

5 参数类型强校验

RESTful方案本身没有对参数的类型做规定，往往都需要自行实现参数的校验机制，以确保安全。

但GraphQL提供了强类型的schema机制，从而天然确保了参数类型的合法性。

获取更多内容请关注微信公众号豆志昂扬:

• 直接增加公众号豆志昂扬；
• 微信扫描下图二维码；