Node.JS for startups or production problems
Good day. I would like to share with the habrosocommunity about my experience using Node.JS on a live project. Five months ago, I began to embody one of my old ideas - service achievements.
When developing projects, I prefer to adhere to the point of view that the choice of technology should be justified by the low cost of its use. Therefore, for my project, I chose the stack - Node.JS + mongoDB, since these are the technologies that I own best.
I want to note that here I will describe only those problems that I encountered myself.
Node.JS is known for its ideology that all I / O calls should occur asynchronously. This approach provides very wide possibilities, although sometimes it leads to certain problems. For example, a banal situation - you need to make a query to the database and, based on the result, make another query, for example, to another table. For religious reasons, I did not use mongoose (ORM for mongodb). In this regard, I used node-mongodb-native . The problem is that when using this module you have to work with the DB cursor, which leads to the appearance of an extra callback:
')
Thus, the task described above is reduced to a banal callback hella:
Such problems are solved by using Coffescript or the async module. Both methods make the code more readable and adequate. As an intermediate solution, I divided calls into functions — this option brings the code into a more or less vertical view, but also, with a sufficiently long chain of calls, it creates the problem of tracking down the error in this very chain.
Crashlog in Node.JS in general problems does not cause any complaints, but sometimes there are exceptions for which, it’s not clear what the error is, only what it is is clear.
For such a log, it is clear that an error in calling the module http. And if the application has more than one http call? Which one caused the error is not clear. Have to watch already logs on the other side.
Developers using Node.JS are probably familiar with the forever module. This module allows you to run node processes and monitor its crashes. But the problem is that forever forks itself to track every application you run. As a result, in the top we see N the number of node processes, and it is not clear which of the processes consumes how many resources. Pid can of course be obtained from the forever list, but this is inconvenient.
Node.JS itself and many modules for it adhere to CommonJS concepts in particular that the error of execution of functions must be returned in the callback by the first argument. In this regard, an error is possible after each I / O call, which can lead to an action. So it is necessary to handle each exception (for this, by the way, they constantly “kick” Node.JS =)). Since my project is at the “deep” beta stage, I solve such problems “live”, ie error handling is implemented only when it begins to occur. Since the application has a modular structure is allowed - the user does not see any errors.
That's probably all. It is worth noting that even though I described only the negative aspects of Node.JS that I encountered, but still there are much more positive points for me) Thank you all for your attention)
PS If anyone is interested in the link to the project is in the profile.
When developing projects, I prefer to adhere to the point of view that the choice of technology should be justified by the low cost of its use. Therefore, for my project, I chose the stack - Node.JS + mongoDB, since these are the technologies that I own best.
I want to note that here I will describe only those problems that I encountered myself.
Force Asynchrony
Node.JS is known for its ideology that all I / O calls should occur asynchronously. This approach provides very wide possibilities, although sometimes it leads to certain problems. For example, a banal situation - you need to make a query to the database and, based on the result, make another query, for example, to another table. For religious reasons, I did not use mongoose (ORM for mongodb). In this regard, I used node-mongodb-native . The problem is that when using this module you have to work with the DB cursor, which leads to the appearance of an extra callback:
')
db.collection('table', function(err, collection) { collection.findOne({uid:uid}, function(err, doc) { cb(doc); }); }); Thus, the task described above is reduced to a banal callback hella:
db.collection('table', function(err, collection) { collection.findOne({uid:uid}, function(err, doc) { db.collection('table2', function(err, collection) { collection.findOne({size:doc.size}, function(err, doc) { cb(doc); }); }); }); }); Such problems are solved by using Coffescript or the async module. Both methods make the code more readable and adequate. As an intermediate solution, I divided calls into functions — this option brings the code into a more or less vertical view, but also, with a sufficiently long chain of calls, it creates the problem of tracking down the error in this very chain.
Debugging
Crashlog in Node.JS in general problems does not cause any complaints, but sometimes there are exceptions for which, it’s not clear what the error is, only what it is is clear.
events.js:71 throw arguments[1]; // Unhandled 'error' event ^ Error: socket hang up at createHangUpError (http.js:1264:15) at Socket.socketOnEnd [as onend] (http.js:1352:23) at TCP.onread (net.js:419:26) For such a log, it is clear that an error in calling the module http. And if the application has more than one http call? Which one caused the error is not clear. Have to watch already logs on the other side.
Forever
Developers using Node.JS are probably familiar with the forever module. This module allows you to run node processes and monitor its crashes. But the problem is that forever forks itself to track every application you run. As a result, in the top we see N the number of node processes, and it is not clear which of the processes consumes how many resources. Pid can of course be obtained from the forever list, but this is inconvenient.
Catching errors
Node.JS itself and many modules for it adhere to CommonJS concepts in particular that the error of execution of functions must be returned in the callback by the first argument. In this regard, an error is possible after each I / O call, which can lead to an action. So it is necessary to handle each exception (for this, by the way, they constantly “kick” Node.JS =)). Since my project is at the “deep” beta stage, I solve such problems “live”, ie error handling is implemented only when it begins to occur. Since the application has a modular structure is allowed - the user does not see any errors.
That's probably all. It is worth noting that even though I described only the negative aspects of Node.JS that I encountered, but still there are much more positive points for me) Thank you all for your attention)
PS If anyone is interested in the link to the project is in the profile.
Source: https://habr.com/ru/post/164755/
All Articles