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

您很好地总结了 Node.js 的优点。我的感觉是 Node.js 特别适合您希望保持从浏览器到服务器的持久连接的应用程序。使用称为 "long-polling" 的技术，您可以编写一个向用户实时发送更新的应用程序。对许多网络巨头（如 Ruby on Rails 或 Django）进行长时间轮询会在服务器上产生巨大的负载，因为每个活动客户端都会占用一个服务器进程。这种情况相当于 tarpit 攻击。当你使用 Node.js 之类的东西时，服务器不需要为每个打开的连接维护单独的线程。

这意味着您可以在 Node.js 中创建一个几乎不占用系统资源来为大量客户端提供服务的 browser-based chat application。任何时候你想进行这种长轮询，Node.js 都是一个不错的选择。

值得一提的是，Ruby 和 Python 都有执行此类操作的工具（分别为 eventmachine 和 twisted），但 Node.js 从头开始做得非常好。 JavaScript 非常适合基于回调的并发模型，并且在这方面表现出色。此外，能够对客户端和服务器都使用本机 JSON 进行序列化和反序列化非常棒。

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

值得指出的是，Node.js 也非常适合在客户端/服务器之间重用大量代码的情况。 Meteor framework 让这一切变得非常简单，很多人认为这可能是 Web 开发的未来。我可以根据经验说，在 Meteor 中编写代码非常有趣，其中很大一部分是花更少的时间考虑如何重构数据，因此在浏览器中运行的代码可以轻松操纵它并将其传回。

这是一篇关于 Pyramid 和 long-polling 的文章，在 gevent 的帮助下很容易设置：TicTacToe and Long Polling with Pyramid。

---

我相信 Node.js 最适合实时应用程序：在线游戏、协作工具、聊天室或任何一个用户（或机器人？或传感器？）对应用程序所做的操作需要立即被其他用户看到，没有页面刷新。

我还应该提到，Socket.IO 与 Node.js 的结合将比长轮询更进一步地减少您的实时延迟。作为最坏的情况，Socket.IO 将回退到长轮询，而是使用 Web 套接字甚至 Flash（如果可用）。

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

此外，Ryan Dahl 在我曾经参加过的一次演讲中说，Node.js 的基准测试与 Nginx 的常规旧 HTTP 请求非常相似。因此，如果我们使用 Node.js 构建，我们可以非常有效地为我们的正常资源提供服务，并且当我们需要事件驱动的东西时，它已经准备好处理它。

另外，它一直都是 JavaScript。整个堆栈上的通用语。

---

使用 NodeJS 的原因：

它运行 Javascript，因此您可以在服务器和客户端上使用相同的语言，甚至可以在它们之间共享一些代码（例如，用于表单验证，或在任一端呈现视图。）

与传统的多线程 Java 或 ROR 框架相比，单线程事件驱动系统即使在一次处理大量请求时也很快，而且也很简单。

可通过 NPM 访问的不断增长的软件包池，包括客户端和服务器端库/模块，以及用于 Web 开发的命令行工具。其中大部分都方便地托管在 github 上，有时您可以在其中报告问题并在数小时内找到它！将所有内容集中在一个屋檐下，具有标准化的问题报告和轻松的分叉，这真是太好了。

它已成为运行 Javascript 相关工具和其他 Web 相关工具（包括任务运行器、缩小器、美化器、linter、预处理器、捆绑器和分析处理器）的事实上的标准环境。

它似乎非常适合原型设计、敏捷开发和快速产品迭代。

不使用 NodeJS 的原因：

它运行 Javascript，没有编译时类型检查。对于大型、复杂的安全关键系统或包括不同组织之间协作的项目，从长远来看，鼓励合同接口并提供静态类型检查的语言可能会为您节省一些调试时间（和爆炸）。 （虽然 JVM 卡在 null 上，所以请为您的核反应堆使用 Haskell。）

除此之外，NPM 中的许多包都有些原始，并且仍在快速开发中。一些旧框架的库已经经历了十年的测试和错误修复，现在非常稳定。 Npmjs.org 没有对包进行评级的机制，这导致了或多或少做相同事情的包激增，其中很大一部分不再维护。

嵌套回调地狱。 （当然有 20 种不同的解决方案……）

