近年來，GoLang的人氣開始飆升。GoLang并不是一門新的編程語言，早在2009年左右，它就和NodeJS一樣被構思出來了。它最近的受歡迎程度歸結為它的優勢，包括快速的性能，可移植性和云原生。此外，GoLang現在是收入最高的編程語言之一。

但是，本文并不是將GoLang與NodeJS的優勢進行比較，網絡上已經涵蓋了許多內容。相反，我將談論GoLang對我們這樣的初創公司有多實用，以及為什么我們決定放棄GoLang而選擇NodeJS。

在一開始的時候…

讓我們從頭開始，我們從包含GraphQL，PostgreSQL和GoLang的后端堆棧開始。我們的工程團隊最初只有兩個人——一個人在后端，另一個人在前端，負責我們的iOS應用。當我加入團隊的時候，這兩位工程師雖然已經走了，但留下了滿滿的后臺問題。

沒有使用ORM，因此顯式查詢數據庫。寫出的查詢效率太低，我們一直在沖擊內存極限，在查詢滿足之前，我們遇到了漫長的等待時間。這段代碼沒有架構，完全是一堆亂七八糟的代碼，到處都是文件。GoLang沒有使用GraphQL庫。很明顯，之前的后端工程師試圖完全vanilla化，如果你想快速擴展，這不是一條理想的道路。

GoLang本身并非問題所在

這些問題都不是GoLang特定的問題，這些問題都是由一個不勝任GoLang的工程師引入的。這就給我們的創業公司帶來了一個問題：GoLang工程師很少，能干的工程師更少。我們發現自己雇傭和解雇了兩個GoLang工程師，他們都試圖修補我們后臺的問題，但沒有成功。勝任的工程師非常昂貴，而且遠遠超出了我們年輕創業公司的預算。

作為一家初創公司，我們正在努力將應用的MVP版本推向市場，這意味著我們需要速度。GoLang和GraphQL可用的一小套庫加上一個小的社區意味著我們以緩慢的速度在解決問題。除此之外，我們對GoLang的經驗不足，我們花費更多的時間解決問題而不是構建功能。該應用程序本身注定會變得更加復雜，這意味著從長遠來看，這種情況是不可持續的。我們需要一個替代方案。

遷移到NodeJS

在某個時候，我們坐下來討論重寫后端。我們需要解決以下問題：

• 我們需要一個合格的后端工程師，以我們的創業公司可以承受的公平的市場價格。
• 我們需要一個后端棧，里面有很多針對常見問題的預制解決方案，以便快速遷移。
• 我們需要一個有足夠資源的后端棧，在我們接近復雜度的時候，可以解決一些不太常見的問題。

我們的決定是用 NodeJS 替代 GoLang。這解決了我們所有的問題，而這些問題的核心是速度和成本。

• NodeJS擁有比GoLang更大的工程師市場。
• 經驗豐富的NodeJS工程師比GoLang工程師便宜得多。
• NodeJS有許多現有的包來解決常見的問題，使我們能夠專注于構建我們的應用程序，而不是修復應用程序。

總而言之，我們遷移到NodeJS的決定很大程度上取決于我們創業公司的業務狀態。而人們經常爭論的是NodeJS還是GoLang適合你的項目，這取決于項目的技術優點，而我們的項目則歸結為什么能讓我們在合理的時間內從原型到MVP。