作者appleboy46 (小惡魔)
看板Soft_Job
標題[心得] 為什麼要學 GraphQL?
時間Sat Jun 20 14:37:36 2020
來聊個簡單的議題? 『為什麼要學 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 文件。
--
Go 教學:
https://www.udemy.com/course/golang-fight/?couponCode=202006
Drone 教學:
https://www.udemy.com/course/devops-oneday/?couponCode=202006
Docker 教學:
https://www.udemy.com/course/docker-practice/?couponCode=202006
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.25.183.202 (臺灣)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1592635061.A.A78.html
1F：噓 hegemon: 廣告文又來了 06/20 14:59
2F：噓 hegemon: 除了第一點以外其他兩項REST也做得到 06/20 15:01
3F：推 lerdor: 針對第一點詢問一下，這個成立的條件是在query的input相同 06/20 15:06
4F：→ lerdor: ？ 06/20 15:06
5F：推 sp063439: 推推 06/20 15:24
6F：推 shingatter: 同問第一題 06/20 15:41
7F：→ mystery7631: 怎麼沒說graphQL文件和規則像大便 06/20 15:59
8F：→ jobintan: 當初因為玩Gatsby.JS，所以順道學了GrapghQL。 06/20 16:26
9F：→ appleboy46: @lerdor 你可以把多個 query 語法寫在一起 06/20 16:29
10F：→ appleboy46: blog 裡面有範例，可以參考看看，就大概知道了 06/20 16:29
11F：→ appleboy46: @mystery7631 也不是沒遇過雷 XD 06/20 16:30
12F：推 stupid0319: 還是傳統md檔最好用 06/20 16:39
13F：噓 ray9592197: 不覺得graph那麼神，黑名單白名單訂一訂就訂死你 06/20 16:57
14F：→ BlacksPig: 沒辦法做conn pool? 06/20 18:00
15F：推 s06yji3: 小弟不才，REST API有辦法做conn pool 嗎？ 06/20 18:05
17F：→ roccqqck: 這是宗教問題 06/20 18:35
18F：→ askaleroux: Swagger配Rest不行嗎？ 06/20 19:55
19F：→ bheegrl: query語法送到後端啊...聽起來就很雷的感覺 06/20 20:22
21F：→ bheegrl: 沒用好就injection吃到飽 06/20 20:24
22F：→ x000032001: swagger跟graphql就相當於手動更新和自動更新 06/20 20:24
23F：→ appleboy46: Size Limiting, Query Whitelisting, Depth Limiting 06/20 20:34
24F：→ appleboy46: 這些都是需要自己再額外控制，增加 GraphQL 安全性 .. 06/20 20:34
25F：噓 sharku: 為何不直接寫後端 06/20 21:18
26F：→ sharku: swagger可以隨code更新 難道你還手動維護 json or yml? 06/20 21:19
27F：→ xlf: 同意前面說的 實在很難做auth 06/20 21:55
28F：→ x000032001: 你還是要用codegen做 而graphql可以直接查schema 06/20 22:02
29F：→ x000032001: 真妙 推文都在守著RESTful 沒人想討論graph帶來的可能 06/20 22:05
30F：推 s24601: 請問swagger怎麼隨code更新 06/20 22:10
31F：→ sharku: 本文123點都不是graphql特有的優點 想推廣也不是用這些 06/20 22:10
33F：→ zeroshine: 原 po 也沒有說錯啊 不知道大家在砲轟什麼 06/20 22:23
34F：推 a8989332: 文人相輕的日常 06/20 22:24
35F：→ zeroshine: graphql 真的讓串 api 的複用變得相當的簡單 06/20 22:25
36F：推 okd: 推一個 有內容可以討論 不太明白在噓什麼 06/20 22:25
37F：→ zeroshine: 甚至在 react apollo 的幫助下 整個 component 裝下去 06/20 22:26
38F：→ zeroshine: 資料也會順便拉好 06/20 22:26
39F：→ zeroshine: 後端工程師懶得幫你做資料轉換 過濾 都可以讓你在 gql 06/20 22:28
40F：→ zeroshine: 上做好 06/20 22:28
41F：推 zeroshine: 甚至可以用 directive 讓這些邏輯應用在各個欄位上 06/20 22:30
42F：→ sharku: 像樓上幾位提的幾點還比較有推廣到 06/20 22:54
43F：推 sojoasd: GraphQL 針對 query 來說，考量拿到什麼欄位，這倒是小 06/21 00:27
44F：→ sojoasd: 事，比較要注意的是欄位往下延伸時，有沒有使用 dataload 06/21 00:27
45F：→ sojoasd: er 協助處理，否則db 查詢會搞爆 server 06/21 00:27
46F：噓 SIMD: 誰沒文件在開發，先討論好文件才開發吧 06/21 00:44
47F：→ jinmin88: swagger表示 我被當塑膠 06/21 01:36
48F：噓 bibo9901: GraphQL就相當把後端結構完全洩漏給前端 06/21 05:48
50F：推 knives: graphql就是垃圾，就是個前端很爽，後端很幹的概念 06/21 07:24
51F：推 b85040312: 後端為什麼很幹 06/21 10:02
52F：推 mychiux413: 我用Go+GraphQL+Apollo(TS)，用了就回不去了 06/21 11:48
53F：→ appleboy46: @knives 什麼是後端很幹的概念？ 06/21 11:48
54F：噓 bibo9901: GraphQL和直接開SQL給前端有什麼本質上的差別? 06/21 15:00
55F：→ bibo9901: 完全失去封裝的意義. 06/21 15:00
56F：→ lerdor: 我想詢問的是第一點下，若要組裝A跟B的query但是他們的inp 06/21 15:29
57F：→ lerdor: ut也分別是C跟D還可以成立嗎？ 06/21 15:29
58F：→ neo5277: 就後端多一層就好了 06/21 15:31
59F：→ appleboy46: @lerdor 可以吧，所有的 Query 都由 Client 自行組裝 06/21 15:36
60F：推 zeroshine: 例如說電商的商品資料在 mobile view 可能只需要 a b c 06/21 16:40
61F：→ zeroshine: 欄位 在 desktop web 下可能會需要 b c d e f 欄位 06/21 16:40
62F：→ zeroshine: graphql 就提供 quary language 讓開發者可以 specify 06/21 16:41
63F：→ zeroshine: 所需要的資料欄位 而不會有 over fetch 的問題 06/21 16:42
64F：→ zeroshine: 也不需要讓後端為各個不同的需求寫不同的 end point 06/21 16:42
65F：推 zeroshine: 的確 restful 可以利用帶參數來完成這種需求 但這就需 06/21 16:45
66F：→ zeroshine: 要工程師自己弄 也沒有 graqhql 的 query 來的容易 06/21 16:46
67F：→ DendiQ: 不懂為啥說GraphQL跟直接開SQL給前端一樣 06/21 16:47
68F：推 jaspreme206: 不懂GQL 的優勢 還出來帶風向 推文水準差矣 06/21 18:35
69F：→ paint: 最近有用 GraphQL 真心好用 06/21 20:48
70F：→ PretenderY: GraphQL最大的特點就是單一的Endpoint跟Type system 06/21 21:48
71F：→ dreamnook: 同樣不懂哪裡跟直接開SQL給前端相同 06/22 00:00
72F：推 marc47: 推用心整理 06/23 00:43
73F：推 vacuum: 大概是怕學新技術的老人看了很氣 06/23 15:36
74F：推 lestibournes: 推，等等消化一下xD 06/24 22:20
75F：→ rodion: 剛看了下 可以說GraphQL非但沒有破壞封裝 反而是增加新的 06/29 10:58
76F：→ rodion: 封裝 是說 GraphQL是對後端SQL(或其他DB)的封裝 06/29 10:58
77F：→ rodion: 也因此 若應用於不適合的情景 可能會有過度封裝/增加不必 06/29 10:59
78F：→ rodion: 要複雜度之虞 06/29 10:59
79F：→ rodion: 或許可以這樣說 已經簡單易懂夠高效的RestAPI 改成GraphQL 06/29 11:01
80F：→ rodion: 是沒啥意義的事情 甚至作繭自縛 06/29 11:01