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