GraphQL 與 RESTful API 應用的場景與分析

2023/02/09閱讀時間約 7 分鐘

網路上已經有很多相關這兩者的討論，單純的討論兩者的理念我認為還是很難決定要在哪些場景使用，因此這裡會針對實現這兩者介面所需要做的事情來比較這裡會先略過權限驗證、流量限制、快取、遞迴查詢… 等等 GraphQL 常常被提及的問題，這些可以透過使用 GraphQL 生態系中的工具如 Hasura、Prisma 來處理

GraphQL 與 RESTful API 差異介紹文章

How to GraphQL — The Fullstack Tutorial for GraphQL

GraphQL Vs. REST APIs | GraphCMS

REST vs GraphQL APIs, the Good, the Bad, the Ugly | Moesif Blog

GraphQL vs REST: Difference between GraphQL and REST API (guru99.com)

以後端來看，如何實現 GraphQL 與 RESTful API

GraphQL
透過實現一組 Post 端點對外，並且由 schema 與 resolvers 這兩個元件所組成

schema 決定了數據的長相
resolvers 決定了處理需求的方式

因此當我們開發一個 Order 的 GraphQL API 時，我們會需要
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 這兩個元件所組成

dto 全稱為數據傳輸對象 (Data transfer object)，為與前端溝通時的結構
logic 這裡指的是後端業務邏輯，針對每一組 API 來設計不同的業務流程

因此當我們開發一個 Order 的 RESTful 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 與快取

這樣當前端需要針對 Order 這個資源操作時，就可以選擇相對應的 API 端點來做操作

如果需要複數的資源的資料，如 Order 與 Product ，會有兩種方案
1. 前端呼叫兩隻 API 來取得資料並在前端拼裝資料，而此缺點會有取得不必要欄位與多次請求造成的效能損耗

2. 後端再定義一組新的 dto 與 logic 來針對新的資源做查詢，如 OrderInfo，可以針對目前需要的欄位進行設計，但針對性強所以不一定能有效複用

以前端來看，如何對接 GraphQL 與 RESTful API

GraphQL
統一的資源取得 Url，且限定使用 Post，基本上可以透過套件來簡化這樣的連接行為，僅需要關注在組合 schema 來取得需要的欄位資料

當我們開發一個 Order 的 GraphQL API 頁面時，我們會需要
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 進行呼叫

因此當我們開發一個 Order 的 RESTful API 頁面時，我們會需要
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，還是要看團隊配合與產品特性而定