Java + NodeJS 通过套接字通信：坏主意？

Java + NodeJS communicating via socket: Bad Idea?

提问by HyderA

I like some features of NodeJS, particularly JQuerification, websocket compatibility via socket.io, view and css engines that I cannot use with JSP (and of course, asynchronous calls). At least, as far as I know. So I plan on creating my application where the backend will be Java, the front end will be generated by NodeJS. The front end forms will send data to NodeJS which will pass it on to the Java backend via socket connections between NodeJS and the Java backend. So NodeJS basically acts like a middleware between the front end and the Java backend.

我喜欢 NodeJS 的一些特性，特别是 JQuerification、通过 socket.io 的 websocket 兼容性、我不能与 JSP 一起使用的视图和 css 引擎（当然还有异步调用）。至少，据我所知。所以我计划创建我的应用程序，其中后端是 Java，前端将由 NodeJS 生成。前端表单将数据发送到 NodeJS，NodeJS 将通过 NodeJS 和 Java 后端之间的套接字连接将数据传递给 Java 后端。所以 NodeJS 基本上就像前端和 Java 后端之间的中间件。

This will be a pretty large application, and my plan looks exciting, but will I hate my future self for going down this route?

这将是一个相当大的应用程序，我的计划看起来很令人兴奋，但是我会因为走这条路而讨厌未来的自己吗？

The advantage I have with this is that I can have a lot of real-time charts and dashboards, and enhance interactions with forms.

我这样做的好处是我可以拥有大量实时图表和仪表板，并增强与表单的交互。

采纳答案by Nicolas Bousquet

Problem is that you speak about a generic platform. Node.JS as the front end, JAVA as backend. Depending on your real needs this can be marvellous or terrible.

问题是您谈论的是通用平台。Node.JS 作为前端，JAVA 作为后端。根据您的实际需求，这可能是奇妙的，也可能是可怕的。

So what? People will respond with their filling depending if they prefer mature technologies or not (or whatever).

所以呢？人们会根据他们是否喜欢成熟的技术（或其他什么）来做出回应。

Hype

炒作

The primary reason a person think about node.js is hype. Like XML database a few years ago. XML was cool and everything had to be done with XML... if you notice, nobody speaks anymore about XML databases.

一个人想到 node.js 的主要原因是炒作。像几年前的 XML 数据库。XML 很酷，一切都必须用 XML 来完成……如果您注意到了，没有人再谈论 XML 数据库了。

So node.js is new, the blog near you speak about it, and coupled with a NoSQL database it must be the perfect fit.

所以 node.js 是新的，你附近的博客会谈论它，再加上 NoSQL 数据库，它一定是最合适的。

Async IO

异步IO

Then comes the justifications like async IO. You know? The thing that is in POSIX standard maybe for more than 20 years. Yes, what you learned at school in your C course. Incidentally, the standard JAVA API supports it too. In fact, if you listen to node.js creator, this is not the concept that is new but using only async libraries. Most libraries out there use a thread model and can't be used for async. Javascript was not a goal per se, but the lack of any standard library in JS was a good start point as it would avoid that the average joe mess up everything by including the wrong library. This not me that said that.

然后是异步 IO 之类的理由。你懂？POSIX 标准中的东西可能已经有 20 多年了。是的，你在学校的 C 课程中学到了什么。顺便提一下，标准的 JAVA API 也支持它。事实上，如果你听 node.js creator，这不是新概念，而是仅使用异步库。大多数库都使用线程模型，不能用于异步。Javascript 本身并不是一个目标，但 JS 中缺少任何标准库是一个很好的起点，因为它可以避免普通人通过包含错误的库来搞砸一切。这不是我说的。

The point is there are now some libraries, but a few if any of backed by a company. We are still not there. And at the same time, the standard professional framework already support async behaviour when needed like long polling HTTP request. See Lift framework, see Jetty or Tomcat support for NIO.

关键是现在有一些图书馆，但有一些是由公司支持的。我们还没到。同时，标准的专业框架已经在需要时支持异步行为，例如长轮询 HTTP 请求。参见 Lift 框架，参见 Jetty 或 Tomcat 对 NIO 的支持。

Like the XML database. Now professional databases like Oracle do support XML. So in case you need it, you can keep your standard high-performance database... And the specialized solution that can only do that... Well nobody remembers even its name.

