We are working with node, mainly for an internal project and to understand the best way to use the technology.
Not coming from a specific asynchronous background the learning curve can be a challenge but we are getting used to the framework and learning the process.
One thing that has polarised us is when the best time to use synchronous code vs asynchronous code is. We are currently using the rule that if anything interacts with IO then it has to be asynchronous via call backs or the event emitter (thats a given), but other items which are not in any way using IO can be constructed as synchronous functions (this will depends as well on the heaviness of the function itself and how blocking it actually is) but is this the best approach to take when working with Node.js?
For instance, we are creating a Hal+JSON builder, which currently exists within our code base. It is synchronous simply because all it is doing is creating some rather smallish object literals and nothing more, there are no external dependencies and certainly no IO interactions.
Is our approach a good one to take or not?
Let’s say you have two functions,
fooandbar, which are executing synchronously:In order to make the API “asynchronous” is to change it to use callbacks:
But the fact of the matter is, this code is still entirely synchronous. The callback is being executed on the same call stack, and no threading optimizations are being made, no scalability benefits are to be had.
It then becomes a question of code readablity and coding style. I personally find the typical
var val = func();type code more readable and readily understandable. The only drawback is, that if you one day would need to change the functionality ofbarso, that it would need to perform some I/O activity or call some other function which is asynchronous, you need to change the API ofbaras well.My personal preference: use traditional, synchnous patterns when applicable. Always use asynchronous style when I/O is involved or when in doubt.