GraphQL 介紹：
- GraphQL 是一種新的 API 標準，它提供了一種比 Restful API 更有效、更強大和更靈活的替代方案。
- 由 Facebook 開發並開源，現在由來自世界各地的公司和個人所組成的大型社區來做維護。
- GraphQL 本質上是一種基於 API 的查詢語言，現在大多數應用程序都需要從服務器中獲取數據，API 的職責就是提供與應用程序需求相匹配的存儲數據接口。
- GraphQL 可以跨不同 DB 應用，而且可以在任何使用 API 的環境中來做使用，可以理解爲 GraphQL 是基於 API 之上的一層封裝，目的是爲了能更靈活去應對業務上的需求變化。
圖中表示 GraphQL 主要是做為伺服器端和客戶端的中介，透過 GraphQL 的轉譯讓前後端可以正常溝通。
GraphQL 數據操作：
查詢（Query）：查詢透過 GraphQL Server 獲取所需要的數據。開發人員可以在查詢中來定義所需的數據字段，GraphQL Server 就會按照指定的結構返回相應的數據。變更（Mutation）：
變更用於 GraphQL Server 修改數據，例如新增、更新或刪除資料。變更操作流程跟查詢語句很相似，但因為資料會異動的關係，通常會需要用戶先通過登入驗證，已確保安全性。訂閱（Subscription）：
訂閱用於接收 GraphQL Server 即時的數據更新。當數據發生變化時，GraphQL Server 就會主動發送相關的更新給有做訂閱的對象，可以透過此機制來做相關的邏輯處理，例如：發送通知或即時更改畫面等等。 訂閱主要是靠 websocket 等協議，來推送變動的消息給訂閱的對象。
圖中表示 GraphQL 主要是做為伺服器端和客戶端的中介，透過 GraphQL 的轉譯讓前後端可以正常溝通。
GraphQL 數據操作：
查詢（Query）：
查詢透過 GraphQL Server 獲取所需要的數據。開發人員可以在查詢中來定義所需的數據字段，GraphQL Server 就會按照指定的結構返回相應的數據。
變更（Mutation）：
變更用於 GraphQL Server 修改數據，例如新增、更新或刪除資料。變更操作流程跟查詢語句很相似，但因為資料會異動的關係，通常會需要用戶先通過登入驗證，已確保安全性。
變更用於 GraphQL Server 修改數據，例如新增、更新或刪除資料。變更操作流程跟查詢語句很相似，但因為資料會異動的關係，通常會需要用戶先通過登入驗證，已確保安全性。
訂閱（Subscription）：
訂閱用於接收 GraphQL Server 即時的數據更新。當數據發生變化時，GraphQL Server 就會主動發送相關的更新給有做訂閱的對象，可以透過此機制來做相關的邏輯處理，例如：發送通知或即時更改畫面等等。 訂閱主要是靠 websocket 等協議，來推送變動的消息給訂閱的對象。
訂閱用於接收 GraphQL Server 即時的數據更新。當數據發生變化時，GraphQL Server 就會主動發送相關的更新給有做訂閱的對象，可以透過此機制來做相關的邏輯處理，例如：發送通知或即時更改畫面等等。 訂閱主要是靠 websocket 等協議，來推送變動的消息給訂閱的對象。
GraphQL 核心概念：
圖表模式 (Schema)：- 用來描述 GraphQL 數據模型中的業務數據，可以理解為操作語法的設計
- 類型是 schema 最核心的東西，數據模型通過類型來做描述
圖表模式 (Schema)：
- 用來描述 GraphQL 數據模型中的業務數據，可以理解為操作語法的設計
- 類型是 schema 最核心的東西，數據模型通過類型來做描述
類型 (Type)：- 標量類型 - 標量是類型系統中最小的單位。類似於程式語言中的基本 class。
- 對象類型 - 僅有標量類型是不能滿足複雜抽象數據模型的需求，這時候可以使用對象類型來處理。可以通過對象模型來構建 GraphQL 中關於一個數據模型的形狀，同時還能聲明各模型間的內在關聯 (例如：一對多、一對一或多對多等關聯關係)。
- 類型修飾符 - 類型系統僅僅只有類型定義是不夠的，還需要對類型進行更廣泛性的描述。類型修飾符就是用來修飾類型，以達到額外的數據類型要求控制。
類型 (Type)：
- 標量類型 - 標量是類型系統中最小的單位。類似於程式語言中的基本 class。
- 對象類型 - 僅有標量類型是不能滿足複雜抽象數據模型的需求，這時候可以使用對象類型來處理。可以通過對象模型來構建 GraphQL 中關於一個數據模型的形狀，同時還能聲明各模型間的內在關聯 (例如：一對多、一對一或多對多等關聯關係)。
- 類型修飾符 - 類型系統僅僅只有類型定義是不夠的，還需要對類型進行更廣泛性的描述。類型修飾符就是用來修飾類型，以達到額外的數據類型要求控制。
Restful API 介紹：
概念：RESTful API 是一種設計和構建 API 的軟體架構風格，主要目的在於實現 Web 服務的可用性、操作性和可擴展性。- 統一介面 - Rest 架構的核心，統一介面能讓客戶端只需要關注實作，透過統一界面的定義，可以增加可讀性，也能讓開發人員更方便的使用。 RESTful API 會利用 URL 來定位資源，並通過 HTTP 方法來操作，包括新增、查詢、修改和删除，剛好對應 HTTP 協議提供的 GET、POST、PUT 和 DELETE 方法。
- Client-Server 架構 - 架構將用戶介面跟資料儲存做切割，使其方便兩者能獨立運作與維護，客戶端是負責請求和處理資料的元件，伺服器端則是負責儲存資料和處理請求的元件。
- 無狀態 - Restful API 每次連線本身都攜帶足夠的資訊，而不用依賴於上次連線的狀態，這邊主要說明 Restful API 每個請求都是獨立的，沒有前後關係，伺服器端不會保存客戶端的狀態訊息。這樣做的好處是可以使每個請求變得簡單，更容易理解和處理，並且能更輕鬆的擴展和維護。
- 可緩存性 - Restful API 會根據 API 請求和回應內容，決定是否能被緩存，增加使用效率客戶端和伺服器端可以協商快取內容，透過設定 HTTP 狀態碼，伺服器端可以告訴客戶端這個資料是否可以快取。
- 分層系統 - 完整的系統可以由多個子元件疊加，客戶端不應該關心請求經過了多少中間層，只需關心請求的結果就可以了。系統可以分成多個層次，每一層獨立完成自己的任務。這樣的結構使得系統更容易維護，並且允許獨立替換不同層次。(例如，資料庫儲存層可以獨立於其他層，在不影響其他層的情況下進行替換或擴充)。
- 代碼請求 - 這是一個可選原則，這個原則主要提倡伺服器端可以將客戶端的程式碼下載到本地來執行。這樣，客戶端可以根據伺服器端發送的程式碼來擴展它的功能。這個原則可以使客戶端程式碼變得更加靈活，並且可以透過伺服器端提供的程式碼來解決問題，而不必再等待下一個版本。
概念：
- 統一介面 - Rest 架構的核心，統一介面能讓客戶端只需要關注實作，透過統一界面的定義，可以增加可讀性，也能讓開發人員更方便的使用。 RESTful API 會利用 URL 來定位資源，並通過 HTTP 方法來操作，包括新增、查詢、修改和删除，剛好對應 HTTP 協議提供的 GET、POST、PUT 和 DELETE 方法。
- Client-Server 架構 - 架構將用戶介面跟資料儲存做切割，使其方便兩者能獨立運作與維護，客戶端是負責請求和處理資料的元件，伺服器端則是負責儲存資料和處理請求的元件。
- 無狀態 - Restful API 每次連線本身都攜帶足夠的資訊，而不用依賴於上次連線的狀態，這邊主要說明 Restful API 每個請求都是獨立的，沒有前後關係，伺服器端不會保存客戶端的狀態訊息。這樣做的好處是可以使每個請求變得簡單，更容易理解和處理，並且能更輕鬆的擴展和維護。
- 可緩存性 - Restful API 會根據 API 請求和回應內容，決定是否能被緩存，增加使用效率客戶端和伺服器端可以協商快取內容，透過設定 HTTP 狀態碼，伺服器端可以告訴客戶端這個資料是否可以快取。
- 分層系統 - 完整的系統可以由多個子元件疊加，客戶端不應該關心請求經過了多少中間層，只需關心請求的結果就可以了。系統可以分成多個層次，每一層獨立完成自己的任務。這樣的結構使得系統更容易維護，並且允許獨立替換不同層次。(例如，資料庫儲存層可以獨立於其他層，在不影響其他層的情況下進行替換或擴充)。
- 代碼請求 - 這是一個可選原則，這個原則主要提倡伺服器端可以將客戶端的程式碼下載到本地來執行。這樣，客戶端可以根據伺服器端發送的程式碼來擴展它的功能。這個原則可以使客戶端程式碼變得更加靈活，並且可以透過伺服器端提供的程式碼來解決問題，而不必再等待下一個版本。
GraphQL 流程：
- 第一步，需要先設計所需數據模型，模型主要是用來定義的數據格式檢核，爲下一步查詢響應做準備。
- 第二步，客戶端會透過查詢語言，描述想要請求的數據對象，和具體需要的資料結構。
- 第三步，伺服器端的 GraphQL 通過客戶端傳過來的請求，根據請求的查詢條件和資料結構，組裝精確的數據回傳至客戶端，讓客戶端組成想呈現的頁面。
- 第一步，需要先設計所需數據模型，模型主要是用來定義的數據格式檢核，爲下一步查詢響應做準備。
- 第二步，客戶端會透過查詢語言，描述想要請求的數據對象，和具體需要的資料結構。
- 第三步，伺服器端的 GraphQL 通過客戶端傳過來的請求，根據請求的查詢條件和資料結構，組裝精確的數據回傳至客戶端，讓客戶端組成想呈現的頁面。
GraphQL 和 Restful 結構差異：
Restful API 其實是多個端點的服務，它會透過打多次不同的 API 來取的所需的資訊。圖中當 Restful API 要取得書和對應作者的資訊，它會透過兩個 API 來將資料湊齊。
GraphQL 則不同， 它是一個單一端點的服務，對外只提供了一個用於調用內部接口的端點，所有的請求都訪問這個唯一端點。圖中 GraphQL 可以定義要查詢的條件和回傳的資料結構，集中成一個請求來得到所需的資料。
Rest API call - 透過使用者資料的 API，取得回傳的使用者 ID 資訊，再利用 ID 資訊至取得地址的 API ，取得對應的使用者地址資料。GraphQL API call - 直接透過對象類型的關聯，能直接取出使用者的個資和其地址資料，並且可以定義想要回傳的欄位格式。
GraphQL 和 Restful 比較：
REST
GraphQL
定義
用於定義 Client 與 Server 之間的資料交換的規則。
是一種查詢語言，用於建立和操作 API 的工具。
適合性
適用於明確定義資源的簡單資料。
適用於大型、複雜且相互關聯的資料來源。
資料存取
具有 URL 形式的多個端點來定義資源。
GraphQL 具有個單一的 URL 端點。
回傳資料
以 Server 定義的固定結構資料。
以 Client 定義的彈性結構資料。
資料結構化和定義方式
資料為弱類型。
後端需決定如何判讀格式化資料。
資料為強類型。
Client 會預先決定要接收的資料結構。
REST | GraphQL | |
定義 | 用於定義 Client 與 Server 之間的資料交換的規則。 | 是一種查詢語言，用於建立和操作 API 的工具。 |
適合性 | 適用於明確定義資源的簡單資料。 | 適用於大型、複雜且相互關聯的資料來源。 |
資料存取 | 具有 URL 形式的多個端點來定義資源。 | GraphQL 具有個單一的 URL 端點。 |
回傳資料 | 以 Server 定義的固定結構資料。 | 以 Client 定義的彈性結構資料。 |
資料結構化和定義方式 | 資料為弱類型。 後端需決定如何判讀格式化資料。 | 資料為強類型。 Client 會預先決定要接收的資料結構。 |
GraphQL 使用場景：
- 多數據源整合 - GraphQL 適合應用在有多個不同數據源需要統整再一起的的情境。例如可能需要從多個數據庫、外部 API、內部服務等不同來源獲取需要的資料。它能夠將這些數據源的數據整合到一個統一的 API 中，客戶端就可以按照需求，查詢所需要的數據，而不用每個數據源都各自發一個獨立的請求。
- 移動應用程序 - GraphQL 特別適合應用在 APP， GraphQL 能讓客戶端精確指定所需要的數據，這樣能減少 APP 過度傳輸資料和使用網路的流量。App 也經常會需要不同結構和大小的數據，GraphQL 能夠根據不同設備和用戶的需求提供最佳性能。
- 複雜數據需求 - GraphQL 允許客戶端用一個複雜的查詢，就能檢索所有需要的資料，從而提高效率並減少過多的數據傳輸。
- 實時數據需求 - 如果應用程序需要實時或即時更新的數據，GraphQL 具有優勢。使用 GraphQL 訂閱功能，可以讓客戶端 觀察數據的變化，當數據異動更新時，可以即時發出通知，這對於聊天應用和實時通知非常有用。
- 多數據源整合 - GraphQL 適合應用在有多個不同數據源需要統整再一起的的情境。例如可能需要從多個數據庫、外部 API、內部服務等不同來源獲取需要的資料。它能夠將這些數據源的數據整合到一個統一的 API 中，客戶端就可以按照需求，查詢所需要的數據，而不用每個數據源都各自發一個獨立的請求。
- 移動應用程序 - GraphQL 特別適合應用在 APP， GraphQL 能讓客戶端精確指定所需要的數據，這樣能減少 APP 過度傳輸資料和使用網路的流量。App 也經常會需要不同結構和大小的數據，GraphQL 能夠根據不同設備和用戶的需求提供最佳性能。
- 複雜數據需求 - GraphQL 允許客戶端用一個複雜的查詢，就能檢索所有需要的資料，從而提高效率並減少過多的數據傳輸。
- 實時數據需求 - 如果應用程序需要實時或即時更新的數據，GraphQL 具有優勢。使用 GraphQL 訂閱功能，可以讓客戶端 觀察數據的變化，當數據異動更新時，可以即時發出通知，這對於聊天應用和實時通知非常有用。
GraphQL 優點：
- 精準獲取數據 - GraphQL 可以讓客戶端依照當前頁面所需的數據，精確的從資料庫取出所需資料，而不是獲取整包的資訊，再由前端來做過濾處理。
- 減少網絡傳輸 - GraphQL 可以透過發送一次的請求，就能獲取來自各方面的資源數據，對比需要透過執行多次的 API 才能將資料組裝完成的流程，這個特性更能減少網絡傳輸次數，以此提高網頁處理效率和回應速度。
- 靈活性和可擴展性 - GraphQL 具有靈活的查詢特性，可以讓客戶端依不同情境，添加對應的查詢條件和定義回傳數據類型，這樣可以使得 API 的擴展性跟靈活度都變高。
- 類型系統 - GraphQL 具有強大的類型系統，透過定義 API 回傳數據結構，能使客戶端和伺服器端能夠更好地理解 API 的回傳的資料結構，從而減少資料格式回傳錯誤的發生。
- 前後端獨立 - GraphQL 允許前端和後端團隊獨立開發，前端可以根據頁面的需求來查詢所需要的資料，而不再需要等待後端開發完 API 才能進行開發。
GraphQL 缺點：
- 學習曲線 - 因為 GraphQL 涉及到比較復雜的類型系統、查詢語言和執行機制等概念。那會相對於當前專案使用的 RESTFUL API，上手難度會再更高一點。
- 複雜性 - GraphQL 因為具有很好靈活性和可擴展性，所以也會使得 GraphQL 變得相對複雜。需要開發人員投入更多的精力來設計、實做和維護它。
- 性能 - 雖然 GraphQL 可以減少網絡傳輸，但如果查詢語句過於複雜，或回傳的資料結構過於多層，就可能會導致查詢執行時間較長，從而影響 API 的響應時間。
- 安全性 - 允許客戶端查詢所需的任何數據，那這樣可能會導致安全上的漏洞。例如數據洩露和暴露 API 中的敏感信息。因此，需要另外採取措施來確保 GraphQL 的安全性，例如建立授權機制等等。
GraphQL 與 Laravel 應用套件：
- rebing/graphql-laravel - 整合了 GraphQL 到 Laravel，並且將前面所述的相關類型定義，轉換成 Laravel 裡面原本就有的語法，設定起來更直覺方便，無需在特地去學 GraphQL 原生的寫法，對象類型關聯的部份，也是直接使用 Laravel 原生 orm 關聯實做即可。
- mll-lab/laravel-graphql-playground - 可直接在網頁上，執行 GraphQL 查詢測試，直觀的檢測 GraphQL 語法邏輯是否有問題，無需再使用 postman 程式語法結果，可以讓開發和除錯更便利快速。
GraphQL-Laravel 程式定義範例：
定義基本類型：
定義基本類型：
定義查詢邏輯： 
設定 schema 關聯：
定義查詢邏輯：
0 Comments:
張貼留言