不断增长的包库可以使一个 NodeJS 项目看起来与下一个完全不同。由于可用的选项数量众多（例如 Express/Sails.js/Meteor/Derby），实现方式存在很大差异。这有时会使新开发人员更难加入 Node 项目。与加入现有项目的 Rails 开发人员形成对比：他应该能够很快熟悉应用程序，因为鼓励所有 Rails 应用程序使用类似的结构。

处理文件可能有点痛苦。在其他语言中微不足道的事情，比如从文本文件中读取一行，对于 Node.js 来说已经很奇怪了，以至于有一个 StackOverflow 问题，有 80 多个赞成票。从 CSV 文件中一次读取一条记录没有简单的方法。等等。

我喜欢 NodeJS，它快速、狂野和有趣，但我担心它对可证明的正确性没有兴趣。让我们希望我们最终能够融合两全其美。我很想看看将来会用什么代替 Node... :)

---

简而言之：

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

Mixu's tech blog: Understanding the node.js event loop 是一篇关于 Node.js 中的事件循环的好文章。

---

我有一个使用 Node.js 的真实示例。我工作的公司有一位客户想要一个简单的静态 HTML 网站。该网站用于使用 PayPal 销售一件商品，客户还希望有一个计数器来显示已售商品的数量。客户预计该网站将有大量访问者。我决定使用 Node.js 和 Express.js 框架制作计数器。

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

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

它非常轻巧且快速。在三周内，该网站的访问量已超过 200000 次，而最少的服务器资源已经能够处理这一切。计数器很容易实现实时。 Node.js 很容易配置。有很多免费的模块。例如，我为 PayPal 找到了一个 Node.js 模块。

在这种情况下，Node.js 是一个很棒的选择。

---

使用 Node 开始下一个项目的最重要原因...

所有最酷的家伙都喜欢它……所以它一定很有趣。

你可以在冰箱里闲逛，并有很多 Node 冒险值得吹嘘。

在云托管成本方面，您是个吝啬鬼。

用 Rails 做过吗

你讨厌 IIS 部署

你以前的 IT 工作变得相当乏味，你希望自己在一个闪亮的新创业公司。

期待什么...

使用 Express，您将感到安全可靠，无需您不需要的所有服务器膨胀软件。

像火箭一样运行并且可以很好地扩展。

你做梦。你安装了它。节点包 repo npmjs.org 是世界上最大的开源库生态系统。

在嵌套回调的土地上，你的大脑会被时间扭曲......

...直到你学会遵守你的承诺。

Sequelize 和 Passport 是您的新 API 朋友。

调试主要是异步代码会变得 umm ... 有趣。

是所有 Noder 掌握 Typescript 的时候了。

谁使用它？

PayPal、Netflix、沃尔玛、LinkedIn、Groupon、优步、GoDaddy、道琼斯

这就是他们切换到 Node.js 的原因。

---

没有什么能比得上银弹。一切都伴随着一些与之相关的成本。这就像如果你吃油腻的食物，你会损害你的健康，而健康的食物不像油腻的食物那样带有香料。他们是否想要健康或食物中的香料是个人选择。 Node.js 考虑在特定场景中使用的方式相同。如果您的应用程序不适合该场景，则不应将其用于您的应用程序开发。我只是把我的想法放在同样的位置上：

何时使用 Node.JS

如果您的服务器端代码需要很少的 cpu 周期。在其他世界中，您正在执行非阻塞操作并且没有消耗大量 CPU 周期的繁重算法/作业。如果您来自 Javascript 背景并且喜欢编写单线程代码，就像客户端 JS 一样。

何时不使用 Node.JS

您的服务器请求取决于繁重的 CPU 消耗算法/作业。

Node.JS 的可扩展性考虑

Node.JS 本身并没有利用底层系统的所有核心，默认是单线程的，你必须自己编写逻辑来利用多核处理器并使其成为多线程。

Node.JS 替代方案

可以使用其他选项来代替 Node.JS，但是 Vert.x 似乎很有前途，并且具有许多附加功能，例如 polygot 和更好的可扩展性考虑。

---

我认为没有人提到 Node.js 的另一件好事是令人惊叹的社区、包管理系统 (npm) 和现有的模块数量，只需将它们包含在 package.json 文件中即可。

---

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

编辑

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

何时使用

在制作强调并发性和速度的系统时。

仅套接字服务器，如聊天应用程序、irc 应用程序等。

社交网络强调实时资源，如地理位置、视频流、音频流等。

像分析网络应用程序一样快速处理小块数据。

