Is there any scenario when we should go for NodeJS REST API instead of Java REST API?

We can build REST api using Java and we can build using NodeJS too. Is there any scenario when we should go for NodeJS REST API instead of Java REST API?
Thanks

That's an implementation decision that is not affected (and does not affect) by the overall design. If you already have Java REST code (and developers familiar with that), it may make sense to keep using that. Similarly with Node.js.

Thanks. In case, it is not the case of existing REST APIs and the team has equally good skills for both Java and NodeJS then how should it be decided in such a case?

There are other factors you might want to consider. For example, node.js is its own separate server, whereas JAX-RS runs inside a servlet container. If you already have servlet containers running anyway, you may be able to use those to host the REST services as well. Or at the least you can leverage your knowledge of hosting servlet containers, if it has been decided that the REST services need their own server.

Thanks. It will be like diverting from the question but does creating Node.js REST API come under serverless programming?

No. Node.js is very much a server, just like any servlet container.

Thank You

Monica Shiralkar wrote:... does creating Node.js REST API come under serverless programming?

Do you mean serverless computing - where the application is executed in a (third-party) cloud environment?

Yes I meant serverless computing. I have seen that in cloud. But node.js definitely has server.

In that context, the server refers to the computing platform, not the role in a client-server architecture.

Node JS is offering javascript coding, so it's quit faster than Java while execution. Node js is better in performance while it comes to handle rest apis comaprig with Java.

But there are some limitations with Node JS as well as it is built for small and less complex applications only. But Java built for large scale and highly complex applications too.

So now is up to you that how Is your application made for and used for. Hope it will be useful to you.

SunilK Chauhan wrote:Node JS is offering javascript coding, so it's quit faster than Java while execution. Node js is better in performance while it comes to handle rest apis comaprig with Java.

Please cite your sources for this claim.

But there are some limitations with Node JS as well as it is built for small and less complex applications only.

Similar, please.

Please check website : https://www.educba.com/java-vs-node-js/

And checkout Key difference section for more info.

A web site with banners advertising training for technology X is hardly an unbiased source of information about X.

I, too, would question claims that Node.js is generally faster than Java, although it may well be in specific circumstances.

Apart form the given points, Node js is also quit better in memory efficiency. Package size of Node js also smaller than Java.

SunilK Chauhan wrote:Apart form the given points, Node js is also quit better in memory efficiency. Package size of Node js also smaller than Java.

I am skeptical about that, having seen the horrific package load that a simple Node Express app demands. Java isn't exactly modest, but I think it can still do better than that.

Doesn't matter, memory's practically free these days.

I use NodeJS when I need a quick-and-dirty app where performance under load and security are not issues. For industrial apps, I use Java. Both have their places.

Tim Holloway wrote:I use NodeJS when I need a quick-and-dirty app where performance under load and security are not issues. For industrial apps, I use Java. Both have their places.

That quick and dirty may imply some background, that systems built with Node.js indeed are that. I recently started my MSc course, and having a module called Component Based Software Development, basically we use Node.js mainly there, and I didn't get an impression that we go dirty route, altough I see an ability to go down that way what you are saying.

So perhaps would be more correct to say, that quite a few misuse this technology?

Note: worth noting, that my knowledge of Node.js is fairly limited as of now.

For me, quick-and-dirty is a bit redundant, since computers pretty much conspire to ensure that anything that can be done in a hurry is littered with caltrops. But I still prefer the phrase, since it contains an explicit reminder that everything has its price.

Again, speaking for myself, "quick-and-dirty" implies that minimizing the time-to-delivery is the priority, not robustness or security. Any loosely-typed language (such as javascript) gets automatic dirty-points because they've forced the choice between careful vetting of data usage onto the developer, who is then free not to do so, especially when the boss is breathing down "Git 'er Dun!" Java, being strongly-typed, does that checking automatically. At the cost, of course, of having to code more carefully and think further ahead.

