{"id":4172,"date":"2013-01-02T17:34:07","date_gmt":"2013-01-02T13:34:07","guid":{"rendered":"http:\/\/blog.denivip.ru\/?p=4172"},"modified":"2013-08-05T14:10:33","modified_gmt":"2013-08-05T10:10:33","slug":"pitfalls-in-large-scale-application-development-on-node-js","status":"publish","type":"post","link":"http:\/\/blog.denivip.ru\/index.php\/2013\/01\/pitfalls-in-large-scale-application-development-on-node-js\/?lang=en","title":{"rendered":"Pitfalls in Large-Scale Application Development on Node.js"},"content":{"rendered":"

\"\"<\/a><\/center><\/p>\n

It has become clear that Node.js has become a striking trend in the community of Web developers. In this post, we are going to discuss, what pitfalls may encroach on the developer in Node.js, and whether it is worth switching to it.<\/p>\n

Basically, developers associate Node.js with small services, e.g., chats. (For more details, read "Development of high-performance services for Node.js").<\/a> Well, they have a good reason for that. Node.js is a perfect fit for services that support a permanent connection to the client or can wait for a response for a long time. Absence of I\/O lock allows you to read large files, keeping your service ready to process new requests. <\/p>\n

So, that’s why the community is so fond of Node.js:<\/p>\n

\u2022\tThe Node can maintain thousands of open connections with clients, while constantly saving the data to the database.
\n\u2022\tThe event-based model works great to make cascaded asynchronous requests to other parts of the application.
\n\u2022\tA large and responsive community combined with a fast speed of the technology development.
\n\u2022\tDozens of modules supported.
\n\u2022\tJSON is the native format of object description. Moreover, if you use MongoDB<\/a>, you may virtually forget of the serialization issue.<\/p>\n

By the way, Node.js also allows to quickly implement highly loaded REST services. This is greatly simplified by such modules as express<\/a>.<\/p>\n

However, there is a reverse side of the coin.<\/p>\n

Unlockable Flow?<\/h2>\n

There is an erroneous opinion that node.js can not be locked. From the architectural viewpoint, Node is built to run everything in a single flow. It means that, heavy math can easily hang the application for a while.<\/p>\n

So, how to deal with it?  There are several approaches to solving this problem. All of them leverage the idea of taking heavy computations off the control flow. Here they are:<\/p>\n

    \n
  1. Break the code down into iterations and run them using setTimeout with a delay of 0 ms. Please keep in mind that 0 here in no way means no delay at all. It means that the node will start executing the code as soon as possible. Of course, you will have to store intermediate results somewhere. Also, all this would lead to extended time needed to execute such computations.<\/li>\n
  2. Delegate execution to workers. Essentially, this approach will generate additional system processes to run your code.<\/li>\n<\/ol>\n

    File read\/write and collisions<\/strong><\/h2>\n

    If you exchange the contents of large files between workers, you should be aware of specifics of accessing them. When opening a file, the Node will fetch its description from the system. Then, the description will be passed to workers.<\/p>\n

    Also, often you need to notify workers or other Node’s instances of making file manipulations. Usually you need to lock a file from other processes to prevent parallel write to it. For such purposes, a separate controller node is written to grant read\/write permissions to other nodes and organize the read\/write waiting queue.<\/p>\n

    Please note that this approach is applicable not just to file manipulations, but to any task involving collision control.<\/p>\n

    Garbage Collector Execution Lock<\/strong><\/h2>\n

    \"\"<\/a><\/strong><\/center><\/p>\n

    As you know, Node.js is built around the V8 engine. Its specifics is that when you start GC, the node stops until GC terminates. The delay time depends on the number of objects in the heap. "Running" applications performance may somewhat degrade due to the garbage collector. To display GC results, run the node as follows:<\/p>\n

    node<\/em> <script> —trace-gc<\/p>\n

    In one approach, the application is split into several parts to reduce the number of objects inside a single system module. Then running the garbage collector in each of the modules will take less time. However the idea is good, you should remember that the code of asynchronous modules should be concerted, engendering complex constructions.<\/p>\n

    So, careful and mindful creation of objects should be your main paradigm in writing services in Node.js. <\/p>\n

    Pitfalls in Debugging<\/strong><\/h2>\n

    Debugging of the node is not an easy task. Of course, you can just run the node in the debug mode. However the debugging experience here is quite poor. It is much easier to use a third-party application, e.g.:<\/p>\n

    1) node-inspector<\/a><\/p>\n

    This product allows you to remotely debug the node in the WebInspector interface, edit the runtime code and even profile your application.<\/p>\n

    Below is a short video on debugging the node using node-inspector<\/p>\n

    <\/embed><\/object><\/center><\/p>\n

    2) PHPStorm\/WebStorm Node.js Debugger<\/p>\n

    These editors have built-in features for local and remote node debugging in their native environment.<\/p>\n

    The event model built into Node.js can easily confuse the developer. The output of the stack consisting of a sequence of invocations of callback functions, is usually not informative. However, you can improve readability of the output, if you make it a rule to give names to all your callbacks. For example:<\/p>\n

    1
    <\/div><\/td>
    setTimeout (function do () {\/ * Some code here * \/});<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

    Now at stack output, you will not get lots of messages relating to unnamed function calls.<\/p>\n

    Callback function cascading<\/strong><\/h2>\n

    Complex Node.js based applications imply sequential call of many callbacks. Quite often, the following structures can be seen in the code:<\/p>\n

    1
    <\/div><\/td>
    do(function () { ... function() { ... function() { ... } } });<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

    It is extremely difficult to read and maintain such code. To structurize your code in such situations, you can use special patterns. For more details about them, read the post "Node.js Control flow".<\/a><\/p>\n

    API variations<\/strong><\/h2>\n

    The Node and its modules are rapidly changing. So there are risks that the newer versions of Node.js and its modules could break the whole application. It means that you have to be prepared, while migrating to a newer API, create new implementations of entire service blocks.<\/p>\n

    For this reason, we recommend to avoid installing any module globally. The situation is quite possible, as two different nodes on the same machine may use two incompatible versions of the same module.<\/p>\n

    npm install <module><\/em><\/p>\n

    Examples of successful use of Node.js<\/strong><\/h2>\n

    On GitHub, there is a list of companies that use Node.js in their services. You can access it by clicking here.<\/a><\/p>\n

    Let’s take a look at some of them:<\/p>\n