1. Node非常适合快速创建原型，但是我再也不会将它用于任何复杂的事情。我花了20年的时间开发与编译器的关系，但我肯定会错过它。

2. 对于维护您已经一段时间没有访问的代码，Node尤其痛苦。类型信息和编译时错误检测是一件好事。为什么要把所有这些都扔掉？为了什么？当当东西往南走时，堆栈痕迹常常完全没有用。

我可以分享在何处以及为什么要使用节点js的几点。

1. 对于聊天，协作编辑等实时应用程序，我们更好地使用了nodejs，因为它是事件基础，可将事件和数据从服务器发送到客户端。
2. 简单易懂，因为它是大多数人都有想法的javascript库。
3. 当前的大多数Web应用程序都朝着有角度的js＆backbone的方向发展，使用node节点很容易与客户端代码交互，因为两者都将使用json数据。
4. 有很多可用的插件。

缺点：-

1. Node将支持大多数数据库，但最好的是mongodb，它将不支持复杂的联接和其他联接。
2. 编译错误...如果任何符合错误的应用程序将停止工作，则开发人员应以其他方式处理每个异常，我们需要再次手动或使用任何自动化工具来启动它。

结论：-Nodejs最好用于简单和实时的应用程序。如果您有非常大的业务逻辑和复杂的功能，最好不要使用nodejs。如果您希望与聊天和任何协作功能一起构建应用程序，则可以在特定部分使用节点，而其余部分应与您的便捷技术一起使用。

如果您的应用程序主要是束缚Web api或其他io通道，提供或使用用户界面，那么node.js可能是您的不二之选，尤其是如果您想获得最大的可扩展性，或者您的生活中的主要语言时是javascript（或各种javascript编译器）。如果您构建微服务，node.js也可以。Node.js也适用于任何规模较小或简单的项目。

它的主要卖点是它允许前端人员对后端内容负责，而不是典型的鸿沟。另一个合理的卖点是，如果您的员工从一开始就以JavaScript为导向。

但是，在某个特定点之外，如果没有可怕的黑客来强迫模块性，可读性和流程控制，就无法扩展代码。不过，有些人喜欢这些骇客，尤其是来自事件驱动的javascript背景，他们似乎很熟悉或可以原谅。

特别是，当您的应用程序需要执行同步流时，就会开始使用半熟的解决方案，这会大大降低您的开发流程速度。如果您的应用程序中包含计算密集型部分，请谨慎选择（仅）node.js。与我最初使用node.js或编写此代码时相比，也许http://koajs.com/或其他新颖性缓解了那些最初棘手的方面。

节点提供的另一项功能是可以动态使用节点的子进程（每个docs需要10mb内存）创建节点的多个v8实例，因此不会影响运行服务器的主进程。因此，卸载需要大量服务器负载的后台作业就成了小孩子的事，我们可以在需要时轻松杀死它们。

我已经使用了很多节点，并且在我们构建的大多数应用中，需要同时连接服务器，因此网络流量很大。诸如Express.js和新的Koajs（已删除回调地狱）之类的框架使在节点上的工作变得更加容易。

我为新项目选择Node.js的另一个原因是：

能够进行基于纯云的开发

我已经使用Cloud9 IDE一段时间了，现在没有它我无法想象，它涵盖了所有开发生命周期。您所需要的只是一个浏览器，您可以随时随地在任何设备上进行编码。您无需在一台计算机（例如在家）中检入代码，然后在另一台计算机（例如在工作场所）中检出代码。

当然，也许有适用于其他语言或平台的基于云的IDE（Cloud 9 IDE也添加了对其他语言的支持），但是使用Cloud 9进行Node.js开发对我来说确实是很棒的体验。

可以在哪里使用

• 高度事件驱动且受I / O约束的应用程序
• 处理与其他系统的大量连接的应用程序
• 实时应用程序（Node.js是从头开始设计的，旨在实时且易于使用。）
• 杂乱地往返于其他来源的信息流的应用程序
• 高流量，可扩展的应用程序
• 无需进行大量数据分析即可与平台API和数据库进行通信的移动应用程序
• 构建联网的应用程序
• 需要经常与后端对话的应用程序

在移动方面，黄金时段公司依靠Node.js来提供移动解决方案。看看为什么？

LinkedIn是杰出的用户。他们的整个移动堆栈均基于Node.js。他们从在每台物理机上运行15台服务器（每个实例有15个实例）到仅4个实例–可以处理两倍的流量！

eBay推出了用于HTTP API的网络查询语言ql.io，该语言使用Node.js作为运行时堆栈。他们能够调整常规的开发人员质量的Ubuntu工作站，以每个node.js进程处理超过120,000个活动连接，每个连接消耗大约2kB内存！

沃尔玛重新设计了其移动应用程序以使用Node.js，并将其JavaScript处理推到了服务器上。

