All 15 Event Loop & Non-blocking IO questions
More in Event Loop & Non-blocking IO
What does 'non-blocking I/O' mean, and how does a Node.js function like fs.readFile() achieve it compared to fs.readFileSync()? How does setImmediate() differ from process.nextTick() in terms of timing and typical use cases? How does the event loop handle a large synchronous loop (like processing a huge array with a for loop), and what problem does this cause? What does it mean that Node.js's I/O is handled by libuv, and how does libuv abstract different operating systems' I/O mechanisms? How would you measure how 'busy' the event loop is in a running Node.js process using a simple technique? What are the distinct phases of the Node.js event loop, and what kind of callbacks does each phase execute? What is 'event loop lag' (or 'event loop delay'), and how would you monitor it in a production Node.js application? What is the poll phase of the event loop, and under what specific conditions does it block waiting versus move on immediately? What is the difference between how Node.js handles I/O-bound concurrency versus CPU-bound work, and why does this distinction shape Node.js's ideal use cases? How would you use async_hooks (the lower-level predecessor to AsyncLocalStorage) to trace the lifecycle of asynchronous resources in Node.js?
Advertisement
Back to results for “File System (fs) Module”
Node.js › Event Loop & Non-blocking IO

What is the difference between synchronous and asynchronous versions of the same core Node.js API, using fs.readFile vs fs.readFileSync as an example, and when is the synchronous version actually appropriate?

Intermediate

Answer

The synchronous version blocks the entire event loop until the operation completes, returning its result directly rather than via a callback or promise -- generally discouraged in a server handling concurrent requests, but genuinely appropriate in specific contexts like a one-off CLI script's startup sequence (reading a config file before anything else happens, where blocking briefly at startup causes no harm since there's nothing else concurrently happening yet) or simple, single-purpose scripts with no concurrency concerns at all.
// Appropriate use of the synchronous version: reading config once at startup,
// before the server starts accepting any concurrent requests
const config = JSON.parse(fs.readFileSync('config.json', 'utf-8'));

app.listen(config.port); // only starts accepting requests after config is loaded
Real-world example A CLI tool that runs once, processes a file, and exits uses fs.readFileSync() throughout without concern, since there's no concurrent request-handling happening that a brief synchronous block could interfere with, unlike in a running web server.

Common follow-ups: What's the specific risk of using a synchronous fs call inside a running Express route handler versus at application startup?;Are there other core Node.js APIs beyond fs that offer both sync and async variants following this same pattern?

File System (fs) Module;CLI Tools & Scripting with Node.js
All 15 Event Loop & Non-blocking IO questions