More in Backend Dev — page 41
Worker Threads: True Parallelism in Node.js
Worker threads give Node.js a separate brain for heavy lifting, letting you run CPU-intensive code without blocking the main event loop. Use them for tasks like image processing, not I/O. The footgun is assuming memory is shared; it isn't.
Libuv: The Engine Behind Node.js Async I/O
Libuv is the C library that powers Node.js's non-blocking I/O. It translates JavaScript's event loop into high-performance async calls for the host OS. The footgun is thinking this makes Node multi-threaded; it uses an event loop and a thread pool.
Node.js Child Processes: Escaping the Main Thread
A child process lets your Node.js app run external commands without blocking the event loop. Use it for CPU-intensive tasks like image processing or running system utilities. The footgun: using synchronous versions (`execSync`) will block your entire server.
Node.js Streams: Processing Data in Chunks, Not Blobs
Think of streams as a data conveyor belt, processing large files or network data in chunks instead of loading it all into memory. Use them for file I/O or network requests.
process.nextTick(): Cutting in Line on the Event Loop
process.nextTick() schedules a callback to run immediately after the current operation, before the event loop continues to timers or I/O. It's used for API consistency or error handling. The footgun is that overusing it can starve the event loop, blocking I/O.
JavaScript's Event Loop: Macrotasks & Microtasks
The JavaScript event loop processes tasks like `setTimeout` callbacks or user clicks from a macrotask queue. A single, long-running macrotask blocks all rendering and user input, freezing the UI. The footgun is assuming `setTimeout(fn, 0)` runs instantly.
Event Loop vs Crypto Module
Node's crypto module offers both synchronous and asynchronous versions of CPU heavy operations like password hashing; the sync versions block the single threaded event loop, while async versions offload the work to a background thread pool.
The Node.js Event Loop: Concurrency on a Single Thread
The Node.js event loop lets a single thread handle high concurrency by offloading I/O. It's ideal for web servers and APIs, but the footgun is that any long-running synchronous code will block the entire application, freezing all other requests.
Node.js Events and the EventEmitter
Node.js handles concurrency with an event-driven model, not threads. "Emitters" fire named events that "listeners" react to, enabling non-blocking I/O for things like file reads and web requests.
V8: The Engine Powering Chrome and Node.js
V8 is the engine that runs your JavaScript, translating it into machine code. It powers both the Chrome browser and the Node.js server-side runtime. The common footgun is confusing the engine (V8) with the runtime environment that provides it with APIs.
The Newtype Pattern: Type Safety for Primitives
Wrap a primitive type in a new struct to give it a unique, compile-time identity. A `Miles(f64)` is different from a `Kilometers(f64)`. Use it to prevent mixing up IDs or units. The footgun: you must explicitly implement or delegate methods for the new type.
Rust's Serde: Taming JSON with Types
Serde JSON translates between human-readable JSON text and native Rust structs, acting as a bilingual interpreter for your data. Use it for web APIs or config files.
Rust's TcpStream: Your Handle to a Network Connection
A `TcpStream` is Rust's handle to a network connection, closing automatically when it goes out of scope. Use it to talk to servers. The footgun: `connect()` can block forever; always prefer `connect_timeout()` in production to avoid hanging.
Rust Enums and Pattern Matching: Type-Safe Alternatives
Rust enums define a type that can be one of several variants, each holding its own data. They're used to model states like `Loading`/`Success`/`Error` or handle optional values with `Option<T>`.
Rust's Fearless Concurrency: Catch Bugs Before They Ship
Rust's "fearless concurrency" uses the ownership and type system to turn data races into compile-time errors. This allows you to safely use threads, message passing, or shared state without runtime surprises. The footgun is assuming this prevents all bugs.
Rust Lifetimes: Preventing Dangling References
Lifetimes are Rust's compile-time guarantee that a reference never outlives the data it points to. The borrow checker uses them to prevent dangling pointers, a common source of bugs.
Daemonizing Go/Rust Apps: Let the OS Do It
Daemonizing an app means running it as a background service, detached from your terminal. This is essential for web servers or job processors. The common footgun is writing custom daemon logic instead of using a system service manager like systemd.
The FromRequest Trait: Consuming Request Bodies in Axum
Axum's `FromRequest` trait defines how to create a type by consuming an HTTP request body. It's the core of extractors like `Json<T>` that deserialize POST data. The footgun: you can only use one `FromRequest` extractor per handler, as it consumes the body.
Rust's Tower Service: One Trait for Clients, Servers, and Middleware
Tower's Service trait is a universal API for async requests. It models any 'request -> future<response>' flow, unifying clients, servers, and middleware. Use it for HTTP servers or database clients. The footgun: ignoring `poll_ready` bypasses backpressure.
Terminal User Interfaces (TUIs): GUIs for the Console
A TUI is a graphical interface built from text, offering rich interactivity without leaving the console. Use them for system monitoring (btop), file management, or database clients. The footgun: don't confuse them with CLIs; TUIs are stateful apps.