将node.js服务器的javascript处理移动到客户端
我想就移动处理的实际意义提出一些意见，这些意见传统上是在服务器上完成的，而不是由客户端在node.js Web应用程序中处理。
示例案例研究：用户上传包含多年银行对帐单条目的CSV文件。 我们要parsing文件，对每个条目进行分类并计算每个类别的累积值，以便我们可以将新分类的语句存储在数据库中，并向用户显示支出分析。
这些条目按照说明中的匹配string进行分类。 有许多类别和许多条目，需要相当长的时间来处理。
在我们的node.js服务器中，我们可以愉快地释放事件循环，同时等待networking响应等，但是如果有任何数据处理或类似的处理，服务器将被阻止响应请求，这似乎是不可避免的。
传统上，CSV文件将被传递到服务器，服务器将处理，保存在数据库中，并发回处理的输出。
在我们的单线程node.js服务器中，这个处理由浏览器处理，输出显示并发送到服务器进行存储。 当然，客户端必须等待完成，但是他们的处理不会阻止服务器响应来自其他客户端的请求。
我很感兴趣，看看有没有人有使用这种模式build立应用程序的经验。
所以，问题是，是否有任何问题获取浏览器，而不是服务器处理，只要有可能，将阻止事件循环的任何处理？ 这是对node.js应用程序开发的一个好的/合理的/可行的方法吗？
虽然完全可能，但简单地将处理转移到客户端机器并不能解决基本问题。
现在，客户端的事件循环被阻止，从而阻止用户与浏览器交互。 浏览器往往检测到这个问题，并停止执行页面的脚本。 你的用户肯定会讨厌的东西。
在委托或分担工作量方面没有办法。 使用第二个进程（例如第二个节点实例）来执行数字运算服务器端还具有允许操作系统使用第二个CPU内核的额外好处。 理想情况下，您可以运行尽可能多的节点实例，因为您在服务器中具有CPU内核，并在两者之间平衡工作负载。 看看二极pipe模块对于如何在节点中实现多进程通信有一定的启发。
我不认为相信客户处理的数据是一个好主意。
相反，您应该考虑创build一个单独的进程侦听的工作队列，将CPU密集型任务从处理HTTP请求的node.js进程中分离出来。
我build议的数据stream量是：
- HTTP上传请求
- 应用程序服务器（将原始文件保存在工作进程可以访问的地方）
- 通知“csv”工作队列
- 工作进程上传的csv文件。