Node.js Fundamentals: Getting Started with Server-Side JavaScript

Introduction

Node.js took JavaScript out of the browser and put it on the server, and in doing so, it didn't just change where JavaScript runs - it introduced a genuinely different concurrency model than most backend engineers had encountered before, built around a single-threaded event loop and non-blocking I/O rather than a thread-per-request model. Understanding that model well is the difference between writing Node.js code that scales gracefully under load and writing code that technically works but silently blocks the entire process the moment real traffic arrives.

This article covers the fundamentals professional engineers need to reason correctly about Node.js as a backend platform: how the event loop actually schedules work, how the module system evolved from CommonJS to native ES modules, how asynchronous patterns fit together, and where the platform's specific design trade-offs show up as real production pitfalls. This isn't a syntax tutorial - it assumes you already know JavaScript - it's a foundation for using Node.js deliberately rather than by trial and error.

The throughline worth keeping in mind throughout: Node.js is exceptionally good at handling many concurrent I/O-bound operations cheaply, and it will punish CPU-bound work that blocks its single thread disproportionately compared to a traditional multi-threaded server. Nearly every fundamental concept in this article, and nearly every pitfall, traces back to that one architectural fact.

The Problem Node.js Was Built to Solve

Before Node.js, the dominant server-side model for handling concurrent requests was thread-per-request or process-per-request: each incoming connection got its own operating system thread or process, and that thread blocked while waiting on I/O - a database query, a file read, a call to another service - before resuming. This model is conceptually simple, but it scales poorly for workloads dominated by I/O wait time, because every blocked thread still consumes memory and scheduling overhead even while doing nothing but waiting, and operating systems have practical limits on how many threads can be efficiently scheduled at once.

Node.js, built on Google's V8 JavaScript engine and Ryan Dahl's original 2009 design, took a different approach: a single main thread running an event loop, where I/O operations are handed off to be completed asynchronously (via the underlying libuv library, which manages a small thread pool for operations that are inherently blocking at the operating system level, like file system access) and the main thread is freed to handle other work while that I/O is in flight. When the I/O operation completes, its callback is queued to run on the main thread. This means a single Node.js process can hold open thousands of concurrent connections that are mostly idle, waiting on I/O, without needing thousands of threads to do it - a genuinely different cost structure than the thread-per-request model.

The trade-off embedded in this design is the one that shapes almost everything else in this article: because there's fundamentally one thread executing your JavaScript, any code that occupies that thread for a meaningful stretch of time - a large synchronous computation, a poorly written loop over a big dataset - blocks every other concurrent request from making progress, no matter how many connections are open. Node.js doesn't parallelize your CPU-bound code across cores automatically the way a thread-per-request model naturally does; it optimizes specifically for I/O-bound concurrency, and understanding that specialization is the starting point for using the platform well rather than fighting its design.

The Event Loop and Non-Blocking I/O in Depth

The event loop is the mechanism that makes Node.js's single-threaded concurrency model work, and it's worth understanding its actual phases rather than treating it as a black box. On each iteration, the loop processes several distinct phases in order: timers (callbacks scheduled by setTimeout and setInterval whose time has elapsed), pending callbacks (I/O callbacks deferred from a previous cycle), poll (retrieving new I/O events and executing their callbacks), check (callbacks scheduled via setImmediate), and close callbacks (cleanup for closed connections or handles). Each phase has its own callback queue, and the loop works through them in this fixed order before starting again - a structure documented in detail in Node.js's own event loop guide.

Layered on top of this phase structure is the microtask queue, which handles Promise callbacks (.then, .catch, async/await continuations) and has higher priority than the phase-based macrotask queue described above - after every single callback the event loop executes, it fully drains the microtask queue before moving on. This is why a resolved Promise's .then callback reliably runs before a setTimeout(fn, 0) callback, even though both are technically "scheduled for the next available opportunity" - they're competing in queues with different priority, not the same queue.

// JavaScript: demonstrating the actual execution order across
// the microtask queue, timers, and immediate callbacks - a common
// source of confusion until the underlying queue priority is understood.
console.log("1: synchronous");

setTimeout(() => console.log("2: timer (macrotask)"), 0);

Promise.resolve().then(() => console.log("3: promise (microtask)"));

setImmediate(() => console.log("4: immediate (check phase)"));

console.log("5: synchronous");

// Actual output order: 1, 5, 3, 2, 4 (exact ordering of 2 vs 4 can vary
// depending on context, but the microtask always resolves before either).

