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

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 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.

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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!

Answer 6

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...