快取

提供物件識別碼讓客戶端建置豐富的快取

在基於端點的 API 中，客戶端可以使用 HTTP 快取輕鬆避免重新擷取資源，並用於識別兩個資源是否相同。這些 API 中的 URL 是全域唯一識別碼，客戶端可以利用它來建置快取。然而，在 GraphQL 中，沒有類似 URL 的原語提供給定物件的這個全域唯一識別碼。因此，最好的做法是讓 API 揭露此類識別碼供客戶端使用。

全域唯一識別碼#

一種可能的模式是保留一個欄位，例如 id，作為全域唯一識別碼。這些文件所使用的範例架構使用這種方法

這是交給客戶端開發人員的強大工具。就像基於資源的 API 的 URL 提供全域唯一金鑰一樣，此系統中的 id 欄位提供全域唯一金鑰。

如果後端使用類似 UUID 的識別碼，那麼揭露這個全域唯一識別碼可能非常簡單！如果後端尚未為每個物件提供全域唯一識別碼，GraphQL 層可能必須建構這個識別碼。通常，這就像將類型的名稱附加到識別碼並將其用作識別碼一樣簡單；然後伺服器可能會透過 base64 編碼使該識別碼不透明。

此外，這個識別碼可以用於與 全域物件識別 的 node 模式搭配使用。

與現有 API 的相容性#

使用 id 欄位作為此目的時，一個問題是使用 GraphQL API 的客戶端如何與現有 API 合作。例如，如果我們的現有 API 接受類型特定的 ID，但我們的 GraphQL API 使用全域唯一 ID，那麼同時使用這兩種方式可能會很棘手。

在這些情況下，GraphQL API 可以將先前 API 的 ID 顯示在一個獨立的欄位中。這讓我們能同時獲得兩全其美的結果

• GraphQL 客戶端可以繼續依賴一致的機制來取得全域唯一 ID。
• 需要與我們先前 API 合作的客戶端也可以從物件中擷取 previousApiId，並使用它。

其他選項#

雖然全域唯一 ID 已被證明是過去強大的模式，但它們並不是唯一可使用的模式，也不是適用於每種情況。客戶端真正需要的關鍵功能是為其快取衍生全域唯一識別碼的能力。雖然讓伺服器衍生該 ID 可以簡化客戶端，但客戶端也可以衍生識別碼。通常，這就像將物件的類型（使用 __typename 查詢）與一些類型唯一的識別碼相結合一樣簡單。

此外，如果使用 GraphQL API 取代現有的 API，如果 GraphQL 中的所有欄位都相同，除了 id 已變更為全域唯一，這可能會令人困惑。這將是另一個原因，說明為什麼有人可能選擇不使用 id 作為全域唯一欄位。