PTT評價

[心得] 為什麼要學 GraphQL?

看板Soft_Job標題[心得] 為什麼要學 GraphQL?作者
appleboy46
(小惡魔)
時間推噓13 推:20 噓:7 →:53

來聊個簡單的議題? 『為什麼要學 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 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.25.183.202 (臺灣)
PTT 網址

hegemon06/20 14:59廣告文又來了

hegemon06/20 15:01除了第一點以外其他兩項REST也做得到

lerdor06/20 15:06針對第一點詢問一下,這個成立的條件是在query的input相同

lerdor06/20 15:06

sp06343906/20 15:24推推

shingatter06/20 15:41同問第一題

mystery763106/20 15:59怎麼沒說graphQL文件和規則像大便

jobintan06/20 16:26當初因為玩Gatsby.JS,所以順道學了GrapghQL。

appleboy4606/20 16:29@lerdor 你可以把多個 query 語法寫在一起

appleboy4606/20 16:29blog 裡面有範例,可以參考看看,就大概知道了

appleboy4606/20 16:30@mystery7631 也不是沒遇過雷 XD

stupid031906/20 16:39還是傳統md檔最好用

ray959219706/20 16:57不覺得graph那麼神,黑名單白名單訂一訂就訂死你

BlacksPig06/20 18:00沒辦法做conn pool?

s06yji306/20 18:05小弟不才,REST API有辦法做conn pool 嗎?

appleboy4606/20 18:08https://bit.ly/2BoW4VU

roccqqck06/20 18:35這是宗教問題

askaleroux06/20 19:55Swagger配Rest不行嗎?

bheegrl06/20 20:22query語法送到後端啊...聽起來就很雷的感覺

bheegrl06/20 20:24沒用好就injection吃到飽

x00003200106/20 20:24swagger跟graphql就相當於手動更新和自動更新

appleboy4606/20 20:34Size Limiting, Query Whitelisting, Depth Limiting

appleboy4606/20 20:34這些都是需要自己再額外控制,增加 GraphQL 安全性 ..

sharku06/20 21:18為何不直接寫後端

sharku06/20 21:19swagger可以隨code更新 難道你還手動維護 json or yml?

xlf06/20 21:55同意前面說的 實在很難做auth

x00003200106/20 22:02你還是要用codegen做 而graphql可以直接查schema

x00003200106/20 22:05真妙 推文都在守著RESTful 沒人想討論graph帶來的可能

s2460106/20 22:10請問swagger怎麼隨code更新

sharku06/20 22:10本文123點都不是graphql特有的優點 想推廣也不是用這些

zeroshine06/20 22:22官網特色就說得夠清楚了 https://graphql.org/

zeroshine06/20 22:23原 po 也沒有說錯啊 不知道大家在砲轟什麼

a898933206/20 22:24文人相輕的日常

zeroshine06/20 22:25graphql 真的讓串 api 的複用變得相當的簡單

okd06/20 22:25推一個 有內容可以討論 不太明白在噓什麼

zeroshine06/20 22:26甚至在 react apollo 的幫助下 整個 component 裝下去

zeroshine06/20 22:26資料也會順便拉好

zeroshine06/20 22:28後端工程師懶得幫你做資料轉換 過濾 都可以讓你在 gql

zeroshine06/20 22:28上做好

zeroshine06/20 22:30甚至可以用 directive 讓這些邏輯應用在各個欄位上

sharku06/20 22:54像樓上幾位提的幾點還比較有推廣到

sojoasd06/21 00:27GraphQL 針對 query 來說,考量拿到什麼欄位,這倒是小

sojoasd06/21 00:27事,比較要注意的是欄位往下延伸時,有沒有使用 dataload

sojoasd06/21 00:27er 協助處理,否則db 查詢會搞爆 server

SIMD06/21 00:44誰沒文件在開發,先討論好文件才開發吧

jinmin8806/21 01:36swagger表示 我被當塑膠

bibo990106/21 05:48GraphQL就相當把後端結構完全洩漏給前端

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

knives06/21 07:24graphql就是垃圾,就是個前端很爽,後端很幹的概念

b8504031206/21 10:02後端為什麼很幹

mychiux41306/21 11:48我用Go+GraphQL+Apollo(TS),用了就回不去了

appleboy4606/21 11:48@knives 什麼是後端很幹的概念?

bibo990106/21 15:00GraphQL和直接開SQL給前端有什麼本質上的差別?

bibo990106/21 15:00完全失去封裝的意義.

lerdor06/21 15:29我想詢問的是第一點下,若要組裝A跟B的query但是他們的inp

lerdor06/21 15:29ut也分別是C跟D還可以成立嗎?

neo527706/21 15:31就後端多一層就好了

appleboy4606/21 15:36@lerdor 可以吧,所有的 Query 都由 Client 自行組裝

zeroshine06/21 16:40例如說電商的商品資料在 mobile view 可能只需要 a b c

zeroshine06/21 16:40欄位 在 desktop web 下可能會需要 b c d e f 欄位

zeroshine06/21 16:41graphql 就提供 quary language 讓開發者可以 specify

zeroshine06/21 16:42所需要的資料欄位 而不會有 over fetch 的問題

zeroshine06/21 16:42也不需要讓後端為各個不同的需求寫不同的 end point

zeroshine06/21 16:45的確 restful 可以利用帶參數來完成這種需求 但這就需

zeroshine06/21 16:46要工程師自己弄 也沒有 graqhql 的 query 來的容易

DendiQ06/21 16:47不懂為啥說GraphQL跟直接開SQL給前端一樣

jaspreme20606/21 18:35不懂GQL 的優勢 還出來帶風向 推文水準差矣

paint06/21 20:48最近有用 GraphQL 真心好用

PretenderY06/21 21:48GraphQL最大的特點就是單一的Endpoint跟Type system

dreamnook06/22 00:00同樣不懂哪裡跟直接開SQL給前端相同

marc4706/23 00:43推用心整理

vacuum06/23 15:36大概是怕學新技術的老人看了很氣

lestibournes06/24 22:20推,等等消化一下xD

rodion06/29 10:58剛看了下 可以說GraphQL非但沒有破壞封裝 反而是增加新的

rodion06/29 10:58封裝 是說 GraphQL是對後端SQL(或其他DB)的封裝

rodion06/29 10:59也因此 若應用於不適合的情景 可能會有過度封裝/增加不必

rodion06/29 10:59要複雜度之虞

rodion06/29 11:01或許可以這樣說 已經簡單易懂夠高效的RestAPI 改成GraphQL

rodion06/29 11:01是沒啥意義的事情 甚至作繭自縛