近年来，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。

(责任编辑：admin)