larry*wei
2011-02-21 05:20
采纳率: 0%
浏览 461

如何决定何时使用 Node.js?

I am new to this kind of stuff, but lately I've been hearing a lot about how good Node.js is. Considering how much I love working with jQuery and JavaScript in general, I can't help but wonder how to decide when to use Node.js. The web application I have in mind is something like Bitly - takes some content, archives it.

From all the homework I have been doing in the last few days, I obtained the following information. Node.js

  • is a command-line tool that can be run as a regular web server and lets one run JavaScript programs
  • utilizes the great V8 JavaScript engine
  • is very good when you need to do several things at the same time
  • is event-based so all the wonderful Ajax-like stuff can be done on the server side
  • lets us share code between the browser and the backend
  • lets us talk with MySQL

Some of the sources that I have come across are:

Considering that Node.js can be run almost out-of-the-box on Amazon's EC2 instances, I am trying to understand what type of problems require Node.js as opposed to any of the mighty kings out there like PHP, Python and Ruby. I understand that it really depends on the expertise one has on a language, but my question falls more into the general category of: When to use a particular framework and what type of problems is it particularly suited for?

转载于:https://stackoverflow.com/questions/5062614/how-to-decide-when-to-use-node-js

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

14条回答 默认 最新

  • ?yb? 2011-02-21 05:30
    已采纳

    You did a great job of summarizing what's awesome about Node.js. My feeling is that Node.js is especially suited for applications where you'd like to maintain a persistent connection from the browser back to the server. Using a technique known as "long-polling", you can write an application that sends updates to the user in real time. Doing long polling on many of the web's giants, like Ruby on Rails or Django, would create immense load on the server, because each active client eats up one server process. This situation amounts to a tarpit attack. When you use something like Node.js, the server has no need of maintaining separate threads for each open connection.

    This means you can create a browser-based chat application in Node.js that takes almost no system resources to serve a great many clients. Any time you want to do this sort of long-polling, Node.js is a great option.

    It's worth mentioning that Ruby and Python both have tools to do this sort of thing (eventmachine and twisted, respectively), but that Node.js does it exceptionally well, and from the ground up. JavaScript is exceptionally well situated to a callback-based concurrency model, and it excels here. Also, being able to serialize and deserialize with JSON native to both the client and the server is pretty nifty.

    I look forward to reading other answers here, this is a fantastic question.

    It's worth pointing out that Node.js is also great for situations in which you'll be reusing a lot of code across the client/server gap. The Meteor framework makes this really easy, and a lot of folks are suggesting this might be the future of web development. I can say from experience that it's a whole lot of fun to write code in Meteor, and a big part of this is spending less time thinking about how you're going to restructure your data, so the code that runs in the browser can easily manipulate it and pass it back.

    Here's an article on Pyramid and long-polling, which turns out to be very easy to set up with a little help from gevent: TicTacToe and Long Polling with Pyramid.

    点赞 打赏 评论
  • 叼花硬汉 2011-02-21 06:43

    I believe Node.js is best suited for real-time applications: online games, collaboration tools, chat rooms, or anything where what one user (or robot? or sensor?) does with the application needs to be seen by other users immediately, without a page refresh.

    I should also mention that Socket.IO in combination with Node.js will reduce your real-time latency even further than what is possible with long polling. Socket.IO will fall back to long polling as a worst case scenario, and instead use web sockets or even Flash if they are available.

    But I should also mention that just about any situation where the code might block due to threads can be better addressed with Node.js. Or any situation where you need the application to be event-driven.

    Also, Ryan Dahl said in a talk that I once attended that the Node.js benchmarks closely rival Nginx for regular old HTTP requests. So if we build with Node.js, we can serve our normal resources quite effectively, and when we need the event-driven stuff, it's ready to handle it.

    Plus it's all JavaScript all the time. Lingua Franca on the whole stack.

    点赞 打赏 评论
  • 妄徒之命 2012-01-15 01:48

    To make it short:

    Node.js is well suited for applications that have a lot of concurrent connections and each request only needs very few CPU cycles, because the event loop (with all the other clients) is blocked during execution of a function.

    A good article about the event loop in Node.js is Mixu's tech blog: Understanding the node.js event loop.

    点赞 打赏 评论
  • csdnceshi62 2013-04-05 17:17

    There is nothing like Silver Bullet. Everything comes with some cost associated with it. It is like if you eat oily food, you will compromise your health and healthy food does not come with spices like oily food. It is individual choice whether they want health or spices as in their food. Same way Node.js consider to be used in specific scenario. If your app does not fit into that scenario you should not consider it for your app development. I am just putting my thought on the same:

    When to use Node.JS

    1. If your server side code requires very few cpu cycles. In other world you are doing non blocking operation and does not have heavy algorithm/Job which consumes lots of CPU cycles.
    2. If you are from Javascript back ground and comfortable in writing Single Threaded code just like client side JS.

    When NOT to use Node.JS

    1. Your server request is dependent on heavy CPU consuming algorithm/Job.

    Scalability Consideration with Node.JS

    1. Node.JS itself does not utilize all core of underlying system and it is single threaded by default, you have to write logic by your own to utilize multi core processor and make it multi threaded.

    Node.JS Alternatives

    There are other option to use in place of Node.JS however Vert.x seems to be pretty promising and has lots of additional features like polygot and better scalability considerations.

    点赞 打赏 评论
  • 10.24 2013-05-06 13:52

    My piece: nodejs is great for making real time systems like analytics, chat-apps, apis, ad servers, etc. Hell, I made my first chat app using nodejs and socket.io under 2 hours and that too during exam week!

    Edit

    Its been several years since I have started using nodejs and I have used it in making many different things including static file servers, simple analytics, chat apps and much more. This is my take on when to use nodejs

    When to use

    When making system which put emphasis on concurrency and speed.

    • Sockets only servers like chat apps, irc apps, etc.
    • Social networks which put emphasis on realtime resources like geolocation, video stream, audio stream, etc.
    • Handling small chunks of data really fast like an analytics webapp.
    • As exposing a REST only api.

    When not to use

    Its a very versatile webserver so you can use it wherever you want but probably not these places.

    • Simple blogs and static sites.
    • Just as a static file server.

    Keep in mind that I am just nitpicking. For static file servers, apache is better mainly because it is widely available. The nodejs community has grown larger and more mature over the years and it is safe to say nodejs can be used just about everywhere if you have your own choice of hosting.

    点赞 打赏 评论
  • ?yb? 2013-05-31 06:34

    I have one real-world example where I have used Node.js. The company where I work got one client who wanted to have a simple static HTML website. This website is for selling one item using PayPal and the client also wanted to have a counter which shows the amount of sold items. Client expected to have huge amount of visitors to this website. I decided to make the counter using Node.js and the Express.js framework.

    The Node.js application was simple. Get the sold items amount from a Redis database, increase the counter when item is sold and serve the counter value to users via the API.

    Some reasons why I chose to use Node.js in this case

    1. It is very lightweight and fast. There has been over 200000 visits on this website in three weeks and minimal server resources has been able to handle it all.
    2. The counter is really easy to make to be real time.
    3. Node.js was easy to configure.
    4. There are lots of modules available for free. For example, I found a Node.js module for PayPal.

    In this case, Node.js was an awesome choice.

    点赞 打赏 评论
  • hurriedly% 2013-06-06 17:42

    Another great thing that I think no one has mentioned about Node.js is the amazing community, the package management system (npm) and the amount of modules that exist that you can include by simply including them in your package.json file.

    点赞 打赏 评论
  • 北城已荒凉 2013-09-27 20:34

    My one more reason to choose Node.js for a new project is:

    Be able to do pure cloud based development

    I have used Cloud9 IDE for a while and now I can't imagine without it, it covers all the development lifecycles. All you need is a browser and you can code anytime anywhere on any devices. You don't need to check in code in one Computer(like at home), then checkout in another computer(like at work place).

    Of course, there maybe cloud based IDE for other languages or platforms (Cloud 9 IDE is adding supports for other languages as well), but using Cloud 9 to do Node.js developement is really a great experience for me.

    点赞 打赏 评论
  • Didn"t forge 2013-11-25 21:47

    Reasons to use NodeJS:

    • It runs Javascript, so you can use the same language on server and client, and even share some code between them (e.g. for form validation, or to render views at either end.)

    • The single-threaded event-driven system is fast even when handling lots of requests at once, and also simple, compared to traditional multi-threaded Java or ROR frameworks.

    • The ever-growing pool of packages accessible through NPM, including client and server-side libraries/modules, as well as command-line tools for web development. Most of these are conveniently hosted on github, where sometimes you can report an issue and find it fixed within hours! It's nice to have everything under one roof, with standardized issue reporting and easy forking.

    • It has become the defacto standard environment in which to run Javascript-related tools and other web-related tools, including task runners, minifiers, beautifiers, linters, preprocessors, bundlers and analytics processors.

    • It seems quite suitable for prototyping, agile development and rapid product iteration.

    Reasons not to use NodeJS:

    • It runs Javascript, which has no compile-time type checking. For large, complex safety-critical systems, or projects including collaboration between different organizations, a language which encourages contractual interfaces and provides static type checking may save you some debugging time (and explosions) in the long run. (Although the JVM is stuck with null, so please use Haskell for your nuclear reactors.)

    • Added to that, many of the packages in NPM are a little raw, and still under rapid development. Some libraries for older frameworks have undergone a decade of testing and bugfixing, and are very stable by now. Npmjs.org has no mechanism to rate packages, which has lead to a proliferation of packages doing more or less the same thing, out of which a large percentage are no longer maintained.

    • Nested callback hell. (Of course there are 20 different solutions to this...)

    • The ever-growing pool of packages can make one NodeJS project appear radically different from the next. There is a large diversity in implementations due to the huge number of options available (e.g. Express/Sails.js/Meteor/Derby). This can sometimes make it harder for a new developer to jump in on a Node project. Contrast that with a Rails developer joining an existing project: he should be able to get familiar with the app pretty quickly, because all Rails apps are encouraged to use a similar structure.

    • Dealing with files can be a bit of a pain. Things that are trivial in other languages, like reading a line from a text file, are weird enough to do with Node.js that there's a StackOverflow question on that with 80+ upvotes. There's no simple way to read one record at a time from a CSV file. Etc.

    I love NodeJS, it is fast and wild and fun, but I am concerned it has little interest in provable-correctness. Let's hope we can eventually merge the best of both worlds. I am eager to see what will replace Node in the future... :)

    点赞 打赏 评论
  • One more thing node provides is the ability to create multiple v8 instanes of node using node's child process( childProcess.fork() each requiring 10mb memory as per docs) on the fly, thus not affecting the main process running the server. So offloading a background job that requires huge server load becomes a child's play and we can easily kill them as and when needed.

    I've been using node a lot and in most of the apps we build, require server connections at the same time thus a heavy network traffic. Frameworks like Express.js and the new Koajs (which removed callback hell) have made working on node even more easier.

    点赞 打赏 评论
  • 旧行李 2014-07-03 07:17

    It can be used where

    • Applications that are highly event driven & are heavily I/O bound
    • Applications handling a large number of connections to other systems
    • Real-time applications (Node.js was designed from the ground up for real time and to be easy to use.)
    • Applications that juggle scads of information streaming to and from other sources
    • High traffic, Scalable applications
    • Mobile apps that have to talk to platform API & database, without having to do a lot of data analytics
    • Build out networked applications
    • Applications that need to talk to the back end very often

    On Mobile front, prime-time companies have relied on Node.js for their mobile solutions. Check out why?

    LinkedIn is a prominent user. Their entire mobile stack is built on Node.js. They went from running 15 servers with 15 instances on each physical machine, to just 4 instances – that can handle double the traffic!

    eBay launched ql.io, a web query language for HTTP APIs, which uses Node.js as the runtime stack. They were able to tune a regular developer-quality Ubuntu workstation to handle more than 120,000 active connections per node.js process, with each connection consuming about 2kB memory!

    Walmart re-engineered its mobile app to use Node.js and pushed its JavaScript processing to the server.

    Read more at: http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/

    点赞 打赏 评论
  • bug^君 2014-07-24 11:39

    If your application mainly tethers web apis, or other io channels, give or take a user interface, node.js may be a fair pick for you, especially if you want to squeeze out the most scalability, or, if your main language in life is javascript (or javascript transpilers of sorts). If you build microservices, node.js is also okay. Node.js is also suitable for any project that is small or simple.

    Its main selling point is it allows front-enders take responsibility for back-end stuff rather than the typical divide. Another justifiable selling point is if your workforce is javascript oriented to begin with.

    Beyond a certain point however, you cannot scale your code without terrible hacks for forcing modularity, readability and flow control. Some people like those hacks though, especially coming from an event-driven javascript background, they seem familiar or forgivable.

    In particular, when your application needs to perform synchronous flows, you start bleeding over half-baked solutions that slow you down considerably in terms of your development process. If you have computation intensive parts in your application, tread with caution picking (only) node.js. Maybe http://koajs.com/ or other novelties alleviate those originally thorny aspects, compared to when I originally used node.js or wrote this.

    点赞 打赏 评论
  • 乱世@小熊 2014-08-03 20:44
    1. Node is great for quick prototypes but I'd never use it again for anything complex. I spent 20 years developing a relationship with a compiler and I sure miss it.

    2. Node is especially painful for maintaining code that you haven't visited for awhile. Type info and compile time error detection are GOOD THINGS. Why throw all that out? For what? And dang, when something does go south the stack traces quite often completely useless.

    点赞 打赏 评论
  • 谁还没个明天 2016-08-09 15:02

    I can share few points where&why to use node js.

    1. For realtime applications like chat,collaborative editing better we go with nodejs as it is event base where fire event and data to clients from server.
    2. Simple and easy to understand as it is javascript base where most of people have idea.
    3. Most of current web applications going towards angular js&backbone, with node it is easy to interact with client side code as both will use json data.
    4. Lot of plugins available.

    Drawbacks:-

    1. Node will support most of databases but best is mongodb which won't support complex joins and others.
    2. Compilation Errors...developer should handle each and every exceptions other wise if any error accord application will stop working where again we need to go and start it manually or using any automation tool.

    Conclusion:- Nodejs best to use for simple and real time applications..if you have very big business logic and complex functionality better should not use nodejs. If you want to build an application along with chat and any collaborative functionality.. node can be used in specific parts and remain should go with your convenience technology.

    点赞 打赏 评论

相关推荐 更多相似问题