July 18, 2016 at 12:19After a year of using NodeJS for development
I offer readers of "Habrahabr" a translation of the article I liked "After a year of using NodeJS in production" by Gavin Vickery. This is a continuation of his article “Why I'm switching from Python to Node.js” , which he wrote a little over a year ago in response to frustrations with using Python and as a justification for switching to Node.
A year of development with full-time command-line tools, client projects and the release of updates for our company’s products, in a nutshell, is what I learned during this time. I would like to share my experience, but it’s not so much about Node, but about the whole JavaScript.
Node is very easy to learn. Special if you are familiar with JavaScript. Google a few tutorials for beginners, play with Express and you're already in the subject, right? Then you will begin to realize that you need to somehow interact with databases. No problem, run NPM ... Yeah, just a handful of decent SQL packages. Later, you will understand that all existing ORM tools are worthless and that the basic driver is the best choice. Now you have problems with implementing your model and checking logic. Soon after, you will begin to write more complex queries and simply get lost in callbacks. Naturally, you will read about the 'callback hell', spit on this matter and start using one of the many promise libraries. From now on, you will simply begin to “promiscify” all the things you do in exchange for a relaxing weekend.
All this makes us say that the Node ecosystem is constantly moving. And the vector of this movement is not very good. New tools that are sort of “much cooler” than the old ones will be found every day. Just imagine: you can always find what you have, but only also “glows”. You will be surprised how simple it can happen to you. And it looks like the community is only encouraging it. Are you using Grunt !? Does everyone use Gulp !? Wait a minute, use NPM native scripts!
Packages that consist of no more than 10 lines of trivial code are downloaded thousands of times every day from NPM. Are you seriously? Do you really need to install this whole string of dependencies to just check the type of array? And these same packages are used by such giants as React and Babel.
You will never become a master of what moves at such a puzzling speed. And this is not a word without saying about the "stability" of such movements.
If you came from another language, such as Python, Ruby or PHP, then you will expect that something will throw an exception to you, something will catch it, at worst the function will return an error. And this is normal. Absolutely fine ... But in Node it is not. On the contrary, you pass errors to your callbacks or promises - that's right, no throwing exceptions. But this works exactly until you want to get a call stack from several nested callbacks. Not to mention the fact that if you forget to return a callback in case of an error, the script will continue to run and will cause a set of other errors, in addition to the first. You will have to double the amount of debugging information in order to debug normally.
Even if you start “seriously” by the standard to process your own errors, you cannot (without reading the source) make sure that most of the packages installed from NPM use the same approach.
These problems will lead you to use catchall exception handlers. Which will be able to pawn a problem place and allow your application to not just gracefully “fall”. Remember, Node is single-threaded. If something blocks the process, everything will go to hell. But this is cool, you use Forever, Upstart and Monit , right?
To manage the 'callback hell', bugs, and hard-to-read logic, more and more developers are starting to use Promis. This is a way to write code that looks more or less synchronous, without the crazy 'callback' logic. Unfortunately, there is not a single “standard” (like for anything else in JavaScript) for implementing or using Promis.
The most frequently mentioned library now is Bluebird . She's pretty good, works fast and makes things "just work." Be that as it may, I found it very useful to wrap everything I need in Promise.promisifyAll ().
For the most part, I used the wonderful async library to keep my callbacks under control. With her, everything looked more natural.
Toward the end of my experience with Node, generators became more popular. I never finished my "immersion" in them and therefore I can not really say anything. I would like to hear someone who is closer to them.
The last straw was that I discovered a lack of standards. It feels like everyone has their own idea of how to work with the things described above. Callbacks? Promis? Error processing? Build scripts? Yes, this has no end.
It all glows ... No one can say how to write standardized JavaScript code. Just google “JavaScript Coding Standards” and you’ll understand what I mean.
I understand that many languages do not have a strict structure, but they usually have a standard guideline created by the language maintainers.
The only thing that is somehow acceptable was written in Mozilla .
I spent a year trying to get JavaScript and a more specific Node to work for our team. Unfortunately, during this time we spent more hours searching for documentation, getting to know the “standards”, debating libraries and debugging trivial code, than for something useful.
Would I advise Node for large projects? Absolutely not. Will people use it anyway? Of course they will. I tried too.
Be that as it may, I would recommend JavaScript for front-end developers like Angular or React (as if you had a different choice).
I would also recommend Node for simple back-end servers, mainly used for web sockets or providing APIs. You can just do it with Express, I say so, because we did so for our QuoterobotPDF server processing. This is a single file containing 186 lines of code, including spaces and comments. And it works just as well as it is simple.
Quite possibly you are surprised, what am I doing now? Now I continue to write the main parts of our products and APIs using Python. Mostly in Flask or Django, using either Postgres or MongoDb.
This is a time-tested option with excellent standards, libraries, easy debugging and stable operation. Of course, and he has flaws. But he is good, you just have to start writing on it. For some reason, Node caught my eye and tightened me. I do not regret my attempt to make friends with him, but I feel that I spent more time on him than I should have.
I hope JavaScript and Node improve in the future. I will be happy to try it again.
Tell us about your experience? Did you have any problems that I experienced? Have you finished “jumping” back to a more comfortable language?
A year of development with full-time command-line tools, client projects and the release of updates for our company’s products, in a nutshell, is what I learned during this time. I would like to share my experience, but it’s not so much about Node, but about the whole JavaScript.
Easy to learn, but impossible to become a master
Node is very easy to learn. Special if you are familiar with JavaScript. Google a few tutorials for beginners, play with Express and you're already in the subject, right? Then you will begin to realize that you need to somehow interact with databases. No problem, run NPM ... Yeah, just a handful of decent SQL packages. Later, you will understand that all existing ORM tools are worthless and that the basic driver is the best choice. Now you have problems with implementing your model and checking logic. Soon after, you will begin to write more complex queries and simply get lost in callbacks. Naturally, you will read about the 'callback hell', spit on this matter and start using one of the many promise libraries. From now on, you will simply begin to “promiscify” all the things you do in exchange for a relaxing weekend.
All this makes us say that the Node ecosystem is constantly moving. And the vector of this movement is not very good. New tools that are sort of “much cooler” than the old ones will be found every day. Just imagine: you can always find what you have, but only also “glows”. You will be surprised how simple it can happen to you. And it looks like the community is only encouraging it. Are you using Grunt !? Does everyone use Gulp !? Wait a minute, use NPM native scripts!
Packages that consist of no more than 10 lines of trivial code are downloaded thousands of times every day from NPM. Are you seriously? Do you really need to install this whole string of dependencies to just check the type of array? And these same packages are used by such giants as React and Babel.
You will never become a master of what moves at such a puzzling speed. And this is not a word without saying about the "stability" of such movements.
Error handling on the principle of “lucky / unlucky”
If you came from another language, such as Python, Ruby or PHP, then you will expect that something will throw an exception to you, something will catch it, at worst the function will return an error. And this is normal. Absolutely fine ... But in Node it is not. On the contrary, you pass errors to your callbacks or promises - that's right, no throwing exceptions. But this works exactly until you want to get a call stack from several nested callbacks. Not to mention the fact that if you forget to return a callback in case of an error, the script will continue to run and will cause a set of other errors, in addition to the first. You will have to double the amount of debugging information in order to debug normally.
Even if you start “seriously” by the standard to process your own errors, you cannot (without reading the source) make sure that most of the packages installed from NPM use the same approach.
These problems will lead you to use catchall exception handlers. Which will be able to pawn a problem place and allow your application to not just gracefully “fall”. Remember, Node is single-threaded. If something blocks the process, everything will go to hell. But this is cool, you use Forever, Upstart and Monit , right?
Callback, Promise or Generator !?
To manage the 'callback hell', bugs, and hard-to-read logic, more and more developers are starting to use Promis. This is a way to write code that looks more or less synchronous, without the crazy 'callback' logic. Unfortunately, there is not a single “standard” (like for anything else in JavaScript) for implementing or using Promis.
The most frequently mentioned library now is Bluebird . She's pretty good, works fast and makes things "just work." Be that as it may, I found it very useful to wrap everything I need in Promise.promisifyAll ().
For the most part, I used the wonderful async library to keep my callbacks under control. With her, everything looked more natural.
Toward the end of my experience with Node, generators became more popular. I never finished my "immersion" in them and therefore I can not really say anything. I would like to hear someone who is closer to them.
Poor standardization
The last straw was that I discovered a lack of standards. It feels like everyone has their own idea of how to work with the things described above. Callbacks? Promis? Error processing? Build scripts? Yes, this has no end.
It all glows ... No one can say how to write standardized JavaScript code. Just google “JavaScript Coding Standards” and you’ll understand what I mean.
I understand that many languages do not have a strict structure, but they usually have a standard guideline created by the language maintainers.
The only thing that is somehow acceptable was written in Mozilla .
Node Summary
I spent a year trying to get JavaScript and a more specific Node to work for our team. Unfortunately, during this time we spent more hours searching for documentation, getting to know the “standards”, debating libraries and debugging trivial code, than for something useful.
Would I advise Node for large projects? Absolutely not. Will people use it anyway? Of course they will. I tried too.
Be that as it may, I would recommend JavaScript for front-end developers like Angular or React (as if you had a different choice).
I would also recommend Node for simple back-end servers, mainly used for web sockets or providing APIs. You can just do it with Express, I say so, because we did so for our QuoterobotPDF server processing. This is a single file containing 186 lines of code, including spaces and comments. And it works just as well as it is simple.
Return to Python
Quite possibly you are surprised, what am I doing now? Now I continue to write the main parts of our products and APIs using Python. Mostly in Flask or Django, using either Postgres or MongoDb.
This is a time-tested option with excellent standards, libraries, easy debugging and stable operation. Of course, and he has flaws. But he is good, you just have to start writing on it. For some reason, Node caught my eye and tightened me. I do not regret my attempt to make friends with him, but I feel that I spent more time on him than I should have.
I hope JavaScript and Node improve in the future. I will be happy to try it again.
Tell us about your experience? Did you have any problems that I experienced? Have you finished “jumping” back to a more comfortable language?