HotChocolate (GraphQL) 忽略查詢中的架構錯誤

Question

我希望能夠“抑制”默認的 HotChocolate（服務器）行為並忽略查詢時的架構錯誤。

讓我試着舉個例子。 假設我們確實有以下模式：

type Query {
    myTypes: [MyType]
}

type MyType{
    id: ID!
    name: String
}

如果我嘗試進行如下查詢：

{
    myTypes {
        id,
        name
    }
}

一切正常。 但是，如果我做類似的事情：

{
    myTypes {
        id,
        name,
        notKnownProperty
    }
}

查詢失敗。 這通常是期望的行為（嚴格模式的全部好處），但在我的特定情況下不是。

用例是當我們有 2 個或更多服務時，它們公開一個相同的模式（具有不同的數據）並且其中一些服務以不同的速度發展。 不幸的是，我們無法控制這些服務的版本，因為其中一些是內部部署的。 我們最終會遇到一些服務比其他服務具有更新版本（具有更多相同類型的字段）的情況。 這限制了我們只能使用最舊的可用客戶端。 我們想做相反的事情 - 使用最新的客戶端並處理其中的缺失字段（例如使用默認值）。

一種可能的解決方案是實施某種版本控制。 在路徑（又名 /graphql/v1）或 object 類型本身（又名 MyType1、MyType2 等）中。 但我個人不喜歡這些方法。

任何想法和意見表示贊賞

提前致謝

Answer 1

一旦您想使用新客戶端，它們應該向后兼容，即能夠正確使用舊版本的 API。 為此，將不存在的值視為具有默認（空）值顯然是不夠的。 當您的最終用戶沒有電話號碼和他們有但舊的 API 版本不提供電話號碼時，這是一個很大的區別。 所以，你需要有一個更強大的策略來實現向后兼容。 如果您不想按原樣使用版本控制，關於 GraphQL（不僅僅是熱巧克力），至少還有兩種其他可用策略：

1. 您的客戶端應用程序最初可以分析該方案以檢查缺少哪些屬性，並決定如何構建對具有該知識的 API 的請求。
2. 您的客戶端應用程序可以即時更改其策略。 即不查詢方案，而是處理查詢的錯誤。 由於 Graph QL 中的錯誤非常結構化，客戶端可以很容易地了解哪些屬性被遺漏並相應地調整未來的請求。