[[438417]]

大家好，我是程序員幽鬼。

用 Go 編寫 API 服務(wù)，許多語言新手問的第一件事是：“我應(yīng)該使用哪個框架?”。

那些來自 Ruby 或 Python 等語言的人可能熟悉大多數(shù)開發(fā)人員(例如 Rails、Django 或 Flask)使用的單一 Web 框架。Go 有點不同，因為實際上沒有一個框架是社區(qū)中最受歡迎的。雖然有幾個可用的框架，其中許多框架我將在這篇文章中討論，但 Go 社區(qū)似乎并沒有就構(gòu)建 API 服務(wù)時的“首選”框架(如果有的話)達(dá)成一致。

雖然我不會在這篇文章中比較或推薦任何特定的框架，但我將嘗試通過介紹為 Go 中的下一個 API 項目選擇框架時應(yīng)該考慮的四個關(guān)鍵事項給你參考。

01 你真的需要框架嗎

在嘗試確定在 Go 中構(gòu)建 API 后端服務(wù)時應(yīng)該使用哪個框架時，你應(yīng)該問自己的第一件事是，你是否需要一個框架?

Go 標(biāo)準(zhǔn)庫非常棒，它提供了許多開箱即用的世界級 API 所需的組件!我在 Go 中架構(gòu)和構(gòu)建了一項服務(wù)，該服務(wù)僅使用 Go 標(biāo)準(zhǔn)庫 + router/mux 即可每天處理數(shù)百萬個請求。

兩個最流行的 routers 是：

• gorilla/mux[1]
• chi[2]

這兩個庫都提供基于 URL 主機(jī)、路徑、headers、HTTP 方法和查詢值等內(nèi)容的快速請求路由，同時允許你定義自己的“自定義”匹配器。

這些 routers 比內(nèi)置的 http.ServeMux[3] 提供更好的體驗，因為它們允許將你的請求路由到不同的處理程序，而無需復(fù)雜的if 或 switch語句塊，例如：

func (b *bookServer) bookHandler(w http.ResponseWriter, req *http.Request) { 
 // how you'd have to implement method based routing if using only the stdlib 
 if req.URL.Path == "/books/" { 
   if req.Method == http.MethodPost { 
     b.createBook(w, req) 
   } else if req.Method == http.MethodGet { 
     b.getAllBooks(w, req) 
   } else if req.Method == http.MethodDelete { 
     b.deleteAllBooks(w, req) 
   } else { 
     http.Error(w, fmt.Sprintf("expect method GET, DELETE or POST at /books/, got %v", req.Method), http.StatusMethodNotAllowed) 
     return 
   } 
 } 
} 

Eli Bendersky 有一個很棒的系列[4]，在 Go 中構(gòu)建 REST API，首先從標(biāo)準(zhǔn)庫開始，然后引入路由器(例如 gorilla[5] 或 chi[6])，最后切換到使用完整的 Web 框架。本系列展示了完全堅持使用標(biāo)準(zhǔn)庫的一些缺點，以及額外的庫(例如上面的兩個路由器包)如何非常有用。

雖然這兩個 routers 都帶有中間件，用于處理基本身份驗證、CORS 協(xié)商、請求日志記錄等內(nèi)容，同時還允許你輕松集成自己的路由器，但它們?nèi)匀徊皇强蚣堋?/p>

如果你的 API 足夠簡單，或者特別是如果你或你的團(tuán)隊剛剛開始使用 Go，我建議從僅使用標(biāo)準(zhǔn)庫 + 路由器/多路復(fù)用器開始，在使用完整框架之前，看看能使用多久。這種方法將使你能夠?qū)W習(xí)基礎(chǔ)知識，而不會被更復(fù)雜框架的細(xì)微差別所困擾。

02 你自己的選擇

如果你決定仍希望為新服務(wù)使用 Web 框架，有幾個較流行的選擇，包括：

• echo[7]
• gin[8]
• buffalo[9]

這些項目可以被描述為完整的 Web 框架，因為它們處理的不僅僅是路由和中間件。它們?yōu)榉?wù)的其他方面提供內(nèi)置和預(yù)配置的功能，例如：

• 日志記錄
• 模板
• 國際化
• 數(shù)據(jù)驗證
• asset 服務(wù)
• 數(shù)據(jù)庫訪問和 ORM
• 等等

如果你只想開始編寫應(yīng)用程序的業(yè)務(wù)邏輯而不擔(dān)心其中的一些實現(xiàn)細(xì)節(jié)，這將非常有用，但它確實有代價：你極大可能被框架的選擇所困擾。不喜歡 echo[10] 格式化日志的方式?想要使用與 buffalo[11] 選擇的路由器不同的路由器?

我并不是說在使用這些框架時交換依賴項是不可能的，但是這可能會很困難，因為框架的全部意義幾乎就是為你做出這些選擇。如果你或你的團(tuán)隊對框架選擇的依賴項感到滿意，那么它可能非常適合你的場景，事實上，它可以提高生產(chǎn)力。但是，如果你是喜歡選擇依賴項并不時調(diào)整或更換它們的個人或團(tuán)隊類型，你可能很快就會發(fā)現(xiàn)框架不是你的最佳選擇。也就是說，你喜歡 DIY~

03 項目脈沖(Pulse)視圖

