Java + NodeJS 通过套接字进行通信：坏主意？
我喜欢 NodeJS 的一些功能，特别是 JQuerification、通过 socket.io 实现的 websocket 兼容性、视图和 CSS 引擎，但我无法将这些功能与 JSP 一起使用（当然还有异步调用）。至少，据我所知。所以我计划创建我的应用程序，后端将是 Java，前端将由 NodeJS 生成。前端表单将数据发送到 NodeJS，NodeJS 将通过 NodeJS 和 Java 后端之间的套接字连接将数据传递到 Java 后端。所以 NodeJS 基本上就像前端和 Java 后端之间的中间件。
这将是一个相当大的应用程序，我的计划看起来令人兴奋，但我会讨厌未来的自己走这条路吗？
这样做的好处是我可以拥有大量实时图表和仪表板，并增强与表单的交互。
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.
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
问题是你谈论的是通用平台。 Node.JS作为前端，JAVA作为后端。根据您的实际需求，这可能是美妙的，也可能是可怕的。
所以呢？人们会根据自己的感觉做出反应，具体取决于他们是否喜欢成熟的技术（或其他什么）。
2021 编辑
NodeJS 已经成熟了很多，即使大多数人喜欢的永远不会是 java（反之亦然）。我仍然建议在给定的上下文中坚持使用您选择的 3 层架构，并仅在需要时添加技术堆栈。我宁愿为数据科学等实际需求添加一个新的堆栈
炒作
人们考虑 Node.js 的主要原因是炒作。就像几年前的 XML 数据库一样。 XML 很酷，一切都必须使用 XML 来完成...如果您注意到的话，没有人再谈论 XML 数据库了。
因此，node.js 是新事物，您附近的博客谈到了它，并且与 NoSQL 数据库相结合，它一定是完美的选择。
异步 IO
然后是异步 IO 等理由。你知道？ POSIX 标准中的东西可能已经有 20 多年了。是的，就是您在学校 C 课程中学到的内容。顺便说一句，标准 JAVA API 也支持它。事实上，如果你听过 Node.js 创建者的话，你会发现这并不是一个新概念，而是只使用了异步库。大多数库都使用线程模型，不能用于异步。 Javascript 本身并不是一个目标，但 JS 中缺乏任何标准库是一个很好的起点，因为它可以避免普通人因包含错误的库而搞砸一切。这不是我说的。
关键是现在有一些图书馆，但其中有一些是由公司支持的。我们还没有到那里。同时，标准专业框架已经在需要时支持异步行为，例如长轮询 HTTP 请求。请参阅 Lift 框架，请参阅 Jetty 或 Tomcat 对 NIO 的支持。
就像 XML 数据库一样。现在像 Oracle 这样的专业数据库确实支持 XML。因此，如果您需要它，您可以保留标准的高性能数据库……而只能做到这一点的专用解决方案……好吧，甚至没有人记得它的名字。
Javascript
现在介绍 javascript。 Javascript 是一个大胆的选择……因为它缺乏库。你知道还缺少什么。这就是为什么你无论如何都需要一个java后端！但不仅如此...IDE对javascript的支持不好。自动完成？勉强工作。重构？你在开玩笑吧？多线程？没有。 Node.js 就像 Windows 3.1。它使用协作多任务处理。
结论
Node.js 很有趣，但还不成熟。你自己说过，你必须选择java，这样你才能做真正的事情，比如连接到数据库。该堆栈增加了另一层的复杂性。
要么你真的需要它，这也许是一个很好的妥协...要么你不需要它，你只是取悦自己...然后当你看到你花更多的时间做每件事时会恨自己...只是说你有 4 层堆栈（浏览器、Node.js、JAVA、DB）而不是 3 层。只是为了炒作和令人愉悦的理论。
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.
So what? People will respond with their feeling depending if they prefer mature technologies or not (or whatever).
2021 Edit
NodeJS has matured a lot even if most like it will never be java (and the reverse is also true). I would still advise to stick to a 3 tier architecture of your choice for a given context and add technological stacks only when needed. I'd rather add a new stack for reals need like data science
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.
So node.js is new, the blog near you speak about it, and coupled with a NoSQL database it must be the perfect fit.
Async 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.
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.
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.
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.
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.
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.
对我来说，这个计划本身听起来很合理。但根据我的经验，重要的是你的团队足够强大来承受它。在这种情况下，我不会走这条路，除非至少有两名优秀开发人员，一名负责后端，一名负责前端。否则，在处理如此多的框架/概念时，很容易迷失方向，并且什么也完成不了。
除此之外，我会注意使后端和前端之间的通信层容易可测试，这将排除套接字连接。如果您的性能要求允许，我会选择浏览器可探索的 REST 风格界面。这也使得以后可以以更少的工作量放弃“花哨的”前端，并在 JSP 或其他方式中实现某些内容。以防万一事情失控……
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 good devs, 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 easily testable, 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...
我个人觉得 NodeJs 很好用。不过，目前我还不会在生产环境中使用。特别是如果生产环境将处理关键数据。
我可能会等到，至少到 1.0 版本。
但如果您打算将其用于非关键应用程序，我会建议您使用它。 IT 总是好的开始，我想随着应用程序的增长，NodeJS 也会成熟。
再说一遍，这是我的个人意见。我只在我的业余项目中使用过 NodeJS，我从未在任何生产环境中使用过 NodeJs。
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.
I would probably wait until, it gets to version 1.0 at least.
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.
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.
如果您打算用 java 编写一些后端程序，为什么不全部用 java 来完成呢？
不确定你所说的“我喜欢 NodeJS 的一些功能，特别是 JQuerification、通过 socket.io 实现的 websocket 兼容性、视图和 css 引擎，但我无法将它们与 JSP 一起使用（当然还有异步调用）”是什么意思。
jquerification - 你的意思是jquery？你可以用jsp来做到这一点。
java中的websocket： http://caucho.com/resin-4.0/examples /websocket-java/index.xtp，虽然你也可以做comet服务器推送，因为它受servlet 3.0支持，
哪个css引擎不能与jsp一起使用？
异步调用是什么意思？
对我来说，node.js 更多的是关于你是否想要一个非阻塞服务器。如果这是要求，您也可以在 java 中做到这一点 - 大多数现代服务器都支持 NIO 配置。
If you are going to program some of the back end in java, why not do it all in 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)."
jquerification - you mean jquery? you can do that with 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
which css engine cannot be used with 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 本身并没有什么本质使它无法实现“实时图表和仪表板，并增强与表单的交互”。因为一项技术提供的“功能”对于实现您的业务目标实际上并不重要，所以将其添加到混合中通常是一个错误。你还提到了redis，我会把它放在同一条船上。 Node 和 Redis 都很酷（顺便说一句，能够说您想要添加到混合中的技术应该始终敲响警钟）并且具有合法的用例，但您所描述的似乎不是一个。如果 java 已经在完成你的繁重工作，那么添加异步“中间层”不会给你带来太多性能方面的好处。
如果您发布有关应用程序的特征、预期负载以及每个请求完成的处理工作的更多详细信息，您可能会获得有关最佳架构的更多有用的评论。祝你好运！
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 massively outweigh 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.
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!
我认为 Nodejs 非常适合我们处理 IO 处理工作的第一层。
第二层可以是像rabbitmq这样的代理。最后一层是用 Java 实现的业务逻辑。因此，我建议看看
我的方法，这是一种中心辐射架构：
https://github.com/farshad-nsh/nodejs-rabbitmq-Java
使用这种方法，您可以同时欣赏 Nodejs 和 Java 世界，并在分布式软件中充分利用两个世界的优点。
I think nodejs is great for first layer where we work on IO handling jobs.
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
my approach which is a kind of hub-spoke architecture:
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.