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

但是，本文并不是將GoLang與NodeJS的優(yōu)勢進(jìn)行比較，網(wǎng)絡(luò)上已經(jīng)涵蓋了許多內(nèi)容。相反，我將談?wù)揋oLang對我們這樣的初創(chuàng)公司有多實(shí)用，以及為什么我們決定放棄GoLang而選擇NodeJS。

在一開始的時(shí)候…

讓我們從頭開始，我們從包含GraphQL，PostgreSQL和GoLang的后端堆棧開始。我們的工程團(tuán)隊(duì)最初只有兩個(gè)人——一個(gè)人在后端，另一個(gè)人在前端，負(fù)責(zé)我們的iOS應(yīng)用。當(dāng)我加入團(tuán)隊(duì)的時(shí)候，這兩位工程師雖然已經(jīng)走了，但留下了滿滿的后臺問題。

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

GoLang本身并非問題所在

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

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

遷移到NodeJS

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

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

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

• NodeJS擁有比GoLang更大的工程師市場。
• 經(jīng)驗(yàn)豐富的NodeJS工程師比GoLang工程師便宜得多。
• NodeJS有許多現(xiàn)有的包來解決常見的問題，使我們能夠?qū)Ｗ⒂跇?gòu)建我們的應(yīng)用程序，而不是修復(fù)應(yīng)用程序。

總而言之，我們遷移到NodeJS的決定很大程度上取決于我們創(chuàng)業(yè)公司的業(yè)務(wù)狀態(tài)。而人們經(jīng)常爭論的是NodeJS還是GoLang適合你的項(xiàng)目，這取決于項(xiàng)目的技術(shù)優(yōu)點(diǎn)，而我們的項(xiàng)目則歸結(jié)為什么能讓我們在合理的時(shí)間內(nèi)從原型到MVP。