[[438417]]

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

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

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

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

01 你真的需要框架嗎

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

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

兩個(gè)最流行的 routers 是：

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

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

這些 routers 比內(nèi)置的 http.ServeMux[3] 提供更好的體驗(yàn)，因?yàn)樗鼈冊试S將你的請求路由到不同的處理程序，而無需復(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 有一個(gè)很棒的系列[4]，在 Go 中構(gòu)建 REST API，首先從標(biāo)準(zhǔn)庫開始，然后引入路由器(例如 gorilla[5] 或 chi[6])，最后切換到使用完整的 Web 框架。本系列展示了完全堅(jiān)持使用標(biāo)準(zhǔn)庫的一些缺點(diǎn)，以及額外的庫(例如上面的兩個(gè)路由器包)如何非常有用。

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

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

02 你自己的選擇

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

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

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

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

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

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

03 項(xiàng)目脈沖(Pulse)視圖

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

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

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

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

04 未來

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

Golang Echo vs Golang Buffalo search trends

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

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

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

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

關(guān)于性能

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

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

結(jié)論

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

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

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