從 REST 到 GraphQL：我為何以及如何進行切換

身為一個擁有 4 年 REST API 建置經驗的軟體工程師，我一直很欣賞 REST 帶來的簡單性和可靠性。無論是設計端點還是建置回應，REST 都是我的首選解決方案。

但今年早些時候，一切都改變了。我的任務是跳到一個需要處理大型、複雜且相互關聯的資料來源的專案。 這不僅僅是取得使用者清單或更新單一記錄，它需要靈活性、精確性和REST 難以提供的規模效率。

輸入GraphQL。 ？

起初，我持懷疑態度。為什麼要修復沒有損壞的東西？但隨著我深入研究，GraphQL 不僅滿足了專案的需求，它也重新定義了我對 API 的看法。憑藉其能力：

• 以客戶端定義的靈活結構傳回數據，
• 透過單一 URL 端點進行操作，
• 拒絕基於強型別架構的無效請求，以及
• 以預先決定的、相互理解的格式交付資料，

GraphQL 很快就不僅僅是一個解決方案，它成為我 API 設計的新標準。

也就是說，本文的目的是不是為了支援 GraphQL 而抹黑 REST API。事實上，我相信兩者可以完美地相輔相成。 REST 在我的專案中仍然發揮著至關重要的作用，特別是對於專用 REST 端點比 GraphQL 查詢更實用的特定用例。

在這篇文章中，我將分享：

1. 為什麼我從 REST 切換到 GraphQL，
2. 我親身體驗過的好處，以及
3. 簡單指南幫助您建立第一個 GraphQL 伺服器。

無論您是對GraphQL 感到好奇的初學者，還是希望過渡的經驗豐富的工程師，本文都將向您展示為什麼GraphQL 值得您關注，以及它如何在不完全取代REST 的情況下改變您的項目。

我從 REST 到 GraphQL 的旅程

多年來，REST API 一直是我的麵包和奶油。我依靠它們來建立強大的系統、管理數據和提供功能。但隨著我的專案變得越來越複雜，裂縫開始出現。

REST API 的挑戰

一個反覆出現的挫敗感是過度獲取和獲取不足的數據。我要么獲得太多我不需要的信息，要么必須提出多個請求才能獲得我所做的一切。管理大量端點增加了複雜性，使更新和維護變得繁瑣。

發現 GraphQL

今年早些時候，我加入了一個需要使用大型互連資料來源的專案。 REST 無法滿足要求，團隊建議使用 GraphQL。最初，我對此表示懷疑，但從單一端點準確查詢所需內容的承諾引起了我的興趣。

GraphQL 的第一印象

從 GraphQL 開始並非沒有挑戰。模式和解析器讓人望而生畏，但它提供的靈活性和控制使這些努力值得。隨著時間的推移，我意識到它如何無縫地解決了我在 REST 方面面臨的痛點。

雖然我仍然在特定情況下使用 REST，但 GraphQL 已成為我處理複雜和動態資料需求的首選工具。

為什麼我要改

當我更深入研究 GraphQL 時，一些關鍵優勢脫穎而出，使轉換變得輕而易舉：

• 靈活性：使用 GraphQL，我可以準確地取得我需要的數據——不多也不少。不再需要處理多個端點或處理過度獲取。
• 效率：單一查詢可以取代多個 REST API 調用，從而大大提高效能。這對於具有複雜且相互關聯的數據的應用程式尤其有影響。
• 開發者體驗：強型模式、內省和更好的除錯工具使開發更加順利且不易出錯。
• 生態系統和社區支援： Apollo Client 和 GraphQL 等工具豐富了體驗，使學習 GraphQL 並將其更輕鬆地整合到我的工作流程中。

我是如何做出轉變的

這個旅程並非沒有挑戰，但將其分解為多個步驟使過渡變得易於管理：

第 1 步：了解 GraphQL 基礎

我從學習核心概念開始：

• 查詢來取得資料。
• 突變 修改數據。
• 解析器 將模式定義連接到實際資料來源。

這個基本理解是建立我的第一個 GraphQL 伺服器的關鍵。

第 2 步：建立我的第一個 GraphQL 伺服器

為了親自實踐，我使用 Node.js 和 Apollo Server 建立了一個簡單的伺服器。過程如下：

1. 設定 Node.js 專案： 使用 npm init 初始化專案並新增必要的依賴項。
2. 安裝 GraphQL 依賴項： 安裝了 apollo-server 和 graphql。
3. 編寫基本模式和解析器：定義一個模式來描述資料並編寫解析器來取得資料。
4. 運行伺服器：啟動伺服器並使用 GraphQL 測試查詢。

第一次看到它工作是不是很興奮？這讓我覺得付出的努力都是值得的。

第 3 步：轉換現有 REST API

下一步是將 GraphQL 整合到現有的基於 REST 的專案中。我採取了漸進的方法：

1. 確定了要替換為 GraphQL 查詢或突變的關鍵 REST 端點。
2. 建構了對應的 GraphQL 模式和解析器。
3. 在過渡期間與 GraphQL 一起維護 REST 端點以確保穩定性。

這種混合方法使我能夠在不破壞現有功能的情況下逐步推出 GraphQL。

快速入門指南：建立您的第一個 GraphQL 伺服器

GraphQL 入門比看起來更簡單。以下是使用 Node.js 和 Apollo Server 設定基本伺服器的快速指南：

第 1 步：安裝依賴項

先初始化 Node.js 專案並安裝必要的套件：

