我正在慢慢学习，node.js并且有一个小项目要开始。该项目将有很多后台流程（从外部站点下载数据，解析CSV文件等）。
对我和节点而言，一个巨大的“胜利”是它在客户端和服务器上都使用了JavaScript。我在日常工作中使用Java和JavaScript进行编码，但在Ruby方面也相当出色。
但是，就像我说的那样，在任何地方都使用一种语言似乎很有吸引力，而JS似乎符合该要求。
但是，我在使用JS运行后台作业方面经验不足。Ruby在这方面似乎很出色。而且我不反对使用它。那么您对此打算100％JS的想法是什么？我意识到很大的项目需要自定义解决方案。我只是想知道是否值得付出努力。或者，我应该只坚持使用Ruby做那些琐事吗？
意见表示赞赏。
谢谢
Answers:
它在处理大量文件I / O方面特别强大，我希望它也能够处理大量网络通信。对于套接字驱动的应用程序，它似乎特别受欢迎。要记住的重要一点是，如果现有库（有很多）无法满足您的需求，那么您可能需要研究一些可以绑定到JS命令的C。您还可以生成其他Node进程，但我怀疑这样做很多会增加负担（我认为-可能是错误的-每个实例都有一个V8实例）。
JS是单线程和阻塞的，这意味着在函数调用完成之前，其他任何事情都无法执行。这是JS的理想功能，从根本上解决了所有线程和排队问题。JS不会阻止C / C ++东西在幕后以更多的多线程方式运行，因此JS的作用实际上是更多的体系结构/消息传递者。如果您要进行图像处理，则不要使用同步JavaScript命令来处理它，因为应用或服务器上的所有其他内容都将被阻止，直到完成为止。这个想法是您要求通过绑定的C / C ++功能来处理图像，然后在完成图像处理后响应“完成”事件。
这要求任何Node.js应用程序中的JS都具有大量事件和回调驱动，否则它的性能可能非常差。因此，您不会在Node中看到很多方法调用，这些方法调用不会传递给函数供以后使用。在Node中很快变得非常清楚的一件事是，如果您没有找到处理回调金字塔的方法，那么您将陷入一个丑陋的世界。例如
//event CBs are more DOM-style than Node style and this isn't built-in Node file I/O
//keeping it simple and quick since I'll just get Node stuff wrong from memory
file.get('someFile.txt', function(e){
e.fileObj.find('some snippet', function(e){
someFinalCallBackHandler( e.snippetLocations );
} );
} );
幸运的是，这里有很多工具和示例可以更好地处理此问题。大多数趋向于围绕promise机制，并简单地将一系列旨在链接到彼此的回调状态的函数链接到一个数组中，该数组可以在后台为您执行丑陋的金字塔工作。
就我个人而言，我非常热爱我们可以使JS处于较高水平，而C / C ++则更接近于chrome。这是终极的组合，它激发了我开始学习C的能力。在完成某些研究之前，请不要让缺少库的潜能吓到您。节点库的生产速度非常快，并且日趋成熟。如果您不做任何非常不寻常的赔率，那么有人可以解决。
与Rails的最大区别在于，JS永远不可能像现在一样出现在Rails上。我们倾向于编写代码以使其能够拥有，但是您希望它非常迅速，因此有很多因素可以使您垂涎三尺，并且直到最近几年，JS中的架构一直都是DIY。我称之为自由，但我意识到这对许多开发人员而言并不理想。
另外，因为您尝试在Mac以外的其他设备上进行安装，所以Node.js中永远不会出现“宝石”问题。客户端Web开发人员轻视依赖关系问题，而这正是许多Node核心的来源。如果在每个流行的平台上都无法在5分钟或更短的时间内立即解决问题，我们通常将其弄碎并扔掉。我尚未遇到一个流行的模块，该模块需要我做一些特殊的事情才能使其正常工作。包装系统，非常好。
但是要更明确/简洁地回答您的核心问题：后台流程是否很好？
是的，Node基本上是IS后台进程，可以通过事件和回调来驱动应用程序。
要注意的一个问题是在异步环境中处理大型文件时会发生什么：如果输入流（文件）比输出流（数据库）快，那么您将无法快速处理输入数据事件足够。这将使系统的某些部分（输出流或内存）不堪重负，或导致数据丢失。因此，异步处理数据可能会有些棘手。但是，正如我所链接的文章所解释的那样，暂停输入流的能力使以适合您情况的方式进行调节成为可能。
Node.js在IO方面表现出色。由于您的大多数线程都在SQL调用中处于阻塞状态，因此您不太可能发现有一天您的进程被阻塞了。
但是，node.js 在计算绑定方面确实很糟糕。当我听到“很多IO”时，我会想“是！去结点！”，但是当我听到“解析中”时，我会有些犹豫。除了人们不能正确地对多线程节点进行操作外，我不确定这是否是出于任何原因，但是到目前为止，我产品的所有计算绑定工作都发生在节点之外。
node.js中的多线程设置起来很棘手。默认情况下，所有内容都是单线程的，并且大多数代码都是在只能在一个线程下运行的前提下编写的。当然，您将需要使用域来防止一个线程上的错误导致整个应用程序崩溃。
还应注意，在某些企业功能中，节点可能会弱一些。例如，其日志库与Java的日志库不一样。当前，尚无一个甚至支持MDC的好的日志记录框架，这实际上意味着您需要做很多var logPrefix = userId + ": "事情。
我也从未运行过私有的npm存储库，根据您的代码是否专有，您可能需要其中之一。
如果您的后台进程可以按顺序运行，那可能会很好。在最后一个职位，我不得不为许多数据源编写许多预处理器，导出和转换实用程序。使用NodeJS轻而易举。
如果您不执行大量的计算绑定处理，短字符串的简单操作以及整数解析也没那么糟糕，那么如果您需要操作图像，它可能不是最好的工具（尽管有可调用的包装器和模块可以很好地工作）。
建议，坚持使用流的模块。这样可以更轻松地将处理过程传递给该特定步骤的模块。例如，如果您查看事件流在gulp-jade中用于gulp构建工具的方式，您将看到它的功能。
对于CSV，您可以使用node-csv，它非常适合为将记录管道传输到处理器流建立基础。
对于大型XML，您希望一次只做一条记录，那么我来看一下node-halfstreamxml，它使用SAX处理器读取XML流，并为每个节点引发事件。我会将其包装到一个读/写流中，以便您提高所需的匹配度。节点中的许多xml对象解析器都会尝试一次读取/解析整个xml，例如说100mb的xml变得庞大...其中halfstreamxml将作为流读取。
注意：还有其他处理器，例如xml-stream，它们将在下面使用expat（C库），这些处理器可以提供更高的性能，但在没有构建环境的情况下却具有较小的可移植性。
总的来说，使用它是一种真正的快乐。