Understanding this ordering isn't trivia - it explains real bugs, particularly around assumptions that a setTimeout(fn, 0) will run "immediately," when in practice several microtasks and possibly other macrotask phases can run first. It also explains why CPU-intensive synchronous code is so disproportionately damaging to a Node.js server's responsiveness: every phase of the event loop, and every microtask, has to wait for the currently executing synchronous code to finish before any of them get a turn - there's no preemption, so a single slow synchronous function call blocks literally everything else the process is doing, including handling other clients' already-in-flight requests.

The Module System: CommonJS, ES Modules, and Practical Implications

Node.js originally used CommonJS as its module system - require() to import, module.exports to export - a synchronous, dynamically resolved system that predates the JavaScript language's own native module syntax. Native ES modules (import/export, standardized as part of ECMAScript and now natively supported in Node.js) have since become the recommended approach for new projects, but the two systems have real, practical differences that matter beyond syntax.

// CommonJS - synchronous resolution, dynamic by nature.
// math.js
function add(a, b) { return a + b; }
module.exports = { add };

// app.js
const { add } = require("./math");
console.log(add(2, 3));

// ES Modules (native, or via TypeScript compiled to ESM) - statically
// analyzable imports, enabling tooling like tree-shaking that CommonJS
// cannot support as reliably because require() calls can be dynamic.
// math.ts
export function add(a: number, b: number): number {
  return a + b;
}

// app.ts
import { add } from "./math.js"; // Note: explicit extension required for native ESM resolution
console.log(add(2, 3));

The practical implications go beyond stylistic preference. ES modules are statically analyzable - the imports and exports of a module can be determined without executing the code - which is what enables build tools to perform tree-shaking (eliminating unused exports from a final bundle) reliably. CommonJS's require() can be called conditionally or dynamically anywhere in a function body, which is flexible but defeats the same static analysis. Node.js determines which system a file uses based on its extension (.cjs forces CommonJS, .mjs forces ESM) or the "type" field in the nearest package.json, and mixing the two within a single project - often unavoidable when depending on older CommonJS-only packages from a native-ESM codebase - requires understanding Node's interoperability rules, since ESM code can import CommonJS modules fairly transparently but the reverse (CommonJS requiring a pure-ESM package) is not supported synchronously and requires a dynamic import() instead.

Practical Implementation: Building a Real Async Workflow

A realistic backend endpoint rarely does just one asynchronous thing - it typically coordinates multiple I/O operations, some sequential and some safely parallel, and handling that coordination correctly is where a lot of Node.js's practical async patterns actually get exercised.

// TypeScript: a realistic request handler coordinating several
// async operations, mixing sequential dependencies with safe parallelism.
import { Request, Response } from "express";

interface OrderDetails {
  order: { id: string; customerId: string; items: { sku: string; qty: number }[] };
  customer: { id: string; name: string; email: string };
  inventoryStatus: { sku: string; inStock: boolean }[];
}

async function getOrderDetails(req: Request, res: Response): Promise<void> {
  try {
    const order = await db.orders.findById(req.params.orderId);
    if (!order) {
      res.status(404).json({ error: "Order not found" });
      return;
    }

    // These two calls don't depend on each other's results, so running
    // them concurrently with Promise.all avoids paying their latency
    // sequentially - a common, high-leverage optimization in Node.js code.
    const [customer, inventoryStatus] = await Promise.all([
      db.customers.findById(order.customerId),
      inventoryService.checkStock(order.items.map((item) => item.sku)),
    ]);

    const details: OrderDetails = { order, customer, inventoryStatus };
    res.status(200).json(details);
  } catch (err) {
    // Centralized error handling: any rejected promise in the chain above
    // lands here, rather than needing a .catch() at every individual call.
    console.error("Failed to fetch order details:", err);
    res.status(500).json({ error: "Internal server error" });
  }
}

The Promise.all usage here reflects a genuinely important habit: sequential await calls that don't actually depend on each other needlessly add their latencies together, while independent calls run through Promise.all only take as long as the slowest one. This is one of the most common, easily fixable performance issues in real Node.js codebases - code that reads cleanly with sequential await statements but that's actually serializing work that had no dependency relationship requiring it.

For CPU-bound work that would otherwise block the event loop, Node.js provides worker_threads, allowing genuine parallel execution on separate threads for the specific cases where it's warranted - image processing, complex data transformation, cryptographic operations at scale.

// JavaScript (Node.js): offloading a CPU-intensive task to a worker
// thread so it doesn't block the main event loop's ability to keep
// serving other requests while the computation runs.
const { Worker } = require("worker_threads");

function runInWorker(workerData) {
  return new Promise((resolve, reject) => {
    const worker = new Worker("./cpu-intensive-task.js", { workerData });
    worker.on("message", resolve);
    worker.on("error", reject);
    worker.on("exit", (code) => {
      if (code !== 0) reject(new Error(`Worker exited with code ${code}`));
    });
  });
}

