使用這些基本 REST API 最佳實踐構建出色的 API
你可能也喜歡這些API文章!
自 2015 年發布以來，GraphQL 已成為REST 的替代品。它為前端開發人員提供了他們渴望已久的靈活性。
向后端開發人員索要單一用途端點的日子已經一去不復返了。現在，查詢可以定義所需的所有數據并一次性請求，至少在理論上可以大大減少延遲。
有了 REST，事情就變得簡單多了 — 尤其是監控。后端團隊可以查看每個端點的測量結果，并立即了解正在發生的事情。
有了 GraphQL，情況就不一樣了。通常只有一個端點，因此測量每個端點并沒有多大幫助。那么，新的地方在哪里可以連接到系統呢？
在本文中，我們研究監控 GraphQL！
為了了解我們系統中有趣的點在哪里，讓我們研究一下潛在的架構。
一個簡單的GraphQL系統主要由三部分組成：
GraphQL 后端首先解析模式，這使服務器了解哪個解析器處理哪種類型。
當我們向 GraphQL 端點發送查詢時，它會被引擎解析，并且對于查詢中的每個請求類型，引擎都會調用我們的解析器來滿足請求。
我們可以想象，這種方法只有在與簡單查詢一起使用時才能提供出色的性能。
有時查詢的各個部分可以在我們的數據源（數據源指的是數據庫或第三方 API 之類的東西）中互連。例如，我們正在加載用戶帳戶及其地址。它們在 GraphQL 模式中可能是兩種類型，但在數據源中僅僅是一條記錄。如果我們一次請求兩者，我們就不會期望服務器向數據源發出兩個請求。
為了解決這個問題，人們開始使用一種叫做data-loader 的模式。
數據加載器是我們 GraphQL API 中的另一層，位于解析器和數據源之間。
在簡單的設置中，解析器將在更復雜的迭代中直接訪問數據源，解析器將告訴數據加載器它們需要什么，然后該加載器將為它們訪問數據源。
這為什么有幫助？
數據加載器可以等到所有解析器都被調用并合并對數據源的訪問。
有人想加載用戶賬戶和地址嗎？現在這只是對數據源的一個請求！
這個想法是，解析器只知道它自己的要求，而數據加載器知道所有解析器想要什么，并且可以優化訪問。
如我們所見，根據我們的架構，我們可以在多個地方監控我們的 GraphQL API。
HTTP 端點是我們監控 REST API 的對象。在 GraphQL 世界中，通常只有一個端點，因此在此級別進行監控只能為我們提供有關 API 總體狀態的信息。
這還不錯。至少它給了我們一個起點。如果一切都正常，低延遲、低錯誤率、沒有客戶投訴、一切都很順利，那么我們只需查看這些指標就可以節省時間和金錢。
如果有什么不對勁，我們需要深入挖掘。
下一個顯而易見的步驟是查看每個查詢，這對于具有相當靜態使用模式的 API 來說已經足夠了。
如果我們僅對自己的客戶使用 API，那么很明顯查詢不會經常更改，但如果我們的 API 可供具有不同要求的不同客戶使用，事情就不再那么簡單了。
突然間，我們可能會有數百個（略微）不同的查詢，由于某種原因，它們都運行緩慢。
緩解此問題的一種方法是檢查最常見的查詢并嘗試綜合監控它們。這意味著我們定義一堆查詢和變量組合，并從測試客戶端運行它們，以檢查推出新版本時它們需要多長時間。這樣，我們可以降低通過更新造成重大性能下降的風險。持久查詢可以幫上忙。它們是緩存最常用查詢的一種方式。
如果事情超出了我們的理解范圍，我們就需要采取進一步的措施。
監控發生情況的最佳位置通常是輪胎與路面接觸的地方。如果我們查看后端訪問數據源的位置，我們就可以更好地掌握現實情況。
我們使用的數據源類型是否不適合訪問模式？我們需要不同類型的數據庫嗎？
我們的數據源類型沒問題，但我們應該改進對它們的請求嗎？如果我們還沒有使用數據加載器，是否需要它？
我們向外部 API 發送的請求是否太慢了？我們能否將數據復制到更靠近后端的位置？
當我們看到后端檢索的數據是什么以及如何檢索時，現在可以問所有這些問題。
這里我們還看到了數據加載器的另一個好處。解析器只允許我們監控一個解析器在做什么；數據加載器允許我們查看一個請求中所有解析器在做什么，并且還允許我們在發現解析器間問題后解決這些問題。
這是監控的最高原則。查詢進入時，用跟蹤 ID 標記查詢，并在查詢被解析到解析器、數據加載器甚至數據源時傳遞此 ID。這樣，我們就可以在記錄時間和錯誤時使用跟蹤 ID，以便稍后整合它們，從而了解整體情況。
這里的想法如下：
雖然測量查詢可能會為我們提供一些關于解析時間的數據，但實際的數據加載是在解析器和/或數據加載器中完成的，而不是在解析查詢時完成的。
由于 GraphQL 的核心思想之一是將查詢與實際數據加載分離，因此在加載數據時我們不再使用查詢，但當有人發送查詢時，看到后臺發生的事情仍然很有趣。
了解 GraphQL API 的后端是如何構建的，可以讓我們對在何處監控這樣的系統有更多的可行想法。
與 REST API 相比，事情確實變得有點麻煩，但 GraphQL API 中并沒有什么神奇的事情發生，它只是我們可以為監控等不同目的而掛鉤的代碼。
如果我們在生產系統中獲得了可見性，那么有關緩存和錯誤處理的問題也會變得更加清晰。
原文地址：https://www.moesif.com/blog/technical/monitoring/How-to-Best-Monitor-GraphQL-APIs/