有关更多信息，请访问：http：//www.pixelatingbits.com/a-closer-look-at-mobile-app-develop-with-node-js/

最适合并发请求处理的节点-

So, Let’s start with a story. From last 2 years I am working on JavaScript and developing web front end and I am enjoying it. Back end guys provide’s us some API’s written in Java,python (we don’t care) and we simply write a AJAX call, get our data and guess what ! we are done. But in real it is not that easy, If data we are getting is not correct or there is some server error then we stuck and we have to contact our back end guys over the mail or chat(sometimes on whatsApp too :).) This is not cool. What if we wrote our API’s in JavaScript and call those API’s from our front end ? Yes that’s pretty cool because if we face any problem in API we can look into it. Guess what ! you can do this now , How ? – Node is there for you.

Ok agreed that you can write your API in JavaScript but what if I am ok with above problem. Do you have any other reason to use node for rest API ?

so here is the magic begins. Yes I do have other reasons to use node for our API’s.

Let’s go back to our traditional rest API system which is based on either blocking operation or threading. Suppose two concurrent request occurs( r1 and r2) , each of them require database operation. So In traditional system what will happens :

1. Waiting Way : Our server starts serving r1 request and waits for query response. after completion of r1 , server starts to serve r2 and does it in same way. So waiting is not a good idea because we don’t have that much time.

2. Threading Way : Our server will creates two threads for both requests r1 and r2 and serve their purpose after querying database so cool its fast.But it is memory consuming because you can see we started two threads also problem increases when both request is querying same data then you have to deal with deadlock kind of issues . So its better than waiting way but still issues are there.

Now here is , how node will do it:

3. Nodeway：当相同的并发请求进入节点时，它将在其回调中注册一个事件并向前移动，它将不等待特定请求的查询响应。因此，当r1请求到达时，节点的事件循环（是的，有一个事件循环在用于此目的的节点中。）使用其回调函数注册一个事件，然后继续处理r2请求，并通过其回调类似地注册其事件。每当任何查询完成时，它都会触发其相应的事件并执行其回调以完成操作而不会被中断。

因此，没有等待，没有线程，没有内存消耗–是的，这是服务其余API的节点。

我的作品：nodejs非常适合制作实时系统，例如分析，聊天应用程序，api，广告服务器等。该死，我在2小时内使用nodejs和socket.io制作了我的第一个聊天应用程序，在考试周内也是如此！

编辑

自从我开始使用nodejs以来已经有好几年了，我已经将它用于制作许多不同的东西，包括静态文件服务器，简单的分析，聊天应用程序等等。这是我何时使用nodejs的观点

何时使用

在制作注重并发性和速度的系统时。

• 仅套接字服务器，例如聊天应用程序，irc应用程序等。
• 社交网络强调实时资源，例如地理位置，视频流，音频流等。
• 像分析网络应用程序一样，真正快速地处理小数据块。
• 公开仅REST的api。

什么时候不使用

它是一种非常通用的Web服务器，因此您可以在任何需要的地方使用它，但可能不在这些地方。

• 简单的博客和静态站点。
• 就像静态文件服务器一样。

请记住，我只是在挑剔。对于静态文件服务器，apache更好，主要是因为它广泛可用。这些年来，nodejs社区变得越来越大，越来越成熟，可以肯定地说，如果您有自己的托管选择，那么nodejs可以在几乎任何地方使用。

没有什么比银子弹更像了。一切都伴随着一些成本。就像您吃油腻的食物一样，您的健康将会受到损害，健康的食物不会像油腻的食物那样带有香料。他们是想要健康还是在食物中添加香料是个人选择。Node.js被认为用于特定场景的方式相同。如果您的应用程序不适合这种情况，则不应在应用程序开发中考虑它。我只是把我的想法放在同一点上：

何时使用Node.JS

1. 如果您的服务器端代码需要很少的cpu周期。在其他情况下，您正在执行非阻塞操作，并且没有繁重的算法/作业，因此不占用大量CPU周期。
2. 如果您来自Javascript领域，并且喜欢像客户端JS一样编写单线程代码。

何时不使用Node.JS

1. 您的服务器请求取决于占用大量CPU的算法/作业。

Node.JS的可伸缩性注意事项

1. Node.JS本身并未利用底层系统的所有核心，并且默认情况下它是单线程的，因此您必须自己编写逻辑以利用多核处理器并使之成为多线程。

Node.JS替代品

还有其他选项可以代替Node.JS，但是Vert.x似乎很有前途，并且具有很多其他功能，例如polygot和更好的可伸缩性考虑。

我认为没有人提到过Node.js的另一件事是令人惊叹的社区，程序包管理系统（npm）以及只需将它们包含在package.json文件中就可以包含的现有模块数量。

我认为Node.js最适合实时应用程序：在线游戏，协作工具，聊天室或任何一个用户（或机器人或传感器？）对应用程序有何影响的应用，其他用户必须立即查看，没有页面刷新。