就像 XML 数据库一样。现在像 Oracle 这样的专业数据库确实支持 XML。因此，如果您需要它，您可以保留标准的高性能数据库……而专门的解决方案只能做到这一点……好吧，没有人记得它的名字。

Javascript

Javascript

Now for javascript. Javascript was a bold choice... For its lack of libraries. You know what is still lacking. That why you need a java backend anyway! But not only that... IDE support for javascript is not good. Autocompletion? Barely work. Refactoring? Are you kidding? Multithreading? Nope. node.js is like windows 3.1. It uses cooperative multitasking.

现在是 javascript。Javascript 是一个大胆的选择……因为它缺少库。你知道还缺少什么。这就是为什么你需要一个 Java 后端的原因！但不仅如此...... IDE 对 javascript 的支持并不好。自动完成？勉强工作。重构？你在开玩笑吗？多线程？不。node.js 就像 windows 3.1。它使用协作式多任务处理。

Conclusion

结论

Node.js is fun, but it is immature. You said it yourself, you have to pick java so you can do the real stuff like connecting to the database. This stack adds complexity with another layer.

Node.js 很有趣，但它还不成熟。你自己说过，你必须选择java，这样你才能做真正的事情，比如连接到数据库。此堆栈增加了另一层的复杂性。

Either you really need it and that's maybe a good compromise... either you don't need it and you just please yourself... and hate yourself later when you see you spend more time to do everything... just to say you have a 4 layer stack (browser, Node.js, JAVA, DB) instead of 3. Just for the hype and the pleasing theory.

要么你真的需要它，这可能是一个很好的妥协......要么你不需要它，你只是取悦自己......然后当你看到你花更多时间做每件事时讨厌自己......只是说你有一个 4 层堆栈（浏览器、Node.js、JAVA、DB）而不是 3。只是为了炒作和令人愉悦的理论。

回答by Waldheinz

To me the plan sounds reasonable per se. But from my experience it is important that your team is strong enough to bear it. In this case I would not go this route unless there are at least two gooddevs, one for the back-end part and one for the front-end. Otherwise it's just too easy to get lost when dealing with so many frameworks / concepts, and nothing gets finished.

对我来说，这个计划本身听起来很合理。但根据我的经验，重要的是你的团队足够强大来承受。在这种情况下，除非至少有两个优秀的开发人员，否则我不会走这条路，一个是后端，一个是前端。否则在处理这么多框架/概念时很容易迷失方向，什么都没有完成。

Besides that I'd take care to make the communication layer between back- and front-end easilytestable, which would rule out socket connections. If your performance requirements allow it, I'd opt for a browser-explorable REST style interface. This would also make it possible to drop the "fancy" front-end with reduced effort later on, and implement something in JSP or whatever. Just in case it gets out of hand...

除此之外，我会注意使后端和前端之间的通信层易于测试，这将排除套接字连接。如果您的性能要求允许，我会选择浏览器可探索的 REST 风格界面。这也可以在以后以减少的工作量放弃“花哨的”前端，并在 JSP 或其他任何东西中实现一些东西。以防万一它失控......

回答by kensen john

I personally feel that NodeJs is nice to do some kicking around with. However I wouldn't put to use in a production environment as of now. Especially if the the production environment would be handling critical data.

我个人觉得 NodeJs 很好用。但是，到目前为止，我不会在生产环境中使用。特别是如果生产环境将处理关键数据。

I would probably wait until, it gets to version 1.0 at least.

我可能会等到它至少达到 1.0 版。

But if you are planning on using it for non critical applications I would say go for it. IT is always good to start, and I guess as your application grows NodeJS will mature as well.

但是如果你打算将它用于非关键应用程序，我会说去吧。开始总是好的，我猜随着您的应用程序的增长，NodeJS 也会成熟。

Then again this is my personal opinion. I have only used NodeJS in my side projects, I have never used NodeJs in any production environment.

再说一次，这是我个人的意见。我只在我的业余项目中使用过 NodeJS，我从未在任何生产环境中使用过 NodeJ。

回答by Ant Kutschera

If you are going to program some of the back end in java, why not do it all in java?

如果您打算用 java 编写一些后端程序，为什么不全部用 java 编写呢？

Not sure what you mean by "I like some features of NodeJS, particularly JQuerification, websocket compatibility via socket.io, view and css engines that I cannot use with JSP (and of course, asynchronous calls)."

