GraphQL 初學者必讀：自動產生 Resolver 的工具與底層邏輯解析

更新日期： 2025 年 5 月 5 日

當你開始學 GraphQL 時，可能會有這樣的疑問：

「為什麼我都已經定義好 Type，還要再手寫 Resolver？」

「能不能像 REST 一樣，一個 endpoint 就包好資料邏輯？」

其實，這並不是 GraphQL 的缺陷，而是一種有意設計：

✅ GraphQL 採取「資料格式」與「資料來源」明確分離的設計哲學。

這樣做的好處是更有彈性，但缺點是…你常常得自己寫很多 Resolver！

尤其當你開發的是大量 CRUD 查詢，這些 Resolver 不但重複，還容易出錯。

因此，越來越多工具出現，幫助你自動產生 Resolver，讓你專注於業務邏輯。

為什麼需要自動化 Resolver？

在 GraphQL 架構中，Resolver 是「查資料」與「處理邏輯」的實際執行者。

每當你從前端發出一個查詢（Query），GraphQL Server 會根據 Schema 確認查的是什麼資料，然後交給對應的 Resolver 去實際執行操作。

Resolver 的職責是什麼？

舉例來說，假設你有一個查詢：

query {
  user(id: 1) {
    name
    email
  }
}

對應的 Resolver 可能會長這樣：

const resolvers = {
  Query: {
    user: (_, args, context) => {
      return db.user.findById(args.id);
    }
  }
};

這段 Resolver 要處理的事情包括：

• 接收查詢參數（例如 args.id）
• 驗證這個請求是否合法（是否登入、是否有權限）
• 到資料庫中查詢 user 資料
• 整理成指定格式回傳給前端

這些事情看起來簡單，但每一個資料型別都要這樣寫一次，尤其當你有 10 個資料表、每張表都有增刪改查操作時，你就得寫上百個幾乎一樣的 Resolver。

為什麼手寫 Resolver 很快會變成一場災難？

在 GraphQL 的開發模式中，每一個資料型別（例如：User、Post、Comment 等）都需要對應的 Resolver 來處理資料查詢與變更。

而一旦你開始為每個型別實作常見的 CRUD（Create、Read、Update、Delete）操作，很快就會產生大量重複又瑣碎的程式碼。

📌 想像一下這樣的情境：

假設你有一個中型系統，裡面包含以下 10 種資料型別（也就是 10 張資料表）：

• User
• Post
• Comment
• Category
• Tag
• Product
• Order
• Invoice
• Notification
• Message

每一個型別通常都會需要基本的 CRUD 操作，例如：

• 查詢單筆資料（findOne）
• 查詢多筆資料（findMany，可加上過濾、排序、分頁）
• 建立資料（create）
• 修改資料（update）
• 刪除資料（delete）

若以這些五種常見操作來估算：

10 種資料型別 × 5 種操作 = 至少 50 個 Resolver 函式

這還只是基礎 CRUD，還不包括：

• 權限驗證邏輯（只能編輯自己的文章）
• 關聯查詢（查詢 User 時順便列出他的所有 Post）
• 轉換欄位格式（格式化日期、合併欄位）
• 客製化查詢（例如：查詢「某個分類下的最新 5 篇已發佈文章」）

📂 實例對照：手寫 vs 自動化

手寫時，每個型別都會有類似以下的樣板邏輯：

const resolvers = {
  Query: {
    post: (_, args) => db.post.findUnique({ where: { id: args.id } }),
    posts: (_, args) => db.post.findMany({ skip: args.skip, take: args.limit }),
  },
  Mutation: {
    createPost: (_, args) => db.post.create({ data: args.input }),
    updatePost: (_, args) => db.post.update({ where: { id: args.id }, data: args.input }),
    deletePost: (_, args) => db.post.delete({ where: { id: args.id } }),
  },
};

如果換成 user, comment, product 呢？你會發現幾乎都是這種「複製貼上 + 換表名」的過程。

🚨 問題會快速累積

• 維護地獄：欄位一變，十幾個 Resolver 全都要手動更新
• 容易犯錯：一不小心複製貼上沒改乾淨，就導致 bug（例如用錯資料表或變數名）
• 團隊開發效率低：新手進團隊也要花時間學怎麼寫、怎麼測試、怎麼避坑
• 測試與除錯困難：重複的樣板邏輯增加測試難度，錯誤資訊不集中

小結

當你的系統資料量與類型一多，「每個都自己手寫 Resolver」會變成極大的負擔，也無法讓你專注在真正有價值的商業邏輯與功能開發上。

