GraphQL 與 RESTful API 應用的場景與分析
更新於 發佈於 閱讀時間約 7 分鐘
網路上已經有很多相關這兩者的討論，單純的討論兩者的理念我認為還是很難決定要在哪些場景使用，因此這裡會針對實現這兩者介面所需要做的事情來比較這裡會先略過 權限驗證、流量限制、快取、遞迴查詢… 等等 GraphQL 常常被提及的問題，這些可以透過使用 GraphQL 生態系中的工具 如 Hasura、Prisma 來處理
GraphQL 與 RESTful API 差異介紹文章
以後端來看，如何實現 GraphQL 與 RESTful API
GraphQL
透過實現一組 Post 端點對外，並且由 schema 與 resolvers 這兩個元件所組成
透過實現一組 Post 端點對外，並且由 schema 與 resolvers 這兩個元件所組成
- schema 決定了數據的長相
- resolvers 決定了處理需求的方式
因此當我們開發一個 Order 的 GraphQL API 時，我們會需要
1. 定義 Order 表的 schema
2. 撰寫針對 Order 表行為的 resolvers，Queries and Mutations (Execution | GraphQL)
3. 透過 GraphQL 生態系提供的監測工具與跟前端溝通，針對常下的查詢條件對資料庫進行 Index 的建立與快取優化
1. 定義 Order 表的 schema
2. 撰寫針對 Order 表行為的 resolvers，Queries and Mutations (Execution | GraphQL)
3. 透過 GraphQL 生態系提供的監測工具與跟前端溝通，針對常下的查詢條件對資料庫進行 Index 的建立與快取優化
這樣當前端使用到 Order 這個 schema 時就可以透過我們自定義的 resolvers 來執行相對應的行為，且能僅拿需要的欄位來避免過度撈取
如果需要複數的 schema 資料，僅需在發送請求時要求聚合的 schema 即可
RESTful API
透過多組 API 端口並用各種 HTTP request methods 來實現服務，基本上由 dto 與 logic 這兩個元件所組成
透過多組 API 端口並用各種 HTTP request methods 來實現服務，基本上由 dto 與 logic 這兩個元件所組成
- dto 全稱為 數據傳輸對象 (Data transfer object)，為與前端溝通時的結構
- logic 這裡指的是後端業務邏輯，針對每一組 API 來設計不同的業務流程
因此當我們開發一個 Order 的 RESTful API 時，我們會需要
1. 定義 Order API 的增刪修查用的 dto
2. 設計增刪用的 API 端點
1. 定義 Order API 的增刪修查用的 dto
2. 設計增刪用的 API 端點
增 (post) /order
刪 (delete) /order
修 (put) /order
查全部 (get) /order
查特定 id (get) /order/{id}
3. 針對不同 HTTP request methods 的端點撰寫業務邏輯
4. 針對設計上規範的查詢條件優化資料庫的 Index 與快取
4. 針對設計上規範的查詢條件優化資料庫的 Index 與快取
這樣當前端需要針對 Order 這個資源操作時，就可以選擇相對應的 API 端點來做操作
如果需要複數的資源的資料，如 Order 與 Product ，會有兩種方案
1. 前端呼叫兩隻 API 來取得資料並在前端拼裝資料，而此缺點會有取得不必要欄位與多次請求造成的效能損耗
1. 前端呼叫兩隻 API 來取得資料並在前端拼裝資料，而此缺點會有取得不必要欄位與多次請求造成的效能損耗
2. 後端再定義一組新的 dto 與 logic 來針對新的資源做查詢，如 OrderInfo，可以針對目前需要的欄位進行設計，但針對性強所以不一定能有效複用
以前端來看，如何對接 GraphQL 與 RESTful API
GraphQL
統一的資源取得 Url，且限定使用 Post，基本上可以透過套件來簡化這樣的連接行為，僅需要關注在組合 schema 來取得需要的欄位資料
統一的資源取得 Url，且限定使用 Post，基本上可以透過套件來簡化這樣的連接行為，僅需要關注在組合 schema 來取得需要的欄位資料
當我們開發一個 Order 的 GraphQL API 頁面時，我們會需要
1. 取得 GraphQL Server 定義的 schema 與 mutations列表
2. 選擇 Order 的 schema 來做請求
3. 對著 GraphQL Url 發送 Order schema 並選擇需要的欄位與需要用的 Queries 或 Mutation
4. 依據 GraphQL 的語言約定，來進行操作
5. 獲取資料並呈現
1. 取得 GraphQL Server 定義的 schema 與 mutations列表
2. 選擇 Order 的 schema 來做請求
3. 對著 GraphQL Url 發送 Order schema 並選擇需要的欄位與需要用的 Queries 或 Mutation
4. 依據 GraphQL 的語言約定，來進行操作
5. 獲取資料並呈現
RESTful API
每一個資源對應到不同的 API Url，針對想要做的 CRUD 動作選擇對應的 HTTP request methods 進行呼叫
每一個資源對應到不同的 API Url，針對想要做的 CRUD 動作選擇對應的 HTTP request methods 進行呼叫
因此當我們開發一個 Order 的 RESTful API 頁面時，我們會需要
1. 取得 RESTful API 定義的 API 列表，可以透過 swagger 或後端提供的文件
2. 針對不同頁面選擇合適的 Order API
3. 依據前後端約定的 API 格式與互動方法來進行交互，如資源定義的結構與分頁指定的 Index …等
4. 獲取資料並呈現
1. 取得 RESTful API 定義的 API 列表，可以透過 swagger 或後端提供的文件
2. 針對不同頁面選擇合適的 Order API
3. 依據前後端約定的 API 格式與互動方法來進行交互，如資源定義的結構與分頁指定的 Index …等
4. 獲取資料並呈現
結論
GraphQL 定義了一個前後端實現交互的約定規範，也給予了前端很大程度取得資料的彈性
適合 C 端產品，多變化的功能需求與跨平台可能性(web、mobile)與高度的效能要求，給予前端獲取資料的彈性呈現畫面
RESTful API 僅針對了風格與建議使用 HTTP request methods 來作行為的標註，較多邏輯與欄位的呈現是控制在後端，導致了每一個 API 的功能的專一性會較強，如共通使用會有多餘的欄位或多次訪問造成 API 較慢的呈現時間
適合 B端產品，在欄位與行為上由後端控制的做法不見得不好，多數儀表板應用應用較常使用這樣的方式來實作，也可以降低前端獲取資料的複雜度與降低資料庫優化的難度
但不論是用 GraphQL 還是 RESTful API，都需要前後端釐清業務場景來設計 DB Schema 與快取優化，而不是用了 GraphQL 或是 RESTful API 就可以把所有問題丟給前端或後端，亦不是 GraphQL 就可以取代 RESTful API，還是要看團隊配合與產品特性而定
參考資料
Queries and Mutations (Execution | GraphQL)
為什麼會看到廣告
留言0
查看全部
你可能也想看
Google News 追蹤
在創作的路上真的很多人問我說
到底要怎麼做出符合自己期待
但又可以表現得很有美感的作品？🥹
這個問題真的應該是每個創作者都一直在學習的課題吧！
提問的內容越是清晰，強者、聰明人越能在短時間內做判斷、給出精準的建議，他們會對你產生「好印象」，認定你是「積極」的人，有機會、好人脈會不自覺地想引薦給你
本文探討三種主流 API 架構設計：REST、gRPC 和 GraphQL，比較它們的優缺點及適用場景，並提供 SEO 建議，以提升文章的搜尋引擎排名。
※ 什麼是Apollo GraphQL Server？
Apollo GraphQL Server 是一個將GraphQL的標準轉化為實際可用的工具和框架，可以在Node.js 常用的中介軟體像是 Express 或 Fastify 所建立的伺服器中，輕鬆加入和設定 Apollo GraphQL
※ REST API 和 Apollo GraphQL Server 的區別：
資料獲取方式：
REST API：每個資源都有一個固定的 URL，並且通過 HTTP 方法（如 GET、POST、PUT、DELETE）來操作這些資源。伺服器決定返回的資料結構。
GraphQL：使用單一的端點（通
※ 什麼是GraphQL？
GraphQL 是由 Facebook 於 2015 年開發的一種 API 查詢語言。客戶端（前端）只會接收到所需的數據，減少了不必要的數據傳輸和多次請求的需要，提高了應用程序的性能和效率。GraphQL 支持查詢、變更和即時更新操作，解決了傳統 REST API 中的
API（Application Programming Interface，應用程式介面）可以視為不同軟體系統之間的溝通橋梁，讓雙邊可以交換數據並執行各種功能。這篇會記錄產品經理一定要知道的幾個 API 概念，像是常見的錯誤代碼以及不同的 HTTP 方法（如 PUT、GET、POST）和實際案例說明
※ 什麼是Web API
API 就是後端開出來讓前端來用的介面，讓前端與後端可以溝通。
API流程：
終端使用者用任何一種裝置進入瀏覽器。
瀏覽器透過 API 向後端發出請求，請求查詢或修改資料。
後端透過 API 收到前端的請求後，取得資料並回應給前端。
前端渲染畫面，終端使用者
※ 原本狀態：伺服器渲染
這是 MVC 架構下的 request / response 示意圖，在這張圖呈現的架構裡，畫面和資料都由同一個架構處理。
伺服器渲染流程：
瀏覽器針對特定網址送出請求。
路由器解析請求後，轉接給對應的 controller。
controller 按照要求，透過
透過GraphQL提供的分頁方式，優化後端讀取資料的效能，避免過度讀取舊資料及準確指定特定項目。同時，利用Local-only field達成資料的整理或再次經過計算，提升管理和重複使用的效能。
在創作的路上真的很多人問我說
到底要怎麼做出符合自己期待
但又可以表現得很有美感的作品？🥹
這個問題真的應該是每個創作者都一直在學習的課題吧！
提問的內容越是清晰，強者、聰明人越能在短時間內做判斷、給出精準的建議，他們會對你產生「好印象」，認定你是「積極」的人，有機會、好人脈會不自覺地想引薦給你
本文探討三種主流 API 架構設計：REST、gRPC 和 GraphQL，比較它們的優缺點及適用場景，並提供 SEO 建議，以提升文章的搜尋引擎排名。
※ 什麼是Apollo GraphQL Server？
Apollo GraphQL Server 是一個將GraphQL的標準轉化為實際可用的工具和框架，可以在Node.js 常用的中介軟體像是 Express 或 Fastify 所建立的伺服器中，輕鬆加入和設定 Apollo GraphQL
※ REST API 和 Apollo GraphQL Server 的區別：
資料獲取方式：
REST API：每個資源都有一個固定的 URL，並且通過 HTTP 方法（如 GET、POST、PUT、DELETE）來操作這些資源。伺服器決定返回的資料結構。
GraphQL：使用單一的端點（通
※ 什麼是GraphQL？
GraphQL 是由 Facebook 於 2015 年開發的一種 API 查詢語言。客戶端（前端）只會接收到所需的數據，減少了不必要的數據傳輸和多次請求的需要，提高了應用程序的性能和效率。GraphQL 支持查詢、變更和即時更新操作，解決了傳統 REST API 中的
API（Application Programming Interface，應用程式介面）可以視為不同軟體系統之間的溝通橋梁，讓雙邊可以交換數據並執行各種功能。這篇會記錄產品經理一定要知道的幾個 API 概念，像是常見的錯誤代碼以及不同的 HTTP 方法（如 PUT、GET、POST）和實際案例說明
※ 什麼是Web API
API 就是後端開出來讓前端來用的介面，讓前端與後端可以溝通。
API流程：
終端使用者用任何一種裝置進入瀏覽器。
瀏覽器透過 API 向後端發出請求，請求查詢或修改資料。
後端透過 API 收到前端的請求後，取得資料並回應給前端。
前端渲染畫面，終端使用者
※ 原本狀態：伺服器渲染
這是 MVC 架構下的 request / response 示意圖，在這張圖呈現的架構裡，畫面和資料都由同一個架構處理。
伺服器渲染流程：
瀏覽器針對特定網址送出請求。
路由器解析請求後，轉接給對應的 controller。
controller 按照要求，透過
透過GraphQL提供的分頁方式，優化後端讀取資料的效能，避免過度讀取舊資料及準確指定特定項目。同時，利用Local-only field達成資料的整理或再次經過計算，提升管理和重複使用的效能。