[心得] 為什麼要學 GraphQL?
來聊個簡單的議題? 『為什麼要學 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
--
廣告文又來了
除了第一點以外其他兩項REST也做得到
針對第一點詢問一下,這個成立的條件是在query的input相同
?
推推
同問第一題
怎麼沒說graphQL文件和規則像大便
當初因為玩Gatsby.JS,所以順道學了GrapghQL。
@lerdor 你可以把多個 query 語法寫在一起
blog 裡面有範例,可以參考看看,就大概知道了
@mystery7631 也不是沒遇過雷 XD
還是傳統md檔最好用
不覺得graph那麼神,黑名單白名單訂一訂就訂死你
沒辦法做conn pool?
小弟不才,REST API有辦法做conn pool 嗎?
這是宗教問題
Swagger配Rest不行嗎?
query語法送到後端啊...聽起來就很雷的感覺
沒用好就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 來說,考量拿到什麼欄位,這倒是小
事,比較要注意的是欄位往下延伸時,有沒有使用 dataload
er 協助處理,否則db 查詢會搞爆 server
誰沒文件在開發,先討論好文件才開發吧
swagger表示 我被當塑膠
GraphQL就相當把後端結構完全洩漏給前端
https://reurl.cc/z8GOQk 還是要看實際應用和需求
graphql就是垃圾,就是個前端很爽,後端很幹的概念
後端為什麼很幹
我用Go+GraphQL+Apollo(TS),用了就回不去了
@knives 什麼是後端很幹的概念?
GraphQL和直接開SQL給前端有什麼本質上的差別?
完全失去封裝的意義.
我想詢問的是第一點下,若要組裝A跟B的query但是他們的inp
ut也分別是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
是沒啥意義的事情 甚至作繭自縛
84
Re: [討論] API沒資料,回200還是404比較好這篇就不以引述的方式回覆了,因為算是對 後續其他人不論在推文中或是回文中的內容 回覆,另外也是針對我自己在前一篇文章中 沒有提到的部分進行說明。 (1) 敘述問題與回答問題33
Re: [討論] API沒資料,回200還是404比較好嗯,我想兩位的建議可以寄信向 GitHub 和 Atlassian 這兩間公司說明一下,或許可以 幫他們團隊縮減人力。 當查詢資源不存在時返回 HTTP Code 404:34
[請益] 有人的公司也沒有提供API文件的嗎安安 小弟剛轉前端,進到一家接案公司寫網頁,工作大概9成都在接API, 但公司內部沒有提供api規格文件讓我參考, 導致每次我都要通靈, 不然就是纏著後端不放,20
Re: [討論] 前端比較痛苦還是後端本魯全端工程師 個人覺得後端比較痛苦,而且要會的不比前端少,可能還更多 因為所有的business model 都在後端,有些商業邏輯複雜到你會想死 前端所需要的功能,後端都要刻api出來(所有資料錯誤,80%都是後端吐的資料有誤) 而且前端的資料驗證,基本上後端為了安全性問題,全都要在再作一次15
[討論] angular值得花時間下去學嗎?大家好 小弟最近在家進修 看了一下angular 本身已會angularjs 目前書看到264/801頁11
Re: [討論] 請大家聊聊 JavaScript的缺陷推 laputaflutin: 同意樓上,不過看到這次美國大選很多新聞網都拿 11/04 21:02 → laputaflutin: svelte來寫,感覺蠻有趣的,應該會拿來試試看 11/04 21:03 禁不住好奇心的我終究還是去看一下 Svelte, 原來它是個反 React、反 Vue、反前端在瀏覽器動態解析樣板的框架兼開發工具。 它讓你在開發時期能夠先以 js 程式碼定義資料,13
[請益] 怎麼處理API版本不同的問題?我是後端工程師 要寫API給WEB跟APP前端 WEB跟APP有些API共用有些沒有 後端就只有一個STA版本 也就是說一個版本要同時滿足APP和WEB的需求10
Re: [請益] 快40歲了想換工作沒人要怎麼辦因為你沒有貼出自己的履歷也沒有詳述口試過程,所以沒辦法給你很實質的建議。但是從你描述自己的方式,我感覺你覺得自己會很多技術,現在不會的技術也能很快學會解決問題。 這種*技術只是工具*的思維恐怕要暫時忘掉,至少在找工作的時候,因為現在的軟體業已經工業化,在裡面工作的人,只有符合工業標準的介面,才能發揮功能。畢竟你不是那個制定標準的人。只有當你自己是一個符合規格的工具,公司才知道怎麼把你放到他們規劃好給那個工具的位置。 所以最重要的是思考*我是什麼工具*,技術不是你的工具,技術是把自己打造成某個工具的手段,而軟體業需要的各種工具,其實都有規格書可查,你可以查閱後用來打造自己。 每個工具都有自己運轉的核心能力,跟別的工具接合的介面。舉例來說我是一種叫前端工程師的工具,我會在自己的說明書很清楚說明我的核心是React,已經更新到18,有 GraphQL 跟 restful 兩種跟後端接合的介面,有寫testing測試自己的能力,能用storybook進行隔離開發。 如果是剛畢業的新人,公司可能覺得有核心能力就好了,GraphQL什麼的進來後再安裝。但是如果你要求1M,恐怕構成一個完整能運作的工具的規格,是缺一不可了。6
Re: [請益] 專精前端(或後端)vs全端工程師之前剛好有一份工作是全端,我不知道是否會趨勢化,但全端不一定是一人包前後的案子 事實上那是一份不小的專案,前後端各有數人在開發,甚至客戶 App 也會來串機器 簡單介紹一下那個專案架構 我方開發 web 前端,機器上跑大量 C 的程式,需要把既有 command line 東西視覺化 為了達成雲端操作,所以需要有一個全端來設計 API + SDK- 回一下 nodejs 伺服器相關 (不只維運), 個人覺得好用的有 pm2 方便的 nodejs 運行工具, 可簡單的做到開機自動啟動, cluster, 掛掉自動重啟等等 supertest / swagger-ui-express / express-oas-generator