GitHub 上項目的未解決 issue 數(shù)量以及項目維護(hù)人員對這些 issue 和 PR 的響應(yīng)程度也是需要牢記的重要“軟”指標(biāo)。雖然有大量未解決的 issue 并不一定意味著項目不好，但這可能意味著某些功能或內(nèi)部工作不清楚并且沒有盡可能地記錄。

**注意：**情況并非總是如此，因為這也可能意味著該項目正在獲得動力，人們對貢獻(xiàn)新功能感到興奮。打開 issue 和 PR 以了解項目發(fā)生的情況。

但是，如果項目維護(hù)者似乎與社區(qū)沒有建立良好的關(guān)系，或者他們不經(jīng)常對問題或討論做出回應(yīng)，這可能意味著你可能會發(fā)現(xiàn)自己正在等待答案或錯誤修復(fù)被合并你選擇那個特定的框架。GitHub 有點被忽視的 pulse 視圖[12]可以幫助顯示項目的活躍程度以及 issue 打開和關(guān)閉的頻率。

大多數(shù)流行的框架也會有一個專用的 Gitter、Discord 或 Slack，因此也可能值得一試，看看社區(qū)對新手有多大幫助。

04 未來

最后，將你選擇的框架的流行度與其他框架進(jìn)行比較可能是值得的，因為流行度下降可能意味著隨著社區(qū)轉(zhuǎn)向另一個解決方案，該項目可能會被放棄或停滯不前。雖然 GitHub 上的星星數(shù)量是項目受歡迎程度的一個不錯的指標(biāo)，但這并不能告訴你趨勢如何像谷歌趨勢搜索那樣變化。這是一個谷歌趨勢搜索的例子，比較了過去一年美國對 golang echo 和 golang buffalo[13] 的興趣。

Golang Echo vs Golang Buffalo search trends

在 r/golang[14] 上搜索你選擇的框架也可能會給你與社區(qū)中其他人對項目的有用性和潛在未來的一些不同意見。

雖然這不是完全證明，也沒有人知道未來，但是如果框架開始消亡或仍然強大，這種策略以及如上所述觀察項目的脈沖應(yīng)該會給你一個相對好的想法。如果你代表你的團(tuán)隊為工作項目選擇框架，這一點尤其重要，因為我們中的許多人都處于不幸的境地，不得不維護(hù)構(gòu)建在不再收到任何錯誤修正或安全性的框架之上的應(yīng)用程序更新。

還值得查看框架的文檔，看看它是否是最新的，以及是否有任何最近發(fā)布的使用相同框架和主要版本的教程。如果沒有人在網(wǎng)上寫它，這可能表明它不像以前那樣好。

這是選擇標(biāo)準(zhǔn)庫而不是第三方框架的優(yōu)勢所在，因為標(biāo)準(zhǔn)庫永遠(yuǎn)不會消失，也不會發(fā)生太大變化。

關(guān)于性能

總結(jié)一下，我認(rèn)為框架作者過度[15] 推崇的[16]一個“功能”是性能。雖然性能很重要，但我不認(rèn)為選擇一個 web 框架主要是因為它是“性能”最好的，尤其是在 Go 中。Go 已經(jīng)非常快了，你的框架代碼很可能不會成為應(yīng)用程序的瓶頸。在你需要開始分析和優(yōu)化你的框架之前，數(shù)據(jù)庫、網(wǎng)絡(luò)或僅僅是自己的應(yīng)用程序代碼通常會成為你的服務(wù)性能問題的根源。

雖然知道你選擇的框架比另一個框架更快，這可能會讓人感覺很好，但快 10ms，你的用戶可能永遠(yuǎn)不會注意。

結(jié)論

簡而言之，選擇適合你或你團(tuán)隊的框架(或不選擇)，因為沒有適合所有人的“正確”答案。如果你決定確實要使用一個框架，我建議你至少選擇兩個并在兩者中實現(xiàn)相同的簡單 CRUD API，以查看你更喜歡哪個。

你同意還是不同意這篇文章中的觀點?你和你的團(tuán)隊嘗試過哪些框架?你最喜歡哪一個，為什么?

原文鏈接：https://dev.to/markphelps/4-things-to-consider-when-choosing-a-go-api-framework-4bei

參考資料

[1]gorilla/mux: https://github.com/gorilla/mux

[2]chi: https://github.com/go-chi/chi

[3]http.ServeMux: https://pkg.go.dev/net/http#ServeMux

[4]很棒的系列: https://eli.thegreenplace.net/2021/rest-servers-in-go-part-1-standard-library/

[5]gorilla: https://github.com/gorilla/mux

[6]chi: https://github.com/go-chi/chi

[7]echo: https://github.com/labstack/echo

[8]gin: https://github.com/gin-gonic

[9]buffalo: https://github.com/gobuffalo/buffalo

[10]echo: https://github.com/labstack/echo

[11]buffalo: https://github.com/gobuffalo/buffalo

[12]pulse 視圖: https://github.com/gin-gonic/gin/pulse/monthly

[13]golang echo 和 golang buffalo: https://trends.google.com/trends/explore?geo=US&q=golang%20echo,golang%20buffalo

[14]r/golang: https://www.reddit.com/r/golang

[15]過度: https://github.com/gin-gonic/gin#benchmarks

[16]推崇的: https://github.com/labstack/echo#benchmarks