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

1. API 的形狀很重要

是否有一種 API 語言比 REST API 的“你從 JSON 響應(yīng)中得到什么”更靈活，并且比“隨心所欲”更適合作為 SQL 構(gòu)造?原來有GraphQL。對(duì)于前端開發(fā)人員來說，這太棒了。對(duì)于構(gòu)建 API 的人來說，這同樣很棒。為什么?因?yàn)樗试S連接點(diǎn)、自動(dòng)文檔和“需要時(shí)抽象;不需要時(shí)詳細(xì)?！蔽覐?qiáng)烈建議將 GraphQL 實(shí)現(xiàn)為這些變速箱 API 的形狀。

2. 抽象后端很重要

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

3. 性能和可靠性問題

有兩種方法可以做 API。要么每個(gè) API 都承擔(dān)著處理性能(“讓我引入緩存”)或錯(cuò)誤(“這個(gè)后端有時(shí)會(huì)發(fā)出錯(cuò)誤數(shù)據(jù)，讓我編寫邏輯來繞過它”)的負(fù)擔(dān)，或者每個(gè) API 都聲明它的內(nèi)容這樣做，系統(tǒng)就會(huì)觀察并做正確的事情。第二種模式更可取——想想 SQL，你不編碼錯(cuò)誤條件或性能。相反，數(shù)據(jù)庫(kù)試圖并且?guī)缀蹩偸亲稣_的事情。

4. 如何構(gòu)建 API 很重要

前端團(tuán)隊(duì)的需求隨著客戶和市場(chǎng)的需求而不斷發(fā)展。并且同時(shí)存在多個(gè)前端需求。跟上這一切并不容易。當(dāng)然，你可以啟動(dòng)一個(gè)程序，對(duì)其進(jìn)行編碼，并隨著需求的發(fā)展來管理其生命周期。該程序承擔(dān)了性能、可靠性等方面的負(fù)擔(dān)。或者，你可以使用聲明性構(gòu)造構(gòu)建 API — 使用來自后端 Y 的調(diào)用實(shí)現(xiàn)類型 X。類型 Z 使用此字段連接到類型 X。聲明式構(gòu)造允許快速構(gòu)建 API。聲明式結(jié)構(gòu)還有另外兩個(gè)真正有用的目的：(i)它們使業(yè)務(wù)邏輯遠(yuǎn)離前端 API 和(ii)它們導(dǎo)致更好的部署和運(yùn)行時(shí)特性，因?yàn)樗菀淄评砗筒扇⌒袆?dòng)，一個(gè)使用聲明性構(gòu)造構(gòu)建的 API。

5. 部署和運(yùn)行時(shí)特性很重要

啟動(dòng)并運(yùn)行 API 很重要，但是到達(dá)那個(gè)點(diǎn)的路比前面的路要短得多。后端永遠(yuǎn)不穩(wěn)定，密鑰被撤銷，不良數(shù)據(jù)被發(fā)出，程序需要擴(kuò)展，需要監(jiān)控性能，誰在這樣做? API 團(tuán)隊(duì)越來越多地采用 API 即服務(wù)作為這些日常運(yùn)營(yíng)問題的解決方案。

6. API 安全問題

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

7. 這是API管理嗎?

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

結(jié)論

好的 GraphQL 端點(diǎn)必須平衡很多東西。我相信 GraphQL 真的很強(qiáng)大，對(duì)于前端和后端開發(fā)人員來說都是一個(gè)不錯(cuò)的選擇，但是 GraphQL 是新的，構(gòu)建 GraphQL API 的開發(fā)人員必須認(rèn)識(shí)到最佳實(shí)踐和權(quán)衡，他們必須做出有意識(shí)的決定來做正確的事。最終，推動(dòng)平衡的系統(tǒng)和工具將成為構(gòu)建開發(fā)人員和使用 GraphQL API 的開發(fā)人員的最佳工具。