這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。每一天，或者是每隔幾天，總有人來到 [/r/golang](https://www.reddit.com/r/golang/) ，並詢問些類似如下的問題“哪個架構是最好的？”。我認為我們應該嘗試提出這個問題，至少以一種容易理解的方式提出。你不應該使用架構。對於一個複雜的問題，這也許是一個非常簡潔的答案。這並不是說你任何時候都不應該使用架構。眾所周知，當我們開發軟體的時候，有這麼一種趨勢，慢慢形成適應通用開發的模式，並且一次又一次地加快開發同樣的東西。它試著儘可能的消除重複代碼。## 標準庫或 stdlibGo 語言標準庫的品質很高。你應該儘可能的使用它。如果你正在編寫 API 服務，你需要熟悉 `net/http` 包，而且你最終無論使用哪個架構都是基於這個包的。將第三方包匯入標準庫是需要認真考慮的，當他們解決的是一個非常專註的問題時，這是不適合進入標準庫的。舉個例子，產生 UUID 的包，或 JWT 包。一些包（包括 web 架構）都是基於標準庫構建的。一個很好的具體例子，[jmoiron/sqlx](https://jmoiron.github.io/sqlx/) 包就是基於 `sql/database` 包構建的。## 包管理器Go 和包含一個軟體包市場的語言有很大的不同。Node 有 [npm](https://www.npmjs.com/)，PHP 有 [packagist（composer）](https://packagist.org/)，Ruby 有 [gems](https://rubygems.org/)。事實上 Go 沒有官方軟體包管理器（一個中央市場），這對於尋找到一個軟體包有著重大的影響。有幾個軟體包管理器可用，例如 [gvt](https://github.com/FiloSottile/gvt)，[glide](https://github.com/Masterminds/glide) 和一個官方的實驗品 dep，[dep](https://github.com/golang/dep) 可能會在將來的某個時間和 Go 語言工具鏈一起捆綁發布。> dep 是官方的實驗品，但還不是官方的工具。查看更多關於 dep 的[路線圖](https://github.com/golang/dep/wiki/Roadmap)！實際上，在官方的 readme 檔案中 Glide 建議遷移到 dep。當你開始使用包管理器，建議使用 dep。Go 代碼放在 GitHub，Bitbucket 和其他存放庫，甚至可以自行託管。最完整的 Go 語言套件列表可以通過搜尋 godoc 來找到，godoc 是由這些包產生的文檔的中央託管。它不提供類似於上面提到的其他語言項目的軟體包市場。有一個值得注意的項目：有點接近其他的軟體包管理器，被用作包索引，它是 [gopkg.in](http://labix.org/gopkg.in)。任何你建立的軟體包都可能因為代碼品質等各種原因而沒有被採用。某些程式包作者比其他人更為人所知，如果你正在尋找一些像 flags 配置包那樣微不足道的東西，那麼你只剩下少量但是高品質的選擇。這在相關的包軟體系統中是不可能的。相比之下，Node 的軟體包品質急劇下降，因為它的焦點分布在前端和後端之間，所以 Node 中有許多怪癖的代碼，這在 Go 中是不存在。Go 是一個完整伺服器端的語言，而 Node 往往服務於很多前端的 Javascript 代碼。Node 開發中有一些東西，無法用任何邏輯來解釋，例如開發和採用 [left-pad](https://www.npmjs.com/package/left-pad) 和 [is-array](https://www.npmjs.com/package/is-array) 包的原因。我無法解釋它們為何每周有成百上千萬的下載量。## Go 生態系統Go 有一個較小的生態系統，但是有很多基於 Go 的項目都被廣泛的採用，最近 GitHub 上的 [go-chi/chi](https://github.com/go-chi/chi) 有 2500 星星和非常好的評論（和 sqlx 類似，chi 項目是基於底層的 `net/http` 包構建的）。我們在 [ErrorHub](https://errorhub.io/) 上使用它，我建議你使用它。有許多 web 架構可用，但是如上所述，你應該首先使用 stdlib，這樣你可以在繼續前進時明白你真正需要的。使用 web 架構本身是完全沒有必要的，但是當你有新的需求時，你可以做出更明智地選擇從哪裡遷移。## 從其他語言遷移到 GoGo 和其他語言之間的不同之處在於語言細節。從 Python 遷移到 Ruby 或從 PHP 遷移到 Javascript 時，你會發現同樣的差異。Go 也不例外。你可能會發現[（例如切片是如何工作的）](https://scene-si.org/2017/08/06/the-thing-about-slices/)起初有點混亂，但從任何語言遷移到任何其他語言時都會遇到這些問題。讓我們再看看 ruby 的一個例子 [predicate methods](http://ruby-for-beginners.rubymonstas.org/objects/predicates.html)。Go 的入門門檻真的很低。我在 15 年前使用 PHP，遷移到 Go 是相對比較簡單的。讓你理解 Node 的非同步作業是很困難的，包括 Promise 和 yield。如果我能推薦兩篇閱讀材料，那麼你應該閱讀一下 [the interview with Ryan Dahl, the creator of Node](https://www.mappingthejourney.com/single-post/2017/08/31/episode-8-interview-with-ryan-dahl-creator-of-nodejs/)，[Bob Nystroms critique of asynchronous functions](http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/) 也是必讀的。> 這就是說，我認為 Node 並不是構建大型伺服器網站的最佳語言。我會用 Go 的。說實話，這就是我離開 Node 的原因。我意識到：哦，實際上，這不是有史以來最好的伺服器端系統。>> **Ryan Dahl**## Go 的力量Go 非常適合為任何您選擇驅動您的前端架構的項目提供 API 端點。Websockets？沒問題。一群正在互相交談的 Go 程式？你有沒有聽說過 Docker 或者 Kubernetes？這些系統有著令人難以置信的可擴充性，並且是用 Go 寫的。Go 是一門出色的語言，可以提供後端邏輯，例如和資料庫互動介面，並通過 HTTP API 端點開放訪問。前端技術棧的選擇將確保你可以為瀏覽器使用和呈現此資料。你被 React 所困惱嗎？將其替換為 VueJS 而不用丟棄任何 Go 代碼。在其他語言中，你必須嚴格遵守這個原則來分割應用程式，因為通常情況下，你不是在編寫伺服器，而只是產生將在瀏覽器中運行產生輸出的指令碼。當然，使用 Go 可以以相同的方式使用 `html/template`，但是選擇使用前端架構實現前端，將會給你帶來好處：專註於該架構的開發人員。不是每個人都喜歡 Go。你不會用 bash 寫一個 網頁伺服器，對不對？## 你為什麼要用 Go？對我來說主要的賣點就是標準庫，語言和文檔的品質非常高。Ruby，Node，PHP 和其他以 web 開發為中心的語言通常都是單線程的，如果可能的話，超出這個範圍的通常都是使用一個附加組件，而不是一等公民。他們的記憶體管理很差（儘管，至少 PHP 在過去的 15 年裡有了很大的改進），也許最重要的是它們都屬於指令碼語言範疇。編譯的代碼總是會比通過解譯器啟動並執行任何代碼都快。人們總是重新發明輪子，不僅僅是因為他們可以，而且還因為他們可以以某種方式改善它。這可以以很小的增量完成，例如最佳化一個產生特定輸出的特定函數，或者可以以更大的增量完成，例如建立一門將並發性作為一等公民的程式設計語言。其他的東西可能不會被處理（這就是為什麼在 Go 中有很多關於泛型的爭議），但總是有可以改進的空間。我不排除有人會另闢蹊徑去提供他們認為最合適的最好的泛型的可能性。人們總是根據他們的經驗做出反應。如果你的經驗告訴你，並發性是某些 XY 語言的問題，那麼你將會找到解決辦法。遷移到 Go 是一個很好的方法來解決這個問題。## 筆記這篇文章反映了 Go 確實有包管理器，但是到目前為止還沒有官方的工具，也沒有和 Go 的工具鏈一起捆綁發布。前面的文章誤導了這一點，它暗示了 Go 根本沒有包管理器。從技術上講，所有其他包管理器（至少 npm 和 composer）都是是附加組件。## 我很榮幸你能夠閱讀本文...但如果你能購買一本我的書，那真是太棒了：- [API Foundations in Go](https://leanpub.com/api-foundations)- [12 Factor Apps with Docker and Go](https://leanpub.com/12fa-docker-golang)- [The SaaS Handbook (work in progress)](https://leanpub.com/saas-handbook)我保證如果你買一本書，你會學到更多東西。購買一份拷貝支援我寫更多關於類似的話題。謝謝你買我的書。如果你想預約我的諮詢/自由服務時間，請隨時給我發[電子郵件](black@scene-si.org)。 我非常擅長 APIs，Go，Docker，VueJS 和擴充服務[等等](https://scene-si.org/about)。
via: https://scene-si.org/2017/10/18/choosing-a-go-framework/
作者：Tit Petric 譯者：MDGSF 校對：polaris1119
本文由 GCTT 原創編譯，Go語言中文網 榮譽推出
本文由 GCTT 原創翻譯，Go語言中文網 首發。也想加入譯者行列，為開源做一些自己的貢獻嗎？歡迎加入 GCTT！
翻譯工作和譯文發表僅用於學習和交流目的，翻譯工作遵照 CC-BY-NC-SA 協議規定，如果我們的工作有侵犯到您的權益，請及時聯絡我們。
歡迎遵照 CC-BY-NC-SA 協議規定 轉載，敬請在本文中標註並保留原文/譯文連結和作者/譯者等資訊。
文章僅代表作者的知識和看法，如有不同觀點，請樓下排隊吐槽
975 次點擊