// Usage inside a request handler:
// const result = await runInWorker({ dataset: largeDataset });

This pattern is the direct, practical answer to the architectural trade-off described earlier: rather than accepting that CPU-bound work will block the main thread, or reaching for a different platform entirely, worker_threads lets Node.js hand off genuinely parallel-izable work to separate threads while the main event loop stays free to handle I/O-bound request traffic uninterrupted.

Trade-offs and Common Pitfalls

Several mistakes recur often enough in production Node.js codebases that they're worth naming explicitly, because each one traces directly back to a specific, identifiable misunderstanding of the platform's model.

Blocking the event loop with synchronous work. The single most damaging category of Node.js performance bug is synchronous, CPU-intensive code running directly on the main thread - a large JSON parse, an unoptimized regular expression against a long string (particularly ones vulnerable to catastrophic backtracking), a synchronous file system call (fs.readFileSync in a request handler, rather than its asynchronous counterpart). Because there's no preemption, this doesn't just slow down the request that triggered it; it stalls every other concurrent request the process is handling, which is why a Node.js service can appear to work fine under light load in testing and then degrade sharply and confusingly under real concurrent traffic.

Unhandled promise rejections. A rejected Promise with no .catch() handler and no surrounding try/catch used to fail silently in older Node.js versions; more recent versions terminate the process by default on an unhandled rejection, which is safer but means an overlooked error path can now crash a running service rather than merely failing to log an error. Both behaviors point to the same underlying discipline requirement: every Promise chain in a codebase needs an explicit error-handling path, and relying on a global unhandledRejection handler as the actual error-handling strategy, rather than a last-resort safety net, tends to produce services that fail in ways no one anticipated.

Callback-based code mixed inconsistently with Promises. Node.js's core APIs originally exposed a callback-based style (fs.readFile(path, (err, data) => {...})), and while most core modules now offer Promise-based variants (via fs/promises, for instance, or the util.promisify helper for older or third-party callback APIs), a codebase that mixes both styles inconsistently tends to accumulate exactly the kind of error-handling gaps described above - a callback-style error that's checked in some call sites and silently ignored in others, because the calling convention itself doesn't enforce that the error path be handled.

Memory leaks from long-lived closures and event listeners. Because a Node.js process is often long-running (unlike a request-scoped thread in some other server models, which naturally sheds its memory when the request completes), references retained inside closures, unremoved event listeners, or an ever-growing cache with no eviction policy accumulate across the process's entire lifetime rather than being cleaned up between requests, and a leak that seems negligible in a short-lived test can degrade a production service's memory usage steadily over days or weeks of continuous uptime.

Treating clustering as a substitute for addressing blocking code. Node.js's built-in cluster module, or process managers like PM2, let you run multiple Node.js processes across CPU cores to use hardware that a single-threaded process otherwise couldn't take advantage of - but this is horizontal scaling of independent event loops, not a fix for code that blocks any one of them. Teams sometimes reach for clustering as a way to paper over a service with blocking code, and it does genuinely help by giving each blocked instance fewer concurrent requests to stall, but it doesn't address the actual defect, which will still degrade each individual process's responsiveness under enough concurrent load.

Best Practices for Reliable Node.js Services

A handful of habits, applied consistently, prevent the majority of the pitfalls above before they reach production.

Default to asynchronous, non-blocking APIs everywhere I/O is involved, and treat any synchronous alternative (readFileSync, execSync, and similar) as something that requires explicit justification in code review, reserved for genuine one-time startup code rather than anything in a request-handling path. This single discipline addresses the most damaging category of Node.js performance issue directly at its source.

Push genuinely CPU-intensive work off the main thread deliberately, using worker_threads for in-process parallelism or a separate service/queue-based architecture for heavier workloads, rather than hoping a given computation stays small enough to not matter. Identifying which parts of your workload are CPU-bound versus I/O-bound early, and architecting around that distinction, avoids the awkward retrofit of extracting blocking code out of a request path after it's already caused a production incident.

Adopt async/await consistently as the default style for asynchronous code, since it composes with standard try/catch error handling far more legibly than chained .then()/.catch() calls or raw callbacks, and reduces the specific class of "forgot to handle this error path" bug that mixed styles tend to produce. Use Promise.all (or Promise.allSettled where partial failure should be tolerated rather than short-circuiting the whole batch) deliberately for genuinely independent operations, rather than defaulting to sequential await calls that silently serialize latency that didn't need to be serialized.

