Unit 2 - Practice Quiz

Express.js is a minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications.

The Node Package Manager (npm) uses the install command to add packages like Express to a project's dependencies.

The GET method is used to request data from a specified resource. It should not change the state of the server and is considered safe and idempotent.

The app.post() method is used to handle HTTP POST requests, which are typically used for sending data to the server, such as creating a new user or submitting a form.

express.Router acts as a mini-application, allowing you to create modular, mountable route handlers. It's used to organize your application's routes logically.

express-validator is a set of middleware functions that provides tools for validating and sanitizing user input to ensure it meets certain criteria (e.g., checking if an email is valid).

Standard middleware has three arguments (req, res, next), but error-handling middleware is unique in that it has a fourth argument, err, at the beginning to catch errors from other middleware.

The http module is a core part of Node.js that provides the functionality to create and manage HTTP servers and make HTTP requests.

The http.createServer() method creates an instance of http.Server. It takes a callback function that is executed for each incoming request.

The req object is an instance of http.IncomingMessage and contains all the information about the request sent by the client, such as headers, URL, and method.

The res.end() method is crucial in the native http module; it must be called on each response to signify to the server that the response is complete.

The req.url property contains the path part of the URL from the request. You can use an if/else or switch statement on req.url to send different responses for different paths.

A status code of 200 OK is the standard response for successful HTTP requests. 404 means Not Found, and 500 means Internal Server Error.

The statusCode property on the response object (res) is used to set the HTTP status code that will be sent to the client. For example: res.statusCode = 200;.

A monolithic architecture builds an application as a single unit. All components are interconnected and interdependent, and it is deployed as a single entity.

Microservices break a large application into smaller, independent services. This allows teams to work on different services in parallel and scale specific parts of the application without affecting the whole system.

The server.listen() method binds the server to a specific port and host, allowing it to start accepting incoming HTTP requests.

Middleware functions are the building blocks of an Express application. They are executed in sequence and can perform tasks like logging, authentication, and data parsing.

The res.set() method is the standard way to set a single HTTP response header. A common shortcut for this specific task is to use res.json(), which automatically sets the header and sends the JSON response.

res.json() is a convenient helper method in Express that converts a JavaScript object or array into a JSON string, sets the Content-Type header to application/json, and ends the response.

The core concept of Express is the middleware pattern. Each middleware function can process the request, modify the response, or pass control to the next middleware in the stack using the next() function. The entire application is essentially a chain of these middleware functions.

Since npm version 5, npm install <package> automatically saves the package to the dependencies section of package.json. Therefore, the --save flag is technically redundant for this purpose, though it is often used for clarity or backward compatibility with older workflows.

Route parameters, defined with a colon (:) in the URL path, are captured by Express and made available in the req.params object. In this case, req.params would be { userId: '101', bookId: '5432' }.

express.urlencoded() is the middleware responsible for parsing incoming requests with URL-encoded payloads (the default for HTML forms). The parsed data is then populated on the req.body object. express.json() is used for JSON payloads.

The app.use() method is used to mount middleware or routers. By providing a path prefix (/api/users), all routes defined within the userRoutes router will be prepended with this path. app.get is for defining a specific GET route, not for mounting an entire router.

