來聊個簡單的議題? 『為什麼要學 GraphQL?』
部落格好讀版: https://bit.ly/why-is-graphql
身為網站工程師，您不能不知道什麼是 GraphQL，這是一個前端跟後端溝通的 API
Query 語法，大幅改善了前後端的合作模式，這篇會跟大家介紹為什麼麼要學 GraphQL，
以及整理出三大 GraphQL 優勢，讓大家了解跟傳統 Restful API 有什麼不同。當然不是
叫開發者捨棄 Restful API，而是根據專案的不同，來決定不同的技術 Stack。像是服務
跟服務之前您說要用 GraphQL，肯定被打槍，而是要用更輕量的 Restful API 或 GRPC。
好了，底下來說明三點 GraphQL 的優勢。
影片: https://www.youtube.com/watch?v=00NKSvAraLQ
01:36 一次連線拿回前端所需資料
04:07 根據不同畫面拿不同欄位資料
06:06 即時 API 文件
1. 一次連線拿回前端所需資料
GraphQL 可以直接將 Query 語法寫在一起送到後端，後端全部處理完成後再一次回給前
端，大幅降低 connection 次數。
2. 根據不同畫面拿不同欄位資料
在 Restful API 世界裡，後端會一次回傳所有資料，不會管前端需不需要這欄位，也就
是前端沒有權力決定該拿什麼欄位，這樣會造成很多不必要的網路傳輸。Restful API
也可以根據不同畫面回不同的欄位資訊，卻造成後端很大的負擔。這時候用 GraphQL 解
決了此問題，只要在 Query 語法內定義好要拿的資料即可。
3. 即時 API 文件
大家應該都知道文件沒有一天是即時更新的，寫 Restful API 要求後端也補上文件，簡
直是難上加難，專案在趕的時候，誰還在管文件有沒有到最新，這邊就要推薦 GraphQL
了，因為只要程式碼一動，開發者透過 Client 工具就可以即時知道現在的 API 文件。

廣告文又來了除了第一點以外其他兩項REST也做得到

針對第一點詢問一下，這個成立的條件是在query的input相同？

推推

同問第一題

怎麼沒說graphQL文件和規則像大便

當初因為玩Gatsby.JS，所以順道學了GrapghQL。

@lerdor 你可以把多個 query 語法寫在一起blog 裡面有範例，可以參考看看，就大概知道了@mystery7631 也不是沒遇過雷 XD

還是傳統md檔最好用

不覺得graph那麼神，黑名單白名單訂一訂就訂死你

沒辦法做conn pool?

小弟不才，REST API有辦法做conn pool 嗎？

這是宗教問題

Swagger配Rest不行嗎？

query語法送到後端啊...聽起來就很雷的感覺https://ithelp.ithome.com.tw/articles/10208008沒用好就injection吃到飽

swagger跟graphql就相當於手動更新和自動更新

Size Limiting, Query Whitelisting, Depth Limiting這些都是需要自己再額外控制，增加 GraphQL 安全性 ..

為何不直接寫後端swagger可以隨code更新 難道你還手動維護 json or yml?

同意前面說的 實在很難做auth

你還是要用codegen做 而graphql可以直接查schema真妙 推文都在守著RESTful 沒人想討論graph帶來的可能

請問swagger怎麼隨code更新

本文123點都不是graphql特有的優點 想推廣也不是用這些

官網特色就說得夠清楚了 https://graphql.org/原 po 也沒有說錯啊 不知道大家在砲轟什麼

文人相輕的日常

graphql 真的讓串 api 的複用變得相當的簡單

推一個 有內容可以討論 不太明白在噓什麼

甚至在 react apollo 的幫助下 整個 component 裝下去資料也會順便拉好後端工程師懶得幫你做資料轉換 過濾 都可以讓你在 gql上做好甚至可以用 directive 讓這些邏輯應用在各個欄位上

像樓上幾位提的幾點還比較有推廣到

GraphQL 針對 query 來說，考量拿到什麼欄位，這倒是小事，比較要注意的是欄位往下延伸時，有沒有使用 dataloader 協助處理，否則db 查詢會搞爆 server

誰沒文件在開發，先討論好文件才開發吧

swagger表示 我被當塑膠

GraphQL就相當把後端結構完全洩漏給前端

https://reurl.cc/z8GOQk 還是要看實際應用和需求

graphql就是垃圾，就是個前端很爽，後端很幹的概念

後端為什麼很幹

我用Go+GraphQL+Apollo(TS)，用了就回不去了

@knives 什麼是後端很幹的概念？

GraphQL和直接開SQL給前端有什麼本質上的差別?完全失去封裝的意義.

我想詢問的是第一點下，若要組裝A跟B的query但是他們的input也分別是C跟D還可以成立嗎？

就後端多一層就好了

@lerdor 可以吧，所有的 Query 都由 Client 自行組裝

例如說電商的商品資料在 mobile view 可能只需要 a b c欄位 在 desktop web 下可能會需要 b c d e f 欄位graphql 就提供 quary language 讓開發者可以 specify所需要的資料欄位 而不會有 over fetch 的問題也不需要讓後端為各個不同的需求寫不同的 end point的確 restful 可以利用帶參數來完成這種需求 但這就需要工程師自己弄 也沒有 graqhql 的 query 來的容易

不懂為啥說GraphQL跟直接開SQL給前端一樣

不懂GQL 的優勢 還出來帶風向 推文水準差矣

最近有用 GraphQL 真心好用

GraphQL最大的特點就是單一的Endpoint跟Type system

同樣不懂哪裡跟直接開SQL給前端相同

推用心整理

大概是怕學新技術的老人看了很氣

推，等等消化一下xD

剛看了下 可以說GraphQL非但沒有破壞封裝 反而是增加新的封裝 是說 GraphQL是對後端SQL(或其他DB)的封裝也因此 若應用於不適合的情景 可能會有過度封裝/增加不必要複雜度之虞或許可以這樣說 已經簡單易懂夠高效的RestAPI 改成GraphQL是沒啥意義的事情 甚至作繭自縛