我对这类东西很陌生，但最近我听到了很多关于node.js有多好的消息。考虑到我是多么喜欢使用jquery和javascript，我不禁想知道如何决定何时使用node.js。我心目中的Web应用程序有点像是——获取一些内容，将其存档。

从我最近几天做的所有作业中，我得到了以下信息。J.N.

• 是一个命令行工具，可以作为常规Web服务器运行，并允许一个人运行JavaScript程序。
• 使用伟大的V8 javascript引擎
• 当你需要同时做几件事时非常好
• 是基于事件的，所以所有类似Ajax的出色工作都可以在服务器端完成
• 允许我们在浏览器和后端之间共享代码
• 我们来谈谈MySQL

我遇到的一些来源是：

• 进入node.js–介绍和安装
• 理解nodejs
• 逐节点示例(archive.is)
• 让我们做一个网络应用：nodepad

考虑到node.js在Amazon的EC2实例中几乎是开箱即用的，我试图了解需要node.js的问题类型，而不是像php、python和ruby这样的强大的国王。我知道这实际上取决于一个人对一种语言的专长，但我的问题更多地属于一般范畴：什么时候使用一个特定的框架，以及它特别适合什么类型的问题？

你总结了node.js最棒的地方。我的感觉是node.js特别适合那些您希望保持从浏览器到服务器的持久连接的应用程序。使用一种称为"长轮询"的技术，您可以编写一个应用程序，将更新实时发送给用户。在许多Web巨头上进行长时间的轮询，如RubyonRails或Django，会在服务器上产生巨大的负载，因为每个活动客户机都会占用一个服务器进程。这种情况相当于柏油坑攻击。当您使用node.js之类的东西时，服务器不需要为每个打开的连接维护单独的线程。

这意味着您可以在node.js中创建一个基于浏览器的聊天应用程序，它几乎不需要系统资源来为许多客户机提供服务。每当您想进行这种长时间的轮询时，node.js是一个很好的选择。

值得一提的是，Ruby和Python都有工具来完成这类工作(分别是eventmacher和twisted)，但是node.js做得非常好，而且从头开始。Javascript非常适合基于回调的并发模型，它在这里非常出色。此外，能够使用客户机和服务器自带的JSON进行序列化和反序列化也非常漂亮。

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

值得指出的是，node.js也非常适合在客户机/服务器缺口中重用大量代码的情况。Meteor框架使这变得非常简单，很多人都建议这可能是Web开发的未来。我可以从经验中说，在Meteor中编写代码是非常有趣的，其中很大一部分是花更少的时间思考如何重组数据，这样在浏览器中运行的代码就可以轻松地操纵它并将其传递回去。

这里有一篇关于金字塔和长投票的文章，在Gevent的帮助下，它非常容易建立起来：Ticcactoe和长投票金字塔。

我相信node.js最适合于实时应用：在线游戏、协作工具、聊天室，或者任何一个用户(或机器人)所在的地方。还是传感器？)与应用程序的连接需要其他用户立即看到，而不需要刷新页面。

我还应该提到socket.io与node.js的结合将进一步减少您的实时延迟，而不是长轮询。在最坏的情况下，socket.io将回到长轮询状态，如果有可用的话，可以使用web socket甚至flash。

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

另外，RyanDahl在一次谈话中说，我曾经参加过node.js基准测试，它与nginx在常规的老HTTP请求方面有着密切的竞争。因此，如果我们使用node.js构建，我们可以非常有效地为我们的常规资源服务，当我们需要事件驱动的东西时，它就可以处理它了。

另外，它一直都是javascript。全套语言。

使用nodejs的原因：

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

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

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

• 它已经成为一个标准环境，在这个环境中运行与javascript相关的工具和其他与Web相关的工具，包括任务运行者、迷你、美化者、过梁、预处理器、绑定器和分析处理器。

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

不使用nodejs的原因：

