Whenever i use await. I need to mark the function as async (non blocking). Isn't node by default async? What significance this keep words add.
Node is not by default async. Node favors asynchronous APIs because it is single-threaded. You may write synchronous code. It depends on APIs and modules you are using, not on node itself.
From nodejs.org blog https://nodejs.org/en/knowledge/getting-started/control-flow/how-to-write-asynchronous-code/
Node.js promotes an asynchronous coding style from the ground up, in
contrast to many of the most popular web frameworks.
So while node.js suggests async coding, it is still JavaScript, and Javascript does not do async unless you tell it to, through callbacks, promisify, or async/await.
Related
I have been using the async package from NPM inside my Node.js service to run different operations in sequence. Example: when I would like to run functionA, functionB, functionC in sequence. I would use Promise in Node.js, but this means using callbacks which are not that efficient when we have lot of functions which need to run in sequence.
I have recently familiarized myself with Reactive Programming using Observables and this is widely being used in frontend frameworks such as AngularJS and React. I was wondering if Node.js has something similar to that and if there are any better ways to handle async operations in sequence.
The Node.js addons can be evoked in two ways: synchronous and asynchronous.
The two ways are possible, so I guess that the synchronous way could be more advantageous in some situation. What is that particular situation?
Pretty much the ONLY time I use the synchronous version of an IO function is in the startup phase of the server. It simplifies the startup code, but does not impact the ultimate scalability or performance of the server. For example, the built-in require() is synchronous for this reason.
During runtime when processing a request, you pretty much never want to use any synchronous function if there is an asynchronous alternative because it significantly reduces the scalability and performance of your server. It can add some coding complexity to always use the async version, but that extra complexity is what gives node.js it's performance and scalability.
There's a node already doing some repetitive works(like setInterval) and network event handling.
I've built another network library in C++ using Boost.Asio and want to use it from node I explained above(with node-ffi and it works well).
Here's the problem. Node has its own event dispatcher and Boost.Asio too. So, after I've invoked the above C++ library from node, because it blocked, no other node code could not be reached and didn't work anymore.
Can I make them to coexist peacefully...?
Asio's io_service::poll_one() works find in some way but there's a better solution.
node-ffi's Async Library Call is perfect for this situation. It says...
node-ffi supports the ability to execute library calls in a different
thread using the libuv library. To use the async support, you invoke
the .async() function on any returned FFI'd function.
I look for the package that allows to work with redis in synchronous manner. The problem is I don't want to rewrite the code for async flow.
The possible solution is
Find synchronous library to work with redis.
Implement a middle layer script in some synchronous language and communicate with this script by synchronous execution operation.
I tried to use synchronize with no success so far.
You may want to give a try at co, which will let you write non-blocking code using almost any existing node library. Here is a specific example using node-redis.
Please note that co requires node 0.11.x (with --harmony flag) or 0.10.x with a wrapper like gnode.
I have been reading about Clojure for some time and I'm considering it as a replacement to Node.js (which I have used for another project). The most promising library seems to be Aleph/Lamina, which unfortunately doesn't have nearly as many examples as Node. My questions are:
How can I process requests with a chain of async operations, such as reading a document from MongoDB, doing some calculations, saving the new document and sending it in the response? I was not able to write it from the examples in Lamina wiki page. It sounds like a pretty common use case and I was surprised not to found any code showing it. It would be great if you could show me some sample code.
Is this setup adequate for a heavy-load server (say, tens of thousands requests per second)? I can't afford to create one thread for each new request, so I need something similar to the Node approach.
Is there any example of a medium- or large-sized company out there using any of this?
Is there any better Clojure replacement to Node (besides Aleph/Lamina)? Perhaps Clojurescript targetting Node? My client is not written in Javascript, so using the same language in both client and server is not an advantage in my case.
Thanks!
Few pointers:
You need to look at Aleph which builds HTTP abstractions over Lamina channels abstraction.
Reading and writing docs to MongoDB can be async but the library should provide this. In Node.js the MongoDB library has to be async other wise it would screw up the Node programming model, where as this is not the case with Clojure so most probably the Clojure MongoDB library provides non-async function.
Async operations are only helpful in case of IO i.e reading/writing to mongodb, sending response back etc. Generation computations are CPU bound operations and has nothing to do with async model.
Vert.x is Java world Node.js. Clojure support is on roadmap. I would prefer Aleph as you can play in async and non-async world as required.