公开一个 REST only api。

什么时候不使用

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

简单的博客和静态网站。

就像一个静态文件服务器。

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

---

可以用在什么地方

高度事件驱动和高度 I/O 绑定的应用程序

处理与其他系统的大量连接的应用程序

实时应用程序（Node.js 从一开始就设计为实时且易于使用。）

处理大量进出其他来源的信息流的应用程序

高流量，可扩展的应用程序

必须与平台 API 和数据库通信的移动应用程序，无需进行大量数据分析

构建网络应用程序

需要经常与后端对话的应用程序

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

LinkedIn 是一位知名用户。他们的整个移动堆栈都建立在 Node.js 之上。他们从在每台物理机上运行 15 个服务器和 15 个实例变为仅运行 4 个实例——这可以处理双倍的流量！

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

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

阅读更多：http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/

---

Node best for concurrent request handling -

那么，让我们从一个故事开始。从过去 2 年开始，我一直在研究 JavaScript 和开发 Web 前端，我很享受它。后端人员为我们提供了一些用 Java、python 编写的 API（我们不在乎），我们只需编写一个 AJAX 调用，获取我们的数据并猜一猜！我们完了。但实际上这并不容易，如果我们获得的数据不正确或存在一些服务器错误，那么我们就会卡住，我们必须通过邮件或聊天联系我们的后端人员（有时也在 WhatsApp 上:)。）这个不酷。如果我们用 JavaScript 编写 API 并从前端调用这些 API 会怎样？是的，这很酷，因为如果我们在 API 中遇到任何问题，我们可以调查它。你猜怎么着 ！你现在可以做到这一点，如何？ – 节点为您服务。

好的，同意你可以用 JavaScript 编写你的 API，但是如果我对上述问题没问题怎么办。您还有其他理由将 node 用于 rest API 吗？

所以这里是魔术开始。是的，我确实有其他理由为我们的 API 使用节点。

让我们回到我们传统的基于阻塞操作或线程的REST API系统。假设发生两个并发请求（r1 和 r2），每个请求都需要数据库操作。所以在传统系统中会发生什么：

<强> 1。等待方式：我们的服务器开始服务r1请求并等待查询响应。 r1 完成后，服务器开始服务 r2 并以相同的方式进行。所以等待不是一个好主意，因为我们没有那么多时间。

<强> 2。线程方式：我们的服务器将为请求 r1 和 r2 创建两个线程，并在查询数据库后达到它们的目的，所以它的速度很快。但是它很消耗内存，因为你可以看到我们启动了两个线程也有问题当两个请求都查询相同的数据时会增加，那么您必须处理死锁类型的问题。所以它比等待方式更好，但仍然存在问题。

现在在这里，节点将如何做到这一点：

<强> 3。 Nodeway : 当相同的并发请求进入节点时，它会使用其回调注册一个事件并继续前进，它不会等待特定请求的查询响应。因此，当 r1 请求到来时，节点的事件循环（是节点中有一个事件循环用于此目的。）使用其回调函数注册一个事件并继续为服务 r2 请求提供服务，并类似地使用其回调注册其事件。每当任何查询完成时，它都会触发其相应的事件并执行其回调以完成而不会被中断。

所以没有等待，没有线程，没有内存消耗——是的，这是提供休息 API 的节点。

---

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

能够进行纯基于云的开发

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

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

---

节点提供的另一件事是能够使用节点的子进程（childProcess.fork() 每个需要 10mb 内存根据文档）动态创建节点的多个 v8 实例，因此不会影响运行服务器的主进程。因此，卸载需要大量服务器负载的后台作业变得轻而易举，我们可以在需要时轻松杀死它们。

我一直在使用节点，在我们构建的大多数应用程序中，同时需要服务器连接，因此网络流量很大。像 Express.js 和新的 Koajs（移除了回调地狱）这样的框架使在节点上的工作变得更加容易。

---

穿上石棉长裤...

昨天我在 Packt Publications 的头衔，Reactive Programming with JavaScript。它并不是一个真正以 Node.js 为中心的标题。前面的章节旨在涵盖理论，后面的代码繁重的章节涵盖实践。因为我真的不认为不给读者一个网络服务器是合适的，所以 Node.js 似乎到目前为止是显而易见的选择。案子在打开之前就被关闭了。

我本可以对我使用 Node.js 的体验给出一个非常乐观的看法。相反，我对遇到的好点和坏点很诚实。

