V8 (Google's JavaScript engine — compiles and executes JS), libuv (C library — provides the event loop, thread pool, and async I/O), and the Node.js standard library (fs, http, path, crypto, etc.). → Module 1

1. Timers — executes setTimeout and setInterval callbacks
2. Pending callbacks — I/O callbacks deferred from previous cycle
3. Idle / Prepare — internal use
4. Poll — retrieves new I/O events; blocks if queue is empty
5. Check — executes setImmediate callbacks
6. Close callbacks — socket close events, etc.

→ Module 5

process.nextTick() fires before the event loop moves to the next phase — it is part of the microtask queue and runs immediately after the current operation completes. setImmediate() fires in the Check phase of the event loop — after I/O events have been processed. nextTick always runs before setImmediate. → Module 5

exports is a reference to module.exports. They diverge when you reassign exports directly: exports = { fn } — this breaks the reference, and module.exports remains unchanged. Always use module.exports = { fn } or exports.fn = fn. Never reassign exports itself. → Module 4

It switches the project to ES Modules — all .js files are treated as ESM (import/export syntax). Without it, .js files use CommonJS (require/module.exports). You can use .mjs for ESM files and .cjs for CJS files regardless of the type setting. → Module 4

npm install reads package.json, resolves versions, and updates package-lock.json. npm ci reads package-lock.json exactly and fails if it does not match package.json. npm ci is faster, reproducible, and used in CI/CD pipelines. Never use npm install in CI. → Module 8

The libuv thread pool handles operations that cannot be done asynchronously at the OS level: DNS lookups (dns.lookup), file system operations (fs), crypto operations (crypto.pbkdf2, crypto.randomBytes). The default pool size is 4 threads. Set UV_THREADPOOL_SIZE to increase it (max 128). → Module 5

Promise.allSettled() waits for all promises to either resolve or reject, and returns an array of result objects ({ status: 'fulfilled', value } or { status: 'rejected', reason }). Use it when you want all operations to complete regardless of failures — e.g., sending notifications to multiple users where one failure should not prevent the others. Promise.all() rejects immediately if any promise rejects. → Module 6

Middleware executes in the order it is registered with app.use(). A request reaches the error handler (a function with 4 parameters: err, req, res, next) when any middleware or route handler calls next(error) or throws in an async function (with async error wrapping). The error handler must be registered after all routes and other middleware. → Module 11

app.use('/path', router) mounts the router at a path prefix — all routes in the router are prefixed with /path. router.use(middleware) applies middleware only to routes defined in that router. Router-level middleware does not affect other routers mounted on the main app. → Module 13

422 Unprocessable Entity — the request was well-formed (valid JSON, correct Content-Type) but the content failed validation. Some APIs use 400 Bad Request for this, but 422 is more semantically precise. Always include a errors array in the body with field-level details. → Module 10

Cursor-based pagination uses the last item's ID or timestamp as a reference point: WHERE id > :cursor LIMIT 20. Offset pagination uses SKIP (page-1)*limit LIMIT limit. Cursor pagination does not degrade with large offsets — skipping 1 million records in MongoDB or PostgreSQL is slow, but querying from a cursor is O(log n). Use cursor pagination for large datasets, real-time feeds, and infinite scroll. → Module 10

• Controller: HTTP layer — parses req, calls a service, writes res. No business logic.
• Service: Business logic — orchestrates data, applies rules, throws domain errors. No knowledge of req/res.
• Repository (or Model): Data access — queries the database. No business logic.

→ Module 13

select: false excludes the field from all query results by default. To include it explicitly in a query, use .select('+fieldName'). Use it for sensitive fields like password — this prevents accidentally returning them in API responses. → Module 14

save() triggers all Mongoose validators and pre/post save middleware. findByIdAndUpdate() bypasses them by default — pass { runValidators: true } to enable validators, but pre-save hooks still do not run. Use save() when middleware must fire (e.g., password hashing). → Module 14

prisma migrate dev creates new migration files from schema changes and applies them (for development). prisma migrate deploy applies existing migration files without creating new ones and without prompting — designed for production and CI/CD. Never run prisma migrate dev in production. → Module 15

By default, a nested router does not have access to parent route parameters — Express resets req.params at each router boundary. express.Router({ mergeParams: true }) preserves parent params in nested routers. Required when a child router needs a parent's req.params (e.g., /workspaces/:workspaceId/tasks — the tasks router needs workspaceId). → Module 13 / → Module 16

N+1 occurs when you fetch N records then make one DB query per record for related data: const posts = await Post.find() then for (post of posts) post.author = await User.findById(post.author) — N+1 total queries. Fix: await Post.find().populate('author', 'name email') — Mongoose fetches all authors in one additional query. In Prisma: prisma.post.findMany({ include: { author: true } }). → Module 16

1. Receive request
2. Check cache for the key → cache hit: return cached value immediately
3. Cache miss: query the database
4. Store the result in cache with a TTL
5. Return the result

The application manages the cache explicitly. Data is only cached when first requested. → Module 17

KEYS * is O(N) and blocks Redis while it scans the entire keyspace — on a large dataset this can freeze Redis for seconds, affecting all clients. Use SCAN instead: it iterates in batches without blocking: redis.scanStream({ match: 'posts:*', count: 100 }). → Module 17

• Header: algorithm (alg: "HS256") and token type (typ: "JWT") — base64url encoded
• Payload: claims — sub (subject/userId), role, exp (expiry), iat (issued at) — base64url encoded, not encrypted
• Signature: HMAC of header + payload using the secret key — verifies integrity

→ Module 18

OAuth involves a cross-site redirect — the browser redirects from Google back to your domain. sameSite: 'strict' blocks cookies on cross-site navigations entirely, so the refresh token cookie would not be sent after the OAuth redirect. sameSite: 'lax' allows cookies on top-level navigations (following a link, form submission to the site) but blocks on cross-origin fetch/XHR, providing CSRF protection while supporting OAuth. → Module 21

4 (the minimum). In production you use 12 (300ms per hash). In tests you might run thousands of hash operations — at cost 12 that's minutes. Cost 4 produces a valid bcrypt hash in ~1ms, keeping tests fast without compromising correctness. Set BCRYPT_ROUNDS=4 in .env.test. → Module 19

• 401 Unauthorized: the request lacks valid authentication — no token, invalid token, or expired token. The client should authenticate and retry.
• 403 Forbidden: the client is authenticated but does not have permission to perform the action. Authenticating again will not help.

→ Module 20

By default, Passport serialises the authenticated user into an HTTP session (cookie-based). { session: false } disables this — no session is created. In a JWT API you issue a token instead of a session, so sessions are unnecessary overhead. Always pass { session: false } when building a stateless JWT API with Passport. → Module 21

Express matches routes in registration order. If the catch-all is registered first, it intercepts all requests — including API calls — and returns index.html. API routes must be registered before the catch-all so /api/* requests reach their handlers. → Module 22

// vite.config.js
server: {
  proxy: {
    '/api': { target: 'http://localhost:3000', changeOrigin: true }
  }
}

In production, React is served from the same Express server (same origin), so CORS is never needed. → Module 22

Server Components (default) render on the server, can directly access databases and secrets, and ship zero JavaScript to the browser. Client Components ('use client' directive) render in the browser, handle interactivity (event handlers, hooks), and their JavaScript is included in the bundle. Server Components can render Client Components but not vice versa. → Module 23

This is an Express Router concept, not Socket.IO. In Socket.IO, rooms are managed with socket.join(roomId) and socket.to(roomId).emit(event, data) — no mergeParams needed. Socket.IO handles room routing internally. → Module 26

• io.to(roomId).emit() — sends to everyone in the room, including the current socket
• socket.to(roomId).emit() — sends to everyone in the room except the current socket

Use socket.to() when broadcasting a user's own action (they already see it client-side). Use io.to() when you need to notify everyone including the sender. → Module 26

await expect(asyncFn()).rejects.toThrow('message');
// or
await expect(asyncFn()).rejects.toMatchObject({ statusCode: 404 });

Do NOT await the function outside expect — the rejection must be inside expect() to be caught. → Module 27

jest.fn() creates a standalone mock function from scratch — no original implementation. jest.spyOn(object, 'method') wraps an existing method on an object, recording calls but still calling the original by default. You can then optionally override the implementation with .mockImplementation(). Always call spy.mockRestore() in afterEach to restore the original. → Module 28

Writing the test first forces you to design the interface before the implementation — you think about how the function will be called rather than how it will work. It ensures every line of code is covered by a test (because the test existed first), produces tests that describe intent rather than implementation details, and creates a fast feedback loop (Red → Green → Refactor). → Module 28

The application will throw an error the first time a request hits that route — potentially hours or days after startup. The fix is to validate all required env vars at startup (before the server starts listening) using Zod or Joi. If validation fails, the process exits immediately with a clear error listing which variables are missing. → Module 29

.dockerignore prevents files from being sent to the Docker build context (and from being copied into the image). Always include: node_modules/ (Docker installs fresh), .env (secrets must not be in images), .git/, coverage/, and test files. A lean build context speeds up docker build and reduces the image attack surface. → Module 30

Running as root means that if an attacker exploits the application, they have root access inside the container — and potentially on the host if container isolation fails. Use USER node (the built-in non-root user in official Node images) or create a dedicated user: RUN adduser -S appuser && USER appuser. → Module 30

pm2 restart kills all processes and starts them again — causes downtime. pm2 reload performs a zero-downtime reload in cluster mode: it starts new workers, waits for them to be ready (listening on the port), then sends SIGINT to old workers one at a time. New requests go to the new workers while old workers drain their in-flight requests. → Module 32

PM2 spawns one worker process per available CPU core (os.availableParallelism() or os.cpus().length). On a 4-core server, instances: 'max' starts 4 Node.js processes all sharing port 3000. The OS load-balances incoming connections across them, fully utilising all CPU cores. → Module 32

SIGTERM is sent by the OS, PM2, or Kubernetes when requesting a graceful shutdown (e.g., during pm2 reload or a container stop). The handler should: stop accepting new connections (server.close()), wait for in-flight requests to complete, close database connections, and then call process.exit(0). Without a SIGTERM handler, Node.js exits immediately — leaving in-flight requests broken and potentially corrupting database operations. → Module 32

Cluster module: spawns multiple Node.js processes, each with its own event loop, V8 instance, and memory. Used for HTTP scaling across CPU cores. Workers communicate via IPC.

Worker threads: run within the same process, sharing memory (via SharedArrayBuffer). Used for CPU-intensive tasks that would block the event loop (image processing, crypto, data compression). Workers communicate via postMessage.

→ Module 32