因此，引入自動產生 Resolver 的工具，就成了現代 GraphQL 開發的重要選擇。

為什麼引入自動化工具是好選擇？

隨著 GraphQL 在企業與團隊中普及，開發者面臨的挑戰不再只是「能不能寫出 Resolver」，而是：

• 怎麼讓開發速度變快？
• 怎麼減少樣板與人為錯誤？
• 怎麼讓團隊協作更順利？

這正是自動化 Resolver 工具誕生的核心動機。

這些工具能根據你現有的資料結構，幫你快速產出完整的 GraphQL API，包括 Schema、CRUD Resolver、型別驗證，甚至文件與授權邏輯。

它們到底能幫你做什麼？

這類工具能幫助開發者完成以下繁瑣又重複的工作：

你只需要：

1. 定義好你的資料模型（例如：資料表或 Prisma schema）
2. 工具就會自動幫你「畫出圖」、定義欄位、生成 CRUD Resolver
3. 可額外擴充自訂邏輯，或與第三方服務整合

初學者常見疑問：這樣不會太依賴工具嗎？

很多初學者會擔心：

「我這樣是不是沒真的學會 GraphQL？」

「是不是偷懶、不扎實？」

其實不然，這類工具的定位，就像是你用 TypeScript 而不是純 JS，用 Tailwind 而不是自己寫 CSS，目的是減少不必要的重複勞動，把開發者的注意力留給真正需要思考的業務邏輯。

自動化不是偷懶，而是更有效率的開發策略。

使用自動化工具，不是為了跳過學習 Resolver，而是用智慧節省精力、聚焦在有價值的工作上。

你節省下來的時間，應該花在：

• 🔐 權限驗證邏輯：誰能讀、誰能改，寫清楚比自動生成更重要
• 🌐 外部 API 整合：像 Stripe、Firebase、Google Maps 的串接
• 🧵 多資料來源整合：把來自資料庫 + API 的結果組裝成一個 GraphQL 結構
• ⚙️ 非同步工作流程：例如建立訂單後自動發送通知、更新其他系統

常見自動化 Resolver 工具總覽與比較

以下是目前在開發圈中最常見的三種 GraphQL 自動化工具或框架，依據它們的功能特性與適用場景，幫你快速比較：

Hasura

• 開箱即用：你只需要準備好一個 PostgreSQL 資料庫，Hasura 就能自動讀取資料表與關聯，立刻生成 GraphQL API。
• 支援即時訂閱：可透過 Subscription 追蹤資料變化，非常適合需要即時通知的前端應用。
• 權限控制完整：可依使用者角色設定欄位層級的讀寫權限，不需自行寫在 Resolver 裡。
• 圖形化 UI 操作：大多數功能可用 UI 設定，無需寫一行 Resolver。

適合情境：

• 沒有複雜邏輯需求的原型系統
• 管理後台、分析儀表板等內部工具
• 有明確資料結構但開發人力不足的小團隊

Prisma + Nexus

• Prisma 提供強型別 ORM，可以透過 schema 定義資料模型，並同步產生 TypeScript 型別。
• Nexus 則是以程式方式定義 GraphQL schema，透過結合 Prisma，可快速自動產出 CRUD Type 與 Resolver。
• 支援覆蓋預設邏輯，方便加入自訂邏輯、驗證、轉換與第三方整合。
• 型別推導強，可搭配 VS Code 完整自動補全、錯誤提示。

適合情境：

• 需彈性控制 API 設計的大型專案
• 需要客製化業務邏輯（如：不同角色看到不同資料）
• 有撰寫單元測試與 CI/CD 的工程團隊

GraphQL Codegen

• 不直接產 API，而是根據已有的 GraphQL Schema + Query 文件，自動產出對應的 TypeScript 型別。
• 能自動生成：
• variables、response、fragments 對應的型別
• 後端的 Resolver interface（只產生函式介面，不包含邏輯）
• 支援多種 plugin，可整合 Apollo、React Hooks、URQL、GraphQL Yoga 等生態系
• 幫助前後端維持型別同步，避免發生 API 改 schema 卻忘記通知對方的問題。

適合情境：

• 前端多人協作，需保持型別同步與安全
• 有既有後端 API，但想提升開發效率與維護性
• GraphQL Schema 不常變動，但 Query 很多（適合做自動補全）

這些工具是怎麼運作的？原理拆解與實際流程

自動產生 GraphQL Resolver 的核心流程，其實可以分成三個階段：