• 它运行没有编译时类型检查的javascript。对于大型、复杂的安全关键系统或项目(包括不同组织之间的协作)，一种鼓励契约式接口并提供静态类型检查的语言可以从长远来看节省一些调试时间(和爆炸)。(尽管JVM与null有冲突，但请在核反应堆中使用Haskell。)

• 除此之外，新产品管理中的许多包装都有点生涩，而且仍在快速发展中。一些用于旧框架的库已经经历了十年的测试和错误修复，现在已经非常稳定。NPMJS.org没有对软件包进行评级的机制，这导致了软件包在做相同的事情时或多或少地出现了激增，其中很大一部分不再被维护。

• 嵌套回调地狱。(当然，这有20种不同的解决方案…)

• 不断增长的软件包池可以使一个nodejs项目与下一个截然不同。由于有大量可用的选项(例如express/帆.js/meteor/derby)，因此在实现方面存在很大的差异。这有时会使新开发人员更难进入节点项目。与之形成对比的是，Rails开发人员加入了一个现有的项目：他应该能够很快地熟悉这个应用程序，因为所有的Rails应用程序都被鼓励使用类似的结构。

• 处理文件可能有点麻烦。在其他语言中，一些琐碎的事情，比如从文本文件中读取一行，对于node.js来说已经够奇怪了，因为它上面有一个stackoverflow问题，有80多个upvotes。从csv文件中一次读取一个记录没有简单的方法。等。

我喜欢点头，它快速、狂野、有趣，但我担心它对可证明的正确性没有兴趣。希望我们最终能把两个世界的精华融为一体。我很想知道将来什么会取代节点…：)

简而言之：

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

关于node.js中事件循环的一篇好文章是mixu的技术博客：了解node.js事件循环。

我有一个使用node.js的真实例子。我工作的公司有一个客户想要一个简单的静态HTML网站。这个网站是用来销售一个项目使用贝宝，客户还希望有一个柜台，显示出售物品的数量。客户希望有大量的访问者访问这个网站。我决定使用node.js和express.js框架制作计数器。

node.js应用程序很简单。从redis数据库中获取已售出商品的数量，在出售商品时增加计数器的数量，并通过api为用户提供计数器值。

在本例中，我选择使用node.js的一些原因

在本例中，node.js是一个很棒的选择。

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

• 所有最酷的家伙都喜欢…所以一定很有趣。
• 你可以在凉爽的地方闲逛，并且有很多节点的冒险活动可以炫耀。
• 在云托管成本方面，你是个吝啬鬼。
• 有没有用铁轨做的？
• 你讨厌IIS部署
• 你以前的IT工作越来越枯燥，你希望自己能重新开始。

期待什么…

• 如果没有你不需要的所有服务器膨胀软件，使用Express你会感到安全。
• 跑得像火箭，而且缩放得很好。
• 你做梦。你安装了它。node package repo npmjs.org是世界上最大的开源图书馆生态系统。
• 你的大脑会在嵌套回调的土地上扭曲…
• …直到你学会信守诺言。
• Sequelize和Passport是您的新API朋友。
• 调试主要是异步代码将得到umm…有趣。
• 现在是所有节点掌握typescript的时候了。

谁用的？

• 贝宝，Netflix，沃尔玛，LinkedIn，Groupon，Uber，GoDead，陶氏琼斯
• 这就是为什么他们切换到节点。

没有什么比得上银弹。每件事都伴随着一些相关的成本。这就像你吃油腻的食物，你会损害你的健康，健康的食物不带香料，如油腻的食物。无论他们想要健康还是像在他们的食物中一样需要香料，这都是个人的选择。与node.js在特定场景中使用的方式相同。如果你的应用不适合这种情况，你就不应该在你的应用开发中考虑它。我只是把我的想法放在同一个地方：

何时使用node.js

不使用node.js时

node.js的可扩展性考虑

node.js替代方案

