以下是你通過作為前端和后端之間的齒輪箱的 API 思考時的一些注意事項。

1. API 的形狀很重要

是否有一種 API 語言比 REST API 的“你從 JSON 響應中得到什么”更靈活，并且比“隨心所欲”更適合作為 SQL 構造?原來有GraphQL。對于前端開發人員來說，這太棒了。對于構建 API 的人來說，這同樣很棒。為什么?因為它允許連接點、自動文檔和“需要時抽象;不需要時詳細。”我強烈建議將 GraphQL 實現為這些變速箱 API 的形狀。

2. 抽象后端很重要

從根本上說，前端應用程序并不關心數據來自哪里，他們只想要數據。這意味著無論數據來自 REST 端點、SQL 數據庫、NoSQL 數據庫、GraphQL 后端，甚至是 WSDL/XML 后端，前端都不應該關心。如果有兩個不同的后端將數據輸入一個通用類型，那就這樣吧，前端不應該關心。

3. 性能和可靠性問題

有兩種方法可以做 API。要么每個 API 都承擔著處理性能(“讓我引入緩存”)或錯誤(“這個后端有時會發出錯誤數據，讓我編寫邏輯來繞過它”)的負擔，或者每個 API 都聲明它的內容這樣做，系統就會觀察并做正確的事情。第二種模式更可取——想想 SQL，你不編碼錯誤條件或性能。相反，數據庫試圖并且幾乎總是做正確的事情。

4. 如何構建 API 很重要

前端團隊的需求隨著客戶和市場的需求而不斷發展。并且同時存在多個前端需求。跟上這一切并不容易。當然，你可以啟動一個程序，對其進行編碼，并隨著需求的發展來管理其生命周期。該程序承擔了性能、可靠性等方面的負擔。或者，你可以使用聲明性構造構建 API — 使用來自后端 Y 的調用實現類型 X。類型 Z 使用此字段連接到類型 X。聲明式構造允許快速構建 API。聲明式結構還有另外兩個真正有用的目的：(i)它們使業務邏輯遠離前端 API 和(ii)它們導致更好的部署和運行時特性，因為它更容易推理和采取行動，一個使用聲明性構造構建的 API。

5. 部署和運行時特性很重要

啟動并運行 API 很重要，但是到達那個點的路比前面的路要短得多。后端永遠不穩定，密鑰被撤銷，不良數據被發出，程序需要擴展，需要監控性能，誰在這樣做? API 團隊越來越多地采用 API 即服務作為這些日常運營問題的解決方案。

6. API 安全問題

API 為前端團隊提供了很大的靈活性和對數據的訪問，他們允許他們建立很棒的體驗，但是現在，需要做些什么來確保不發生壞事呢?你有后端密鑰要管理，你可以管理前端訪問控制，如果你決定使用 GraphQL，你會更加頭疼“我的突變端點不應該可訪問”或“瀏覽器是否更改了查詢參數并且現在正在詢問不應該訪問的數據?” API 管理可以解決一些問題，但一般來說，GraphQL 和后端密鑰相關的問題無法通過圍繞你的 API 進行分層 API 管理來解決。

7. 這是API管理嗎?

API 管理不應與 API 混淆。雖然許多 API 管理產品允許你在其工具中構建 API，但你越來越希望在適合該 API 的工具中構建 API。例如，如果你的 API 是 GraphQL，你需要一個工具來幫助你構建和運行設計良好且性能良好的 GraphQL API。然后，你可能希望在開發門戶、分析和一些使用 API 管理的前端密鑰管理中分層。

結論

好的 GraphQL 端點必須平衡很多東西。我相信 GraphQL 真的很強大，對于前端和后端開發人員來說都是一個不錯的選擇，但是 GraphQL 是新的，構建 GraphQL API 的開發人員必須認識到最佳實踐和權衡，他們必須做出有意識的決定來做正確的事。最終，推動平衡的系統和工具將成為構建開發人員和使用 GraphQL API 的開發人員的最佳工具。