让我在这里引用一些相关的引述：

警告：Node.js 和它的生态系统很热——热到让你很伤心！当我担任数学老师的助理时，有人告诉我的一个不明显的建议是不要告诉学生某事“容易”。回想起来，原因有点明显：如果你告诉人们某事很容易，那么没有看到解决方案的人最终可能会觉得（甚至更）愚蠢，因为他们不仅不知道如何解决问题，而且还知道问题所在。他们太愚蠢了，理解是一件容易的事！有些陷阱不仅会惹恼来自 Python / Django 的人，如果您更改任何内容，它们会立即重新加载源代码。使用 Node.js，默认行为是，如果您进行一项更改，旧版本将继续处于活动状态，直到时间结束或您手动停止并重新启动服务器。这种不恰当的行为不仅惹恼了 Python 爱好者。它还激怒了提供各种解决方法的本地 Node.js 用户。在撰写本文时，StackOverflow 问题“在 Node.js 中自动重新加载文件”已经获得了 200 多个赞成票和 19 个答案；编辑将用户定向到保姆脚本 node-supervisor，其主页位于 http://tinyurl.com/reactjs-node-supervisor。这个问题让新用户有很大的机会感到愚蠢，因为他们认为他们已经解决了这个问题，但旧的、有缺陷的行为完全没有改变。而且很容易忘记弹服务器；我已经多次这样做了。我想传达的信息是，“不，你并不愚蠢，因为 Node.js 的这种行为咬了你的后背；只是 Node.js 的设计者认为没有理由在这里提供适当的行为。一定要尝试应对它，也许从节点主管或其他解决方案那里获得一点帮助，但请不要因为你很愚蠢而走开。你不是那个有问题的人。问题在于 Node.js 的默认行为。”这部分，经过一番讨论，被留下来，正是因为我不想给人一种“很容易”的印象。我在让事情正常工作时反复割伤我的手，我不想平息困难，让你相信让 Node.js 及其生态系统运转良好是一件简单的事情，如果它对你来说也不是一件简单的事，你不知道你在做什么。如果您在使用 Node.js 时没有遇到令人讨厌的困难，那就太好了。如果你这样做了，我希望你不要走开感觉，“我很愚蠢——我一定有什么问题。”如果您在处理 Node.js 时遇到令人讨厌的意外，您并不愚蠢。不是你！它是 Node.js 及其生态系统！

附录，在最后几章的渐强和结论之后，我并不真正想要它，讨论了我在生态系统中能够找到的东西，并为白痴字面主义提供了一种解决方法：

另一个看起来非常合适并且可能还可以赎回的数据库是 HTML5 键值存储的服务器端实现。这种方法具有 API 的主要优势，大多数优秀的前端开发人员都非常了解。就此而言，它也是一个大多数不太好的前端开发人员都很好理解的 API。但是使用 node-localstorage 包，虽然不提供字典语法访问（您想使用 localStorage.setItem(key, value) 或 localStorage.getItem(key)，而不是 localStorage[key]），但实现了完整的 localStorage 语义，包括默认的 5MB 配额——为什么？服务器端 JavaScript 开发人员是否需要自我保护？对于客户端数据库功能，每个网站 5MB 的配额确实是一个慷慨且有用的喘息空间，让开发人员可以使用它。您可以设置一个低得多的配额，并且仍然可以为开发人员提供比跛行和 cookie 管理不可估量的改进。 5MB 的限制并不能很快地用于大数据客户端处理，但是有一个非常慷慨的限额，足智多谋的开发人员可以用来做很多事情。但另一方面，在最近购买的大多数磁盘中，5MB 并不是特别大的一部分，这意味着如果您和网站在合理使用磁盘空间的问题上存在分歧，或者某些网站只是贪得无厌，它并不真正花费你很多，除非你的硬盘驱动器已经太满，否则你没有被淹没的硬盘驱动器的危险。如果余额少一点或多一点，也许我们会过得更好，但总的来说，这是解决客户端上下文内在紧张的一个不错的解决方案。但是，可以温和地指出，当您是为您的服务器编写代码的人时，您不需要任何额外的保护来防止您的数据库超过可容忍的 5MB 大小。大多数开发人员既不需要也不希望工具充当保姆并保护它们免于存储超过 5MB 的服务器端数据。 5MB 配额是客户端的黄金平衡行为，在 Node.js 服务器上有点愚蠢。 （并且，对于本附录中涵盖的多用户数据库，可能会有点痛苦地指出，除非您在磁盘上为每个用户帐户创建单独的数据库，否则每个用户帐户不是 5MB；这是在每个用户帐户之间共享 5MB所有用户帐户在一起。如果你像病毒一样传播，那可能会很痛苦！）文档指出配额是可定制的，但是一周前给开发人员的一封电子邮件询问如何更改配额没有得到答复，就像 StackOverflow 的问题一样.我能找到的唯一答案是在 Github CoffeeScript 源代码中，它被列为构造函数的可选第二个整数参数。所以这很容易，您可以指定一个等于磁盘或分区大小的配额。但是除了移植一个没有意义的特性之外，该工具的作者完全没有遵循一个非常标准的约定，将 0 解释为变量或函数的“无限制”，其中整数用于指定某些资源使用的最大限制。解决这个错误的最好办法可能是指定配额为 Infinity：

