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

Posted 2023-03-07

【中文标题】如何决定何时使用 Node.js？

【英文标题】：How to decide when to use Node.js?

【发布时间】：2011-07-01 01:28:59

【问题描述】：

我是这种东西的新手，但最近我听说Node.js 有多好。考虑到我是多么喜欢使用 jQuery 和 javascript，我不禁想知道如何决定何时使用 Node.js。我想到的 Web 应用程序类似于 Bitly - 获取一些内容，将其存档。

从我这几天做的所有功课中，我得到了以下信息。 Node.js

是一种命令行工具，可以作为常规 Web 服务器运行并允许运行 JavaScript 程序 利用伟大的V8 JavaScript engine 当你需要同时做几件事时非常好 是基于事件的，所以所有类似于Ajax 的精彩内容都可以在服务器端完成 让我们在浏览器和后端之间共享代码 让我们谈谈 mysql

我遇到的一些来源是：

Diving into Node.js – Introduction and Installation Understanding NodeJS Node by Example (Archive.is) Let’s Make a Web App: NodePad

考虑到 Node.js 几乎可以在 Amazon's EC2 实例上开箱即用地运行，我试图了解哪些类型的问题需要 Node.js，而不是像 @ 这样的任何强大的国王987654331@、Python 和 Ruby。我知道这实际上取决于一个人对语言的专业知识，但我的问题更多地属于一般类别：何时使用特定框架以及它特别适合什么类型的问题？

【问题讨论】：

这个问题正在 meta (meta.***.com/q/332386/497418) 上讨论。

【参考方案1】：

您很好地总结了 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 特别适合需要从浏览器到服务器的持久连接的应用程序是非常重要的。 - 例如聊天程序或互动游戏' 如果只是构建一个不一定需要用户/服务器通信的应用程序，那么使用其他框架开发就可以了，并且花费的时间会少得多。

感谢... 很好的 Q 和 A ;-) 我也会考虑掌握一项伟大的技术，用于前端和后端开发，而不是几个不同的技术 ;)

为什么要使用长轮询？未来和sockets 发生了什么？

我的简短回答是后台进程。请求和响应（包括 REST API）都可以使用任何其他语言和服务器来实现。所以对于那些想在 node.js 中转换他们的 web 项目的人来说。再想想它是同一件事！将节点用作后台进程，例如使用 imap 阅读电子邮件、图像处理、将文件上传到云，或任何冗长或永无止境的进程，这些进程主要是面向事件的......

【参考方案2】：

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

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

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

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

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

【讨论】：

只是有人在 .Net 和 Node 之间切换的观察，系统不同区域的不同语言在上下文切换时有很大帮助。当我查看 Javascript 时，我在客户端工作，C# 表示 App Server，SQL = 数据库。在整个过程中使用 Javascript，我发现自己混淆了这些层，或者只是花费了更长的时间来进行上下文切换。这很可能是整天在 .NET 堆栈上工作并在晚上打瞌睡的产物，但它确实有所作为。

有趣的是，跨文化个体在主流文化和本土文化之间转换时转换方言的做法被称为“语码转换”。

就在前几天，我在思考如何以某种方式为不同的.js 文件分配不同的颜色。客户端绿色，服务器端蓝色。我一直在“迷失”自己。

【参考方案3】：

简而言之：

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

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

【参考方案4】：

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

何时使用 Node.JS

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

何时不使用 Node.JS

您的服务器请求依赖于占用大量 CPU 的算法/作业。

Node.JS 的可扩展性考虑

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

Node.JS 替代品

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

【讨论】：

我不确定“何时不使用”中列出的“如果您的服务器端请求包括阻塞操作，如文件 IO 或套接字 IO”。如果我的理解是正确的，node.js 的优势之一就是它具有强大的异步方式来处理 IO 而不会阻塞。所以 Node.js 可以被视为阻塞 IO 的“良药”。

@OndraPeterka：你说得对，Node.js 可以治愈阻塞服务器 IO，但是如果服务器上的请求处理程序本身正在对其他一些 Web 服务/文件操作进行阻塞调用， Node.js 在这里无济于事。非阻塞 IO 仅适用于对服务器的传入请求，但不适用于来自您的应用请求处理程序的传出请求。

