GraphQL 是啥？

官方介紹：GraphQL 既是一種用于 API 的查詢語言也是一個滿足你數據查詢的運行時。GraphQL 對你的 API 中的數據提供了一套易于理解的完整描述，使得客戶端能夠準確地獲得它需要的數據，而且沒有任何冗余，也讓 API 更容易地隨著時間推移而演進，還能用于構建強大的開發者工具。

通俗點說就是： 我們在使用 Restful 風格接口的時候，增刪改查可能會有四個接口，但是如果你用了 GraphQL 的話，可能就只需要一個接口，通過傳遞不同的模板參數，去執行不同的增刪改查操作。

你可以靈活地去調用 GraphQL 去獲取你自己想要的數據。

簡單實踐

GraphQL 優勢？

很多公司的后端使用了 GraphQL 來代替之前的 Restful 接口風格，那么為啥呢？GraphQL 到底有什么優勢，值得這些公司去使用呢？

1.靈活

我們使用 Restful 的時候，大部分情況下一個接口只能返回一種數據，如果你想要另一種數據，那只能是重新再寫一個接口。

但是在 GraphQL 中，返回什么樣的數據，可以由調用方去決定，就比如剛剛實踐的例子，假如我傳了：

那么數據庫查詢會返回給我兩個字段的數據：

如果你只需要一個字段，那么你可以傳：

那么數據庫查詢就只會返回給你一個字段：

2.精簡

其實剛剛已經舉過例子了，Restful 風格下，增刪改查需要寫四個接口，但是 GraphQL 可能只需要一個接口即可，大大減少了接口代碼。

3.統一

因為 GraphQL 查詢的入口大大減少，甚至可能一個項目只有一個查詢入口，所以統一了查詢的規范。

GraphQL 局限性

1.學習成本

大部分前后端都習慣了 Restful 風格，想要轉 GraphQL 需要一定的學習成本，所以我們可以看到一般使用 GraphQL 的都是初創公司或者大公司，只有這些公司才有條件或者成本區做這件事。

2.建設成本

很多公司都一直是建設 Restful 的基礎架構，如果想要轉 GraphQL，那意味著可能需要改造現有的架構，這是需要時間成本和建設成本的。

3.雞肋？

說 GraphQL 好用吧，確實挺好用，但是說非他不可吧，好像也不是。感覺就是還沒到非用他不可的地步。

4.安全性

正是因為 GraphQL 的靈活性開放性，所以導致了他的安全系數大大降低。

調用方能靈活獲取數據，那是萬萬不可的，因為有一些私密數據可不能給他們去獲取~

可能還有遇到一些惡意用戶，對你的數據進行查詢，進而對你造成不利。

5.排隊？

只有一個查詢入口的話，那如果很多調用方同時調用的話，難道要排隊查詢嗎？這樣的話會不會查詢時長會很久？