还有其他的选项可以代替node.js，但是vert.x似乎很有前途，它有很多额外的功能，比如polygot和更好的可伸缩性考虑。

我认为没有人提到过node.js的另一个伟大之处是令人惊叹的社区、包管理系统(NPM)以及您可以通过简单地将它们包含在package.json文件中来包含的模块数量。

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

编辑

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

何时使用

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

• 仅限套接字服务器，如聊天应用程序、IRC应用程序等。
• 强调实时资源的社交网络，如地理位置、视频流、音频流等。
• 处理小数据块的速度非常快，就像分析Web应用程序一样。
• 作为只显示REST的API。

何时不使用

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

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

记住我只是吹毛求疵。对于静态文件服务器，Apache更好，主要是因为它具有广泛的可用性。这些年来，Nodejs社区变得越来越大和成熟，可以肯定的是，如果你有自己的托管选择，Nodejs可以在任何地方使用。

它可以用在

• 高度事件驱动的应用程序受到严重的I/O限制
• 处理与其他系统的大量连接的应用程序
• 实时应用程序(node.js是从一开始就为实时和方便而设计的使用
• 能够处理大量信息流到其他来源或从其他来源流出的应用程序
• 高流量、可扩展的应用程序
• 必须与平台API和数据库对话的移动应用程序，而无需执行大量数据分析学
• 构建联网应用程序
• 需要经常与后端对话的应用程序

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

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

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

沃尔玛将其移动应用重新设计为使用node.js，并将其javascript处理推送到服务器上。

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

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

那么，让我们从一个故事开始。从过去2年来，我一直在开发JavaScript和Web前端，我很喜欢它。后端的家伙为我们提供了一些用Java编写的API，Python(我们不在乎)，我们只是写了一个Ajax调用，获取我们的数据并猜出了什么！我们完了。但事实上，这并不容易，如果我们得到的数据不正确，或者有一些服务器错误，那么我们就卡住了，我们必须通过邮件或聊天联系我们的后端人员(有时也在whatsApp上)，这并不酷。如果我们用JavaScript编写API，并从前端调用这些API呢？是的，这很酷，因为如果我们在API中遇到任何问题，我们可以研究它。猜猜看！你现在可以做这个了，怎么做？–节点在那里。

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

魔法开始了。是的，我确实有其他的理由为我们的API使用节点。

让我们回到传统的基于阻塞操作或线程的RESTAPI系统。假设发生了两个并发请求(R1和R2)，每个请求都需要数据库操作。所以在传统系统中会发生什么：

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

2。线程化方式：我们的服务器会为r1和r2两个请求创建两个线程，在查询数据库后服务于它们的目的，使其快速冷却，但这是一种内存消耗，因为您可以看到，当两个请求查询相同的数据时，我们启动的两个线程的问题也会增加，所以您必须处理死锁之类的问题。S。所以这比等待更好，但问题仍然存在。

下面是节点将如何执行此操作：

三。nodeway：当同一个并发请求进入节点时，它将用它的回调注册一个事件，并向前移动，它不会等待特定请求的查询响应。因此，当r1请求进入节点时，它的事件循环(是的，节点中有一个事件循环用于此目的。)用它的回调函数a注册一个事件。nd继续为r2请求提供服务，并在回调中类似地注册其事件。每当任何查询完成时，它都会触发相应的事件，并执行回调以完成查询，而不会被中断。

所以不需要等待，不需要线程，不需要消耗内存——是的，这是为RESTAPI提供服务的节点。

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

能够进行纯粹的基于云的开发

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

当然，其他语言或平台也可能有基于云的IDE(Cloud9IDE也在为其他语言添加支持)，但是使用Cloud9donode.js开发对我来说确实是一个很好的体验。

穿着石棉长袍…

昨天我的题目是packt出版物，用javascript进行反应式编程。它实际上不是以node.js为中心的标题；早期的章节旨在涵盖理论，之后的代码重的章节则涵盖实践。因为我真的认为不给读者一个Web服务器是不合适的，所以node.js似乎是迄今为止最明显的选择。这个案子甚至还没开审就已经结案了。

我可以非常乐观地看待我在node.js上的经验。相反，我对我遇到的好点和坏点是诚实的。

让我包括一些与此相关的报价：

Warning: Node.js and its ecosystem are hot--hot enough to burn you badly!

When I was a teacher’s assistant in math, one of the non-obvious suggestions I was told was not to tell a student that something was"easy." The reason was somewhat obvious in retrospect: if you tell people something is easy, someone who doesn’t see a solution may end up feeling (even more) stupid, because not only do they not get how to solve the problem, but the problem they are too stupid to understand is an easy one!

There are gotchas that don’t just annoy people coming from Python / Django, which immediately reloads the source if you change anything. With Node.js, the default behavior is that if you make one change, the old version continues to be active until the end of time or until you manually stop and restart the server. This inappropriate behavior doesn’t just annoy Pythonistas; it also irritates native Node.js users who provide various workarounds. The StackOverflow question"Auto-reload of files in Node.js" has, at the time of this writing, over 200 upvotes and 19 answers; an edit directs the user to a nanny script, node-supervisor, with homepage at http://tinyurl.com/reactjs-node-supervisor. This problem affords new users with great opportunity to feel stupid because they thought they had fixed the problem, but the old, buggy behavior is completely unchanged. And it is easy to forget to bounce the server; I have done so multiple times. And the message I would like to give is,"No, you’re not stupid because this behavior of Node.js bit your back; it’s just that the designers of Node.js saw no reason to provide appropriate behavior here. Do try to cope with it, perhaps taking a little help from node-supervisor or another solution, but please don’t walk away feeling that you’re stupid. You’re not the one with the problem; the problem is in Node.js’s default behavior."

This section, after some debate, was left in, precisely because I don't want to give an impression of"It’s easy." I cut my hands repeatedly while getting things to work, and I don’t want to smooth over difficulties and set you up to believe that getting Node.js and its ecosystem to function well is a straightforward matter and if it’s not straightforward for you too, you don’t know what you’re doing. If you don’t run into obnoxious difficulties using Node.js, that’s wonderful. If you do, I would hope that you don’t walk away feeling,"I’m stupid—there must be something wrong with me." You’re not stupid if you experience nasty surprises dealing with Node.js. It’s not you! It’s Node.js and its ecosystem!

附录，在上一章的高潮和结论之后，我并不真正想要它，它讨论了我在生态系统中所能找到的东西，并为现代文学主义提供了一个解决办法：

Another database that seemed like a perfect fit, and may yet be redeemable, is a server-side implementation of the HTML5 key-value store. This approach has the cardinal advantage of an API that most good front-end developers understand well enough. For that matter, it’s also an API that most not-so-good front-end developers understand well enough. But with the node-localstorage package, while dictionary-syntax access is not offered (you want to use localStorage.setItem(key, value) or localStorage.getItem(key), not localStorage[key]), the full localStorage semantics are implemented, including a default 5MB quota—WHY? Do server-side JavaScript developers need to be protected from themselves?

For client-side database capabilities, a 5MB quota per website is really a generous and useful amount of breathing room to let developers work with it. You could set a much lower quota and still offer developers an immeasurable improvement over limping along with cookie management. A 5MB limit doesn’t lend itself very quickly to Big Data client-side processing, but there is a really quite generous allowance that resourceful developers can use to do a lot. But on the other hand, 5MB is not a particularly large portion of most disks purchased any time recently, meaning that if you and a website disagree about what is reasonable use of disk space, or some site is simply hoggish, it does not really cost you much and you are in no danger of a swamped hard drive unless your hard drive was already too full. Maybe we would be better off if the balance were a little less or a little more, but overall it’s a decent solution to address the intrinsic tension for a client-side context.

However, it might gently be pointed out that when you are the one writing code for your server, you don’t need any additional protection from making your database more than a tolerable 5MB in size. Most developers will neither need nor want tools acting as a nanny and protecting them from storing more than 5MB of server-side data. And the 5MB quota that is a golden balancing act on the client-side is rather a bit silly on a Node.js server. (And, for a database for multiple users such as is covered in this Appendix, it might be pointed out, slightly painfully, that that’s not 5MB per user account unless you create a separate database on disk for each user account; that’s 5MB shared between all user accounts together. That could get painful if you go viral!) The documentation states that the quota is customizable, but an email a week ago to the developer asking how to change the quota is unanswered, as was the StackOverflow question asking the same. The only answer I have been able to find is in the Github CoffeeScript source, where it is listed as an optional second integer argument to a constructor. So that’s easy enough, and you could specify a quota equal to a disk or partition size. But besides porting a feature that does not make sense, the tool’s author has failed completely to follow a very standard convention of interpreting 0 as meaning"unlimited" for a variable or function where an integer is to specify a maximum limit for some resource use. The best thing to do with this misfeature is probably to specify that the quota is Infinity:

按顺序交换两条注释：

People needlessly shot themselves in the foot constantly using JavaScript as a whole, and part of JavaScript being made respectable language was a Douglas Crockford saying in essence,"JavaScript as a language has some really good parts and some really bad parts. Here are the good parts. Just forget that anything else is there." Perhaps the hot Node.js ecosystem will grow its own"Douglas Crockford," who will say,"The Node.js ecosystem is a coding Wild West, but there are some real gems to be found. Here’s a roadmap. Here are the areas to avoid at almost any cost. Here are the areas with some of the richest paydirt to be found in ANY language or environment."

Perhaps someone else can take those words as a challenge, and follow Crockford’s lead and write up"the good parts" and / or"the better parts" for Node.js and its ecosystem. I’d buy a copy!

And given the degree of enthusiasm and sheer work-hours on all projects, it may be warranted in a year, or two, or three, to sharply temper any remarks about an immature ecosystem made at the time of this writing. It really may make sense in five years to say,"The 2015 Node.js ecosystem had several minefields. The 2020 Node.js ecosystem has multiple paradises."

节点提供的另一个功能是，能够使用节点的子进程(child process.fork()，每个进程需要每个文档10MB内存)动态创建多个V8节点实例，从而不影响运行服务器的主进程。因此，卸载一个需要大量服务器负载的后台工作就成了孩子们的游戏，我们可以在需要时轻松地杀死他们。

我经常使用节点，在我们构建的大多数应用程序中，需要同时连接服务器，因此网络流量很大。像express.js和新的koajs(去掉了回调地狱)这样的框架使得在节点上工作更加容易。

如果您的应用程序主要使用Web API或其他IO通道，提供或获取用户界面，node.js对您来说可能是一个不错的选择，特别是如果您希望获得最大的可伸缩性，或者如果您生活中的主要语言是javascript(或各种类型的javascript发起者)。如果构建微服务，node.js也可以。node.js也适用于任何小型或简单的项目。

它的主要卖点是允许前端用户负责后端产品，而不是典型的分水岭。另一个合理的卖点是，如果你的员工是面向javascript的。

但是，如果没有强制模块化、可读性和流控制的可怕攻击，就无法扩展代码。不过，有些人喜欢这些黑客，尤其是来自事件驱动的JavaScript背景的黑客，他们看起来很熟悉或者很容易理解。

特别是，当您的应用程序需要执行同步流时，您会开始在半成熟的解决方案上出血，这些解决方案会大大降低开发过程的速度。如果您的应用程序中有计算密集型部分，请谨慎选择node.js。也许http://koajs.com/或者其他一些新奇的东西可以缓解那些原本棘手的问题，与我最初使用node.js或者写这个相比。

我可以在何处以及为何使用节点JS共享一些要点。

缺点：

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