1️⃣ 資料來源擷取（Source of Truth）→ 2️⃣ Schema 組裝 → 3️⃣ Resolver 自動化邏輯構建。

雖然每個工具切入點不同，但這三個步驟幾乎是通用的，只是「誰負責什麼」不一樣。

讀取結構定義（Source of Truth）

這個階段是所有工具的起點：從某個既有的結構來源取得資料型別資訊，作為後續自動產生 Type 與 Resolver 的依據。

🔍 這一步在做什麼？

可以理解為工具正在建立一份「可機器理解的資料說明書」，它讀的是：

• 結構（Schema）
• 欄位與型別
• 資料關聯
• 查詢與操作方式

這是整個自動化流程的基石：如果這一步出錯，後面所有自動化產物都可能錯誤或無法產生。

轉換為 GraphQL 元件（Schema 組裝）

讀取完結構後，下一步是將這些資訊轉換成符合 GraphQL 規範的各種型別（Type）與操作介面。

這一步的核心目標是：「幫你把 SDL（Schema Definition Language）寫出來」。

🔧 可能產生的 GraphQL 元件：

📦 這一步讓你不用自己手動撰寫 GraphQL SDL，它會自動：

• 根據每個 Model 產出對應的 Type
• 建立好對應 CRUD 的查詢與變更操作
• 對 Input 與 Output 自動加上型別限制與欄位說明

💡 範例比較：

你原本可能需要自己寫：

type Product {
  id: ID!
  name: String!
  price: Float!
}

但現在工具會根據資料來源自動產生，節省你建構 API 骨架的時間。

套用預設邏輯或產生樣板程式碼（Resolver 構建）

這一步才是真正讓你「不用自己寫 Resolver」的關鍵！

工具會根據前面產生的 GraphQL Schema，為每一個操作（Query / Mutation）自動綁定對應的查詢邏輯、資料來源、驗證條件與回傳型別。

📦 最後你會得到：

📌 關鍵好處：

• 省時省力：幫你寫好八成的樣板
• 型別正確：避免因型別不一致導致的錯誤
• 可自訂：有彈性地保留手寫邏輯空間（尤其在 Prisma + Nexus）

這整套流程像什麼？

額外補充：自動化並不意味著封閉或僵化

這些工具雖然自動化程度高，但大多數都提供「自訂擴充」的能力，例如：

• Hasura 提供 Remote Schema 與 Action 可對接自定義後端邏輯
• Nexus 的 Resolver 可任意調整回傳值、加入中介層（middleware）
• Codegen 只生成框架，你可以依實際需求彈性實作資料邏輯

因此，自動化工具並不是只適合簡單場景，它們其實也能應對大型系統，只是幫你先把「骨架」搭好，讓你更快聚焦在關鍵邏輯與效能優化上。

提醒：自動化 ≠ 不用理解 Resolver

在學習 GraphQL 時，很多初學者看到自動化工具能快速產出 CRUD API，會產生一種誤解：

「既然工具都幫我產好了，那我是不是不需要了解 Resolver 的細節？」

這種想法雖然自然，但實際上是危險且侷限的。

因為你雖然可以靠工具快速開始，但在真實專案中，遇到客製化邏輯、整合流程、效能瓶頸或錯誤 debug時，Resolver 就是你必須親自下場處理的第一線戰場。

Resolver 是 GraphQL 的執行核心

無論是查詢資料、修改資料、轉換欄位內容、驗證權限、整合外部 API……

這些工作，最終都會落在 Resolver 上完成。

你可以把 Resolver 想像成是「GraphQL 的後端控制器」，負責：

1. 接收前端傳來的參數
2. 決定該怎麼處理這筆請求
3. 從資料來源取得資料或執行操作
4. 將結果整理好後回傳給前端

為什麼理解 Resolver 仍然是必要的？

你需要理解 Resolver 的呼叫流程

Resolver 函式實際上會被呼叫時，會自動傳入這四個參數：

(fieldName: (parent, args, context, info) => { ... })

🔎 如果你不了解這些參數用途，會很難：

• 把 nested query 資料串起來（如查 user 時一併帶出 posts）
• 判斷是哪個 Resolver 被觸發，導致錯誤不知從何下手
• 使用 context 中的登入者資訊做權限驗證

你要知道什麼時候會進入哪個 Resolver

GraphQL 的 Resolver 是以欄位為單位觸發的，而不是一次跑完整個查詢。

舉例：

query {
  user(id: 1) {
    id
    name
    posts {
      title
      comments {
        content
      }
    }
  }
}

