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?

  • Why is it got down voted?plz add comments.
    – smali
    Apr 12, 2017 at 9:35
  • 1
    It might be useful to have two servers / endpoints for different responsibilities, but I'm sceptical about combining such different technologies though.
    – Randy
    Apr 12, 2017 at 9:36
  • 3
    A better question to ask would be "does using Node.js with Java EE most effectively fulfill our software requirements?" Apr 12, 2017 at 13:15
  • @RobertHarvey COnsidering that probably one of the requirment is the maintenability of the product, which obviously tend to be harder if you stack more technologies.
    – Walfrat
    Apr 14, 2017 at 9:42

2 Answers 2


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?

  • Okay, but we are not using micro-service architecture and yes it doesn't mean that we need more resources but finding experts and training on two technologies will be little time consuming for a small company.
    – smali
    Apr 12, 2017 at 10:39
  • Limiting the system only to the current and specific knowledge of the team, is synonym of failing project. It's just matter of time to know why.
    – Laiv
    Apr 17, 2017 at 19:15

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

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.