@ajay from nodejs.org 他们说“非阻塞 I/O”，请检查您的“非阻塞 I/O”2 和 3。

在当前版本中，node实际上通过集群支持多核支持。这确实将 Node 应用程序的性能提升了至少两倍。但是，我认为当他们稳定集群库时，性能应该是两倍以上。

您可以使用 node.js 进行繁重的计算。使用fork。见***.com/questions/9546225/…。 Node 使用 cluster 模块可以很好地处理多个内核。 nodejs.org/api/cluster.html

【参考方案5】：

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

编辑

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

何时使用

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

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

何时不使用

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

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

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

【讨论】：

简单的博客仍然可以从 Node.js 中受益。对于提供静态文件，您仍然可以使用 Node.js，如果负载增加，只需在其前面添加 Nginx 反向代理，按照当前的最佳实践。 Apache httpd 服务器是垂死的恐龙 - 请参阅 this Netcraft survey。

我会说否则 - 看看ghost.org，看起来很棒，并且建立在 NodeJs 之上 - 协作，实时文章编辑。此外，在 NodeJs 中创建一个简单的页面，比如使用 sailsjs.org，既简单又快速，您无需费心学习任何服务器端编程语言

【参考方案6】：

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

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

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

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

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

【讨论】：

你如何主持这样的事情？那你必须在生产服务器上设置nodejs吗？在linux中？

有一些 PaaS，例如 nodejitsu 和 Heroku。或者您确实可以在 linux 机器上设置 nodejs，即来自 amazon ec2。见：lauradhamilton.com/…

200,000 次访问在 1,814,400 秒内。根本不相关。甚至 bash 也可以在最慢的服务器上处理这么多请求。暂存服务器。最慢的虚拟机。

【参考方案7】：

我认为关于 Node.js 的另一件很棒的事情是令人惊叹的社区、包管理系统 (npm) 和现有的模块数量，您可以通过简单地包含它们在你的 package.json 文件中。

【讨论】：

而且这些包都是比较新鲜的，所以它们有后见之明的好处，并且倾向于符合最近的网络标准。

恕我直言，npm 上的很多包都很糟糕，因为 npm doesn't have a mechanism to rate packages。来自CPAN 的事后诸葛亮？

太糟糕了，没有一个 websockets 库可以满足 rfc 6455 规范。当给出这个事实时，node.js 的***分子是聋子、哑巴和盲人。

我不知道您何时发表评论，但目前 ws 库支持该规范

【参考方案8】：

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

能够进行纯基于云的开发

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

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

【讨论】：

其实 Cloud9 IDE 和其他的（koding 我用的那个）支持几乎所有的网络语言。

你是认真的吗？这是选择堆栈的标准吗？ :) 很高兴它为你工作！

【参考方案9】：

使用 NodeJS 的原因：

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

与传统的多线程Java 或 ROR 框架相比，single-threaded 事件驱动系统是 fast，即使同时处理大量请求，也很简单。

李>

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

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

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

不使用 NodeJS 的原因：

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

除此之外，NPM 中的许多包还有些原始，并且仍在快速开发中。一些旧框架的库已经经历了十年的测试和错误修复，现在非常稳定。 Npmjs.org has no mechanism to rate packages，这导致大量软件包或多或少地做同样的事情，其中​​很大一部分不再维护。

嵌套回调地狱。 （当然有20 different solutions这个……）

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

处理文件可能有点麻烦。在其他语言中微不足道的事情，比如从文本文件中读取一行，是weird enough to do with Node.js，有一个 *** 问题，有 80 多个赞成票。有no simple way to read one record at a time from a CSV file。等等。

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

【讨论】：

@nane 是的，我认为他们可以解决这个问题，但是您必须限制自己只使用以类型安全语言编写的库，或者接受不是全部您的代码库 是静态类型的。但是有一个论点是：既然您应该为您的代码编写良好的测试而不管语言如何，那么即使对于动态类型的代码，您的置信度水平也应该相等。如果我们接受这个论点，那么强类型的优势就降低为有助于开发/调试时间、可证明性和optimization。