npm init -y  
npm install apollo-server graphql  

第 2 步：定義架構與解析器

建立一個名為index.js的檔案並加入以下程式碼：

const { ApolloServer, gql } = require('apollo-server');  

// Simulated user data  
const users = [  
  { id: '1', name: 'John Doe', email: 'john@example.com' },  
  { id: '2', name: 'Jane Smith', email: 'jane@example.com' },  
  { id: '3', name: 'Alice Johnson', email: 'alice@example.com' },  
];  

// Define schema  
const typeDefs = gql`  
  type User {  
    id: ID  
    name: String  
    email: String  
  }  

  type Query {  
    users: [User]  
    user(id: ID!): User  
  }  
`;  

// Define resolvers  
const resolvers = {  
  Query: {  
    users: () => users,  
    user: (_, { id }) => users.find((user) => user.id === id),  
  },  
};  

// Create server  
const server = new ApolloServer({ typeDefs, resolvers });  

// Start server  
server.listen().then(({ url }) => {  
  console.log(`? Server ready at ${url}`);  
});  

第 3 步：執行伺服器並測試

啟動伺服器：

node index.js  

在瀏覽器或 GraphQL 等工具中開啟提供的 URL 並測試查詢：

查詢所有使用者：

query {  
  users {  
    id  
    name  
    email  
  }  
}  

透過ID查詢單一使用者：

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

恭喜？ ？您剛剛建立了您的第一個 GraphQL 伺服器！

經驗教訓

切換到 GraphQL 給了我寶貴的教訓：

進展順利

• 這項轉變顯著提高了資料獲取效率。不再有索取不足或過度索取的情況！
• 強型別模式減少了運行時錯誤並使偵錯更容易。
• 生態系統的工具（如 Apollo Client）提高了開發人員的工作效率。

我會採取什麼不同的做法

• 循序漸進地學習：我一頭栽進去，這讓人不知所措。採取分階段的方法並首先關注查詢和突變會更順利。
• 從小處開始：我先用 GraphQL 取代單一 REST 端點，以了解工作流程。

給他人的建議

• 不要完全放棄 REST：REST 和 GraphQL 可以共存。使用 REST 進行簡單操作，使用 GraphQL 滿足複雜、相互關聯的資料需求。
• 利用社區：GraphQL 擁有活躍的社區和優秀的資源。不要猶豫尋求幫助或學習他人的經驗。

過渡到 GraphQL 不僅僅是改變工具，而是重新思考與數據互動的方式。從小事做起，不斷嘗試，享受這段旅程！

REST 與 GraphQL：快速比較

在 REST 和 GraphQL 之間做出決定時，了解關鍵差異可以幫助您為專案做出正確的選擇。這是一個快速細分：

功能 REST API GraphQL 標題>

Feature	REST API	GraphQL
Data Fetching	Fixed data structure for endpoints; can lead to over-fetching or under-fetching.	Flexible queries; fetch exactly what you need.
Endpoint Management	Multiple endpoints for different resources.	Single endpoint for all queries and mutations.
Flexibility	Limited flexibility; requires custom endpoints for specific data needs.	Highly flexible; client defines data requirements.
Type Safety	Relies on documentation; no built-in type enforcement.	Strongly-typed schema ensures predictable data.
Error Handling	Custom error formats; inconsistent across APIs.	Standardized error responses from schema validation.
Tooling	Varied and often endpoint-specific tools.	Rich ecosystem with tools like Apollo, GraphQL, and Relay.

資料取得 端點的固定資料結構；可能會導致過度抓取或抓取不足。 靈活的查詢；準確地取得您需要的內容。 端點管理 不同資源的多個端點。 所有查詢和突變的單一端點。 靈活性 靈活性有限；需要自訂端點來滿足特定資料需求。 高度靈活；客戶定義資料要求。 類型安全 依賴文件；沒有內建類型強制。 強類型架構確保資料可預測。 錯誤處理 自訂錯誤格式；跨 API 不一致。 架構驗證的標準化錯誤回應。 工具 各種且通常是特定於端點的工具。 擁有 Apollo、GraphQL 和 Relay 等工具的豐富生態系。 表>

雖然 REST API 可靠且得到廣泛支持，但 GraphQL 在需要複雜、相互關聯的資料和靈活性的場景中表現出色。
更深入研究我上一篇文章的差異

結論

從 REST 過渡到 GraphQL 對我來說改變了遊戲規則。靈活性、效率和改進的開發人員體驗使我的專案更加健壯和可擴展。也就是說，我堅信 REST API 和 GraphQL 可以共存，在不同的用例中相互補充。

如果您正在考慮進行轉換，我鼓勵您從小事做起，進行實驗，並逐漸將 GraphQL 整合到您的堆疊中。這是一段值得踏上的旅程，我很高興看到你如何將它變成你自己的。

入門資源

這裡有一些工具和指南可以幫助您深入了解 GraphQL：

• GraphQL 文檔
• Apollo 伺服器指南
• GraphQL 遊樂場

班蒂爾在嗎？
您是否已從 REST 過渡到 GraphQL，或者您是否正在考慮進行切換？一路走來，您經歷過哪些挑戰或成功？請隨時在下面的評論中分享您的想法、問題或經驗。讓我們一起成長、一起學習吧！ ？

以上是從 REST 到 GraphQL：我為何以及如何進行切換的詳細內容。更多資訊請關注PHP中文網其他相關文章！