26

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.

Improve this question
5
  • 4
    The only reason not to do the backend in node.js is because you already have a backend in java. If you do not, do the entire thing in node.js Commented Jun 1, 2011 at 12:34
  • 3
    @Raynos: the two backends server different purposes. Node allows for some functionality that we could use, while Java provides robust data connectivity. Doing the entire thing in Node would be troublesome as Node doesn't fully support RDBMSs. Also, we could use redis for in-memory database cache. Googling is a stupid phrase, but hey, it communicates its purpose perfectly! Commented Jun 1, 2011 at 16:56
  • If your writing a new backend that doesnt communicate to existing databases you should properly take a look at mongo & couch. It's the noSQL vs SQL argument I won't bother to go into. Commented Jun 1, 2011 at 17:01
  • @Raynos: We cannot use a noSQL database as a primary data source, we will be needing features that don't exist in noSQL databases, heck, we can't even use MySQL. But we will use a noSQL database as a cache layer. So we will use both. Commented Jun 1, 2011 at 17:07
  • @Raynos, I don't think so, I agree with gAMBOOKa, there's no point in using something that is immature, and frankly, Java has withstood the test of time and while nodejs is solid, it's module ecosystem is not as mature as Java. Why reinvent the wheel in Nodejs when it's done for you in Java. Commented Mar 31, 2013 at 11:23

6 Answers 6

Reset to default
20
+50

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

8 Comments

Although what you say about node.js sounds a bit like a rant, I really agree that using it should be well justified by facts, not feelings. That's why I highlighted an escape route in my answer. Also: +1
I do not want to say node.js is bad. It is imature. I would not choose it. But I can understand some like it. Then I would try to stay simple. Use one backend (full node.js or full java), not two! Or justify you really can't do without both. For a generic advice, there are no justification for that.
In fact, Java does not support async IO. Java supports nonblocking IO. It's two different IO models. Async IO with respect to NIO is more simple, as you could provide callback which will be executed upon operation completes. But I agree with you. In the end node.js is not mature platform at all.
While I agree with most of what you said, I myself was concerned that I may be buying into the hype. But I see a lot of cool open source applications on github that don't have any java equivalents, such as these. Moreover, look at how simple it is to setup a https or socket server on nodejs, doing the same in Java is so painful.
so I'm back...there are things that nodejs does very well but overall, I find that there's no real advantage of choosing nodejs say established solutions like Java. Having said that it's like a swiss army knife, but not all of the components are reliable, often npm modules are abandoned, then picked up again, repeat, there's simply not enough maturity with npm modules and libraries for nodejs. Having said that it's only been a few years and nodejs is moving so fast. I wouldn't discount it yet but it's not ready to replace Java, far, far from it. It might not even get there.
|
9

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

Improve this answer

1 Comment

+1 for REST API being exposed by Java. You can then either connect to it directly or connect to a node server that calls the REST api for you.
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.

Improve this answer

6 Comments

I would also recommend not using node in production until at least v0.6
I've been using Node in production for several non critical projects, and personally have no concerns over it's reliability or raw capabilities. Frankly, i'm very impressed. The main concerns I would have for any project considering it's use is whether you are sufficiently TDD/BDD'ing your work to give you the confidence that what you are deploying is a robust as you will eventually desire it to be. The fact of learning Node tends towards knocking something together quickly, which as I have experienced is a far cry from the final working stable code.
To be fair to what Raynos said, Node has already broken backward compatibility going from 0.4 to 0.5(latest source). A lot of modules wouldn't install in 0.5, and I had to revert to 0.4
@gAMBOOKa that's because the odd version numbers are unstable / not compatible. I believe the node.js community will put a lot more effort into making the 0.6 api more stable (and frozen).
@Raynos: You are correct - "Node.js version numbers follow the C convention of major.midi.minor. Stable versions of Node.js have an even midi version number, development versions have an odd midi version number" - ofps.oreilly.com/titles/9781449398583/chapter_5.html
|
1

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.

Improve this answer

1 Comment

thinking about it, and looking around on the web, im not sure websockets is really a good idea right now - seems a little immature. server push using servlet 3.0, as I blogged at blog.maxant.co.uk/pebble/2011/06/05/1307299200000.html makes more sense to me.
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!

Improve this answer

Comments

0

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.

Improve this answer

1 Comment

format the answer, especially spacing and Hyperlink

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.