不确定“我喜欢 NodeJS 的某些功能，尤其是 JQuerification、通过 socket.io 的 websocket 兼容性、我不能与 JSP 一起使用的视图和 css 引擎（当然还有异步调用）”的意思。”

jquerification - you mean jquery? you can do that with jsp.

jquerification - 你的意思是jquery？你可以用jsp做到这一点。

websockets in java: http://caucho.com/resin-4.0/examples/websocket-java/index.xtp, although you might as well do comet server push as its supported with servlet 3.0

java中的websockets：http: //caucho.com/resin-4.0/examples/websocket-java/index.xtp，虽然你也可以做彗星服务器推送，因为它支持servlet 3.0

which css engine cannot be used with jsp?

哪个css引擎不能与jsp一起使用？

what do you mean by asynchronous calls?

异步调用是什么意思？

for me, node.js is more about whether you want a non-blocking server. if that is the requirement, you can do that in java too - most modern server support configuring for NIO.

对我来说，node.js 更多的是关于你是否想要一个非阻塞服务器。如果这是要求，您也可以在 Java 中执行此操作 - 大多数现代服务器支持为 NIO 配置。

回答by jkraybill

Are you going to be hiring developers to work on your project, or is it solo? If you plan on ever scaling a development team, I've found that minimizing the total number of discrete technologies in your product usually has benefits in team-scaling that massivelyoutweigh performance and/or productivity advantages of adding that technology. Every technology you add makes it that much harder to hire someone who's an expert in all of them, and greatly increases the chances that when you hire someone who's not an expert in all of them, they screw something up because they've got a lot to learn.

您是要雇用开发人员来处理您的项目，还是单独工作？如果您计划扩展开发团队，我发现最大限度地减少产品中离散技术的总数通常对团队扩展有好处，这大大超过了添加该技术的性能和/或生产力优势。你添加的每一项技术都使得聘请一位精通所有技术的人变得更加困难，并且大大增加了当你雇佣一个不精通所有技术的人时，他们把事情搞砸的可能性，因为他们有很多学习。

Your arguments for using node.js honestly seem pretty weak; there is nothing intrinsic about Java that makes it unable to do "real-time charts and dashboards, and enhance interactions with forms." Adding a technology to the mix because it offers "features" that aren't actually essential to achieve your business goals is often a mistake. You also mention redis, which I would put in the same boat. Both node and redis are cool (being able to say that about a technology you want to add to your mix should always sound warning bells, btw) and have legitimate use cases, but what you've described doesn't seem to be one. If java is already doing your heavy lifting, adding an asynchronous "middle tier" isn't going to buy you much in terms of performance.

老实说，您使用 node.js 的论点似乎很薄弱；Java 没有任何内在的东西使它无法做“实时图表和仪表板，并增强与表单的交互”。将一项技术添加到组合中，因为它提供的“功能”对于实现您的业务目标实际上并不重要，这通常是一个错误。你还提到了 redis，我会把它放在同一条船上。node 和 redis 都很酷（能够说你想添加到你的组合中的技术应该总是响起警告铃声，顺便说一句）并且有合法的用例，但你所描述的似乎不是一个。如果 java 已经在做你的繁重工作，那么添加异步“中间层”不会在性能方面给你带来太多好处。

If you post more details about the characteristics of your application, expected load, and processing work that's done per request, you will probably get more helpful comments about the best architecture. Good luck to you!

如果您发布有关应用程序特征、预期负载和每个请求完成的处理工作的更多详细信息，您可能会获得更多关于最佳架构的有用评论。祝你好运！

回答by farshad-nsh

I think nodejs is great for first layer where we work on IO handling jobs.

我认为 nodejs 非常适合我们处理 IO 处理作业的第一层。

The second layer could be a broker like rabbitmq. The last layer is your business logic which is implemented in Java. So I suggest to have a look at

第二层可以是像rabbitmq这样的代理。最后一层是您的业务逻辑，它是用 Java 实现的。所以我建议看看

my approach which is a kind of hub-spoke architecture:

我的方法是一种中心辐射架构：

https://github.com/farshad-nsh/nodejs-rabbitmq-Java

https://github.com/farshad-nsh/nodejs-rabbitmq-Java

Using this approach you can appreciate nodejs and java world simultaneously and utilize the bests of both worlds in a distributed software.

使用这种方法，您可以同时欣赏 nodejs 和 java 世界，并在分布式软件中利用这两个世界的优点。