衡量API效能對於實現正確性非常重要，而對於GraphQL也是如此。實際上，有些人可能因為效能問題而使用GraphQL，並用一個GraphQL呼叫替換多個呼叫。但是你的GraphQL查詢實際上更快嗎？這就是監控它們的重要性。

如果您已習慣基於端點的HTTP API，則可能之前已成功完成某些監視。例如，監控API效能的最基本方法之一是測量響應時間。

不幸的是，我們很快發現，測量GraphQL端點的響應時間幾乎不能讓我們深入瞭解GraphQL API的執行狀況。讓我們看一下超簡化的例子。想象一下，您維護一個當前提供簡單查詢的GraphQL API：

query {
  viewer {
    name
    bestFriend {
      name
    }
  }
}

現在，一個新的API客戶端開始使用我們的GraphQL API，但是不同的更大的需求：

query {
  viewer {
    friends(first: 1000) {
      bestFriend {
        name
      }
    }
  }
}

第二個實際上是請求超過一百個物件，而第一個只查詢一個物件。如果您正在監視GraphQL端點，您會看到響應時間大幅增加。這是因為我們返回的響應確實有點慢，因為我們提供了更復雜的查詢！

如果您正在管理公共API，或者使用大量客戶端和查詢的非常大的內部API，由於查詢的基數較高，監控效能可能並不容易，隱藏在其中。然後我們必須找到其他方法。

一種常見的方法是將我們的思維方式從監控查詢轉變為監控解析器，其中計算單個欄位。然後我們可以快速檢視欄位是否表現緩慢。這種方法存在一個主要問題，這使得使用這種方法很難準確地監控GraphQL API的效能：延遲/批量載入

我們如何確定GraphQL端點的響應時間對於特定查詢來說是否太慢。可以構建類似於慢查詢日誌的東西，以幫助工程師找出哪些查詢執行緩慢。

是否能找到查詢複雜性和查詢執行時間之間的關係。如果我們發現它們以特定方式相關，我們理論上可以檢測到異常。例如，具有高執行時間的低複雜性查詢可能表示我們需要仔細檢視查詢的執行情況。

大規模的GraphQL監控真的很難。現在沒有太多工具可以幫助我們解決這些問題，但我希望我們能夠探索更智慧的方法來深入瞭解GraphQL的執行效能，敬請期待！