Is it ever better to use Node's filesystem sync methods over the same async methods?-CodePudding

This is a question about performance more than anything else.

Node exposes three different types of methods to accomplish various filesystem tasks:

Promises API (async)
Callback API (async)
Synchronous API (sync)

I've read more articles and stackoverflow answers than I can count, all of which claiming to never need the sync methods.

I recently wrote a script which required a couple directories to be made if they didn't already exist. During this, I noticed that if I used the async/await methods (primarily fs.promises.mkdir and fs.promises.access), the event loop would simply continue to the next async bit of code, regardless of the fact that the next bits require those directories. This is expected behavior, after all, it's async.

I understand this could be solved with a nice little callback hell sesh, but that isn't the question, whereas the idea that the promises api can be used over all other methods is.

The question then becomes:

Is it ever better to use Node's filesystem sync methods over the same async methods?

Is it ever truly required in situations like this to block the process?

Or said differently:

Is it possible to completely avoid sync methods and ONLY use the promises api (NOT promises callbacks)?

It seems like using the sync methods (given my situation above, where the directories are required to be there before any other call is made) can be EXTREMELY useful to write readable, clear code, even though it may negatively impact performance.

With that being said, there's an overwhelming level of information to say that the sync api is completely useless and never required.

Again, this purely caters to the promises api. Yes, callbacks and promises are both async, but the difference between the job and message queues makes the both api's completely different in this context.

PS: For additonal context on examples, I've provided a code sample so you don't have to imagine my example ;)

Thanks! :)

// Checks if dir exists, if not, creates it. (not the actual code, just an example)

// Sync version
if (!fs.existsSync(dirPath)) {
     fs.mkdirSync(dirPath);
}

// Async version
  try {
    await fs.promises.access(dirPath);
  } catch {
    await fs.promises.mkdir(dirPath);
  }

CodePudding user response：

It depends on the situation. The main benefit of the sync methods is that they allow for easier consumption of their results, and the main disadvantage is that they prevent all other code from executing while working.

If you find yourself in a situation where other code not being able to respond to events is not an issue, you might consider it to be reasonable to use the sync methods - if the code in question has no chance of or reason for running in parallel with anything else.

For example, you would definitely not want to use the sync methods inside, say, a server handling a request.

If your code requires reading some configuration files (or creating some folders) when the script first runs, and there aren't enough of them such that parallelism would be a benefit, you can consider using the sync methods.

That said, even if your current implementation doesn't require parallelism, something to keep in mind is that, if the situation changes and you find that you do actually need to allow for parallel processing, you won't have to make any changes to your existing code if you had started out by using the promise-based methods in the first place - and if you understand the language, using the Promises properly should be pretty easy, so if there's a chance of that, you might consider using the Promises anyway.