Java + NodeJS communicating via socket: Bad Idea?

Question

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, asynchron

Answer 1

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!