Monitor process-level health metrics that are specific to Node.js's architecture - event loop lag (the delay between when a callback is scheduled and when it actually executes, a direct signal of the main thread being blocked) and memory growth over time - rather than relying solely on generic infrastructure metrics like CPU and memory snapshots, which don't distinguish a healthy, busy process from one that's steadily leaking memory or accumulating event loop delay.

Keep dependencies deliberately audited and current, given how much of a typical Node.js application's actual runtime code comes from npm dependencies rather than first-party code; tools like npm audit and Dependabot-style automated update tooling exist specifically because the platform's package ecosystem is large enough that unaudited dependencies represent a real, ongoing attack surface rather than a theoretical concern.

Key Takeaways

Never run blocking, synchronous, CPU-intensive code inside a request-handling path - it stalls every concurrent request the process is handling, not just the one that triggered it.
Use Promise.all for genuinely independent async operations rather than defaulting to sequential await, which silently adds latencies together that didn't need to be paid sequentially.
Give every Promise chain an explicit error-handling path rather than relying on a global unhandled-rejection handler as your actual error-handling strategy.
Offload real CPU-bound work to worker_threads or a separate service, rather than hoping the computation stays small enough not to matter as traffic grows.
Monitor event loop lag directly, since it's the most specific, honest signal of whether your Node.js process's main thread is being blocked, in a way generic CPU metrics won't reliably surface.

Analogies and Mental Models

A useful mental model for the event loop: think of a single, extremely fast waiter working an entire restaurant alone. The waiter doesn't stand at one table waiting for the kitchen to finish cooking a dish - they take the order, pass it to the kitchen (which works independently, like Node's I/O operations handled via libuv), and immediately move to the next table. When a dish is ready, the waiter delivers it and moves on again. This works remarkably well as long as the waiter never gets stuck doing something slow themselves, like personally cooking a dish at the table - the moment they do that, every other table waits, no matter how many dishes are otherwise ready in the kitchen. That's exactly the danger of blocking synchronous code: it turns your one efficient waiter into someone stuck at a single table while everyone else's food gets cold.

Worker threads, in this analogy, are like calling in a second cook specifically for a dish that genuinely requires hands-on preparation the waiter can't just hand off and walk away from - used sparingly, for the specific dishes that actually need it, rather than as a general solution to a slow kitchen.

The 80/20 Insight

Nearly all of the practical difference between a Node.js service that scales well and one that mysteriously degrades under load comes down to one discipline: never letting synchronous, CPU-bound code run on the main thread for any meaningful duration. Everything else in this article - module systems, Promise composition patterns, clustering - matters, but a service that rigorously keeps its main thread free for scheduling I/O, and pushes any genuine computation to worker threads or a separate service, will avoid the large majority of Node.js-specific production incidents. Teams that master async/await syntax and Promise composition while still occasionally blocking the event loop with an unoptimized regex or a synchronous file read will still hit exactly the failure mode Node.js's architecture is most punishing about.

Conclusion

Node.js's fundamentals aren't complicated in the abstract - a single-threaded event loop, non-blocking I/O, a module system, and a rich set of async patterns built on Promises - but using the platform well requires taking its specific architectural trade-off seriously rather than treating Node.js as a JavaScript-flavored version of a thread-per-request server. The platform rewards workloads dominated by I/O wait and punishes workloads that block its one thread, and nearly every best practice in this article is a direct consequence of designing around that fact rather than against it.

Engineers who internalize this - who understand what the event loop is actually doing, write async code that composes correctly, and know exactly when a piece of work needs to be pushed off the main thread rather than run on it - get to use Node.js's genuine strengths: high concurrency for I/O-bound workloads, a single, consistent language across frontend and backend, and an enormous package ecosystem, without regularly rediscovering its sharp edges the hard way in production.

References

Node.js Documentation. "The Node.js Event Loop, Timers, and process.nextTick()." nodejs.org/en/learn/asynchronous-work/event-loop-timers-and-nexttick
Node.js Documentation. "Worker Threads." nodejs.org/api/worker_threads.html
Node.js Documentation. "Modules: CommonJS modules" and "Modules: ECMAScript modules." nodejs.org/api/modules.html, nodejs.org/api/esm.html
Node.js Documentation. "Cluster." nodejs.org/api/cluster.html
libuv Documentation. "Design overview." docs.libuv.org/en/v1.x/design.html
MDN Web Docs. "Using promises" and "async function." developer.mozilla.org
ECMA-262. "ECMAScript Language Specification" (Promise and module syntax standardization). tc39.es/ecma262/
npm Documentation. "npm audit." docs.npmjs.com/cli/v10/commands/npm-audit
Node.js Documentation. "Don't Block the Event Loop (or the Worker Pool)." nodejs.org/en/learn/asynchronous-work/dont-block-the-event-loop