dongsuo9982
2015-02-22 15:05
浏览 78

Node.js或去mongodb服务器[关闭]

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.

图片转代码服务由CSDN问答提供 功能建议

我一直在尝试创建一个mongodb服务器,该服务器将接收发布请求并从mongodb服务器中插入或读取并进行回复 背部。 我已经开始使用node.js。 但是,当我阅读东西时,我已经意识到,人们实际上讨厌node.js。 许多人正在穿越去GO。 所以现在我都很困惑。

我之所以选择node.js是因为javascript具有与json的天然兼容性。 但是,在我读完所有内容之后,node.js听起来像是在浪费时间。 有人可以帮我澄清我的困惑吗?

谢谢。

编辑:人们提到了回调地狱的问题,并降低了节点的性能 .js一旦业务逻辑开始变得比简单循环更复杂。

  • 写回答
  • 关注问题
  • 收藏
  • 邀请回答

1条回答 默认 最新

  • duanlv4984 2015-02-22 15:20
    已采纳

    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 :D

    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.

    打赏 评论

相关推荐 更多相似问题