英文:
Node.js or go for a mongodb server
问题
我一直在尝试创建一个接收POST请求并在MongoDB服务器中插入或读取数据的MongoDB服务器,并进行回复。我选择了Node.js作为起点。然而,在我阅读相关资料的过程中,我意识到很多人实际上讨厌Node.js,很多人都转向了Go语言。所以我现在感到很困惑。
我选择Node.js是因为JavaScript具有天然的JSON兼容性。然而,在我阅读的所有内容中,Node.js听起来像是浪费时间。有人可以帮助我澄清我的困惑吗?
谢谢。
编辑:人们提到了回调地狱的问题,以及一旦业务逻辑变得比简单循环更复杂时,Node.js的性能下降的问题。
英文:
I have been trying to create a mongodb server which will receive post requests and insert or read from a mongodb server and reply back. I have started with node.js. However while I was reading stuff, I have been realizing, people actually hate node.js. Many people are crossing to GO. So I am all confused now.
I have chosen node.js because of the natural json compatibility of javascript. However after all the things I have read, node.js sounds like a waste of time.
Could someone help me clarify my confusion ?
Thank you.
Edit : People refer to the problem of callback hell, and lowering performance of node.js once the business logic starts to be more complex than simple loops.
答案1
得分: -2
> 人们提到了回调地狱的问题
这对我来说从来不是个问题。你可以在代码中使用任何结构。如果你发现你真的需要1000个嵌套的回调,任何一个Promise库可能会有所帮助,但在大多数情况下这种情况很少见。
> 当业务逻辑变得比简单循环更复杂时,会降低Node.js的性能
这很少是个问题。大多数应用程序都是I/O限制的。如果你的应用程序不是,你有几个选择。一种选择是不使用Node.js。另一种选择是为拖慢性能的特定部分编译一个本地扩展(因为你将编写本地代码来解决这个问题),然后从你的Node.js应用程序的其他部分调用它。这样你就可以获得大部分本地代码的性能,同时仍然可以在JavaScript中灵活工作。
既然你链接到了那篇Reddit帖子,我会回答一些那里的评论。
> JavaScript非常快。是的,这是真的,V8非常快...然而,只有在你进行简单基准测试时才是如此。一旦你开始添加复杂的应用程序逻辑,所有的性能都会消失,因为虚拟机很难正确推断类型,从而无法进行优化。但如果你的应用程序由一个紧密的循环组成,它将会很快...所以它有这个优点:D
这是相对的。毫无疑问,弱类型和解释性的任何东西都会更慢。这是一个你必须决定是否对你正在做的事情有意义的权衡。就我个人而言,对我来说,启动另一台服务器来处理负载要比重写我在Go中使用的所有有用的模块和框架要便宜得多。也许对你来说情况不同,所以你可以自己决定。
> 在我全职开发Node.js的三年中,我只有一次在服务器和客户端中使用了相同的4行代码。
这通常是正确的。我不明白为什么共享的客户端/服务器代码对Node.js来说是某种卖点,因为对大多数应用程序来说并不是这样。我有一个案例,我为一个RPC层编写的几个类在服务器和客户端上运行。不过,我要说的是,有很多NPM包可以在两者上运行,所以如果你习惯在其中一个上使用一个好的包,它通常也会在另一个上工作。
> 哦,我有提到Node.js并不完全是JavaScript吗?NPM上的很大一部分包也是用Coffeescript编写的。希望你不介意学习另一种语言来处理你依赖的包。所以,使用相同的语言来处理服务器和客户端的问题就不成立了!
你不需要学习Coffeescript来使用一个用Coffeescript编写的NPM包。Coffeescript会编译成JavaScript,并且在你的代码中使用方式与任何其他包相同。此外,这些相同的Coffeescript包在浏览器中也可以正常运行,因为它们都构建为JavaScript。
> 使用Go,你可以获得类型安全。这一点无法过分强调...除了可能是Ruby程序员(开个玩笑!别开枪打我)。
这取决于你是否认为这对你的用例很重要。
> Node.js相对于Go的一个优势是NPM上可用的大量包。但其中大部分都是无用的废弃物。所以,即使这一点也是值得商榷的。
不要使用废弃的垃圾,就像你在任何平台上都不会使用任何包一样。很容易看出什么是废弃的垃圾。NPM会指出哪些包已经更新过以及何时更新过,它们的依赖关系是否是最新的,以及有多少人在使用该包。对于Node.js来说,确实有大量有用的包可用,就像大多数流行的平台一样。
> 测试:让我们说在Node.js/Javascript中,你必须编写检查变量类型的测试。这是正确测试JS并确保没有发生任何奇怪情况的唯一方法。
这并不准确,我真的很好奇这个人的应用程序中发生了什么,以至于这是必要的。
英文:
> People refer to the problem of callback hell
This has never been an issue for me. You can use whatever structure you want in your code. Any promise library may be helpful if you find that you really need 1,000 nested callbacks, but this is rare in most circumstances.
> lowering performance of node.js once the business logic starts to be more complex than simple loops
Rarely is this a problem. Most applications are IO-bound. If yours isn't, you have a couple options. One is not to use Node.js. Another is to compile a native extension for the specific part that's dragging you down (since you'll be writing native code to solve this problem anyway) and call it from the rest of your Node.js application. That way you get most of the performance of your native code but still get the flexibility of working in JavaScript.
Since you linked to that Reddit post, I'll address some of the comments there.
> Javascript is very fast. Yes this is true, V8 is very fast... however, only if you are benchmarking a simple benchmark. As soon as you start adding in complex application logic all that performance goes out the door because the virtual machine has a very difficult time correctly inferring the type and thus not being able to optimize. But if your application consists of a tight loop, it will be fast.. so its got that going for it
It's all relative. No doubt that weakly typed and interpreted anything is slower. It's a trade-off that you have to decide makes sense for what you're doing. Personally, it's far cheaper for me to fire up another box to handle the load than it is to rewrite all of the helpful modules and frameworks I use in Go. Maybe that's not the case for you, so you get to decide.
> In my 3 years of full time node.js development, I have honestly only had ONE occasion where I used the same 4 lines of code both in the server and in the client.
This is generally true. I don't understand why shared client/server code is some sort of selling point for Node.js, as it isn't for most applications. I had one case where several classes I wrote for an RPC layer ran on both the server and the client. One thing I will say though is that there are a ton of NPM packages that run in both so if you get used to using a nice package on one, it will often times work on the other.
> Ohh and did I mention Node.js isn't really all JavaScript? A good portion of the pakcages on NPM are also written in Coffeescript. Hope you don't mind learning another language to deal with a package you depend on. So much for using the same language for both server and client!
You don't have to learn Coffeescript to use an NPM package written in Coffeescript. Coffeescript compiles to JavaScript, and are used in your code the same way any other package is. Also, those same Coffeescript packages do run just fine in the browser since it all builds to JavaScript.
> With Go you get type safety. This CANNOT be overstated.. except to maybe ruby-ists(jk jk! don't shoot me).
It's up to you to decide if this matters for your use case.
> The one benefit you have with Node.js over Go is the massive number of packages available on NPM. But most of them are useless abandoned junk. So, even that is questionable.
Don't use abandoned junk, just like you wouldn't with any packages on any platform. It's very easy to see what's abandoned junk. NPM calls out what's been updated and when, whether or not its dependencies are up to date, and how many people are using that package. There are definitely a massive number of useful packages available for Node.js, just like they are for most popular platforms.
> Testing: Lets just say that in Node.js/Javascript you would have to write tests that check the type of a variable. tsk tsk tsk... This is the only way to properly test JS and make sure nothing crazy is going on.
That's not really accurate, and I'm really curious what's going on in this person's application where this is necessary.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论