What are the ideal use scenarios for Node.js?

Asked

Viewed 3,815 times

15

The theme is broad, but I’ll try to focus on what I really need to understand.

Lately I’ve been studying Node.js, and I’ve been surprised by the tool, in the comparative that I’ve seen, seems to be a mature and effective tool.

In many places, I see recommendations for use when the focus of the application is scalability, because Node is Single Thread.

But I am developing a relatively large application, at least features. and I am in doubt which tool to use in the Back-End.

Basically the application will have:

  • Webservice Restful in Backend (Java or Node.js).
  • Relational Database(Postgres);
  • Front-End with Angularjs(Web) and Android(Ionic) for Mobile(Haven’t decided yet).

My doubts are as follows:

  • In which scenarios Node.js is recommended to use it, and which scenarios should I avoid?
  • In this model above, Node.js fits or would be better to use another tool in the Back-End?
  • Node.js was made to work with sequential requests (make a request and wait for the return in the same "transaction")?

  • As Node.js behaves with Relational database(postgres), the above system will probably have many queries to Bd, this scenario is compatible with the tool ?

  • 1

    uso quando quiser alta performance e um consumo menor de memória no servidor depends on comparison with what, right? : ) People make some claims out there that are so weird, it’s not the technology that makes the difference, it’s the way they use.

  • I agree with @bigown . I use Node.js daily, it works stable mto. Personally I find the question too broad.

  • @Sergio there do not know, I do not know enough to judge if it is wide. It seems a little.

  • Yes, I agree, I think the placement was awkward, but I read in several places, if not exactly, very similar to the phrase. regarding the approach, what I could improve to not leave the question so wide?

  • The only question that is valid after reading would be the following: What are the best practices for programming a web server? The question that has not been asked.

  • @Brunocosta I think it runs a little outside the context of my question, briefly I wanted to understand if Node.js applies to the software model above, if its use is recommended.

Show 1 more comment

1 answer

14


I’m sorry, but to give a full answer I’m gonna have to get away a little bit from what’s being asked.

Your question recently refers only to one of the problems that servers web have to answer. This problem is the Throughput (requests answered per time unit (minutes)).

Remember that the processing (code instructions) is always done in a thread. And this remains true when you’re programming a web server, whose responsibility is as follows::

  • Receive orders
  • Process the order
  • Send the answer

One peculiarity is that much of this processing is I/O processing (receive requests and send replies). And while the I/O processing request is not solved the CPU can continue to process the remaining orders.

But this can only happen if the requests for I/O are made asynchronously.

Let’s illustrate what happens in a synchronous and signed I/O request, with 2 read requests to file A and B and let’s imagine that we want to look for a certain word in both files.

inserir a descrição da imagem aqui

As you can see, if the processing is done asynchronously, the total time will be shorter. In fact the total time will correspond to the following:

Time = Max(Processing I/O A, Processing I/O B) + Word Search in A + Word Search in B

Now that we know why asynchronous I/O processing is beneficial we can present good practices to be followed at all times but also when we are developing a web server.

  • All I/O requests are made asynchronously.
  • In general a thread is never locked waiting for I/O.

Now if whoever is reading this answer knows what I have explained and knows the Node, knows that a large enough investment has been made to provide Apis that process I/O orders asynchronously. Still, in reading files, for example, it is possible to do synchronously.

And this is what allows the Node to have such a large throughput "just" with a thread. But in the end it is also the programmer’s job to ensure that there are no I/O requests to be made synchronously.

If this same practice is applied with other technologies NEVER it will be possible that only 1 thread can have a higher throughput of for example 4 threads on a 4-color CPU. There may be many other reasons why one or other technique is better in a given scenario, and yet Node can perform better than another that is multi-threaded.

These reasons may be, but are not limited to:

  • Implementation of virtual machines quite different
  • Implementation of widely available Apis
  • Interpreted language vs doubly compiled language
  • ...

But this is not at all a limiting factor for the Node. Because the same effect can be achieved by launching 4 processes from the same server and designating them in different colors. This way Node will also have the ability to use all the colors of a processor to handle orders.

As Node.js behaves with Relational database(postgres), the above system will probably have many queries to Bd, this scenario is compatible with the tool?

Guess, a query in the database is an I/O request. If it’s done asynchronously, as I mentioned, it doesn’t matter if it’s done on Node or not.

Node.js was made to work with sequential requests (make a request and wait for the return in the same "transaction")?

Two sequential requests can also be made asynchronously. The difference is that the second can only start when the first is complete.

  • I would add that in my file reading example there is no guarantee that the request to read file A will be met before the request to read file B, even if it was done first.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.