[[438417]]

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

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

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

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

01 你真的需要框架嗎

在嘗試確定在 Go 中構建 API 后端服務時應該使用哪個框架時，你應該問自己的第一件事是，你是否需要一個框架?

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

兩個最流行的 routers 是：

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

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

這些 routers 比內置的 http.ServeMux[3] 提供更好的體驗，因為它們允許將你的請求路由到不同的處理程序，而無需復雜的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 中構建 REST API，首先從標準庫開始，然后引入路由器(例如 gorilla[5] 或 chi[6])，最后切換到使用完整的 Web 框架。本系列展示了完全堅持使用標準庫的一些缺點，以及額外的庫(例如上面的兩個路由器包)如何非常有用。

雖然這兩個 routers 都帶有中間件，用于處理基本身份驗證、CORS 協商、請求日志記錄等內容，同時還允許你輕松集成自己的路由器，但它們仍然不是框架。

如果你的 API 足夠簡單，或者特別是如果你或你的團隊剛剛開始使用 Go，我建議從僅使用標準庫 + 路由器/多路復用器開始，在使用完整框架之前，看看能使用多久。這種方法將使你能夠學習基礎知識，而不會被更復雜框架的細微差別所困擾。

02 你自己的選擇

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

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

這些項目可以被描述為完整的 Web 框架，因為它們處理的不僅僅是路由和中間件。它們為服務的其他方面提供內置和預配置的功能，例如：

• 日志記錄
• 模板
• 國際化
• 數據驗證
• asset 服務
• 數據庫訪問和 ORM
• 等等

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

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

03 項目脈沖(Pulse)視圖

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

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

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

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

04 未來

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

Golang Echo vs Golang Buffalo search trends

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

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

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

這是選擇標準庫而不是第三方框架的優勢所在，因為標準庫永遠不會消失，也不會發生太大變化。

關于性能

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

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

結論

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

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

原文鏈接：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