@kervin，我同意一些基准测试会很棒，但我对我能在网上找到的内容感到失望。有些人认为 .NET 的性能与 Node 相比是 comparable，但它对您实际在做什么至关重要。 Node 可能擅长于传递具有许多并发连接的少量消息，但对于繁重的数学计算来说并不是那么好。良好的性能比较需要测试各种情况。

@joeytwiddle 在处理大型复杂程序和静态类型检查时，像 Typescript 这样的东西不会帮助 Node.js 吗？

@joeytwiddle 对于它的价值，您可以使用stillmaintained.com 来确定是否仍然维护 npm 包（因为大多数都在 github 上）。此外，npm search 和 npm show 将显示包的最后发布日期。

通过将 rails 与 node 进行比较，您会将平台与框架混淆。 Rails 是 Ruby 的框架，就像 Sails 和 Meteor 是 Javascript 的框架一样。

【参考方案10】：

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

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

【参考方案11】：

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

所有最酷的家伙都喜欢它......所以它必须很有趣。 您可以在冰箱里闲逛，并有很多 Node 冒险值得吹嘘。 在云托管成本方面，您是个吝啬鬼。 已经用 Rails 做到了这一点 你讨厌 IIS 部署 您的旧 IT 工作变得相当枯燥，您希望自己在一个闪亮的新创业公司中。

会发生什么...

Express 没有您不需要的所有服务器膨胀软件，您会感到安全可靠。 像火箭一样运行，并且扩展性很好。 你梦想它。你安装了它。节点包 repo npmjs.org 是世界上最大的开源库生态系统。 在嵌套回调的领域，您的大脑会被时间扭曲... ...直到你学会保留你的Promises。 Sequelize 和 Passport 是您的 API 新朋友。 调试主要是异步代码会得到 umm ... 有趣。 是时候让所有节点掌握 Typescript。

谁使用它？

PayPal、Netflix、沃尔玛、LinkedIn、Groupon、优步、GoDaddy、道琼斯 这就是他们switched to Node 的原因。

【讨论】：

是的，我可以用传统方式回答这个问题。我认为我有资格这样做，但大部分已经说过，我认为一些轻松的乐趣会打破单调。我会定期就其他问题提供技术答案。

使用 ES6 异步代码生成器可以避免嵌套回调

@CleanCrispCode：确实如此！ ES6 采用了 C# 风格 async/await，所以现在我们可以推出更简洁的异步 Node 代码，也支持传统的 try/catch。在 2016/17 年，JS 编码人员正在切换到 ES6。

一万倍这个“你会觉得使用 Express 很安全，没有你不需要的所有服务器膨胀软件”

【参考方案12】：

可以用在哪里

高度事件驱动和高度 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 内存！

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

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

【参考方案13】：

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

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

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

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

【讨论】：

有许多现有的扩展 Node.js 应用程序的方法，您似乎没有提供任何关于“半生不熟的解决方案”、“可怕的黑客”和“可怕的 API”声明的参考。介意扩展这些吗？

我把它作为练习留给读者，但是看看所谓的流量控制解决方案就足够了。

这不是一个真正的答案。您声称现有的解决方案是“可怕的黑客”，但没有指出其中任何一个。您是否考虑过您可能根本不了解或不了解扩展 Node.js 应用程序的正确方法？

我稍微更新了我的答案。也许你仍然有抱怨，但如果你认为这是错误的，你应该评论细节......而不是在答案中指出缺乏。这对 imo 社区来说会更有成效。

【参考方案14】：

Node 非常适合快速原型制作，但我永远不会再将它用于任何复杂的事情。 我花了 20 年时间与编译器建立关系，我确实很想念它。

Node 对维护一段时间未访问的代码尤其痛苦。类型信息和编译时错误检测是好事。为什么要扔掉这一切？为了什么？并且该死的，当某些事情确实向南时，堆栈跟踪通常完全没用。

【讨论】：

