I'm trying to find a good deserializer/denormalizer for json-api (which is proving surprisingly difficult).
I've come across a few examples where the deserialization process (basically just denormalizing the relationships and flattening attributes) is defined as an async function. Here's one such example, but there are many that I've found.
Now, my understanding of node/javascript is that it is predicated on systems being I/O bound, so its design is such that operations should be non-blocking so that other operations can be scheduled during I/O and thus we get concurrent operations.
What I don't understand however is the usage within a deserializer such as this. We have the full payload at the time of deserialization, there's no I/O occurring whatsoever. I can only guess that the author assumes that the relationship lookups could all happen concurrently, however, since javascript is still single threaded, I can't see how this could in any way improve performance.
It seems to me this is just making a deterministic operation non deterministic (since I suppose the schedule could also schedule other operations besides the deserialization).
Am I missing something here? Is there truly a benefit to making this asynchronous? I'm not a front-end (or a node) developer so I feel like I'm missing something (since I've seen this pattern used in deserializers a LOT)
This will be run in the browser (not a node backend) if it makes any difference.
As it seems, the authors of the library that you mentioned as an example do not use async / await correctly:
// see: https://github.com/wopian/kitsu/blob/master/packages/kitsu-core/src/deattribute/index.js
// v does await nothing, as it receives an array
// v unneccessary
await data.map(async el => deattribute(el))
There is no reason to use async / await at all here, so I doubt that it serves any purpose in the library.
Are async/promises in javascript (in the browser) beneficial where there's no I/O?
No. Although promises are always resolved asynchronously , they will still end up in the so called microtask queue (in browsers), which will be emptied before the browser does rerender, therefore calling async functions will not help you to unfreeze the UI.
I can only guess that the author assumes that the relationship lookups could all happen concurrently, however, since javascript is still single threaded, I can't see how this could in any way improve performance.
I agree, this won't increase performance at all.
It seems to me this is just making a deterministic operation non deterministic (since I suppose the schedule could also schedule other operations besides the deserialization).
No, it could not, as there is no asynchronous IO involved that would free the engine from it's current task. Therefore it will still run in a blocking way.