前端開發人員希望構建出色的體驗，然而，他們需要來自后端的數據并對后端執行操作。他們的問題的答案是 API。誰構建了這些 API? 它們是快速構建還是前端開發人員等待？ 誰運行和管理 API? 畢竟，后端的行為方式并不統一——它們說不同的語言，發出不同形狀的數據，有不同的身份驗證要求等等。因此，運行和管理前端 API 并非易事。想要學習前端技術，可以參加Web前端培訓，有更加全面系統的課程來學習，幫助你更好的理解與運用前端開發知識和技能。

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

　　1. API 的形狀很重要

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

　　2. 抽象后端很重要

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

　　3. 性能和可靠性問題

　　有兩種方法可以做 API。要么每個 API 都承擔著處理性能(“讓我引入緩存”)或錯誤(“這個后端有時會發出錯誤數據，讓我編寫邏輯來繞過它”)的負擔，或者每個 API 都聲明它的內容這樣做，系統就會觀察并做正確的事情。第二種模式更可取——想想 SQL，你不編碼錯誤條件或性能。相反，數據庫試圖并且幾乎總是做正確的事情。在Web前端培訓中，有經驗豐富的專業老師面授指導教學，通過理論結合實戰的方式教授前端知識，讓你快速學會前端技術。

　　4. 如何構建 API 很重要

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

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

　　啟動并運行 API 很重要，但是到達那個點的路比前面的路要短得多。后端永遠不穩定，密鑰被撤銷，不良數據被發出，程序需要擴展，需要監控性能，誰在這樣做? API 團隊越來越多地采用 API 即服務作為這些日常運營問題的解決方案。參加Web前端培訓是入門學習的最佳選擇，在短時間內盡快掌握JavaScript的相關知識，有助于你更好地進行開發工作。

　　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 的開發人員的最佳工具。如果你想往前端的方向走，還有更多的東西要學，可以報個Web前端培訓班，有系統全面的課程和明確清晰的學習路線，讓學習更輕松更有效。