我在如何使用Gatsby建立博客 / How to build a blog with Gatsby這篇文章中提過GraphQL在Gatsby中的應(yīng)用?？偟膩碇v，它是一個新潮的技術(shù)，在適宜的使用場景威力無窮。這里我們來討論一下用/不用GraphQL的理由吧。
簡單介紹GraphQL
GraphQL是Facebook2015年開源的數(shù)據(jù)查詢規(guī)范。現(xiàn)今的絕大多數(shù)Web Service都是RESTful的，也就是說，client和server的主要溝通模式還是靠client根據(jù)自己的需要向server的若干個endpoint (url)發(fā)起請求。由于功能的日漸豐富，對Web Application的要求變得復(fù)雜，REST的一些問題逐漸暴露，人們開始思考如何應(yīng)對這些問題。GraphQL便是具有代表性的一種。GraphQL這個名字，Graph + Query Language，就表明了它的設(shè)計初衷是想要用類似圖的方式表示數(shù)據(jù)：即不像在REST中，數(shù)據(jù)被各個API endpoint所分割，而是有關(guān)聯(lián)和層次結(jié)構(gòu)的被組織在一起。
比方說，假設(shè)這么一個提供user信息的REST API: <server>/users/<id>，和提供用戶的關(guān)注者的API：<server>/users/<id>/followers，以及該用戶關(guān)注對象的API: <server>/users/<id>/followed-users。傳統(tǒng)的REST會需要3次API call才能請求出這三份信息（假設(shè)<server>/users/<id> 沒有包含followers and followed-users信息，which will be a definite redundancy if it does）:
1 GET <server>/users/<id>
{
"user": {
"id" : "u3k2k3k178",
"name" : "graph_ql_activist",
"email" : "graph_ql@activist.com",
"avatar" : "img-url"
}
}
2 GET <server>/users/<id>/followed-users
3 GET <server>/users/<id>/followers
然而如果使用GraphQL，一次API請求即可獲取所有信息并且只選取需要的信息（比如關(guān)于用戶只需要name不要email, followers只要最前面的5個name，followed-users只要頭像等等）:
query {
user (id : "u3k2k3k178") {
name
followers (first: 5) {
name
}
followed-users {
avatar
}
}
}
我們會得到一個完全按照query定制的，不多不少的返回結(jié)果（一般是一個json對象）。
5個使用GraphQL的理由
使用GraphQL的理由， 必然是從討論RESTful Service的局限性和問題開始。
- 數(shù)據(jù)冗余和請求冗余 (overfetching & underfetching)
- 靈活而強類型的schema
- 接口校驗 (validation)
- 接口變動，維護與文檔
- 開發(fā)效率
1 數(shù)據(jù)冗余和請求冗余 (overfetching & underfetching)
根據(jù)users API的例子，我們可以想見，GET用戶信息的REST call，我們就算只是想要一個用戶的一兩條信息(比如name & avatar)，通過該API，我們也會得到他的整個信息。所謂的overfetching就是指的這種情況——請求包含當前不需要的信息。這種浪費會一定程度地整體影響performance，畢竟更多的信息會占用帶寬和占用資源來處理。
同樣從上面的例子我們可以看出來，在許多情況下，如果我們使用RESTful Application，我們常常會需要為聯(lián)系緊密并總量不大的信息，對server進行多次請求，call復(fù)數(shù)個API。
舉一個例子，獲取ID為"abc1"和"abc2"的兩個用戶的信息，我們可能都需要兩個API call，一百個用戶就是一百個GET call，這是不是很莫名其妙呢？這種情況其實就是underfetching——API的response沒有合理的包含足夠信息。
然而在GraphQL，我們只需要非常簡單地改變schema的處理方式，就可以用一個GET call解決：
query {
user (ids : ["ab1", "abc2", ...])
}
我們新打開一個網(wǎng)頁，如果是RESTful Application，可能請求數(shù)據(jù)就會馬上有成百上千的HTTP Request，然而GraphQL的Application則可能只需要一兩個，這相當于把復(fù)雜性和heavy lifting交給了server端和cache層，而不是資源有限，并且speed-sensitive的client端。
2 靈活而強類型的schema
GraphQL是強類型的。也就是說，我們在定義schema時，類似于使用SQL，是顯式地為每一個域定義類型的，比如說：
type User {
id: ID!
name: String!
joinedAt: DateTime!
profileViews: Int! @default(value: 0)
}
type Query {
user(id: ID!): User
}
GraphQL的schema的寫作語言，其實還有一個專門的名稱——Schema Definition Language (SDL)。
這件事情的一大好處是，在編譯或者說build這個Application時，我們就可以檢查并應(yīng)對很多mis-typed的問題，而不需要等到runtime。同時，這樣的寫作方式，也為開發(fā)者提供了巨大的便利。比如說使用YAML來定義API時，編寫本身就是十分麻煩的——可能沒有理想的auto-complete，語法或者語義有錯無法及時發(fā)現(xiàn)，文檔也需要自己小心翼翼地編寫。就算有許多工具(比如Swagger)幫助，這仍然是一個很令人頭疼的問題。
3 接口校驗 (validation)
顯而易見，由于強類型的使用，我們對收到的數(shù)據(jù)進行檢驗的操作變得更為容易和嚴格，自動化的簡便度和有效性也大大提高。對query本身的結(jié)構(gòu)的校驗也相當于是在schema完成后就自動得到了，所以我們甚至不需要再引入任何別的工具或者依賴，就可以很方便地解決所有的validation。
4 接口變動，維護與文檔
RESTful Application里面，一旦要改動API，不管是增刪值域，改變值域范圍，還是增減API數(shù)量，改變API url，都很容易變成傷筋動骨的行為。
如果說改動API url(比如/posts --> /articles)，我們思考一下那些地方可能要改動呢？首先client端的代碼定然要改變request的API endpoint；中間的caching service可能也需要改要訪問的endpoint；如果有l(wèi)oad balancer, reverse proxy，那也可能需要變動；server端自己當然也是需要做相應(yīng)改變的，這根據(jù)application自己的編寫情況而定。
相比之下，GraphQL就輕松多了。GraphQL的Service，API endpoint很可能就只有一個，根本不太會有改動URL path的情況。至始至終，數(shù)據(jù)的請求方都只需要說明自己需要什么內(nèi)容，而不需要關(guān)心后端的任何表述和實現(xiàn)。數(shù)據(jù)提供方，比如server，只要提供的數(shù)據(jù)是請求方的母集，不論它們各自怎么變，都不需要因為對方牽一發(fā)而動全身。
在現(xiàn)有工具下，REST API的文檔沒有到過分難以編寫和維護的程度，不過跟可以完全auto-generate并且可讀性可以很好地保障的GraphQL比起來，還是略顯遜色——畢竟GraphQL甚至不需要我們費力地引入多少其他的工具。
再一點，我們都知道REST API有一個versioning: V1, V2, etc.這件事非常的雞肋而且非常麻煩，有時候還要考慮backward compatibility。GraphQL從本質(zhì)上不存在這一點，大大減少了冗余。增加數(shù)據(jù)的fields和types甚至不需要數(shù)據(jù)請求方做任何改動，只需要按需添加相應(yīng)queries即可。
另外，有了GraphQL的queries，我們可以非常精準地進行數(shù)據(jù)分析(Analytics)。比如說具體哪些queries下的fields / objects在哪些情況下是被請求的最多/最頻繁的——而不像RESTful Application中，如果不進行復(fù)雜的Analytics，我們只能知道每個API被請求的情況，而不是具體到它們內(nèi)含的數(shù)據(jù)。
5 開發(fā)效率
相信上面說的這些點已經(jīng)充分能夠說明GraphQL對于開發(fā)效率能夠得到怎樣的提升了。
再補充幾點。
GraphQL有一個非常好的ecosystem。由于它方便開發(fā)者上手和使用-->大家爭相為它提供各種工具和支持-->GraphQL變得更好用-->社區(qū)文化和支持更盛-->... 如同其他好的開源項目一樣，GraphQL有著一個非常好的循環(huán)正向反饋。
對于一套REST API，哪怕只是其使用者(consumer)，新接觸的開發(fā)者需要一定時間去熟悉它的大致邏輯，要求乃至實現(xiàn)。然而GraphQL使用者甚至不需要去看類似API文檔的東西，因為我們可以直接通過query查詢query里面所有層級的type的所有域和它們各自的type，這不得不說很方便：
{
__schema {
types {
name
}
}
}
==> 我們可以看到query所涉及的所有內(nèi)容的類型：
{
"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，我還有個非常個人的理由偏愛它：對于API的測試，相比于比較傳統(tǒng)的Postman或者自己寫腳本進行最基本的http call（或者curl），我更喜歡使用insomnia這個更為優(yōu)雅的工具。而在此之上，它還非常好地支持了GraphQL，這讓我的開發(fā)和測試體驗變得更好了。（Postman至今還不支持GraphQL，雖然本質(zhì)上我們可以用它make GraphQL query call）
5個不用GraphQL的理由
- 遷移成本
- 犧牲Performance
- 缺乏動態(tài)類型
- 簡單問題復(fù)雜化
- 緩存能解決很多問題
1 使用與遷移成本
現(xiàn)有的RESTful Application如果要改造成GraphQL Application？
hmmm...
我們需要三思。首先我就不說RESTful本來從end to end都有成熟高效解決方案這樣的廢話了。遷移的主要問題在于，它從根本上改變了我們組織并暴露數(shù)據(jù)的方式，也就是說對于application本身，從數(shù)據(jù)層到業(yè)務(wù)邏輯層，可能有極其巨大的影響。所以它非常不適合現(xiàn)有的復(fù)雜系統(tǒng)“先破后立”。一個跑著SpringMVC的龐大Web Application如果要改成時髦的GraphQL應(yīng)用？這個成本和破壞性難以預(yù)計。
并且，盡管我們說GraphQL有著很好的社區(qū)支持，但本質(zhì)上使用GraphQL，就等于要使用React與NodeJS。所以如果并不是正在使用或者計劃使用React和Node，GraphQL是不適合的。
2 犧牲Performance
Performance這件事是無數(shù)人所抱怨的。如同我們前面所說的，GraphQL的解決方案，相當于把復(fù)雜性和heavy lifting從用戶的眼前，移到了后端——很多時候，就是數(shù)據(jù)庫。
要討論這一點，我們首先要提的是，為了支持GraphQL queries對于數(shù)據(jù)的查詢，開發(fā)者需要編寫resolvers。
比如說這樣一個schema:
type Query {
human(id: ID!): Human
}
type Human {
name: String
appearsIn: [Episode]
starships: [Starship]
}
enum Episode {
NEWHOPE
EMPIRE
JEDI
}
type Starship {
name: String
}
對于human，我們就需要一個最基礎(chǔ)的resolver:
Query: {
human(obj, args, context, info) {
return context.db.loadHumanByID(args.id).then(
userData => new Human(userData)
)
}
}
當然這還沒完，對不同的請求類型，我們要寫不同的resolver——不僅原來REST API的CRUD我們都要照顧到，可能還要根據(jù)業(yè)務(wù)需求寫更多的resolver。
這件事情造成的影響，除了開發(fā)者要寫大量boilerplate code以外，還可能導致查詢性能低下。一個RESTful Application，由于每個API的確定性，我們可以針對每一個API的邏輯，非常好的優(yōu)化它們的性能，所以就算存在一定程度的overfetching/underfetching，前后端的性能都可以保持在能夠接受的范圍內(nèi)。然而想要更普適性一些的GraphQL，則可能會因為一個層級結(jié)構(gòu)復(fù)雜而且許多域都有很大數(shù)據(jù)量的query跑許多個resolvers，使得數(shù)據(jù)庫的查詢性能成為了瓶頸。
3 缺乏動態(tài)類型
強類型的schema固然很省力，但是如果我們有時候想要一些自由(flexibility)呢？
比方說，有時候請求數(shù)據(jù)時，請求方并不打算定義好需要的所有層級結(jié)構(gòu)和類型與域。比方說，我們想要單純地打印一些數(shù)據(jù)，或者獲取一個user的一部分fields直接使用，剩下部分保存起來之后可能使用可能不使用，但并不確定也不關(guān)心剩下的部分具體有那些fields——多余的部分可能作為additional info，有些域如果有則使用，沒有則跳過。
這只是一個例子，但是并不是一個鉆牛角尖的例子——因為有時候我們所要的objects的properties本來就可能是dynamic的，我們甚至可能會通過它的properties/fields來判定它是一個怎樣的object。
我們要怎么處理這種問題呢？一種有些荒誕現(xiàn)實主義的做法是，往Type里加一個JSON string field，用來提供其相關(guān)的所有信息，這樣就可以應(yīng)對這種情況了。但是這是不是一個合理的做法呢？
4 簡單問題復(fù)雜化
最顯著的例子，就是error handling。REST API的情況下，我們不需要解析Response的內(nèi)容，只需要看HTTP status code和message，就能知道請求是否成功，大概問題是什么，處理錯誤的程序也十分容易編寫。
然而GraphQL的情景下，hmmm...
只要Service本身還在正常運行，我們就會得到200的HTTP status，然后需要專門檢查response的內(nèi)容才知道是否有error：
{
"errors": [
{
"message": "Field \"name\" must not have a selection since type \"String\" has no subfields.",
"locations": [
{
"line": 31,
"column": 101
}
]
}
]
}
Another layer of complexity.
同時，簡單的Application，使用GraphQL其實是非常麻煩的——比如前面提到的resolvers，需要大量的boilerplate code。另外，還有各種各樣的Types, Queries, Mutators, High-order components需要寫。相比之下，反倒是REST API更好編寫和維護。
5 緩存能解決很多問題
編寫過HTTP相關(guān)程序之后應(yīng)該都知道，HTTP本身就是涵蓋caching的，更不要提人們?yōu)榱颂岣逺ESTful Application的performance而針對緩存作出的種種努力。
對于overfetching和請求次數(shù)冗余的問題，假設(shè)我們的整個application做了足夠合理的設(shè)計，并且由于REST API的固定和單純性，緩存已經(jīng)能非常好地減少大量的traffic。
然而如果選擇使用GraphQL，我們就沒有了那么直白的caching解決方案。首先，只有一個API endpoint的情況下，每個query都可能不同，我們不可能非常輕松地對request分門別類做caching。當然并不是說真的沒有現(xiàn)成的工具，比如說Appollo client就提供了InMemoryCache并且，不論有多少queries，總是有hot queries和cold ones，那么pattern總是有的。針對一些特定的query我們還可以定向地緩存，比如說PersistGraphQL便是這樣一個工具。然而這樣做其實又是相當于從queries中提煉出類似于原來的REST API的部分了，并且又增加了一層complexity，不管是對于開發(fā)還是對于performance，這都可能有不容忽視的影響。
總結(jié)
GraphQL最大的優(yōu)勢，就是它能夠大大提高開發(fā)者的效率，而且最大化地簡化了前端的數(shù)據(jù)層的復(fù)雜性，并且使得前后端對數(shù)據(jù)的組織觀點一致。只是使用時，需要考察scale, performance, tech stack, migration等等方面的要求，做合理的trade-off，否則它可能不僅沒能提高開發(fā)者效率，反倒制造出更多的問題。