One of the most commonly-used micro-services on my own LAN is a NodeJS program. I have a neat little device I built hanging on my kitchen wall near the door. It has an e-ink display and builtin WiFi node. Once a minute, it sends out a ReST request to an in-house server to get the time of day in minutes (e-ink is best when the display doesn't change too often). That server also runs a cron task at 4am each morning to the local National Weather Service node. Well, actually, it's national, but for my own locality. That task reads weather predictions and squashes them down to a 1-word verdict for the workday, which is then saved and repeated as needed. Also, the same micro-server contacts my home automation server to get the current outside temperature and the message-of-the-day.

All of this is a fairly small NodeJS aggregator. It doesn't need speed, it's not accessible outside the LAN - and doesn't contain anything critical anyway. And it wasn't worth spending several days making a Java webapp out of it. I can live with the relative fragility of a JavaScript app here since even when it does occasionally go pong, nothing worrisome happens.

NodeJS could be used in the following scenarios

Deployment Time needs to be minimised because the NodeJS application is a server itself.

You need a lot of work done in client side scripting. Choosing a Mean Stack deployment would then make sense.

Security is not a concern.

SMB market apps

No dependence on ORM.

Kanika Sud wrote:NodeJS could be used in the following scenarios

Deployment Time needs to be minimised because the NodeJS application is a server itself.

You need a lot of work done in client side scripting. Choosing a Mean Stack deployment would then make sense.

Security is not a concern.

SMB market apps

No dependence on ORM.

NodeJS is neither more nor less suited for client-side scripting than Java is. In fact, JavaServer Faces has extensive client-side JavaScript under the hood, in addition to support of traditional HTML client-side functions.

Deployment time for a Tomcat app is minimal. Most of the work is in building the app. Deployment of a Spring Boot server app is even faster.

No dependence on ORM? https://sequelize.readthedocs.io/en/v3/

Tim Holloway wrote:

NodeJS is neither more nor less suited for client-side scripting than Java is. In fact, JavaServer Faces has extensive client-side JavaScript under the hood, in addition to support of traditional HTML client-side functions.

Deployment time for a Tomcat app is minimal. Most of the work is in building the app. Deployment of a Spring Boot server app is even faster.

No dependence on ORM? https://sequelize.readthedocs.io/en/v3/

In my 11 years of work experience, I've found that technology choices are governed by use cases.
Tomcat isn't that minimal when you're creating say, a PDF converter.
I do know about Sequelize. Like mentioned by someone above, many developers prefer to exploit NodeJs without using structure and good technique.

I might be wrong though. It's open to discussion.

All that's required to install Tomcat is to download, unzip, and run the startup script.

All that's required to deploy most Tomcat webapps is to drop them into the TOMCAT_HOME/webapps directory. Although a complex app might require adding a JDBC driver jar to Tomcat and a deployment descriptor file (context.xml). Spring ORM does need 2 extra libraries in Tomcat, last time I checked. After that, you're good for almost anything.

I think you've confused Tomcat development with JEE webapp development. Developing a JEE webapp is a lot of work, and that's basically what we've been discussing here. The idea that some projects aren't worth the effort to make Java webapps and some are. Anything that's really heavy on database operations I'd probably use JEE and an ORM. Creating PDF's I probably would, since there are good Java resources for that.

On the other hand, as I said, I have apps that simply pull a few data items from various other sources and present them as a unit to remote devices and that wasn't worth the effort of coding a JEE webapp. So I didn't.

I would contend that Spring Boot is the best of both worlds, but it probably is the most difficult to learn.  NodeJS is a memory hog, and that matters if you host on something like a relatively cheap VPS for yourself.  It would not matter if you have your own equipment or LAN.  Spring Boot also supports JAX-RS.

NodeJS does have security issues you can nullify with Spring Boot.  You can even use a code obfuscator to protect your work with Spring Boot, where as the tools available for doing that on NodeJS are not as effective over all.

Java in general has a relatively larger initial startup foot print than JavaScript, but JavaScript requires that things stay in memory constantly to run more quickly.  You can run certain open source JVMs that keep things in memory constantly and reach the same performance levels, but in my opinion, the performance cost is not worth it because of Java's scaling ability.

As said, JavaScript handles small things more efficiently by design, and Java scales better.  I would not suggest NodeJS for serving a database that sits on more than one server, even in the Cloud.  For everything else, it works pretty well.  I just wouldn't run sensitive stuff, like credit card info, through it in my meager opinion, but that personally takes a VPS host's security in mind.

Architecturally speaking, one difference between NodeJS and JEE is Separation of Concerns. In JEE, the server and the application are two distinct entities, to the point that in many cases the same webapp written for WebSphere can run under Tomcat and vice versa. In NodeJs, you start off with a template appserver and you start adding user code and third-party libraries on top of it so that the lines of separation are blurred. And yes, aside from the fact that this can make diagnosis and maintenance harder as you scale up, the lack of clear dividing walls is how you end up with exploits.

I've built some Java webapps that were pretty large, but I always felt like I could justify the components that made it large. Node's dependencies make stuff large, but since the dependencies may be required by the app or by the server or both, they're just harder to justify. Especially in a quick-and-dirty app, which has always implied "small" and "few dependencies" to me. I might feel more comfortable if I lived full-time in the Node world, but as an occasional visitor, it does seem over-complex.

How about Spring Boot? It's like NodeJS in that the app and server are one, but at the same time it's different, because what you really have is still a separation between the webapp and the webapp server. It's just not as visible because Spring Boot wraps both of them together.

And of course, since you need to know Spring, Spring Boot, JEE and Tomcat to fully understand everything, it's a lot more demanding.

Aside from that, historically I'd not recommend Spring Boot to run large-scale server farms, I'd look at clusters running stand-alone webapp servers. But I'm willing to consider it as an option if you're running them as individual containers (or Kubernetes pods) operating as ReST servers. In a case like that, where you'd probably build a container holding appserver and deployed app, you might as well do it using only Java tools (Spring Boot) as to expect less-expert developers to know how to do webapps and how to build something like a Docker image.

With a standard Spring Boot setup, I agree that it does not by default provide all the necessary tools for a server farm.  There are library add-ons designed for Spring and specifically Boot itself meant to interface with another server software that will manage the server farm for you, especially a group meant for databases.  However, Reactor is suppose to allow management of a farm itself from a single server a lot more passable.  To my understanding, NodeJS has an implementation in development that mixes Reactor like Spring does.

When speaking of a farm designed for databases only, some makers offer their own server product as a front-facing interface that does the heavy-lifting for you in that regard.  I still understand generally wanting a cluster for massive amounts of traffic, though.  The most recent Hibernate designed for Spring reflects this in a measure, but most of the options meant for server farms do not come as default options.  You have to enable a specific one you want, so that Spring Boot will look for the libraries you need for the ORM to that product, whether open source or not.  Having said that, I haven't implemented for a cluster yet.

Just asking,

Can we sort this out by listing out reasons for the hype for NodeJS in REST APIs and then we can independently list out scenarios for both NodeJS and Java... When a REST API should use what?

Like a conclusive statement of sorts

NodeJS is neither more nor less suited for client-side scripting than Java is. In fact, JavaServer Faces has extensive client-side JavaScript under the hood, in addition to support of traditional HTML client-side functions.

Deployment time for a Tomcat app is minimal. Most of the work is in building the app. Deployment of a Spring Boot server app is even faster.

I am myself surprised how eager the next gen developers are for NodeJS. Could the reason be a "write everything in JavaScript approach?"

Also, for the Spring Boot, I do agree with someone who talked about the learning curve.

Even though I am not a NodeJS fan, I found it very easy to catch up with.

Mostly it got popular because of its coupling with Angular and Mongo.

Please also throw some light on micro instances.

Now, a server being an application itself... As opposed to one one server handling many applications. How do you think that differs or alters performance? Would love to hear technical expertise in this regard too.

Let's say you have many apps which are centrally handled... Which would you prefer?

Kanika Sud wrote:
I am myself surprised how eager the next gen developers are for NodeJS. Could the reason be a "write everything in JavaScript approach?"

I would say so. That's the same reason  why ORMs such as JPA have become so popular. Instead of requiring fluency in multiple languages (Java and SQL), you reduce everything to just Java. Javascript is especially attractive because for webapps, you're frequently expecting JavaScript expertise for the client-side logic.

And because it makes you "productive" because you don't have to do all the design-in-advance and project initialization is a single command with Node.

On the other hand, JavaScript is a horrible language with neither discipline nor consistency - I think there are 5 different ways for a string not to be a string in JS. And these "productive" platforms don't scale well as the codebase gets more complex. I mentioned recently somewhere on the Ranch about major SAAS products having to resort to creative solutions because they were committed to quick-and-dirty code that was becoming impossible to maintain at scale.

Kanika Sud wrote:Please also throw some light on micro instances.

Now, a server being an application itself... As opposed to one one server handling many applications. How do you think that differs or alters performance? Would love to hear technical expertise in this regard too.

Let's say you have many apps which are centrally handled... Which would you prefer?

Historically, it would be one server hosting many apps. But not so much anymore, for 2 reasons.

First, there are lighter-weight servers, so the overhead of running multiple server instances isn't as high. Tomcat may not have the full stack like WebSphere or WildFly do, but it's smaller and starts faster and there are many cases where you either don't need the full JEE stack or can afford alternatives - most notably, things like JSF and JPA are built into full-stack servers, but can be supported via app-local libraries in Tomcat and jetty.

NodeJS doesn't separate the server code from the app code, so there's an even greater potential for sharing resources between the two - the positive side of what I mentioned earlier.

If the app is designed using ReST, you also don't have the issues that come from trying to cluster servers. If you need more processing power, you can just bring more processors online. This is very easy when using containers and an elastic manager such as Kubernetes.

Which brings me to the second reason. Hardware is extremely cheap these days. It's almost to the point that the cost of the electricity to run it is more than the hardware itself. So unlike ancient times when you had to upgrade or replace a million-dollar mainframe, you can just slot in more CPUs.

Tim Holloway wrote:And because it makes you "productive"...

I've got better understanding now what you meant by quick and dirty. Now that I used JS along with Node.js for a while I got more understanding about its "productivity" on server side. Except that we have been advised to use 3rd party libraries to do syntax checking during file save, as well as to use some 3rd party library for html templating, as well as 3rd party library to ease up that and that... During the time lecturer prepared the slides and the time I've put my hands-on, one of those libraries (not module, full library) were deprecated and fully replaced by another. Unlucky I didn't figure out that earlier, so I went into my very first migration task. So I'm really unsure what the word "productive" means in the context of scripting languages. quick and dirty that's probably exactly what it means. Because if to do things with some safety policy, a lot of a heck need to get involved. What you get in Java out of the box for compile-time checking, you are up for using 3rd party libraries in scripting languages just to save your time really and headache. But then you fall into the trap of libraries lifecycle's which can be shorter than milk's in some cases it seems.

I read that Node.js creatoor working on different tool called Deno, which is meant to address Node.js security concerns, of course with a price of incompatibility. All feels very fragile to me in this area. Or at least at a very fast changing ratio.

Actually, Node is one of the better platforms. At least you have a manifest that indicates specific versions of included modules. In the good old days, you have to take whatever was current.

Java is superior on that, however, since from the root up it was designed to deal with apps whose lifespan rivaled COBOL programs. It has built-in deprecation mechanisms and build frameworks such as Maven that encourage fixed version selections to make app-building repeatable any place and time. Not everyone has managed this process responsible, so I have had occasional failures, and of course "version hell" breaks out when you start upgrading modules with dependencies", but overall, it's much more robust.

Tim Holloway wrote:Actually, Node is one of the better platforms.

Do you also want to comment on asynchronous programming and event loop, while we are looking at both JAVA and Node.js? Was looking for a more conclusive explanation. I mean I think the first and last reason is the asynchronous handling then, no?

I'm only dimly aware of the multi-threading of JavaScript and only by rumour of Node. But the standard operation for any TCP/IP service - including webservers - is that there's a central Listener that waits for incoming connections and when connection is made, then the new connection gets handed off to a processor thread. So in other words, expect asynchronous processing as the rule, not the exception. Certainly in Java that's the case and it's why Servlets don't run as processes themselves. It's much more efficient to have a general request pool that gets a Connection and  a Servlet (or JSP) than to have lots of per-servlet threads. Especially if you have thousands of users.

The thing to watch out for in either case is when a process wants to modify resources shared with other processes. That's something you want as little of as is possible. In JEE that means keeping most variables in Request or Session scope. In Node, I assume something similar exists, but I'm mostly doing full ReST stuff in Node, so I don't have anything in Session scope and Request-scope data is easily found from the Request object.

If you do end up sharing resources across threads, Java offers synchronized access. JavaScript has something similar but it's been too long ago for me to remember what.