說到前後端分離，絕對就會談論到 API 串接的問題，目前在開發上 API 架構的主流規範 RESTfull API，相信大家也已經相當的熟悉。

而今天要討論的 GraphQL 其實也只是一種不同的 API 架構規範，由 Facebook 提出並開源，從專案維護的角度來說我認為採用 GraphQL 作為 API 規範有許多的好處。

其實 GraphQL 並不是什麼很神奇的黑魔法，一樣是發送 http 請求，只是 body 參數有一套自己的規範罷了。

這篇文章主要在跟大家聊聊 GraphQL 的概念，以及解決了什麼問題。

RESTfull API 的痛點

所謂知己知彼，討論 GraphQL 前自然要先聊聊 RESTfull 的架構有什麼需要被解決的問題，不然又何必沒事找事的更換架構呢？

RESTfull 常見的問題可能有：

1. API 數量太多難以管理。

2. 切分較細時嵌套多層效能不彰。

3. 一套後端多套前端時，共用規劃不易。

4. 使用 field 參數來規範返回值，容易造成資料過多、複雜難讀，畢竟若想減少 API 就需要塞大量參數進 body。

GraphQL 就只是個 POST Body 的 Spec

上面講了 RESTfull API 的痛點，現在就來談談 GraphQL 又怎麼解決吧。

其實，GraphQL 就像是提供了 field 餐數來規範回傳值的 RESTfull API，只不過有個說話比較大聲的人（Facebook）出來訂了個標準罷了。

覺得 GraphQL 不好用想自己搞全新定義？當然也沒問題啊。

只是要造的輪子會有點多而已...

畢竟 GraphQL 已經有相應的生態系了，就連攸關開發體驗的 VSCode plugin 都已經有人幫忙造好輪子了。

補充說明：
GraphQL 的 HTTP Status 固定使用 200 回傳

前端如何使用 GraphQL

在前端使用上需要理解的部分主要是 Schema 與 Query 這兩大部分：

Schema - Server side 定義整體資料結構格式

GraphQL 的 Schema 就像菜單一樣列出關於：

1. 「你可以點的餐點 (查詢的資料)」
2. 「套餐搭配 (資料間的關聯)」
3. 「套餐內容 (資料架構)」

這明明是 Server side 的工作，為什麼前端會需要理解呢？

因為

1. 你要要懂的閱讀 Schema 才能知道有什麼餐點可以點
2. 前端要和後端工程師討論所需要的資料，也就是需要一起討論 Schema 的規格

Query - Client side 符合 Schema 定義的查詢格式

Query 就是你送出的餐點訂購單，只要你的點單有符合 Schema 的規格，GraphQL 就能滿足你的需求，為你送上你所需要的資料。

聽說 GraphQL 前端要什麼資料都可以？

代誌無遐爾簡單！GraphQL 沒那麼神奇，我們定義的 Schema 其實也都還是需要後端工程師來幫忙實作出來，所以如果你索要資料時並沒有基於 Schema 來發送請求的話，就像是你打了個沒被定義的的 API 一般，自然什麼也都取不到囉。

GraphQL 一定要安裝套件才能使用嗎？

又回到上面聊過的話題啦：

GraphQL 也只是一個 POST Body 的 Spec

所以當然也可以直接用 fetch 來打 API，只要 Body 遵照這樣的格式就可以了

{
	query: String // GraphQL 格式字串
	operationName: String
	variables: JSON // 定義 query 中使用到的參數
}

就可以看到還是可以順利的發送請求啦！

...不過這樣是不是太辛苦了呢？