上面這段查詢，會觸發的 Resolver 包含：

• Query.user
• User.posts
• Post.comments

🧠 如果你沒理解 Resolver 呼叫順序，你會搞不清楚為什麼 comments 沒有資料？

或者誤以為只有 Query.user 被呼叫，錯過 debug 的重點。

你會需要自己處理自訂邏輯與外部整合

大多數實務情況下，你都會遇到下列需求：

• 在 createOrder 時，自動扣除庫存、發送通知（需要寫額外邏輯）
• 查詢某個使用者的個人資料，但要根據登入者身份判斷哪些欄位可顯示（權限控制）
• 整合第三方系統，如串接 Firebase、Stripe、外部 REST API 等

📌 這些都不是自動化工具可以幫你搞定的，而必須透過手寫 Resolver 處理。

你一定會遇到要 debug 的時候

當你的查詢結果出現：

• null
• undefined
• Cannot read properties of undefined
• 一段 Query 執行時間過長

你就需要打斷點、檢查參數、檢查資料來源與邏輯執行順序。

而這些錯誤 90% 都會發生在 Resolver 層。

🔧 如果你只是仰賴自動工具，但不懂 Resolver，你將完全不知道錯在哪裡、該怎麼修。

比喻幫助理解：你是建築師還是搬磚工？

• 使用 Hasura 就像買了一棟模組化組裝房屋，幫你蓋好牆、鋪好地板。
• 使用 Codegen 就像有工人幫你搬來建材與圖紙。
• 使用 Prisma + Nexus 就像有預組裝結構，但還需你設計內裝。

但無論哪種情況，你終究還是需要懂得房子的結構、用途與流程邏輯。

否則一旦天花板漏水（資料查錯）、插座不通（型別錯誤）、水管堵塞（Query 慢），

你就只能傻眼站在原地。

小結：工具能幫你「產生」，但理解才能幫你「維護」

結語：什麼情況適合用自動化工具？什麼情況該手寫 Resolver？

自動化工具並不是要取代開發者的角色，而是為了讓你把時間花在「該花的地方」。

不過該用哪一種工具、或是否該手寫 Resolver，還是要視專案性質、團隊狀況與資料架構複雜度而定。

推薦使用自動化工具的情境

如果你的專案符合下列任一條件，那麼導入自動化工具可以大幅提升開發效率，降低錯誤風險：

快速開發原型、內部系統

• 例如行政後台、資料視覺化介面、管理者面板。
• 時間緊迫、功能明確，資料結構以 CRUD 為主。
• 可直接使用 Hasura 自動產生完整 API，搭配簡易前端框架快速完成。

中大型應用，需要型別安全與邏輯彈性

• 你需要完整的型別推導、測試能力、程式碼結構與可擴充性。
• 想保有自訂權限邏輯、中介層處理（如驗證 token、轉換格式等）。
• 使用 Prisma + Nexus，可快速建立基本 Resolver，又能根據業務需求進行客製。

想強化前後端型別一致性

• 專案是多人開發、前後端分離、追求 CI/CD 流程完整。
• 想要自動產生 Query 對應的 variables、response、fragments 型別。
• 可使用 GraphQL Codegen 搭配 Apollo、URQL 等前端框架，提高型別安全與維護性。

建議手寫 Resolver 的情境

雖然自動化能幫你節省許多時間，但在以下這些情況，手寫 Resolver 通常是必要且不可避免的：

需要整合多個資料來源（API + 資料庫 + 第三方服務）

• 例如從 REST API 取得訂單，再從資料庫補齊用戶資料。
• 工具無法知道你的資料流動邏輯，只能由你明確定義 Resolver 中的整合流程。

涉及進階邏輯與條件控管

• 例如依據不同角色顯示不同欄位（主管可見薪資，一般員工不可見）。
• 訂單建立後觸發推播、計算紅利點數等。
• 這些都超出了 CRUD 的範圍，需自己處理事件驅動與流程控制。

對效能或查詢方式有特殊要求

• 例如需要撰寫 aggregate、join、window function、全文搜尋等特殊查詢。
• 或需微調查詢流程以避免 N+1 問題、進行 batch loading。
• 這些細節通常需要手動撰寫 Resolver 才能控制得當。

實務建議：混合使用，按需導入最合適

其實，大部分真實專案會採取「自動化 + 手寫混合式策略」：

這種做法能在保有彈性的同時，加快開發流程，對不同團隊與專案階段來說都是最務實的選擇。

小結：不要一刀切，選擇最適合你團隊的方式