我还应该提到，与Node.js结合使用Socket.IO可以比使用长轮询进一步减少实时延迟。在最坏的情况下，Socket.IO将退回到长时间轮询，如果可用，请改用Web套接字，甚至使用Flash。

但是我还应该提到，使用Node.js可以更好地解决代码可能因线程而阻塞的任何情况。或任何需要应用程序由事件驱动的情况。

另外，Ryan Dahl在一次谈话中说，我曾经参加过，对于常规的旧HTTP请求，Node.js基准测试与Nginx紧密竞争。因此，如果我们使用Node.js进行构建，则可以非常有效地服务于我们的常规资源，并且当我们需要事件驱动的东西时，就可以对其进行处理。

再加上所有时间都是JavaScript。Lingua Franca整个筹码量。

使用Node启动下一个项目的最重要原因...

• 所有最酷的家伙都加入其中...所以一定很有趣。
• 您可以在凉爽的地方闲逛，并有很多值得夸耀的Node冒险。
• 当涉及到云托管成本时，您是一分钱pin。
• 曾经在那里与Rails一起做过
• 您讨厌IIS部署
• 您过去的IT工作变得越来越乏味，您希望自己处于崭新的起步阶段。

期待什么...

• 借助Express，您将感到安全无忧，而无需使用所有您不需要的服务器膨胀软件。
• 像火箭一样运行，并且缩放良好。
• 你梦到了。您已安装。节点软件包repo npmjs.org是世界上最大的开源库生态系统。
• 您的大脑将在嵌套的回调中浪费时间...
• ...直到您学会遵守诺言。
• Sequelize和Passport是您的新API朋友。
• 调试大多数异步代码将变得非常有趣。
• 是所有提名人掌握Typescript的时间。

谁使用它？

• 贝宝，Netflix，沃尔玛，LinkedIn，Groupon，Uber，GoDaddy，道琼斯
• 这就是为什么他们切换到Node的原因。

在总结Node.js的出色功能方面，您做了出色的工作。我的感觉是，Node.js特别适合希望从浏览器回到服务器的持久连接的应用程序。使用称为“长轮询”的技术，您可以编写一个向用户实时发送更新的应用程序。在Ruby on Rails或Django之类的许多Web巨人上进行长时间的轮询会在服务器上产生巨大的负载，因为每个活动的客户端都要吃掉一个服务器进程。这种情况相当于一次pit弹袭击。使用Node.js之类的服务器时，服务器无需为每个打开的连接维护单独的线程。

这意味着您可以在Node.js中创建一个基于浏览器的聊天应用程序，该应用程序几乎不需要占用系统资源即可为大量客户端提供服务。每当您想进行这种长轮询时，Node.js都是一个不错的选择。

值得一提的是，Ruby和Python都具有执行此类操作的工具（分别是eventmachine和twisted），但是Node.js从头开始就表现出色。JavaScript在基于回调的并发模型中处于特殊位置，并且在这里很有用。而且，能够使用客户端和服务器都原生的JSON进行序列化和反序列化非常漂亮。

我期待在这里阅读其他答案，这是一个很棒的问题。

值得指出的是，Node.js对于在客户端/服务器之间重复使用大量代码的情况也非常有用。该流星框架使得这个非常容易，而且很多人都暗示这可能是网络发展的未来。我可以从经验中说，用Meteor编写代码非常有趣，其中很大一部分是花费更少的时间来考虑如何重组数据，因此可以轻松地在浏览器中运行代码操纵它并将其传递回去。

这是一篇有关金字塔和长轮询的文章，事实证明，在gevent的一点帮助下，设置起来非常容易：TicTacToe和金字塔长轮询。

我有一个使用Node.js的真实示例。我工作的公司有一位客户希望拥有一个简单的静态HTML网站。该网站用于使用PayPal出售一件商品，客户还希望拥有一个可以显示所售商品数量的柜台。客户预计将有大量访问该网站的访客。我决定使用Node.js和Express.js框架进行计数。

Node.js应用程序很简单。从Redis数据库中获取已售商品数量，在售出商品时增加计数器，并通过API将计数器值提供给用户。

在这种情况下选择使用Node.js的一些原因

1. 它非常轻巧且快速。在过去三周内，该网站的访问量已超过200000，并且最少的服务器资源已能够处理所有这些。
2. 计数器真的很容易实时显示。
3. Node.js易于配置。
4. 有很多免费的模块。例如，我找到了PayPal的Node.js模块。

在这种情况下，Node.js是一个了不起的选择。

简而言之：

Node.js非常适合具有大量并发连接的应用程序，并且每个请求仅需要很少的CPU周期，因为在执行功能期间会阻塞事件循环（与所有其他客户端一起使用）。

Mixu的技术博客中有一篇有关Node.js中事件循环的好文章：了解node.js事件循环。

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 (eventmachineand 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.