if (typeof localStorage === 'undefined' || localStorage === null)
  {      
  var LocalStorage = require('node-localstorage').LocalStorage;
  localStorage = new LocalStorage(__dirname + '/localStorage',
    Infinity);
  }

按顺序交换两条评论：

人们不必要地不断地使用 JavaScript 作为一个整体，而 JavaScript 成为受人尊敬的语言的一部分是道格拉斯·克罗克福德 (Douglas Crockford) 的一句话，“JavaScript 作为一种语言有一些非常好的部分和一些非常糟糕的部分。这是好的部分。只是忘记那里还有其他东西。”也许炙手可热的 Node.js 生态系统会发展出自己的“Douglas Crockford”，他会说：“Node.js 生态系统是一个编码狂野的西部，但有一些真正的宝石有待发现。这是一个路线图。以下是几乎不惜一切代价避免的区域。以下是在任何语言或环境中都可以找到一些最富有的地区。”也许其他人可以把这些话当作一个挑战，跟随 Crockford 的脚步，为 Node.js 及其生态系统写出“好的部分”和/或“更好的部分”。我要买一本！鉴于所有项目的热情程度和绝对的工作时间，可能需要在一年、两年或三年内大幅缓和在撰写本文时对不成熟生态系统的任何评论。五年后说“2015 年 Node.js 生态系统有几个雷区”可能真的有道理。 2020 年的 Node.js 生态系统拥有多个天堂。”

---

如果您的应用程序主要绑定 web api 或其他 io 通道，提供或获取用户界面，node.js 可能是您的一个公平选择，特别是如果您想挤出最大的可扩展性，或者，如果您生活中的主要语言是 javascript（或各种 javascript 转译器）。如果你构建微服务，node.js 也可以。 Node.js 也适用于任何小型或简单的项目。

它的主要卖点是它允许前端负责后端的东西，而不是典型的分歧。另一个合理的卖点是，如果您的员工一开始就面向 javascript。

然而，超过某个点，如果没有可怕的 hack 来强制模块化、可读性和流控制，你就无法扩展你的代码。不过，有些人喜欢这些 hack，尤其是来自事件驱动的 javascript 背景的人，它们看起来很熟悉或可以原谅。

特别是，当您的应用程序需要执行同步流程时，您开始为半生不熟的解决方案流血，这会大大减慢您的开发过程。如果您的应用程序中有计算密集型部分，请谨慎选择（仅）node.js。与我最初使用 node.js 或编写此代码时相比，也许 http://koajs.com/ 或其他新奇事物可以缓解那些原本棘手的方面。

---

我可以分享几点在哪里以及为什么要使用 node js。

对于聊天、协作编辑等实时应用程序，我们使用 nodejs 更好，因为它是事件库，从服务器向客户端发送事件和数据。简单易懂，因为它是大多数人都有想法的 javascript 基础。当前大多数 Web 应用程序都转向 Angular js&backbone，使用 node 很容易与客户端代码交互，因为两者都将使用 json 数据。很多插件可用。

缺点：-

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

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

---

Node 非常适合快速原型，但我再也不会将它用于任何复杂的事情。我花了 20 年时间与编译器建立关系，我确实很怀念它。 Node 在维护您有一段时间没有访问过的代码时尤其痛苦。类型信息和编译时错误检测是好事。为什么要扔掉这一切？为了什么？而且，当某些事情确实向南时，堆栈跟踪通常完全没用。

---