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

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