express.Router acts as a "mini-app" that can have its own middleware stack. This is ideal for applying middleware (like an authentication check) to a whole group of related routes (e.g., all /admin/* routes) without affecting other parts of the application.

express-validator separates validation and sanitization. isEmail() is a validator that checks the format. normalizeEmail() is a sanitizer that canonicalizes the email address (which includes converting the domain part to lowercase), making it the correct and idiomatic choice for this task.

The standard pattern is to import the validationResult function. Inside the route handler, you call const errors = validationResult(req);. You then check if errors.isEmpty() is false. If it is not empty, you can return a 400 Bad Request response with the validation errors, typically by calling res.status(400).json({ errors: errors.array() }).

Express identifies an error-handling middleware by its unique signature of four arguments. The presence of the first err argument is what allows Express to differentiate it from regular middleware (req, res, next) and call it only when an error is passed to next().

Calling next() with an argument, such as next(error), signals to Express that an error has occurred. Express will then skip any subsequent non-error-handling middleware and jump directly to the first error-handling middleware that has the (err, req, res, next) signature.

The native http module provides the foundational, low-level tools for creating an HTTP server. While it lacks the convenient abstractions of Express, it is extremely lightweight and fast, making it a good choice for simple microservices, proxies, or situations where performance is critical and framework overhead is undesirable.

The http.createServer method creates the server instance. However, the server does not start accepting connections until server.listen() is called. This method binds the server to a port and hostname, placing it in a listening state for incoming requests.

The http.IncomingMessage object (commonly req or request) has a method property which is a string containing the HTTP request method, such as 'GET', 'POST', 'PUT', etc.

response.write() can be used to send chunks of the response body, but response.end() must be called to signal to the server that all response headers and body have been sent. This finalizes the response. res.send() is a higher-level method provided by frameworks like Express.

In the native http module, the req.url property contains the full request URL string that comes after the domain, including the path and any query parameters (e.g., /about?user=1). For basic routing, you typically check this property to decide which response to send.

The status code 201 Created is the standard response for a POST or PUT request that successfully results in the creation of a new resource. 200 OK is for a generic successful request. 204 No Content is for success with no body. You set this code by assigning a value to the res.statusCode property before sending headers.

The correct method on the http.ServerResponse object for setting a single response header is setHeader(name, value). This method should be called before res.end() or res.write() are called, as they may implicitly send the headers.

A key benefit of microservices is independent deployability. Teams can update, test, and deploy their specific service on their own schedule without coordinating a large-scale, high-risk deployment of the entire monolithic application. This leads to faster release cycles.

In a monolith, all data typically resides in a single database, making transactions straightforward (ACID). In a microservices architecture, each service often owns its own data. This creates the challenge of managing transactions and consistency across multiple services and databases, often requiring complex patterns like the Saga pattern.

Conway's Law states that organizations design systems that mirror their own communication structure. This is highly relevant to the monoliths vs. microservices debate. To successfully build microservices, it's often necessary to structure teams as small, autonomous, cross-functional units that own a service end-to-end, rather than having large, siloed functional teams (UI, backend, DB) as is common with monoliths.

In Express, errors occurring in asynchronous callbacks (like setTimeout, database queries, or file I/O) must be explicitly passed to the next() function. Simply throwing the error will not work because the call stack of the Express router has already been cleared. The error would be unhandled and crash the Node.js process. Calling next(err) passes control to the next middleware in the stack that has an error-handling signature (err, req, res, next), which is the intended behavior.

When routers are nested, the request processing flows from the outermost middleware to the innermost. The request GET /api/v1/data first matches the mount point /api on the app object, which passes control to parentRouter. The middleware on parentRouter is executed (Parent Middleware is logged). This middleware calls next(), so Express continues to match the rest of the path (/v1/data) against routes within parentRouter. It finds the mount point /v1 for childRouter and passes control. Finally, the route /data on childRouter is matched, and its handler is executed (Child Route is logged).

The core mechanism that handles this is backpressure, a fundamental feature of Node.js Streams. The response object (res) is a writable stream. When the client's network buffer (managed by the OS kernel) is full, calls to res.write() (which is used internally by pipe()) will return false. The .pipe() method automatically listens for this signal and pauses the readable stream (the file stream) from reading more data. Once the buffer has drained and is ready for more data, the writable stream emits a 'drain' event, and .pipe() resumes the readable stream. This prevents the server from reading the entire file into memory at once.

The Saga pattern is designed to manage data consistency across multiple microservices without using distributed locks or a two-phase commit, which are complex and can reduce availability. In a Saga, a sequence of local transactions is executed. If any transaction fails, a series of compensating transactions are run to undo the impact of the preceding successful transactions. In this case, if the payment fails, the Saga would trigger a 'CancelOrder' command in the Order Service, effectively rolling back the operation.

For asynchronous custom validators in express-validator, the correct way to indicate a validation failure is to return a rejected Promise. Using async/await, this is achieved by throwing an Error. The message of the error will be used as the validation error message. Returning false or a resolved promise with false is for synchronous validators. The third option is close, but it doesn't explicitly return the promise, which can lead to unexpected behavior. The most robust and idiomatic approach is to throw an error within the async function, which is equivalent to returning a rejected promise.

The PUT method is used to create or replace a resource at a target URI. The first time the request is received, the resource does not exist, so it is created. The correct status code for a successful creation is 201 Created. Since PUT is idempotent, the second request should have the same net effect. The server sees that the resource already exists and replaces it with the same data. A successful PUT that updates an existing resource should return 200 OK or 204 No Content. Therefore, 201 followed by 200 is the most semantically correct sequence. 304 is for conditional GET requests, and 409 would imply a state conflict that prevents the request from being completed, which is not the case in an idempotent update.

Each of these properties controls a different timeout. server.timeout sets the general socket inactivity timeout. server.headersTimeout limits the time a client has to send headers. server.requestTimeout sets a timeout for the entire request. However, server.keepAliveTimeout is specifically designed to control how long an idle socket is kept open in the keep-alive state after the last response is sent, before it is automatically destroyed. This is the precise setting for controlling resource consumption from idle keep-alive connections.

While the HTTP/1.1 specification does not explicitly forbid a body in a GET request, it assigns no semantic meaning to it. As a result, most clients and servers ignore it. The express.json() middleware, which is built on the body-parser library, is designed to not parse bodies for GET, HEAD, or DELETE requests. It checks the HTTP method and effectively skips the body-parsing logic for these methods. This usually means req.body will remain undefined as it was before the middleware ran.

Path traversal attacks often use URL-encoded characters (like %2f for / or %2e for .) to bypass simple string checks. Therefore, the first step must be to decode the URI component to its actual character representation. After decoding, a path like /api/users/../products/../images can be resolved. The path.normalize() function is then used to correctly resolve path segments like . and .., resulting in the canonical path /api/images. Performing normalization before decoding would fail to resolve the encoded ..%2f segment correctly, leaving the vulnerability open.

Express's router.param() function creates a middleware that is triggered whenever the specified parameter (id in this case) is present in a matched route. Express routing is smart enough to match the most specific route first, so /123/profile will match /:id/profile over /:id. Once this route is matched, Express notices the :id parameter and executes the corresponding param handler first. The handler attaches the user object to req and calls next(). Control then returns to the /:id/profile route handler, which can now access req.user.

The CAP theorem states that a distributed system can only provide two of the following three guarantees: Consistency, Availability, and Partition Tolerance. In a microservices architecture, network partitions (P) are a reality and must be tolerated. To maintain high availability (A), the system must be able to respond even if it can't communicate with another service that holds the latest data. This necessitates sacrificing strong consistency (C). The practical result is eventual consistency, where a service might respond with slightly outdated (stale) data during a partition, with the expectation that the data will become consistent across the system once the partition heals.

The server.close() method is designed for graceful shutdowns. When called, it immediately stops the server from accepting any new connections. However, it does not forcefully terminate existing connections. It waits for all currently active connections to complete their request/response cycle and close naturally. Only after the very last connection has been closed will the server itself shut down and the optional callback function be invoked. This ensures that no requests are dropped during the shutdown process.

The sanitization chain is applied sequentially.

1. trim(): Removes leading/trailing whitespace. The string becomes "<IMG SRC=j&#X41vascript:alert('XSS');>".
2. escape(): Replaces <, >, &, ', " with their HTML entities. The string becomes "<IMG SRC=j&#X41vascript:alert('XSS');>". Note that the ampersand in &#X41 is also escaped to &.
3. toLowerCase(): Converts the entire string to lowercase. The final result is "<img src=j&#x41vascript:alert('xss');>".

res.end is a low-level method inherited from Node's native http.ServerResponse. It sends the data and closes the connection without performing any extra processing. In contrast, res.send is a higher-level Express method that provides additional functionality. It inspects the type of the argument passed to it. If it's a Buffer, res.send will automatically set the Content-Type response header to application/octet-stream, which is the correct MIME type for arbitrary binary data. This makes res.send more convenient and less error-prone for common use cases.

Express processes middleware in the order they are defined. middlewareA runs and calls next(). Then, middlewareB runs. When middlewareB calls next() with an argument (an error object), Express immediately stops processing the regular middleware stack and begins searching for an error-handling middleware. It skips handlerH and any other regular middleware. It finds errorHandlerE (which has the signature (err, req, res, next)) and executes it. Therefore, the execution flow is A -> B -> E.

Modern versions of NPM (v3+) resolve dependency conflicts by creating a nested node_modules structure. NPM will try to install the most widely compatible or highest version of a dependency (in this case, a 4.17.x version for lib-A) at the top level. When it processes lib-B, it sees that its dependency on Express (~4.16.0, i.e., 4.16.x) is not satisfied by the top-level version. To resolve this, it installs a specific version of Express that satisfies lib-B's requirement inside lib-B's own node_modules folder. This prevents version clashes and allows both libraries to function correctly with the version of Express they were designed for.

The express.urlencoded middleware has an extended option that determines the parsing library. When extended: false (the historical default), it uses the classic querystring library, which does not support nested objects. When extended: true, it uses the qs library, which allows for rich, nested objects and arrays to be parsed from the URL-encoded data. To handle a structure like user[address][city], you must explicitly set extended: true.

Express adds layers of abstraction for routing, middleware processing, and request/response object enhancements. While these are incredibly useful for building applications (APIs, websites), they introduce a small amount of overhead. For a highly specialized, performance-critical task like a minimal reverse proxy where every microsecond counts and the advanced features of Express are unused, dropping down to the native http module allows for direct, low-level control over the request and response streams, yielding the best possible performance by avoiding the framework's overhead.

The If-None-Match header is used for conditional requests. It tells the server to only send the full resource if its ETag does not match any of the ETags provided by the client. Since the server's ETag "xyz123" matches the client's, it means the client's cached version is still fresh. The correct server response is 304 Not Modified. This response must not contain a body, as it instructs the client to use the version it already has in its cache. This is a crucial optimization for saving bandwidth and improving performance.

Express wraps its synchronous middleware and route handlers in a try...catch block internally. If an error is thrown, it's caught and passed along to the error-handling chain (as if next(err) was called). However, this mechanism does not extend to asynchronous operations that execute outside the initial call stack. An error thrown inside a callback for fs.readFile, for instance, happens on a new turn of the event loop. Express's try...catch is no longer on the stack, so the error is an uncaughtException which, by default, crashes the Node.js process. This is why in callback-based async code, you must manually check for the err object and call next(err).