Reasons for using asynchronous APIs
The reason why the concept of asynchronous became popular in Web2.0 is because Javascript is executed on a single thread in the browser, and it also uses a thread with UI rendering. This means that UI rendering and responses are in a stagnant state when Javascript is executed. For better user experience, an asynchronous approach (of course, this is in the so-called single-threaded language) does not block the main thread and continue to respond to user operations. This belongs to the category of user experience.
Similarly, if engineers with experience in other languages, of course, understand that CPU switching between threads requires a lot of time (mainly switching between contexts and caching), so improving efficiency is also a reason to use asynchronous APIs.
Of course, these are not absolutely correct, but everyone says so. Because if the overhead of creating multithreads is less than parallel execution, then the method of multithreading is the first choice, which is often considered a CPU-intensive processing task.
In short, asynchronous IO or asynchronous API can be regarded as the feature of Node, because it is a platform that applies asynchronous IO on the application layer on a large scale, and it strives to allocate resources more efficiently on a single thread.
About Promise
Here, this article does not intend to explain the usage of Promise in detail, but only briefly explains some of the APIs and trial scope of Promise:
//Combining nodejs' fs.readdir function to create a native Promisevar promiseTask = new Promise(function(resolve,reject){ fs.readdir('/var/www',function(err,files){ if(!err){ resolve(files); }else{ reject(err); } });});promiseTask.then(function(files){ console.log('Content is:'+files); return files; //In order to continue to demonstrate other APIs, you can continue to use then to define the next operation function.}); promiseTask.catch(function(err){ console.log('The error is reported as:'+err);});How to wait for multiple promises to complete?
//Connect the above promiseTask.then(function(files){ var readFilsePromiseList = files.map(function(file,index){ return new Promise(function(resolve,reject){ fs.readFile(file,'utf-8',function(err,str){ if(!err){ resolve(str) } else{ reject(err) } }); }); }); return Promise.all(readFilsePromiseList);}).then(function(fileStrArray){ console.log('So-called file reading completed:'+fileStrArray);});This code does show the elegance of nodejs development.
So what's the problem?
The most elegant language at present still relies on the operating system, that is, the system limitations still exist:
I don't know if this error can be interpreted as exhausted file operation handles, but I hope you can understand this article that the operating system cannot open unlimited multiple files at the same time.
And this:
This is easy to understand, and the memory is exhausted. Of course, the memory limit can be adjusted by adding the following two running parameters:
node --max-old-space-size=8192 ./index.js #Unit MB node --max-new-space-size=2048 ./index.js #Unit KB
The above parameters take effect when V8 is initialized and cannot be changed dynamically once they take effect.
Many people may propose that these two limitations exist as well in other languages. Yes, other languages exist as well.
However, powerful GC or multithreaded programming models in other languages can allow engineers to release them in time after applying for system resources.
Although unnecessary system resources can be manually released in nodejs, can every operation in the reference program be released in time?
For example, the nodejs redis package (npm install redis) does not provide synchronization operation methods.
This means that more process control is needed in the development process. Unfortunately, nodejs in a single-threaded system is not good at this, because there is no concept of multi-threading, no locking mechanism, and it is impossible to include semaphore mechanisms in the usual sense. The result is that engineers don’t know when to manually release resources.
Unless you have absolute control over your project, you do not use any third-party packages that use asynchronous APIs.
Therefore, the current conclusion is that Promise is just a development technique. Understanding these is not suitable for all development scenarios.
Summarize
The above is all about the node.js asynchronous API and its limitations. I hope this article will be helpful to everyone. If you have any questions, please leave a message to communicate.