What risks are there to using Node.js with Java EE?

Question

We are developing a B2B web application in which we are using(suggested by seniors) two servers. One is Node.js (to serve all the request related html & static content) and the other is Tomcat to implement REST services for serving back-end.

I think it will add an unnecessary overhead if we consider the following:

• Need to maintain two servers.
• Security(Session management/View Management).
• Resources (need Node.js developers as well as Java Developers).
• Deployment and Configurations.

Am I wrong to consider these risks with such an Architectural decision? What would be the potential rationale for deciding on using two completely different frameworks like this where there is functionality and feature overlap?

Answer 1

If you're using microservices then it should not matter which microservice is written using which technology.

Having two languages and runtimes for two parts of the systems can have a disadvantage of having to configure two types of deployments but it shouldn't be complicated if done well.

On the other hand this seems like using the right toll for the job. If you need two tools then you should use two tools instead of using one tool just for the sake of minimizing the number of tools used. Note that the right tool for the job is not only an abstract fitness for a particular purpose but also other factors need to be taken into account like people's experience, tools already written, available code, libraries, architecture etc.

Also having two separate systems will enforce clear API boundaries. This can help reduce leaky abstractions and tight coupling so at the end of the day it may not be such a bad idea that it may sound like at the beginning.

Keep in mind that needing Node developers and Java developers doesn't mean needing more resources. You don't think that either of those gropus of developers could create both parts of the system in the same time as one of those parts, do you?

Answer 2

I not a fan of the 'best tool for the job' philosophy. But its a big picture problem rather than a technical one.

Generally recruiters like to bundle devs into skill sets/stacks. Java, Microsoft, JS. If you stick with a single stack its easy to recruit new devs. Everyone knows the playing field.

Its not that those devs are incapable of picking up a random stack and making it work, It's just the way the world works.

Companies want to employ people who have done the exact same thing before somewhere else. If you start using random technologies you fall off the easy well known path and make your life harder.

Also on a technical side, you want to be able to reuse your low level components. Logging, db access, cloud api wrappers etc. If you stick to a single stack you can just have one set of these.

Of course implicit in this idea is that you chosen stack does offer a workable solution to your problem. eg If you want a widget on an android phone, your going to have to do it in xml/java