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

你很好地总结了Node.js.的优点。我的感觉是Node.js特别适合那些你想保持从浏览器回到服务器的持久连接的应用程序。使用一种被称为长轮询的技术，你可以编写一个应用程序，实时向用户发送更新。对许多网络巨头进行长时间轮询，比如ruby on rails或Django，会给服务器带来巨大的负载，因为每个活动客户端消耗一个服务器进程。这种情况相当于塔皮攻击。当你使用Node.js之类的东西时，服务器不需要为每个打开的连接维护单独的线程。

这意味着您可以在Node.js中创建一个基于浏览器的聊天应用程序，它几乎不需要任何系统资源来服务大量客户端。任何时候您想进行这种长轮询，Node.js都是一个很好的选择。

值得一提的是，Ruby和Python都有工具来做这种事情（分别为事件机器和扭曲），但Node.js做得非常好，而且从头开始。JavaScript非常适合基于回调的并发模型，它在这里表现出色。此外，能够使用客户端和服务器的原生JSON进行序列化和反序列化是非常漂亮的。

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

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

这是一篇关于Pyramidand long-轮询的文章，它很容易设置，只需要一点gEvent的帮助：使用金字塔进行TicTacToe和长轮询。

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

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

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

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

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

简而言之：

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

关于Node.js中的事件循环的一篇好文章是Mixu的技术博客：了解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似乎很有希望，并且有很多附加功能，如多边形和更好的可扩展性考虑。

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

编辑

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

何时使用

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

• 仅套接字服务器，如聊天应用程序、irc应用程序等。
• 强调实时资源的社交网络，如地理位置、视频流、音频流等。
• 像分析网络应用程序一样快速处理小块数据。
• 因为只暴露一个REST API。

什么时候不使用

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

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

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

我有一个现实世界的例子，我用过Node.js.我工作的公司有一个客户想要一个简单的静态超文本标记语言网站。这个网站是用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的伟大的事情是惊人的社区，包管理系统（npm）和存在的模块数量，你可以通过简单地将它们包含在你的package.json文件中。

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

能够进行纯云开发

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

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

使用NodeJS的原因：

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

• 单线程事件驱动的系统是快速即使在一次处理大量请求时，也很简单，与传统的多线程Java

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

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

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

使用NodeJS的原因没有：

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

• Npmjs.org没有对包进行评级的机制

• 嵌套回调地狱。（当然，有20种不同的解决方案来解决这个问题…）

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

• 处理文件可能有点麻烦。在其他语言中很琐碎的事情，比如从文本文件中读取一行，很奇怪，足以与Node.js有关

我喜欢NodeJS，它快速、狂野和有趣，但我担心它对可证明的正确性没有什么兴趣。让我们希望我们最终能融合两全其美。我渴望看到未来什么会取代Node…：）

node提供的另一件事是能够使用node的子进程（childProcess.fork（）每个需要10mb内存）动态创建多个v8实例的node，从而不会影响运行服务器的主进程。因此，卸载需要巨大服务器负载的后台工作变成了儿戏，我们可以在需要时轻松杀死它们。

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

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

• 所有最酷的人都喜欢它……所以它必须很有趣。
• 你可以在冷却器里闲逛，有很多节点冒险可以吹嘘。
• 在云托管成本方面，你是个吝啬鬼。
• 用Rails做到了这一点
• 你讨厌IIS部署
• 你的旧IT工作变得相当枯燥，你希望你在一个闪亮的新启动。

期待什么…

• 使用Express，您将感到安全可靠，而无需您从未需要的所有服务器臃肿软件。
• 运行像火箭和规模很好。
• 你梦想它。你安装了它。节点包reponpmjs.org是世界上最大的开源库生态系统。
• 你的大脑会在嵌套回调的土地上扭曲时间…
• …直到你学会保持你的Promises。
• 序列化和护照是您的新API朋友。
• 调试大部分异步代码会得到umm…有趣。
• 是时候让所有节点掌握打字稿了。

谁用它？

• PayPal、Netflix、沃尔玛、LinkedIn、Groupon、Uber、Go爸爸、道琼斯
• 这就是为什么他们切换到节点。

它可以用于

• 高度事件驱动和严重I/O绑定的应用程序
• 处理与其他系统的大量连接的应用程序
• 实时应用程序（Node.js是从头开始设计的，用于实时和简单要使用。）
• 处理大量信息流入和来自其他来源的应用程序
• 高流量、可扩展的应用程序
• 必须与平台API和数据库对话的移动应用程序，而无需处理大量数据分析
• 构建网络应用程序
• 需要经常与后端通信的应用程序

在移动方面，黄金时段的公司依靠Node.js为他们的移动解决方案。

LinkedIn是一个杰出的用户。他们的整个移动堆栈都建立在Node.js.他们从运行15台服务器，每台物理机器上有15个实例，到只有4个实例-可以处理两倍的流量！

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

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

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

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

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

但是，超过一定程度后，如果没有强制模块化，易读性和流控制的可怕黑客，您就无法扩展代码。虽然有些人喜欢这些黑客，尤其是来自事件驱动的javascript背景，但它们看起来很熟悉或可以原谅。

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

1. Node非常适合快速原型，但我再也不会用它来做任何复杂的事情了。我花了20年的时间与编译器建立关系，我真的很想念它。

2. 节点对于维护你有一段时间没有访问过的代码尤其痛苦。键入信息和编译时错误检测是好事。为什么要把所有这些都扔掉？为了什么？该死，当某些事情发生变化时，堆栈跟踪通常完全无用。

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