虽然您没有进行编译时检查，但 JSDoc 允许您添加任何您想要的类型信息，这样当您回来时事情会更有意义。由于其良好定义的环境（闭包），正确分解的（小）函数通常也很容易理解。错误的堆栈跟踪通常可以通过一些重构来解决，以确保您不会将逻辑拆分为中间的异步回调。将异步回调保持在同一个闭包中可以轻松推理和维护。

我使用编译语言已经 30 年了，但在使用它仅一年之后，JavaScript 现在是我的首选语言。它非常高效 - 与 Java C# C++ 或 C 相比，我可以用更少的代码做更多的事情。但这是一种不同的心态。在许多情况下，无类型变量实际上是一个优势。 JSLINT 是必不可少的。当你需要同时做事情时，异步回调比你必须使用线程的任何语言更安全、更容易并且最终更有效率。无论如何，你必须了解 JavaScript，因为它是浏览器的语言。

我对提出的担忧表示同情，我注意到已经做出了一些努力来解决这些问题，尽管它们肯定没有被普遍应用。有一个名为 Tern 的惊人项目，它可以从 Javascript 代码和库的静态分析中提供 类型推导。它有各种编辑器的插件。还有 Typescript、JSDoc 和 BetterJS。然后是Go，众多compile-to-Javascript languages 之一！

【参考方案15】：

Node best for concurrent request handling -

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

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

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

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

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

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

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

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

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

【讨论】：

嗨，安舒尔。您能否详细说明或建议一些有关线程方式如何发生死锁的资源。

【参考方案16】：

穿上石棉长裤……

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

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

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

警告：Node.js 及其生态系统热--热得足以让你大吃一惊！

当我担任数学老师的助理时，有人告诉我的一个不明显的建议是不要告诉学生某事“容易”。回想起来，原因有点明显：如果你告诉人们某事很容易，那么没有看到解决方案的人最终可能会觉得（甚至更）愚蠢，因为他们不仅不知道如何解决问题，而且还知道问题所在。他们太愚蠢了，理解起来很容易！

有些陷阱不仅会惹恼来自 Python / Django 的人，如果您更改任何内容，它们会立即重新加载源代码。对于 Node.js，默认行为是，如果您进行一项更改，旧版本将继续处于活动状态，直到时间结束或您手动停止并重新启动服务器。这种不恰当的行为不仅惹恼了 Python 爱好者；它还激怒了提供各种解决方法的本地 Node.js 用户。在撰写本文时，*** 问题“在 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所有用户帐户放在一起。如果病毒传播，那可能会痛苦！）文档指出配额是可自定义的，但是一周前给开发人员的一封电子邮件询问如何更改配额没有得到答复，因为*** 的问题是一样的。我能找到的唯一答案是在 Github CoffeeScript 源代码中，它被列为构造函数的可选第二个整数参数。所以这很容易，您可以指定一个等于磁盘或分区大小的配额。但是除了移植一个没有意义的特性之外，该工具的作者完全没有遵循一个非常标准的约定，即将 0 解释为变量或函数的“无限”，其中整数用于指定某些资源使用的最大限制。解决这个错误的最好办法可能是指定配额为 Infinity：

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

按顺序交换两个 cmets：

人们不断地使用 JavaScript 作为一个整体，不必要地自取其辱，而 JavaScript 成为受人尊敬的语言的一部分是道格拉斯·克罗克福德 (Douglas Crockford) 所说的，“JavaScript 作为一门语言有一些非常好的部分，也有一些非常糟糕的部分。这是好的部分。只是忘记那里还有其他东西。”也许炙手可热的 Node.js 生态系统会发展出自己的自己的“Douglas Crockford”，他会说，“Node.js 生态系统是一个编码狂野的西部，但也有一些真正的瑰宝可以找到。这是一个路线图。以下是几乎不惜一切代价避免的区域。以下是在任何语言或环境中都能找到的一些最富有的领域。”

也许其他人可以把这些话当作挑战，并效仿 Crockford 的做法，为 Node.js 及其生态系统写出“好的部分”和/或“更好的部分”。我要买一本！

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

【参考方案17】：

我可以分享几点使用node js的地方和原因。

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

缺点：-

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

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