为什么我们从GoLang迁移到NodeJS

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

在某个时候，我们坐下来讨论重写后端。我们需要解决以下问题：

• 我们需要一个合格的后端工程师，以我们的创业公司可以承受的公平的市场价格。
• 我们需要一个后端栈，里面有很多针对常见问题的预制解决方案，以便快速迁移。
• 我们需要一个有足够资源的后端栈，在我们接近复杂度的时候，可以解决一些不太常见的问题。