让我们从一个故事开始。在过去的2年里，我一直在研究JavaScript并开发Web前端，我很喜欢它。后端人员提供了一些用JavaPython编写的API（我们不在乎），我们只需编写一个AJAX调用，获取我们的数据，猜猜看！我们完成了。但实际上这并没有那么容易，如果我们获得的数据不正确或有一些服务器错误，那么我们就卡住了，我们必须通过邮件或聊天联系我们的后端人员（有时也在WhatsApp上：）。）这并不酷。如果我们用JavaScript编写我们的API，并从我们的前端调用这些API呢？是的，这很酷，因为如果我们在API中遇到任何问题，我们可以研究它。猜猜看！你现在可以做到这一点，怎么做？-Node适合你。

OK同意你可以用JavaScript编写你的API，但如果我对上述问题没意见怎么办。你还有其他原因使用节点作为休息API吗？

魔术开始了。是的，我确实有其他理由将节点用于我们的API。

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

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

2.穿线方式：我们的服务器将为请求r1和r2创建两个线程，并在查询数据库后达到它们的目的。

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

因此，当r1请求到来时，节点的事件循环（是的，节点中有一个事件循环）用其回调函数注册一个事件，然后继续服务r2请求，类似地，它用其回调注册其事件。每当任何查询完成时，它都会触发其相应的事件并执行回调直到完成而不会被中断。

所以没有等待，没有线程，没有内存消耗-是的，这是服务rest API的节点。

穿着石棉长裤…

昨天我在Packt Publations的书名是使用JavaScript进行反应式编程。它并不是一个真正以Node.js为中心的书名；前面的章节旨在涵盖理论，后面的代码繁重的章节涵盖实践。因为我真的认为不给读者一个网络服务器是不合适的，Node.js似乎是显而易见的选择。这个案例甚至在打开之前就已经结束了。

我本可以对我的经历给出一个非常乐观的看法Node.js.相反，我对我遇到的优点和缺点很诚实。

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

警告：Node.js和它的生态系统很热，热到足以把你烧伤！

当我还是一名数学助教时，我被告知的一个不明显的建议是不要告诉学生某件事情“很容易”。回想起来，原因有些明显：如果你告诉人们某件事情很容易，那些看不到解决方案的人最终可能会觉得（甚至更）愚蠢，因为他们不仅不知道如何解决这个问题，而且他们太愚蠢而无法理解的问题是一个简单的问题！

有一些陷阱不仅惹恼了来自Python/Django的人，如果你改变了任何东西，它会立即重新加载源代码。Node.js，默认行为是，如果你做了一个更改，旧版本将继续处于活动状态，直到时间结束，或者直到你手动停止并重新启动服务器。这种不恰当的行为不仅惹恼了Pythonistas；它还激怒了提供各种变通方法的本地Node.js用户。StackOverflow问题“在Node.js中自动重新加载文件”在撰写本文时已经有超过200个赞成票和19个答案；编辑将用户引导到保姆脚本，节点主管，主页位于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并不是一个特别大的部分，这意味着如果您和网站对磁盘空间的合理使用存在分歧，或者某些网站只是hoggish，它并不会真正花费您太多，并且除非您的硬盘驱动器已经太满，否则您不会面临硬盘驱动器被淹没的危险。如果余额少一点或多一点，也许我们会更好，但总的来说，这是解决客户端上下文内在紧张局势的一个不错的解决方案。

然而，可能会有人温和地指出，当你为服务器编写代码时，你不需要任何额外的保护来防止数据库大小超过可容忍的5MB。大多数开发人员既不需要也不希望工具充当保姆，保护他们存储超过5MB的服务器端数据。5MB配额在客户端是一个黄金平衡行为，在Node.js服务器上有点愚蠢。（对于本附录中涵盖的多用户数据库，可能会有点痛苦地指出，除非您为每个用户帐户在磁盘上创建一个单独的数据库，否则每个用户帐户不会有5MB；这是所有用户帐户共同共享的5MB。如果你像病毒一样传播，这可能会得到痛苦！）留档指出配额是可定制的，但一周前给开发人员的一封电子邮件询问如何更改配额没有得到答复，StackOverflow问题也是如此。我能找到的唯一答案是在Github CoffeeScript源代码中，在那里它被列为构造函数的可选第二个整数参数。所以这很容易，你可以指定一个等于磁盘或分区大小的配额。但是，除了移植一个没有意义的特性之外，该工具的作者完全没有遵循一个非常标准的惯例，即对变量或函数将0解释为“无限”，其中整数是为某些资源使用指定最大限制。处理这个错误功能的最好办法可能是指定配额为无限：

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生态系统是一个编码的狂野西部，但有一些真正的宝石可以找到。这是一个路线图。这是几乎不惜任何代价避免的领域。这是在任何语言或环境中都能找到的一些最富有的收益的领域。“

也许其他人可以把这些话当作一个挑战，跟随克罗克福德的领导，为Node.js及其生态系统写下“好的部分”和/或“更好的部分”。

考虑到所有项目的热情程度和纯粹的工作时间，可能有必要在一年、两年或三年内大幅缓和撰写本文时关于生态系统不成熟的任何评论。五年后，“2015年的Node.js生态系统有几个雷区。2020年的Node.js生态系统有多个天堂。”

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

1. 对于像聊天这样的实时应用程序，协作编辑更好，我们使用nodejs，因为它是事件库，从服务器向客户端发射事件和数据。
2. 简单易懂，因为它是大多数人都有想法的JavaScript基础。
3. 当前大多数Web应用程序都在向角度js和骨干发展，使用node很容易与客户端代码交互，因为两者都将使用json数据。
4. 很多可用的插件。

缺点：-

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

结论：-如果你有非常大的业务逻辑和复杂的功能，最好不要使用nodejs。如果您想与聊天和任何协作功能一起构建应用程序… node可以在特定部分中使用，并且应该使用您的便利技术。