This session introduces Node.js, a powerful technology for building web servers, applications, and more. Instructor Piyush Garg, a full-stack developer with 8+ years of Node.js experience, aims to guide beginners to intermediate levels. The only prerequisite is basic JavaScript knowledge.

The core of understanding Node.js lies in grasping what JavaScript is and how it traditionally runs. Historically, JavaScript was confined to web browsers, executing within JavaScript engines like Chrome's V8, Firefox's SpiderMonkey, or Safari's WebKit. These engines compile and run JavaScript code, enabling interactive web pages. Without a browser's embedded engine, JavaScript couldn't run standalone.

This limitation changed with Node.js. Ryan Dahl, the creator of Node.js, took Chrome's open-source V8 JavaScript engine and embedded it into a C++ program. Since C++ can run outside a browser and interact directly with a computer's operating system, this ingenious combination allowed JavaScript to escape the browser sandbox.

Therefore, Node.js is not a framework or a library; it is a JavaScript runtime environment. It provides the necessary environment for JavaScript code to be executed on a server or a local machine, outside of a web browser. This capability unlocked new possibilities, enabling JavaScript for backend web development, command-line interface (CLI) tools, mobile applications, IoT devices, and more. The potential applications of Node.js are vast, transforming JavaScript into a versatile language for full-stack development.

This session guides you through the straightforward process of installing Node.js on your machine, which is crucial for running JavaScript code outside of a web browser.

The recommended approach is to download the LTS (Long Term Support) version from the official Node.js website (nodejs.org). LTS releases are stable and thoroughly tested, making them ideal for development and production environments. While "Current" versions offer the latest features, they might be unstable and aren't recommended for serious projects. Node.js typically releases new LTS versions annually (even-numbered versions are LTS, odd-numbered are current development branches).

The installation involves downloading the pre-built installer for your specific operating system (macOS, Linux, or Windows) and CPU architecture, then following a standard "next, next, agree" setup wizard.

Once installed, you can verify the installation by opening your terminal and running two commands:

1. node -v: This command displays the installed Node.js version (e.g., v22.1.0), confirming that Node.js is correctly set up.

2. npm -v: This command shows the npm (Node Package Manager) version. npm is automatically bundled and installed with Node.js and is essential for managing external JavaScript packages and dependencies in your projects.

The session also introduces the Node.js REPL (Read-Eval-Print Loop), accessible by simply typing node in the terminal. This provides an interactive console where you can immediately write and execute JavaScript code, perfect for quick tests and learning. You can exit the REPL by pressing Ctrl + D. Successful installation of Node.js and npm opens up a world of possibilities for building web servers, command-line tools, and more with JavaScript.

This session guides you through running your first Node.js code, emphasizing how JavaScript can now be executed outside the traditional browser environment.

The process begins by setting up a new, empty project folder and opening it in a code editor like Visual Studio Code. Inside this folder, you create a new JavaScript file (e.g., script.js).

To execute this JavaScript file using Node.js:

1. Open your terminal or command prompt.

2. Navigate to the project folder containing script.js.

3. Run the command: node script.js. Node.js, acting as the JavaScript runtime environment, will execute the code within script.js, and any console.log() statements will appear directly in your terminal. You can optionally omit the .js extension, simply running node script.

The session also introduces useful Node.js CLI commands:

• node --help: Provides a comprehensive list of all available Node.js command-line options and arguments, allowing you to explore its capabilities.

• node --watch (or node -w): This command is incredibly useful for development. When running node --watch script.js, Node.js will automatically re-execute the script every time changes are saved to script.js, streamlining the development workflow. You can exit watch mode by pressing Ctrl + C.

Furthermore, the session reiterates the importance of npm (Node Package Manager), which is bundled with Node.js. Commands like npm --help allow you to explore npm's functionalities, including installing and managing external JavaScript packages, which will be crucial for building more complex Node.js applications.

This session clarifies a crucial distinction: not all JavaScript code runs universally. While JavaScript in a browser can use functions like alert(), fetch(), document, and window, these are Web APIs provided by the browser itself, not native JavaScript features. Consequently, if you try to run alert() in a Node.js environment, it will fail because Node.js, being a command-line runtime, lacks a graphical user interface (GUI) or browser-specific functionalities.

Node.js focuses on backend operations. While it re-implements some universally useful Web APIs like setTimeout() and setInterval() (which are also technically browser APIs), it avoids browser-specific ones. This means JavaScript code written for browser interaction (DOM manipulation, alerts) will not work in Node.js, and conversely, Node.js-specific features like file system access (fs module) or cryptography (crypto module) won't run directly in a browser.

In essence, JavaScript has two distinct runtime environments: the browser environment (with its Web APIs) and the Node.js environment (with its own set of backend APIs). Understanding these subtle differences is key to writing effective JavaScript for different platforms.

This session dives into Node.js modules, which are collections of reusable code providing specific functionalities. Node.js offers three types of modules: built-in modules (provided out-of-the-box by Node.js), third-party modules (downloaded via npm), and custom modules (created for your own projects).

The focus is on built-in modules, specifically the File System (FS) module. Unlike browser JavaScript, Node.js can directly access your machine's file system due to its C++ foundation.

To use a built-in module, you use the require() function (e.g., const fs = require('fs');). This function loads the module's code and makes its functionalities available. The require() function has a specific lookup order: it first searches for third-party modules, then built-in modules. Custom modules are identified by paths (e.g., require('./myModule.js')).

The session demonstrates using fs.readFileSync('notes.txt', 'utf8') to synchronously read the content of a local file. This showcases Node.js's ability to perform file I/O, a task impossible in a pure browser environment. Understanding require() and built-in modules like FS is fundamental for building backend applications with Node.js.

This session dives into npm (Node Package Manager), Node.js's default package manager, explaining its role in handling project dependencies and the key files it uses.

npm is primarily used to install, manage, and share JavaScript packages. It automatically comes with your Node.js installation. Before installing packages, you need to initialize your project as an npm package by running npm init in your project's root directory. This command interactively creates a package.json file.

The package.json file acts as a manifest for your project. It stores metadata like the project's name, version, and, crucially, its dependencies (external packages your project relies on).

When you run npm install <package-name> (or npm i <package-name>), npm downloads the package's source code from the npm registry (the public repository of JavaScript packages) and places it into a node_modules folder in your project. This node_modules folder contains all the external code your project uses.

Additionally, npm automatically generates a package-lock.json file. This file precisely records the exact versions of all installed packages and their sub-dependencies, ensuring reproducible builds across different environments. You should never commit node_modules or package-lock.json to version control (like Git) as they are automatically regenerated by running npm install. The package.json file is the only dependency-related file you typically share.

This session delves into the Node.js built-in File System (FS) module, a powerful tool for interacting with your computer's file system directly from JavaScript.

To use the FS module, you require() it: const fs = require('fs');. A newer, preferred syntax to explicitly indicate it's a built-in module is require('node:fs'), which also helps avoid naming conflicts with third-party packages.

The FS module provides both synchronous (*Sync) and asynchronous methods. This session demonstrates synchronous operations:

• Reading files: fs.readFileSync('filename.txt', 'utf8') reads file content.

• Writing files: fs.writeFileSync('copy.txt', 'content', 'utf8') creates/overwrites files.

• Appending to files: fs.appendFileSync('log.txt', 'new content') adds data without overwriting.

• Creating directories: fs.mkdirSync('foldername', { recursive: true }) creates folders, recursive: true for nested paths.

• Removing directories: fs.rmdirSync('foldername') removes empty folders. (Note: fs.rmSync is a newer, more versatile method for removing files/directories, even non-empty ones, often with recursive: true).

• Deleting files: fs.unlinkSync('filename.txt') deletes files.

The FS module empowers Node.js applications to perform robust file I/O operations directly on the server or local machine, essential for backend development.

This session addresses a critical concept in Node.js: the difference between synchronous (blocking) and asynchronous (non-blocking) operations, which is fundamental to Node.js's performance model.

The demonstration uses the FS (File System) module to read a file (notes.txt).

• Synchronous (*Sync) operations (e.g., fs.readFileSync): These are blocking. When fs.readFileSync is called, the Node.js process stops and waits for the file reading to complete before moving to the next line of code. If reading a large file (e.g., 1GB), this could block the entire server for minutes, making it unresponsive to other users.

• Asynchronous (non-*Sync) operations (e.g., fs.readFile): These are non-blocking. When fs.readFile is called, Node.js initiates the file reading in the background and immediately moves to execute the subsequent lines of code. Once the file reading is complete, a callback function (passed as an argument to fs.readFile) is executed, receiving the data or any errors. This allows the server to remain responsive and handle multiple requests concurrently.

The core takeaway is to prefer asynchronous, non-blocking operations for heavy tasks (like file I/O or network requests) in Node.js to ensure server responsiveness and efficient resource utilization, especially in web servers.

This session delves deeper into the core of Node.js's internal working by explaining synchronous (blocking) versus asynchronous (non-blocking) operations. This distinction is crucial for understanding how Node.js handles concurrent tasks efficiently.

Using the File System (FS) module as an example, the instructor contrasts fs.readFileSync (synchronous) with fs.readFile (asynchronous).

• Synchronous operations are blocking: the code execution halts until the operation completes. If reading a large file, the entire program, including a web server, would pause, leading to unresponsiveness.

• Asynchronous operations are non-blocking: Node.js initiates the operation in the background (e.g., reading a file) and immediately proceeds to execute subsequent code. Once the background task finishes, a callback function is triggered, receiving the result or any errors. This enables Node.js to manage multiple I/O operations without blocking the main thread, making it highly scalable for web servers.

The fundamental principle is that for heavy tasks like file I/O or network requests, asynchronous methods should always be preferred to ensure the application remains responsive. The architectural implications of this asynchronous nature are what make Node.js efficient in handling many concurrent connections.

This session introduces Events in Node.js, a fundamental concept for understanding its asynchronous, event-driven architecture. The core idea is that instead of constantly "polling" for changes (like checking a doorbell every second), Node.js operates on an event model where actions "trigger" specific responses.

An analogy is used: rather than repeatedly checking if an Amazon package has arrived (blocking operation), a delivery person rings the doorbell (an event), prompting you to respond. Similarly, in Node.js, the CPU isn't constantly checking for incoming requests; it's invoked only when an event occurs.

Key terms introduced:

• Event-driven architecture: A programming paradigm where the flow of the program is determined by events (e.g., a user click, a file read completion, a network request arriving).

• Emitters: Objects that "emit" named events (like the delivery person ringing the bell).

• Listeners: Functions that "listen" for specific emitted events and execute a response when that event occurs. Listeners can be "multi-callable" (respond every time) or "single-callable" (respond only once).

Node.js's core API (including FS module and HTTP module) is built around this asynchronous, event-driven model, making it highly efficient and non-blocking. This foundational understanding is crucial for building scalable real-time applications like chat apps and notification systems.

This session dives into practical implementation of Node.js Events, explaining how to create and manage event-driven architecture using the EventEmitter class. This is a core concept for building responsive and efficient Node.js applications.

First, you import the EventEmitter class: const EventEmitter = require('node:events');. This module is built-in to Node.js, so no installation is required. An instance of EventEmitter is then created: const eventEmitter = new EventEmitter();.

Key operations demonstrated:

• Attaching Listeners (.on() / .once()): You register a callback function (the "listener") to a named event. .on('eventName', callback) registers a listener that will execute every time the event is emitted. .once('eventName', callback) registers a listener that executes only once after the event is emitted, then de-registers itself. Listeners can accept data passed during emission.

• Emitting Events (.emit()): You trigger a named event, causing all registered listeners for that event to execute. eventEmitter.emit('eventName', data_to_pass) triggers the event and sends optional data to its listeners.

• Removing Listeners (.removeListener()): You can explicitly remove a listener from an event. eventEmitter.removeListener('eventName', listenerFunction) detaches a specific listener.

The session emphasizes that EventEmitter is crucial for handling custom events and building publisher-subscriber (pub/sub) models in Node.js, allowing for clean, decoupled code where components react to actions without direct dependencies. This pattern is foundational for various Node.js built-in modules (like FS and HTTP) and scalable real-time applications.

This session guides you through building a rudimentary chat application simulation using Node.js's event-driven architecture. The goal is to illustrate how events are emitted and handled, forming the backbone of real-time applications like chat rooms and push notifications.

The core logic resides in a ChatRoom class, which extends EventEmitter (from node:events). This inheritance grants the ChatRoom instance the ability to emit and listen for custom events.

Key functionalities implemented:

• constructor(): Initializes a Set to store active users, ensuring uniqueness.

• join(user): Adds a user to the active set and emits a "join" event with the user's name as data.

• sendMessage(user, message): Validates if the user is active. If so, it emits a "message" event, passing the user and message data. If the user isn't active, it logs an error.

• leave(user): Removes a user from the active set and emits a "leave" event.

On the "driver" side (index.js), an instance of ChatRoom is created. Event listeners are then set up using chat.on() to react to "join," "message," and "leave" events, logging corresponding messages to the console. The session simulates chat interactions by calling join(), sendMessage(), and leave() methods for different users, demonstrating the event-driven flow in action. This basic setup provides foundational knowledge for building more complex, real-time Node.js applications.

This session introduces Buffers in Node.js, a fundamental concept for low-level binary data handling, especially crucial when dealing with file I/O and networking.

At its core, a Buffer is a temporary storage area for raw binary data in memory. Unlike JavaScript strings (which are typically UTF-16 encoded), Buffers allow efficient manipulation of data represented in formats like UTF-8, hexadecimal, or pure binary (0s and 1s). This is vital because many operations, especially those interacting with system resources (like reading files or network streams), require data in these raw binary formats for faster processing.

Buffers are used extensively in Node.js's built-in modules such as FS (File System) and Networking (streams, TCP, WebSockets). They enable Node.js to manage data chunks efficiently, minimizing memory overhead and improving performance in scenarios like streaming large files or handling network protocols. Understanding Buffers provides deeper insight into how Node.js interacts directly with memory and external resources, contrasting with higher-level JavaScript string manipulations. While complex, Buffers are indispensable for optimizing performance in data-intensive and real-time Node.js applications.

This session provides a practical introduction to Node.js Buffers, showcasing how to create and manipulate raw binary data in memory. Understanding Buffers is fundamental for efficient file I/O and networking operations in Node.js.

You start by creating a Buffer instance, typically by allocating a specific size (e.g., Buffer.alloc(4) for 4 bytes) or directly from a string (e.g., Buffer.from('hello chai')).

• When a Buffer is allocated, its memory is initialized with zeros. However, allocUnsafe allocates uninitialized memory, which might contain sensitive "garbage" data, making it faster but risky.

• Buffers behave like arrays, allowing direct manipulation of individual bytes (e.g., buf[0] = 0x4A).

• To convert a Buffer back to a human-readable string, you use buf.toString(), optionally specifying encoding (e.g., 'utf8') or a specific range of bytes.

The session demonstrates how Buffers can be concatenated (Buffer.concat([buf1, buf2])) and their length accessed (buf.length). These low-level memory operations are crucial for optimizing performance when dealing with large data streams, file transfers, and network protocols in Node.js, where direct binary data manipulation is more efficient than standard JavaScript strings.

This session introduces the fundamental concepts behind web servers and HTTP (Hypertext Transfer Protocol), crucial for building any web application with Node.js.

HTTP is the protocol governing how information is transferred over the Internet. Any web interaction involves two main components: a client and a server.

• A client (e.g., your browser, mobile phone) initiates communication by sending a request to a server.

• A server is essentially a computer connected to the internet 24/7 with a public, static IP address (e.g., hosted on AWS, Azure, or Google Cloud). Its role is to receive and process these requests.

Requests can vary in type (e.g., GET for fetching data, POST for submitting data, DELETE for removing data). Upon receiving a request, the server performs various operations like authentication, authorization, validation, and data processing (often involving database interactions with systems like PostgreSQL, MongoDB, or MySQL).

After processing, the server sends back a response to the client. This entire interaction is known as the request-response cycle, which enables seamless communication between clients and servers across the internet. Understanding this cycle is foundational for developing HTTP servers and web applications in Node.js.

This session explains the fundamental principles of web server communication using HTTP (Hypertext Transfer Protocol). As a backend developer, your role is to build a server that effectively handles incoming requests and sends back appropriate responses.

The interaction begins with a client (e.g., your browser) sending a request to a server. This request is always accompanied by an HTTP method, indicating the client's intended action:

• GET: To retrieve (read) data from the server (e.g., viewing a webpage, fetching tweets).

• POST: To submit (create) new data to the server (e.g., sending a tweet, uploading a video).

• PUT: To replace (update fully) existing data on the server.

• PATCH: To partially update existing data on the server.

• DELETE: To remove data from the server.

After processing the request, the server sends back a response, which always includes an HTTP status code. These numeric codes (e.g., 200, 404, 500) indicate the outcome of the request:

• 1xx (Informational): Request received, continuing process.

• 2xx (Success): Request successfully received, understood, and accepted (e.g., 200 OK, 201 Created).

• 3xx (Redirection): Further action needs to be taken to complete the request (e.g., 301 Moved Permanently).

• 4xx (Client Error): The client made a mistake (e.g., 400 Bad Request, 404 Not Found, 401 Unauthorized).

• 5xx (Server Error): The server encountered an error (e.g., 500 Internal Server Error).

This request-response cycle, defined by HTTP methods and status codes, is the bedrock of all web communication.

This session guides you through creating your very first HTTP server using Node.js, building upon the fundamental concepts of HTTP methods and status codes.

You'll start by creating a new project folder and an index.js file. The core of the server lies in the Node.js built-in http module.

Key steps to create an HTTP server:

1. Import http module: const http = require('node:http');

2. Create Server: http.createServer() is used to instantiate the server. This method takes a callback function that executes for every incoming HTTP request. This callback receives two arguments: request (an object representing the incoming request) and response (an object used to send data back to the client).

3. Handle Requests: Inside the callback, you can log incoming requests (console.log('Got an incoming request');).

4. Send Response: To complete the request-response cycle, the server must send a response. This involves:

   • Setting the HTTP status code (e.g., response.writeHead(200) for success).

   • Writing the response body (e.g., response.write('Thanks for visiting my server');).

   • Ending the response (response.end()).

5. Listen on a Port: server.listen(8000) makes the server listen for incoming requests on a specific port (e.g., 8000). A callback can be provided to log when the server successfully starts listening.

Ports act like "room numbers" on a machine's IP address, allowing multiple services to run concurrently without conflict. Accessing localhost:8000 in your browser sends a request to your local machine on port 8000, where your Node.js server is listening. This hands-on experience provides a concrete understanding of how web servers function at a basic level.

This session provides a detailed breakdown of HTTP requests, explaining their components beyond just methods and status codes.

An HTTP request sent from a client to a server comprises several key parts:

• Method: (e.g., GET, POST, PUT, PATCH, DELETE) indicates the action desired by the client.

• Headers: These are like an envelope's metadata, providing extra information as key-value pairs. Examples include Content-Type (specifying data format like application/json), Authorization (for authentication tokens), or User-Agent (identifying the client's device/browser). Headers are crucial for server-side processing and routing.

• Body: This optional component carries the actual data being sent to the server. For GET requests (which fetch data), the body is typically empty. For POST requests (which submit data, like creating a tweet or uploading a video), the body contains the relevant payload.

The structure of a URL (Uniform Resource Locator) is also dissected:

• Scheme: (http:// or https://) defines the protocol used for communication.

• Subdomain: (e.g., www, mail, admin) a prefix to the main domain.

• Naked/Apex Domain: The primary domain name (e.g., google.com).

• Path: (/contact-us, /search) indicates the specific resource or location on the server.

• Query Parameters: (?q=cat&sort=descending) follow a question mark and are key-value pairs used to pass additional, optional data within the URL itself, typically for filtering or sorting.

  
  

This session demonstrates how to build a more intelligent HTTP server in Node.js by handling different URL paths and serving varied responses.

Building upon the basic server setup, the key is to access request.url to determine the specific path the client is requesting (e.g., /, /contact-us, /about). You can then use a switch statement on request.url to define different server behaviors for different routes.

For each route, the server must explicitly:

• Set the HTTP status code using response.writeHead(statusCode). For instance, 200 for successful requests, or 404 for "Not Found" pages.

• Send the response body using response.end('content here').

The session showcases routing for:

• / (root path): Returns "This is your home page."

• /contact-us: Returns contact information.

• /about: Returns "I am a software engineer."

• Default case: For any other unspecified path, it returns "You are lost" with a 404 status code.

This method allows the server to act as a router, directing requests to the appropriate logic and sending tailored responses. The instructor emphasizes using node --watch (or nodemon in real development) to automatically restart the server on code changes, streamlining the development process. This approach is fundamental for building dynamic web applications in Node.js.

This session introduces API testing tools, which are indispensable for developing and debugging web servers. These tools allow you to send various HTTP requests to your server and inspect the responses, including status codes and headers.

Several popular API clients are mentioned:

• Postman: A widely used, comprehensive tool, though noted for becoming "bloated" with many features.

• Insomnia: Another capable alternative, also considered somewhat heavy.

• Bruno: An open-source option.

• Thunder Client: The instructor's preferred tool for this course. It's a VS Code extension, making it lightweight and seamlessly integrated into the development environment.

The session demonstrates using Thunder Client to test the previously built Node.js HTTP server:

1. Installation: Install the "Thunder Client" extension in VS Code.

2. Making Requests: You can create new requests, specify the HTTP method (GET, POST, etc.), enter the URL (e.g., http://localhost:8000), and add headers or a request body if needed.

3. Inspecting Responses: After sending a request, Thunder Client displays the HTTP status code, response body, size, and time taken, along with all response headers.

This hands-on approach shows how to verify your server's behavior, ensuring it correctly handles different HTTP methods and sends appropriate responses, including dynamic content based on request headers. API testing tools are essential for debugging and validating the functionality of your Node.js APIs.

This session focuses on building a more sophisticated HTTP server in Node.js, capable of handling different HTTP methods and URL paths, while also implementing robust request logging.

The server is set up using the node:http module. Each incoming request triggers a callback function that extracts the HTTP method (request.method) and URL path (request.url). Nested switch statements are used to route requests based on both method and path:

• GET requests to / return "Hello from the server".

• GET requests to /contact-us return contact details.

• GET requests to /tweet return mock tweet data.

• POST requests to /tweet simulate a tweet creation, returning "Your tweet was created" (with a 201 Created status code).

• Any other combination of method/path results in a 404 Not Found response ("You are lost").

Crucially, request logging is implemented. The node:fs module is used to append details of every incoming request (timestamp, method, URL) to a log.txt file. This acts as a server log, providing valuable information for monitoring and debugging, especially in production environments. The session also highlights using node --watch index.js for automatic server restarts during development, enhancing efficiency.

This session highlights the limitations of building Node.js HTTP servers directly with the raw node:http module. While it provides fundamental understanding, using raw HTTP leads to messy, unmaintainable code filled with repetitive if/else or switch statements for routing requests. This approach becomes unscalable quickly, especially in team environments or with complex features like database integration, rate limiting, and authentication.

To overcome this, the session introduces Express.js, a highly popular and battle-tested Node.js web framework. Express.js simplifies server development by providing a more structured and declarative way to define routes and handle requests.

Key benefits of Express.js:

• Clean Code: It reduces boilerplate code, making your server logic much cleaner and easier to read.

• Declarative Routing: You define routes using simple syntax like app.get('/') or app.post('/api/users').

• Middleware: Express.js supports middleware, which are functions that can process requests before they reach the main route handler (e.g., for parsing headers or request bodies).

• Extensibility: It handles common server tasks like header parsing, body parsing, and sending responses efficiently.

Express.js is built on top of the raw node:http module, abstracting away its complexities. By learning Express.js, developers can build more robust, maintainable, and scalable Node.js applications, a crucial skill in professional web development.

This session dives into practical implementation with Express.js, showcasing how this Node.js framework offers a cleaner, more structured approach to building web servers compared to the raw node:http module.

The setup begins by initializing an npm project (npm init -y) and installing Express.js (npm i express) along with its type definitions (npm i @types/express) for better autocompletion in VS Code.

Key Express.js concepts demonstrated:

• Application Instance: const app = express(); creates an Express application instance.

• Routing: Express provides a concise way to define routes for different HTTP methods and URL paths. For example, app.get('/') handles GET requests to the root path, while app.post('/tweets') handles POST requests to /tweets. Each route takes a callback function with request and response objects.

• Sending Responses: response.send() is a versatile method for sending various types of responses (strings, JSON, HTML). response.status(statusCode).send() allows explicit control over HTTP status codes (e.g., 201 Created for successful resource creation).

• Server Listening: app.listen(port, callback) starts the server on a specified port, executing a callback upon successful launch.

The session highlights how Express.js abstracts away the complexities of raw HTTP, offering a more declarative and maintainable structure for defining server logic. This foundation is crucial for building scalable and professional Node.js applications.

This session explains Semantic Versioning (SemVer), the standard versioning scheme used by Node.js and npm for packages. SemVer uses a three-part number format: MAJOR.MINOR.PATCH (e.g., 4.21.1).

Each part signifies a different type of update:

• PATCH (rightmost digit): Incremented for backward-compatible bug fixes. Updates here (e.g., 1.2.3 to 1.2.4) won't break existing code.

• MINOR (middle digit): Incremented for backward-compatible new features. Updates here (e.g., 1.2.0 to 1.3.0) add functionality without breaking old code.

• MAJOR (leftmost digit): Incremented for incompatible API changes (breaking changes). Updates here (e.g., 4.x.x to 5.0.0) might break existing code and require manual updates.

npm uses symbols like ~ (tilde) and ^ (caret) in package.json to define acceptable version ranges:

• ~1.2.3: Allows patch updates (e.g., 1.2.4, 1.2.5) but locks the minor version.

• ^1.2.3: Allows minor and patch updates (e.g., 1.3.0, 1.4.0) but locks the major version, preventing automatic updates to breaking changes.

Understanding SemVer is crucial for managing project dependencies and ensuring application stability when updating packages. Developers should actively consult migration guides (e.g., "Moving to Express 5") for major version updates.

This session introduces REST (Representational State Transfer) API, an architectural style for designing web services. It's crucial to understand that REST is a set of principles, not a specific technology, applicable to any backend language (Node.js, Java, Rust, etc.).

Key REST principles:

• HTTP Communication: All communication happens over HTTP.

• Statelessness: The server should not store any client-specific "state" or session data in its memory. Every request must contain all necessary information for the server to process it. This ensures scalability as requests can be handled by any available server instance.

• Client-Server Architecture: The client (e.g., web browser, mobile app) and server are separate, independent applications. The server primarily sends data (often JSON), and the client is responsible for rendering the UI.

• Uniform Interface: HTTP methods (GET, POST, PUT, PATCH, DELETE) should be used consistently and predictably. For example, a GET request to /tweets should always retrieve tweets, not create new ones.

• Cacheability: Responses from the server should be cacheable, allowing clients to store frequently accessed data locally to improve performance.

Understanding these principles is vital for building highly performant, available, and scalable RESTful APIs. The session also reiterates using Thunder Client in VS Code as a convenient tool for testing these APIs without a separate client-side UI.

This session demonstrates building dynamic routes in Express.js to handle varying URL paths and retrieve specific data. We create a mock in-memory database of books (each with an ID, title, and author) to simulate data retrieval.

Key concepts covered:

• Dynamic Routes: To fetch a specific book by its ID (e.g., /books/1, /books/2), Express.js uses colon-prefixed parameters in the route definition (e.g., app.get('/books/:id')). The value after the colon (:id) becomes accessible via request.params.id.

• Data Retrieval and Validation: The code attempts to find a book matching the id from request.params. Crucially, since URL parameters are always strings, the id is explicitly converted to an integer (parseInt(id)).

• Error Handling and Status Codes:

  • If no book is found for a given id, the server responds with a 404 Not Found status and a descriptive JSON error.

  • If the id provided in the URL is not a valid number (e.g., /books/A), the server sends a 400 Bad Request status, indicating a client-side error due to invalid input.

• Unified Route for All Books: The app.get('/books') route now serves two purposes: if an id is provided in the URL, it fetches a specific book; otherwise, it returns all books.

This session highlights essential practices for building robust APIs by validating dynamic URL parameters and returning appropriate HTTP status codes to inform the client about the request's outcome.

This session focuses on building a functional RESTful API for a simple bookstore application using Express.js. The goal is to implement CRUD (Create, Read, Update, Delete) operations, even though we're using an in-memory array as a mock database for now.

Key Express.js routes and functionalities demonstrated:

• POST /books (Create): This route handles adding new books. It expects title and author in the request body (parsed by middleware express.json()). Basic validation ensures both fields are present. A new book object is created with an auto-incrementing ID and pushed to the books array. The server responds with a 201 Created status code and the new book's ID.

• GET /books (Read All): Returns the entire books array as a JSON response.

• GET /books/:id (Read One): This dynamic route captures the id from the URL. It parses the id to an integer and searches the books array. If found, it returns the specific book; otherwise, it sends a 404 Not Found response.

• DELETE /books/:id (Delete): This route handles removing a book by ID. After validating the id, it finds the book's index and uses splice() to remove it from the books array. A 200 OK status is returned upon successful deletion.

This hands-on session showcases how Express.js simplifies API development, enabling clear routing, request body parsing, input validation, and proper HTTP status code responses.

This session demystifies Express.js middleware, a fundamental concept for building robust and organized Node.js web servers. Middleware functions are powerful tools that sit between the incoming HTTP request and the final route handler.

How Middleware Works: When an HTTP request hits your Express.js application, it first passes through any registered middleware functions in sequence. Each middleware function has access to the request and response objects, as well as a next function.

• Reading/Modifying Requests: Middleware can read and even modify the incoming request (e.g., parsing the request body, checking headers).

• Terminating the Cycle: A middleware can choose to send a response directly, effectively "terminating" the request-response cycle and preventing subsequent middleware or the final route handler from executing (e.g., for authentication failures or invalid input).

• Forwarding to Next: If a middleware processes the request successfully and wants it to continue to the next middleware or the route handler, it must explicitly call the next() function.

Common Use Cases for Middleware:

• Body Parsing: (e.g., express.json()) parses incoming JSON or text bodies into request.body.

• Logging: Recording incoming requests, timestamps, and request details.

• Authentication/Authorization: Verifying user login status or permissions before allowing access to routes.

• Validation: Checking incoming data for correctness.

Middleware promotes modularity, reusability, and separation of concerns in Express.js applications, making your codebase cleaner and more maintainable.

This session expands on Express.js middleware, detailing different ways to apply middleware functions to your Node.js application.

Key types of middleware:

• Global Middleware: Applied to the entire application using app.use(middlewareFunction). These run for every incoming HTTP request, regardless of the URL path or HTTP method. Examples include request logging or body parsing.

• Route-Level Middleware: Applied to specific routes. You pass the middleware function as an argument before the final route handler (e.g., app.get('/books', customMiddleware, routeHandler)). These middlewares only execute when that particular route is matched. Multiple route-level middlewares can be chained for a specific route.

How Middleware is Executed: Middleware functions always receive (req, res, next) as parameters.

• req: The request object, allowing you to read and modify incoming data.

• res: The response object, allowing you to send data back to the client and terminate the request-response cycle.

• next(): This crucial function passes control to the next middleware in the stack or to the final route handler. If next() isn't called, the request will hang unless the middleware sends a response.

The session also briefly mentions applying middleware based on specific URL paths (e.g., app.use('/books', middlewareFunction)), which makes the middleware run for all requests starting with /books. This granular control over request processing is what makes Express.js middleware incredibly powerful for tasks like authentication, authorization, and validation.

This session demystifies Node.js custom modules, enabling you to organize your code into reusable files. The core idea is to export functionalities from one JavaScript file and require() them in another.

Two types of exports are explained:

1. Named Exports: You explicitly name each function, variable, or class you want to expose. For instance, in math.js, you'd write exports.add = addFunction; and exports.subtract = subtractFunction;. When importing, you use destructuring to get specific named exports: const { add, subtract } = require('./math');.

2. Default Exports: A module can have only one default export, which doesn't require a name when exported. You use module.exports = someValue; to define it. When importing, you can assign any name to it: const mathUtils = require('./math');. mathUtils would then directly refer to the someValue that was default exported.

The module.exports object is what's returned when you require() a file. Named exports attach properties to this object, while module.exports itself is the default export. Understanding this allows for better code organization, making large Node.js projects more maintainable and readable.

This session focuses on refactoring a basic Express.js API by organizing routes into custom modules, a crucial step for building maintainable and scalable Node.js applications. The goal is to move book-related CRUD operations from the main index.js file into a dedicated routes/book.routes.js module.

Key Refactoring Steps:

1. Initialize npm: npm init -y is used to create a package.json file.

2. Install Express.js and Typings: npm install express @types/express ensures both the framework and its TypeScript typings are available for better code assistance.

3. Create Router Module (routes/book.routes.js):

   • const router = express.Router(); creates an instance of Express.js's Router, which acts as a mini-application for handling routes.

   • All book-related GET, POST, and DELETE routes (e.g., /, /:id) are defined on this router object. The common base path (/books) is removed from these individual routes.

   • module.exports = router; exports the router instance as the default export of this module.

4. Centralize Data (db/books.js): The in-memory books array (mock database) is moved to a separate db/books.js file and exported as a named export.

5. Integrate Router in index.js:

   • const bookRouter = require('./routes/book.routes'); imports the newly created bookRouter.

   • app.use('/books', bookRouter); tells Express.js that any request starting with /books should be handled by bookRouter.

This refactoring significantly improves code readability and separation of concerns. The main index.js now focuses on application-wide setup (middlewares, main routes), while specific resource-related routes (like books) are neatly encapsulated in their own modules. This modular structure is vital for large Node.js projects.

This session introduces the Model-View-Controller (MVC) architectural pattern, a widely adopted standard for structuring web applications, ensuring clean, maintainable, and scalable codebases in Node.js.

MVC divides an application into three interconnected components:

• View: Represents the user interface (UI) – what the user sees. In web applications, this includes HTML, CSS, and client-side JavaScript (e.g., a React app). Views send requests to controllers.

• Controller: Acts as the intermediary between the View and the Model. It receives requests from the View, processes them (including authentication, validation, and authorization), interacts with the Model to perform data operations, and then sends appropriate responses back to the View.

• Model: Represents the application's data layer and business logic. It handles data storage and retrieval, typically interacting directly with the database (e.g., defining table schemas, performing CRUD operations via an ORM).

In a Node.js Express.js application, this translates to:

• Views: Your front-end files (e.g., HTML templates, React components).

• Controllers: JavaScript functions (often grouped by resource, like book.controller.js) that handle specific API endpoints, contain application logic, and interact with models.

• Models: JavaScript files defining your database schemas and database interaction logic (e.g., drizzle/book.model.js).

This separation of concerns makes the codebase modular, allowing multiple developers to work concurrently and simplifying debugging and future enhancements.

This session introduces databases as a crucial component of web application development, where servers interact with them to store and retrieve data (user info, tweets, etc.). The instructor outlines two primary types of databases:

1. SQL Databases (Relational Databases):

   • Store structured data in tables with predefined schemas.

   • Data integrity and relationships between tables are strictly enforced (e.g., a "friends" table linking user IDs).

   • Examples: PostgreSQL, MySQL.

   • Benefit: Ensures data consistency and prevents invalid entries at the database level. More complex to design initially but robust.

2. NoSQL Databases (Non-Relational Databases):

   • Store unstructured or semi-structured data (e.g., JSON documents).

   • Offer more flexibility; schemas are not strictly enforced, allowing varied data structures within the same collection (e.g., users can have different fields like 'gender' without altering a global schema).

   • Example: MongoDB.

   • Benefit: High flexibility and scalability for rapidly changing data.

   • Challenge: Data validation and integrity often fall to the application layer (your server code).

For this course, PostgreSQL (a SQL database) will be prioritized. Learning relational databases first builds a strong foundation in structured data management, making it easier to adapt to NoSQL databases later, as SQL databases enforce more rigorous design principles.

This session introduces Object-Relational Mapping (ORM), a crucial concept in application development that simplifies database interactions. An ORM acts as a middle layer (software) between your application's programming language (e.g., JavaScript) and the database (e.g., PostgreSQL).

The core problem ORMs solve is the "object-relational impedance mismatch." Programming languages work with objects (like a user object with id and name properties), while relational databases (SQL databases) store data in tables using SQL queries. These two paradigms speak different "languages."

An ORM translates your application's object-oriented code into SQL queries for the database, and converts SQL query results back into native objects that your application can easily understand and manipulate. For example, instead of writing INSERT INTO users (id, name) VALUES (1, 'Piyush');, an ORM lets you define a User object in your code and use methods like user.save() to persist it to the database.

Popular ORMs include:

• Drizzle, Prisma, Knex.js (for JavaScript/TypeScript)

• Mongoose (for JavaScript/MongoDB)

• SQLAlchemy (for Python/SQL databases)

• PyMongo (for Python/MongoDB)

By using an ORM, developers can interact with databases using their familiar programming language's syntax, avoiding the need to write raw SQL and simplifying data persistence logic in their applications.

This session guides you through setting up a PostgreSQL database for your Node.js application, emphasizing a Docker-based approach for local development. While direct local installation or cloud-hosted solutions are options, Docker offers a flexible and isolated environment.

Key steps for Dockerized PostgreSQL:

1. Install Docker Desktop: Download and install Docker Desktop for your operating system (Windows, macOS, Linux). Verify installation by running docker version in your terminal.

2. Create docker-compose.yml: In your project's root directory, create a file named docker-compose.yml. This YAML file defines your Docker services.

3. Define PostgreSQL Service:

   • Under services:, define a service (e.g., postgres).

   • Specify the image: (e.g., postgres:17.4) to pull the desired PostgreSQL Docker image. Using a specific version ensures consistency across environments.

   • Map ports: (e.g., '5432:5432') to expose the database port from the container to your local machine.

   • Set environment: variables for PostgreSQL credentials (e.g., POSTGRES_PASSWORD, POSTGRES_USER, POSTGRES_DB).

4. Run with Docker Compose:

   • docker compose up: Starts the PostgreSQL container in the foreground.

   • docker compose up -d: (preferred for development) Starts the container in detached mode (background).

   • docker compose down: Stops and removes the container and its associated network.

Using Docker Compose allows you to easily spin up and tear down a PostgreSQL instance without permanently installing it on your system, preventing conflicts and simplifying environment management.

This session guides you through integrating Drizzle ORM with PostgreSQL in a Node.js project. Drizzle ORM is chosen for its efficiency in handling relational database queries, particularly with complex joins.

The setup involves several steps:

1. Project Initialization: Create a new project, initialize npm (npm init -y), and install Drizzle ORM (drizzle-orm) and the PostgreSQL client (pg). Additionally, install drizzle-kit for schema management and dotenv to handle environment variables.

2. Schema Definition: In drizzle/schema.js, define your database tables using Drizzle's schema syntax (e.g., pgTable, integer, varchar). This is where you structure your data (e.g., a users table with id, name, email columns, including constraints like primaryKey and unique).

3. Drizzle Configuration (drizzle.config.js): This file tells drizzle-kit how to connect to your database and where to find your schema. It specifies the dialect (PostgreSQL), schema path, and dbCredentials (including connectionString).

4. Database Connection (db/index.js): This file sets up the actual database connection using the drizzle function, leveraging the DATABASE_URL (including user, password, host, port, db name) loaded from a .env file via dotenv.

5. Schema Migration: npx drizzle-kit push reads your schema and applies the changes to your PostgreSQL database. npx drizzle-kit studio launches a local UI for viewing and managing your database data.

This comprehensive setup demonstrates how to define a database schema, configure an ORM, manage environment variables, and synchronize your schema with a PostgreSQL database, creating a robust foundation for your Node.js application.

This session tackles a critical step in web application development: migrating an in-memory database to a persistent relational database using Drizzle ORM and PostgreSQL. The goal is to replace the volatile mock data with a robust, scalable storage solution.

Key steps and concepts:

1. Project Setup: Ensure Docker Compose is running PostgreSQL locally. Node.js project is initialized with Express.js, Drizzle ORM, pg (PostgreSQL driver), drizzle-kit, and dotenv installed.

2. Schema Definition: Create drizzle/book.model.js and drizzle/author.model.js. These files define the database schema using Drizzle's declarative syntax:

   • authorsTable: Has id (UUID as primary key, auto-generated), firstName, lastName, and email (unique, not null).

   • booksTable: Has id (UUID), title (varchar), description (text, nullable), and authorId (a foreign key referencing authorsTable.id). This establishes a one-to-many relationship (one author can have many books).

3. Drizzle Configuration (drizzle.config.js): This file configures drizzle-kit to connect to the PostgreSQL database (using connection string from .env) and specifies the location of the schema files.

4. Database Migration: npx drizzle-kit push reads the defined schema and applies it to the running PostgreSQL database, creating the authors and books tables. npx drizzle-kit studio provides a GUI to inspect the database.

5. ORM Integration (db/index.js): A connection to the database is established using drizzle and process.env.DATABASE_URL, then exported for use in controllers.

The instructor poses a challenge: replace the existing in-memory database operations in the Express.js routes with Drizzle ORM queries for PostgreSQL, setting the stage for direct database interaction in the next session.

This session continues the Express.js Bookstore API project, focusing on migrating its CRUD (Create, Read, Update, Delete) operations from an in-memory database to a persistent PostgreSQL database using Drizzle ORM.

Key implementations and updates:

• Database Integration: The db/index.js file now exports the Drizzle ORM database connection (db) which is imported into the routes/book.routes.js module.

• Schema & Models: The drizzle/book.model.js and drizzle/author.model.js define the tables and their relationships (UUID for IDs, varchar for strings, references for foreign keys).

• Read All Books (GET /books): The route now uses await db.select().from(booksTable); to fetch all books asynchronously from PostgreSQL.

• Read Book by ID (GET /books/:id): This route fetches a specific book using await db.select().from(booksTable).where(eq(booksTable.id, id)).limit(1);. It correctly handles UUIDs and returns 404 Not Found if the book doesn't exist.

• Create Book (POST /books): This route inserts new books using await db.insert(booksTable).values({ title, description, authorId }).returning({ id: booksTable.id });. It returns the newly created book's ID and sets a 201 Created status code.

• Delete Book (DELETE /books/:id): This route deletes a book by its UUID using await db.delete(booksTable).where(eq(booksTable.id, id));. It includes validation for non-existent IDs, returning a 404 Not Found status.

The session emphasizes validating foreign key constraints when creating records (e.g., authorId must exist in the authors table), a key benefit of relational databases. The instructor encourages testing functionalities with Thunder Client or a similar API testing tool to verify seamless integration with PostgreSQL.

This session introduces Postman, a widely used API testing client, essential for backend developers to test, debug, and document their web services. Although the instructor prefers Thunder Client, Postman's industry prevalence makes it a vital tool to learn.

Key Postman functionalities for API testing:

• Making Requests: Create new requests, specify the HTTP method (GET, POST, PUT, DELETE, PATCH), and enter the API endpoint URL (e.g., http://localhost:8000/books).

• Request Configuration: Add headers (e.g., Content-Type: application/json) and compose a request body (e.g., JSON payload for POST requests).

• Inspecting Responses: Postman displays the HTTP status code, response data, and all response headers, allowing developers to verify API behavior.

Advanced Postman features for team collaboration:

• Collections: Organize related API requests into collections. This structures your API documentation and testing suites.

• Environments: Define variables (e.g., baseURL = http://localhost:8000) within environments. This allows switching between development, staging, and production API endpoints without manually changing each request's URL.

• Automatic Documentation: Postman can automatically generate interactive API documentation from your collections, which can be published online for front-end developers and other stakeholders.

By mastering Postman, developers can efficiently test their Node.js APIs, collaborate with teams, and provide clear, executable API documentation, streamlining the entire development lifecycle.

This session covers implementing search functionality in the Express.js Bookstore API, demonstrating how to leverage PostgreSQL's indexing capabilities via Drizzle ORM for efficient text searches.

The search functionality is added to the GET /books route using query parameters (e.g., /books?search=node).

• The search query parameter is accessed via request.query.search.

• If a search term is provided, a where clause is added to the Drizzle ORM query. Instead of a simple eq (equality) check, it uses ilike (case-insensitive LIKE) with wildcards (%) to find the search term anywhere within the title column (e.g., ilike(booksTable.title, %${search}%)). This allows for flexible substring searches.

• Database Indexing: To make these text searches performant on large datasets, a GIN (Generalized Inverted Index) index is applied to the title column in the PostgreSQL database. This is done by adding index('title_idx').using(sqlGIN, booksTable.title) to the booksTable definition in drizzle/book.model.js and pushing the schema changes with npx drizzle-kit push.

This optimization dramatically improves search speed, showcasing how proper database indexing is crucial for scalable API performance.

This session clarifies the critical distinction between authentication and authorization, two fundamental pillars of any backend system and web application security.

Authentication:

• Definition: It's the process of verifying who you are. It answers the question, "Do I know you?"

• Analogy: Like a security guard checking your college ID at the main gate. If you have a valid ID, you're authenticated and allowed to enter the campus.

• Web Context: When you log in to a website (e.g., Facebook) with your email and password, the server authenticates you. If successful, it recognizes you as a legitimate user (e.g., "This is Piyush Garg").

Authorization:

• Definition: It's the process of determining what you are allowed to do or what resources you can access after being authenticated. It answers the question, "Are you permitted to access this resource?"

• Analogy: After entering the college (authenticated), a student's ID (which is for "student" role) allows entry into classrooms but not into the staff room. A teacher's ID, however, allows both.

• Web Context: Once authenticated on Facebook, the server determines if you're authorized to view your personal feed, send messages, or perhaps access administrative panels. You can't accept someone else's friend request or change their password, even if you're logged in, because you lack the necessary authorization.

In essence, authentication is about identity verification, while authorization is about permission management. Authentication is always the first step; without knowing who you are, a system cannot decide what you're allowed to do. The main security complexities often lie within the authentication workflow.

In this session, we delve into the complexities of authentication beyond simple concepts, using a "parking lot" analogy to illustrate common architectural challenges.

Imagine a private parking lot with a security guard at the entrance. Drivers (users) park their cars, and the guard gives them a unique token (a receipt) linked to their car's details in a single diary (server-side state). When a driver returns, they present the token, the guard checks the diary, retrieves the car, and deletes the entry. This system works well for low traffic.

However, scaling introduces problems:

1. Single Point of Failure: If the single guard is overwhelmed by high traffic (many requests), the system slows down or crashes.

2. Concurrency Issues: Adding more guards (multiple server instances) but keeping one shared diary (single server-side state) leads to bottlenecks. Only one guard can write in the diary at a time, creating queues and reducing efficiency.

3. Sticky Sessions/Statefulness: If each guard maintains their own diary, drivers must return to the same guard who parked their car. This breaks scalability because traffic cannot be freely distributed among all available guards. If a driver approaches the wrong guard, their car's entry isn't found, leading to authentication failure.

This analogy highlights why authentication systems must be designed to handle high loads and avoid statefulness on the server side, ensuring robust scalability and seamless user experience.

This session dives deep into authentication system design, starting with a practical analogy: a parking lot with security guards and a central diary. This "story" highlights the core concepts and inherent challenges of session-based authentication.

In this model, when a user (car owner) signs up/logs in, the server (security guard) creates a unique token (receipt) and stores the user's data associated with that token in an in-memory diary (server-side state). The token is given to the user, who presents it for subsequent requests. The server then looks up the token in its diary to authenticate the user.

Pros of Session-Based Authentication:

• Centralized Control: The server explicitly manages and can invalidate user sessions. If a token needs to be revoked (e.g., due to suspicious activity), it's simply removed from the diary.

Cons of Session-Based Authentication:

• Stateful Servers: The server must maintain a record (the "diary") of active sessions. This introduces scalability problems:

  • Single Point of Failure: If there's only one server, it becomes a bottleneck under high traffic.

  • Concurrency Issues: With multiple servers, if the diary isn't shared (or if shared, creates a bottleneck for write operations), users might be rejected if their request lands on a server that doesn't hold their session data. This often leads to the need for "sticky sessions," forcing users to return to the same server, which hinders horizontal scaling.

Session-based authentication is ideal for short-lived sessions (like banking websites that log you out quickly). However, for highly scalable, stateless applications, alternative methods like JSON Web Tokens (JWTs) are preferred.

This session initiates building a session-based authentication system in Node.js with Express.js and PostgreSQL (managed by Drizzle ORM). This system is stateful, meaning the server maintains user session information.

First, necessary packages like Express.js, Drizzle ORM, pg, drizzle-kit, and dotenv are installed using pnpm (a faster alternative to npm). The PostgreSQL database is set up via Docker Compose, and its connection URL is stored securely in a .env file.

The database schema (db/schema.js) defines a users table with id (UUID, primary key), name, email (unique), password (hashed), and salt. A new user_sessions table stores id (UUID, primary key), userId (foreign key to users.id), and createdAt (timestamp). These schemas are pushed to PostgreSQL using npx drizzle-kit push.

The signup route (POST /user/signup) handles new user registration:

• It takes name, email, and password from the request body.

• It checks if the email already exists; if so, it returns a 400 Bad Request.

• Otherwise, it generates a unique salt using node:crypto.randomBytes and hashes the user's password with this salt using createHmac.

• The name, email, hashed_password, and salt are inserted into the users table.

• A 201 Created status and the new user's ID are returned.

The login route (POST /user/login) authenticates users:

• It takes email and password.

• It retrieves the user's stored salt and hashed_password from the database.

• The provided plain password is then hashed with the retrieved salt. If this new hash matches the stored hashed_password, the user is authenticated.

• Upon successful login, a new session is created in the user_sessions table, linking it to the user's ID, and its id is returned.

This initial setup provides a working session-based authentication flow, demonstrating secure password storage and basic session management.

This session demonstrates building a session-based authentication system using Express.js, Drizzle ORM, and PostgreSQL. This system is stateful, meaning the server maintains a record of active user sessions.

Key components and logic:

• User Schema: The users table is defined with id (UUID), name, email (unique), password (stored as a hash), and salt.

• Session Schema: A new user_sessions table is created to store id (UUID for session ID), userId (a foreign key linking to users.id), and createdAt (timestamp).

• Signup (POST /user/signup): Takes name, email, password. It generates a unique salt using Node.js's crypto module (randomBytes) and hashes the password using createHmac with the salt. The new user, along with their hashed password and salt, is inserted into the users table.

• Login (POST /user/login): Takes email and plain password. It retrieves the user's stored salt and hashed password from the database. It then re-hashes the provided password with the retrieved salt and compares it to the stored hash. If they match, a new session is created in the user_sessions table, and the session ID is returned.

• Current User (GET /user/me): This route demonstrates how to check if a user is authenticated. It expects the session ID in the request headers. It queries the user_sessions table to find the session and, if found, performs a join with the users table to retrieve and return the user's details.

A critical aspect of this stateful session-based authentication is that every request to a protected route requires a database query to validate the session. This introduces latency and can overwhelm the database under high load, as the server constantly looks up session details. While providing strong control (sessions can be easily revoked from the database), this approach is less scalable for high-traffic applications compared to stateless authentication methods.

This session introduces JSON Web Tokens (JWTs) as a solution to the scalability and latency problems inherent in session-based authentication. JWTs enable stateless authentication, meaning the server doesn't need to maintain a record of active sessions in a database for every request.

How JWTs work:

• Upon successful login, the server generates a JWT. This token is a digitally signed string that encodes user information (like ID, email, name) directly within itself.

• The JWT is signed using a secret key (e.g., JWT_SECRET) known only to the server. This signature ensures the token's integrity; any tampering will invalidate it.

• The server sends this JWT to the client, typically in an Authorization header as Bearer <token>.

• For subsequent requests, the client includes the JWT. The server then verifies the token's signature using the secret key. If valid, the user's information can be extracted directly from the token without a database lookup.

Benefits of JWT-based authentication:

• Reduced Database Load: No database calls are needed for every request once the token is issued, significantly improving performance and reducing database overhead.

• Improved Scalability: Since servers don't store session state, requests can be routed to any server instance, simplifying horizontal scaling.

Trade-offs:

• Token Invalidation: Once issued, a JWT is valid until it expires. Revoking a token before its expiry (e.g., for logout or security reasons) requires additional mechanisms (like a "blacklist" database), which reintroduces some statefulness. This is why JWTs are often given short expiry times (e.g., 1 minute) and paired with refresh tokens for longer sessions.

JWTs are ideal for highly scalable applications where performance is critical, offering a more efficient alternative to stateful session management.

This session introduces authorization, the crucial next step after authentication in web application security. While authentication verifies "who you are," authorization determines "what you're allowed to do" or "what resources you can access."

The core concept is illustrated with an example: a user (U1) requests access to sensitive "payments data" on the server.

1. Authentication First: U1 must first be authenticated (server recognizes them).

2. Authorization Check: The server then checks if U1 has the necessary permissions to access that specific resource.

A common approach to implement authorization is by assigning roles to users (e.g., admin, user). This role can be stored as a field in the users table of your PostgreSQL database. When a user logs in, their JWT (JSON Web Token) can include this role information. Since JWTs are signed, this role can be trusted by the server.

Upon a request for a protected resource, the server's backend logic would:

1. Extract and verify the JWT.

2. Decode the token to get the user's role.

3. Check if that role has permission to access the requested data. If not, an unauthorized error (e.g., HTTP 403 Forbidden) is returned; otherwise, access is granted.

This method effectively controls access to specific API endpoints and data based on user roles, ensuring only authorized users can perform sensitive operations. The instructor challenges you to implement this role-based authorization before the next video.

This session focuses on implementing authorization in our Node.js Express.js API, enabling role-based access control to sensitive routes.

First, the database schema (db/schema.js) is updated to include a role column in the users table, defined as a PostgreSQL enum (user_role_enum) with values like user (default) and admin. This schema change is applied to the database using npx drizzle-kit push. The JWT (JSON Web Token) payload is also updated during login to include the user's role.

Authorization middleware (auth.middleware.js):

• ensureAuthenticated: This middleware checks for a valid JWT in the Authorization: Bearer <token> header. If the token is missing or invalid, it returns a 401 Unauthorized response. If valid, it decodes the token and attaches the user's information to request.user, then calls next().

• restrictToRole(role): This is a closure function that returns another middleware. It takes a role (e.g., 'admin') as an argument. If the request.user.role doesn't match the required role, it returns a 401 Unauthorized error; otherwise, it calls next().

Applying Authorization: For sensitive routes (e.g., /admin/users), the ensureAuthenticated middleware is chained before restrictToRole('admin'), ensuring only authenticated admins can access the resource. This layered approach guarantees both authentication and authorization are enforced, building a robust and secure Express.js API.

This session introduces NoSQL databases, focusing on MongoDB as a primary example, and highlights their key differences from SQL (relational) databases like PostgreSQL.

SQL databases (e.g., PostgreSQL) are characterized by:

• Structured data: Data is stored in tables with predefined schemas.

• Relations: Data across tables is linked by explicit relationships.

• Strict rules: Constraints (like NOT NULL, UNIQUE, foreign keys) are enforced at the database level, ensuring data consistency and integrity.

In contrast, NoSQL databases (e.g., MongoDB, AWS DynamoDB) offer:

• Unstructured/semi-structured data: Data is stored in flexible "documents" (often JSON-like), not rigid tables.

• No predefined schema (schema-less): Each document can have a different structure within the same collection. This provides high flexibility to evolve data models.

• No relations: Relationships between data are typically handled at the application layer (your Node.js code) rather than enforced by the database itself.

The primary advantage of NoSQL is its flexibility and ease of handling rapidly changing data structures, making migrations simpler. However, this flexibility means that data validation and consistency rules must be meticulously enforced within the application logic. The session sets the stage for hands-on work with MongoDB Atlas (cloud-hosted MongoDB) and building a basic CRUD application in the next video.

This session guides you through setting up a MongoDB Atlas cluster (a cloud-hosted NoSQL database) and introduces Mongoose ORM, the primary tool for interacting with MongoDB from Node.js applications.

Setting up MongoDB Atlas:

1. Sign up/Login: Create an account on mongodb.com.

2. Deploy Free Cluster: Choose the free tier (M0 Sandbox) cluster. Select your preferred cloud provider (AWS, Google Cloud, Azure) and a region geographically close to you (e.g., Mumbai for India).

3. Create Database User: Set up a database username and password. Crucially, save these credentials securely (e.g., in a .env file), as they'll be needed for connection.

4. Network Access Configuration: Configure Network Access to allow connections from your current IP address or from anywhere (for development purposes, but restrict to specific IPs in production for security).

5. Get Connection String: After the cluster deploys, obtain the connection string (URI) for your Node.js application, replacing placeholders for username and password.

Introducing Mongoose ORM:

• Unlike Drizzle ORM (used for SQL databases like PostgreSQL), Mongoose is the popular ORM for MongoDB.

• MongoDB stores data in collections (analogous to SQL tables) containing documents (analogous to SQL rows). These documents are flexible and schema-less by default at the database level.

• Mongoose provides a schema-based solution for your application code, allowing you to define rigid or flexible schemas for your documents, adding a layer of structure and validation at the application level.

The session concludes by showing the MongoDB Atlas UI, demonstrating sample collections (e.g., sessions, users) with their flexible document structures, and sets the stage for building a CRUD application using Mongoose in the next video.

This session guides you through integrating MongoDB Atlas (a cloud-hosted NoSQL database) into your Node.js Express.js application using Mongoose ORM. This setup contrasts with previous PostgreSQL examples, demonstrating data management in an unstructured database environment.

Key Setup Steps:

1. Project Initialization: Begin by initializing a new Node.js project with pnpm init (or npm init).

2. Install Dependencies: Install express, mongoose, dotenv (for environment variables), and their respective TypeScript typings.

3. MongoDB Atlas Connection (connection.js):

   • mongoose.connect(process.env.MONGODB_URL) establishes the connection to your MongoDB Atlas cluster. The MONGODB_URL is retrieved from your .env file (which holds sensitive credentials and should not be committed to version control).

   • This connection function is then exported to be used in your main application file (index.js).

4. Schema Definition (user.model.js):

   • Despite MongoDB being schema-less at the database level, Mongoose allows you to define a schema at the application level using mongoose.Schema. This enforces data structure and validation within your Node.js application.

   • For a User model, properties like name (String, required), email (String, required, unique), password (String, required), and salt (String, required) are defined.

   • The timestamps: true option is added to automatically include createdAt and updatedAt fields.

   • mongoose.model('User', userSchema) compiles the schema into a Model, which is then exported. This User model object will be used to perform CRUD operations (Create, Read, Update, Delete) on your MongoDB 'users' collection.

This setup provides a robust foundation for building NoSQL-backed Express.js applications, demonstrating how to define data models and connect to MongoDB for persistent storage.

Today's session focuses on implementing user authentication with JSON Web Tokens (JWTs) in our Node.js Express.js API, providing a stateless authentication solution.

First, the project is set up with Express.js, Mongoose ORM, and dotenv. A user.model.js defines the User schema with fields like name, email (unique), password, and salt. Passwords are securely stored as hashed values using Node.js's crypto module (for randomBytes to generate salt and createHmac for hashing).

Key routes and functionalities:

• Signup (POST /user/signup):

  • Takes name, email, and password from the request body.

  • Checks if the user already exists (returns 400 Bad Request if so).

  • Generates a unique salt and hashes the password.

  • Creates a new user document in MongoDB.

  • Returns a 201 Created status with the new user's _id.

• Login (POST /user/login):

  • Takes email and password.

  • Finds the user by email and verifies the password by hashing the provided password with the stored salt and comparing it to the stored hash.

  • If valid, it generates a JWT containing the user's _id, email, and name (payload) and signs it with a JWT_SECRET (from .env). This JWT is then returned to the client.

This JWT-based authentication makes the server stateless as it no longer stores session information directly. The token itself carries the user's authenticated state, reducing database load and improving scalability. The session concludes by posing a challenge to implement a middleware to verify this JWT for protecting routes.

This session focuses on implementing user authentication with JSON Web Tokens (JWTs) in our Node.js Express.js API, providing a stateless authentication solution.

First, the project is set up with Express.js, Mongoose ORM, and dotenv. A user.model.js defines the User schema with fields like name (unique), email (unique), password, and salt. Passwords are securely stored as hashed values using Node.js's crypto module (for randomBytes to generate salt and createHmac for hashing).

Key routes and functionalities:

• Signup (POST /user/signup):

  • Takes name, email, and password from the request body.

  • Checks if the user already exists (returns 400 Bad Request if so).

  • Generates a unique salt and hashes the password.

  • Creates a new user document in MongoDB.

  • Returns a 201 Created status with the new user's _id.

• Login (POST /user/login):

  • Takes email and password.

  • Finds the user by email and verifies the password by hashing the provided password with the stored salt and comparing it to the stored hash.

  • If valid, it generates a JWT containing the user's _id, email, and name (payload) and signs it with a JWT_SECRET (from .env). This JWT is then returned to the client.

This JWT-based authentication makes the server stateless as it no longer stores session information directly. The token itself carries the user's authenticated state, reducing database load and improving scalability. The session concludes by posing a challenge to implement a middleware to verify this JWT for protecting routes.

This session introduces MongoDB Aggregations, a highly powerful feature for performing advanced data processing and analysis on collections. Unlike simple find queries, aggregations allow you to process data records collectively to derive calculated results, such as sums, averages, or frequency counts, from large datasets.

The core concept is the aggregation pipeline, a sequence of stages that process documents in a step-by-step manner. Each stage performs an operation on the input documents and passes the results to the next stage. This chained approach enables complex data transformations and analyses.

Key aggregation stages demonstrated include:

• $match: Filters documents based on specified conditions, similar to a WHERE clause in SQL.

• $count: Returns the number of documents passed to it, useful for getting total counts after filtering.

• $project: Reshapes each document in the stream, allowing you to select, rename, or compute new fields, and exclude existing ones (e.g., hiding sensitive data like passwords).

• $lookup: Performs a left outer join from one collection to another within the same database, effectively simulating a relational join between collections. This is powerful for denormalized data models often found in NoSQL databases.

MongoDB's aggregation pipeline allows for highly flexible and efficient data manipulation, making it a critical tool for complex data querying, reporting, and transformations, especially vital for large-scale applications.

We're embarking on an exciting new project: building a URL shortener service!

Inspired by popular platforms like Bitly and Dub.co, this project will teach you how to create a service that transforms long, cumbersome URLs into short, memorable links. These short URLs are not only easier to remember and share on social media but can also provide valuable analytics, like click counts.

You'll learn the ins and outs of designing and implementing such a service, covering everything from generating unique short codes to handling redirections and tracking user engagement. This project will leverage various Node.js concepts and libraries we've explored, giving you hands-on experience in building a practical web application. Get ready to dive into the world of web services and create your own efficient URL shortener!

This session outlines the requirements and tech stack for building a URL shortener API, similar to services like Bitly. The goal is to develop a robust backend that converts long URLs into short, manageable codes, providing functionalities like redirection and user-specific analytics.

Key Technologies:

• Backend: Node.js with Express.js for building the REST API.

• Database: PostgreSQL for reliable, structured data storage.

• ORM (Object-Relational Mapper): Drizzle ORM for seamless interaction with PostgreSQL from Node.js.

• Containerization: Docker Compose to easily spin up and manage the PostgreSQL database during development.

• Authentication: JSON Web Tokens (JWTs) for stateless authentication, ensuring security and scalability.

• API Testing: Postman for comprehensive testing and documentation of the API endpoints.

Core API Routes to be Implemented:

• Public Routes (no authentication required):

  • POST /auth/signup: To register new users.

  • POST /auth/login: To authenticate users and receive a JWT.

  • GET /:shortCode: Redirects users from the short URL to the original long URL.

• Authenticated Routes (JWT required):

  • POST /url/shorten: Shortens a given URL for a logged-in user.

  • GET /url/urls: Returns all URLs shortened by the current user (requires authorization to restrict to specific user's URLs).

  • DELETE /url/:shortCode: Deletes a specific short URL (requires authorization to ensure only the owner can delete).

  • PATCH /url/:shortCode: Updates an existing short URL (e.g., changes the long URL or customizes the short code).

This project will provide a comprehensive, hands-on experience in building a modern, secure, and scalable web service.

Okay, to kick off our URL shortener project, we'll set up the basic Node.js Express.js server.

First, initialize the project with PNPM (pnpm init) to create your package.json. Then, install the necessary development dependencies: TypeScript typings for Node.js (@types/node) and Express.js (@types/express) at version 4.x (pnpm install --save-dev @types/node @types/express@4.x). Next, install Express.js itself (pnpm install express@4.x). To enable ES Modules syntax, add "type": "module" to your package.json.

Set up development scripts: a dev script using node --watch index.js for automatic server restarts on code changes, and a start script for production (node index.js).

The core server setup in index.js includes:

• Importing Express.js.

• Creating an Express app instance.

• Defining a port (defaulting to 8000, or using process.env.PORT).

• Starting the server with app.listen(), logging its status.

• A basic GET route (/) that returns "Server is up and running" as a JSON response.

Once these steps are complete, you can start the server with pnpm dev and verify it's working by sending a GET request to http://localhost:8000 using Postman (or Thunder Client). This foundational setup provides a stable environment for building out the rest of the URL shortener's functionalities.

To kickstart our URL shortener project, this session focuses on setting up a PostgreSQL database using Docker Compose, ensuring a clean and isolated development environment.

First, a docker-compose.yml file is created in the project root. This file defines a db service:

• image: postgres:latest: Specifies the PostgreSQL Docker image to use.

• restart: always: Ensures the container automatically restarts if it crashes.

• environment: Sets crucial environment variables for PostgreSQL, including POSTGRES_PASSWORD (e.g., admin), POSTGRES_USER (e.g., postgres), and POSTGRES_DB (e.g., postgres).

• ports: - "5432:5432": Maps port 5432 on your local machine to port 5432 inside the Docker container, allowing your application to connect.

• volumes: - db_data:/var/lib/postgresql/data: Creates a named Docker volume (db_data) to ensure your database's data persists even if the container is removed.

• The volumes section at the bottom defines the db_data volume.

Before running, ensure Docker Desktop is installed and running. Then, from your terminal in the project's root directory, execute docker compose up -d. This command pulls the PostgreSQL Docker image (if not already present), creates the volume, and starts the PostgreSQL container in detached mode (running in the background). You can verify the container's status with docker ps. This setup provides a robust and easily manageable PostgreSQL instance for your Node.js application.

Okay, let's get our URL shortener project ready with Drizzle ORM and PostgreSQL. This setup involves defining database schemas and pushing them to our Dockerized PostgreSQL instance.

First, install the necessary dependencies: drizzle-orm, pg (PostgreSQL driver), drizzle-kit, and dotenv. Then, set up your .env file with DATABASE_URL, including your PostgreSQL username, password, host (localhost for Docker), port (5432), and database name.

Next, define your database schema in models/user.model.js. For a users table, you'll specify columns like id (as a uuid for unique identifiers, set to primaryKey with a default(sql.raw('gen_random_uuid()')) for auto-generation), and other user fields. The pgTable and uuid functions are imported from drizzle-orm/pg-core for this.

For Drizzle to manage migrations, create drizzle.config.js. This file exports a configuration object specifying the out directory for migrations, the schema path (pointing to models/user.model.js), the dialect as postgresql, and dbCredentials using process.env.DATABASE_URL.

Finally, push your schema changes to the database:

1. Ensure your PostgreSQL Docker container is running (docker compose up -d).

2. Run pnpm db:push (after adding db:push script in package.json to execute npx drizzle-kit push).

3. Verify the table creation by running pnpm db:studio (after adding db:studio script in package.json to execute npx drizzle-kit studio) and checking the UI. This confirms your users table is created in PostgreSQL.

This session focuses on designing the PostgreSQL database schema for the users table within our URL shortener project, leveraging Drizzle ORM's declarative syntax.

The users table is defined with the following columns:

• id: A uuid (Universally Unique Identifier) type, serving as the primaryKey. It's set to default(sql.raw('gen_random_uuid()')) to automatically generate a unique ID for each new user.

• firstName: A varchar (variable character string) with a maximum length of 55 characters and is notNull. Drizzle allows specifying a different column name for the database (first_name) than in the application (firstName) for flexibility.

• lastName: Also a varchar(55), but it's nullable as it's an optional field.

• email: A varchar(255), notNull, and crucially, unique to prevent duplicate email registrations.

• password: A text type (for potentially long hashed passwords), notNull.

• salt: A text type, notNull, used for password hashing to enhance security.

• createdAt: A timestamp that default(sql.raw('now()')) to the current time, notNull.

• updatedAt: A timestamp that default(sql.raw('now()')) and updates automatically onUpdate(sql.raw('now()')), notNull.

After defining the schema in models/user.model.js, pnpm db:push is run to synchronize these changes with the PostgreSQL database. This step creates the users table with all defined columns and constraints, including automatic indexing for primaryKey and unique fields, forming the robust foundation for user management.

First, set up your user.routes.js by importing Express.js and creating a router instance, which you'll then export. This file will house all user-related endpoints.

For the /signup route (POST method):

• It's an async function expecting firstName, lastName, email, and password from the request body (ensure app.use(express.json()) middleware is set up in index.js to parse incoming JSON).

• Validation (briefly mentioned for future ZOD integration): You'd typically check for required fields, password strength, etc.

• Existing User Check: Query your PostgreSQL database (via db and usersTable from your db/index.js and models/user.model.js files) to see if a user with the provided email already exists. If so, return a 400 Bad Request error.

• Password Hashing: If the user doesn't exist, generate a unique salt using crypto.randomBytes and hash the user's plain password with this salt using crypto.createHmac. Store both the hashedPassword and salt in the database.

• Create User: Insert the new user's details (including the hashed password and salt) into the users table.

• Response: Return a 201 Created status with the _id of the newly created user.

This establishes the secure and robust signup flow for your application.

This session integrates Zod, a powerful TypeScript-first schema declaration and validation library, into our Node.js Express.js API to ensure incoming request bodies meet predefined structural and data type requirements. This replaces manual validation checks, making the code cleaner and more reliable.

Key steps and concepts:

• Install Zod: pnpm install zod adds the library to your project.

• Define Validation Schema (validations/request.validation.js):

  • Import z from zod.

  • Create a schema object, signUpPostRequestBodySchema, using z.object().

  • Define expected fields: firstName (z.string()), lastName (z.string().optional()), email (z.string().email()), and password (z.string().min(3)). Zod provides built-in methods like .email() and .min() for common validations.

• Apply Validation in Route Handler:

  • In the POST /user/signup route, use await signUpPostRequestBodySchema.safeParseAsync(request.body); to validate the incoming data. safeParseAsync is used for asynchronous parsing and returns a Promise.

  • Check validationResult.success. If false, it means validation failed. Return a 400 Bad Request status with validationResult.error.issues (or validationResult.error.message) to provide detailed error messages to the client.

  • If validationResult.success is true, destructure the validated data (validationResult.data) and proceed with user creation (hashing password, inserting into PostgreSQL via Drizzle ORM).

This integration ensures that only valid data reaches your application's logic and database, significantly improving API robustness and developer experience by automating input validation and providing clear error feedback.

This session focuses on refactoring the signup route in our Node.js Express.js API to improve code organization and reduce duplication. The goal is to extract reusable logic from the route handler into dedicated utility functions and service functions.

Key refactoring steps:

1. Create utils/hash.js: A new utility file is created to encapsulate password hashing logic. It exports an async function, hashPasswordWithSalt(password), which internally generates a random salt using crypto.randomBytes and then hashes the provided password with this salt using crypto.createHmac. It returns both the hashedPassword and the salt.

2. Create services/user.service.js: This file is dedicated to user-related database operations. It exports an async function, getUserByEmail(email), which queries the PostgreSQL database (via Drizzle ORM) to find a user by their email. It selects only necessary fields like id, firstName, lastName, and email, avoiding sensitive data like passwords.

3. Update user.routes.js:

   • The signup route now imports hashPasswordWithSalt and getUserByEmail.

   • The logic for generating salt and hashedPassword is replaced by a single call to hashPasswordWithSalt(password).

   • The database query to check for an existing user is replaced by a call to getUserByEmail(email).

This refactoring significantly cleans up the user.routes.js file, making it more readable and maintainable by delegating specific tasks to dedicated utility and service layers. This separation of concerns is a best practice for building scalable and robust backend applications.

Let's implement the login route for our URL shortener, focusing on user authentication and JWT (JSON Web Token) generation.

The login route (POST /user/login) handles user sign-in:

• It expects email and password from the request body. Input is validated using a Zod schema (loginPostRequestBodySchema), ensuring correct formats.

• User Lookup: It uses getUserByEmail() (a service function) to find the user in the PostgreSQL database. If no user is found, it returns a 404 Not Found error.

• Password Verification: If the user exists, it retrieves the stored salt and hashed password. The provided plain password is then hashed using the same salt and algorithm (SHA256) used during signup (hashPasswordWithSalt() utility). If this newly generated hash doesn't match the stored hash, a 400 Bad Request (invalid password) error is returned.

• JWT Generation: If the password is correct, a JWT is generated using jwt.sign(). The JWT payload contains user id and email. This token is signed with a JWT_SECRET loaded from the .env file.

• Response: The generated JWT is returned to the client. This token acts as the user's proof of authentication for subsequent requests.

This setup enables users to securely log in and receive a JWT, facilitating stateless authentication in the URL shortener application.

Today's session refactors the login route in our URL shortener API, focusing on abstracting JWT (JSON Web Token) generation into a reusable utility.

First, a new utility file, utils/token.js, is created. It imports jwt from jsonwebtoken and the JWT_SECRET from process.env.

• It defines an async function createUserToken(payload), which takes a payload object (containing user id, email, etc.).

• Crucially, this payload is validated against a Zod schema (userTokenSchema) before signing. This schema ensures the id in the payload is a valid string, providing an extra layer of data integrity for the token's contents.

• The function then uses jwt.sign(payload, JWT_SECRET) to create the JWT and returns it.

In the user.routes.js file:

• The direct jwt.sign() call in the login route is replaced with a call to the new createUserToken() utility.

• The userTokenSchema is also imported from validations/token.validation.js to perform the validation within createUserToken().

This refactoring centralizes JWT creation and its payload validation, making the login route cleaner and the token generation logic reusable. It emphasizes the importance of validating even internal data structures passed to sensitive functions like jwt.sign(), thereby enhancing the overall security and maintainability of the Node.js application.

Let's set up a middleware function to detect the current logged-in user. We'll leverage the JSON Web Tokens (JWTs) generated during login to authenticate subsequent requests without hitting the database every time, enhancing performance.

First, create a middlewares/auth.middleware.js file. This middleware, authenticationMiddleware, is an async function with (req, res, next) parameters.

• Token Extraction: It attempts to read the Authorization header from req.headers.

• Validation:

  • If no Authorization header is present, it simply calls next(), allowing the request to proceed (for public routes).

  • If the header exists but doesn't start with "Bearer ", it returns a 400 Bad Request error.

  • Otherwise, it extracts the JWT string.

• JWT Verification: It uses jwt.verify(token, process.env.JWT_SECRET) to validate the token's authenticity and integrity. If verification fails (e.g., invalid signature, expired token), it calls next().

• User Information Attachment: If the token is valid, the decoded payload (containing user id, email, etc.) is attached to the request object as req.user. This makes user data accessible in subsequent route handlers.

• Proceed to Next: Finally, next() is called to pass control to the next middleware or the route handler.

In index.js, this authenticationMiddleware is applied globally using app.use(authenticationMiddleware). This ensures that for every incoming request, the user's authentication status is determined and their data attached to the request object, streamlining access control for all routes.

Let's create the database schema for storing shortened URLs in our URL shortener project, utilizing Drizzle ORM for PostgreSQL. This defines the structure of how each shortened URL will be stored persistently.

A new file, models/url.model.js, is created to define the urlsTable. This table includes the following columns:

• id: A uuid type, serving as the primary key and set to automatically generate a unique ID (default(sql.raw('gen_random_uuid()'))).

• code: A varchar(155) for the unique short code (e.g., bit.ly/xyz123). It's marked as notNull and unique, ensuring no two long URLs share the same short code.

• targetUrl: A text type to store the original long URL, also notNull.

• userId: A uuid representing the ID of the user who shortened the URL. This is defined as a foreign key that references the id column of the usersTable, establishing a crucial one-to-many relationship (one user can shorten many URLs). It's also notNull.

• createdAt and updatedAt: timestamp fields for tracking creation and last update times, both notNull and automatically managed.

After defining the schema, pnpm db:push is run to apply these changes to the PostgreSQL database. This command creates the urls table with all specified columns, constraints (like unique code and foreign key userId), and default values, providing a robust and structured storage solution for our URL data.

This session implements the URL shortening functionality in our Node.js Express.js API, enabling users to convert long URLs into compact, shareable short codes. This is an authenticated route, meaning only logged-in users can shorten URLs.

First, a new routes/url.routes.js file is created to house URL-related endpoints. It defines a POST route to /shorten.

• Authentication Check: The authenticationMiddleware is applied globally in index.js, ensuring req.user is populated with decoded JWT payload. If req.user.id (or req.user) is missing, a 401 Unauthorized error is returned, enforcing that only authenticated users can access this resource.

• Input Validation: The incoming request body is validated against a shortenPostRequestBodySchema (defined in validations/request.validation.js), which expects a mandatory url (validated as a proper URL string) and an optional shortCode. If validation fails, a 400 Bad Request is returned.

• Short Code Generation: If the user doesn't provide a shortCode, nanoId (a lightweight ID generator) is used to create a unique 6-character short code.

• Database Insertion: The generated shortCode, original targetUrl, and userId (from req.user.id) are inserted into the urlsTable in PostgreSQL using Drizzle ORM.

• Response: A 201 Created status is returned with the new shortCode and targetUrl.

This comprehensive setup ensures secure, validated, and persistent URL shortening, storing all shortened URLs and associating them with the creating user in the database.

Today's session focuses on refactoring the URL shortening functionality by extracting common authentication logic into a reusable middleware. This improves code organization and prevents repetition across multiple routes that require a logged-in user.

First, an ensureAuthenticated middleware is created in middlewares/auth.middleware.js. This async function checks if the request.user object (which is populated by the earlier authenticationMiddleware after JWT verification) exists and contains a valid id.

• If req.user or req.user.id is missing, it means the user is not authenticated. In this case, the middleware immediately returns a 401 Unauthorized HTTP status code with an appropriate error message, preventing further execution of the route handler.

• If the user is authenticated, next() is called, allowing the request to proceed to the next middleware or the actual route handler.

In the url.routes.js file, this ensureAuthenticated middleware is then applied directly to the POST /shorten route (e.g., router.post('/shorten', ensureAuthenticated, async (req, res) => { ... });). This ensures that the URL shortening logic only executes if the user is authenticated, making the route secure.

The session concludes by assigning a task: further refactor the URL shortening logic (specifically the database insertion) into a dedicated service function within services/url.service.js. This continues the pattern of separating concerns, leading to a cleaner and more maintainable codebase.

This session implements the core redirection functionality for our URL shortener service. This allows users to visit a short code and be seamlessly redirected to the original long URL.

The main logic resides in a GET route on url.routes.js that captures a dynamic path parameter representing the shortCode (e.g., /:shortCode).

• Short Code Extraction: The shortCode is extracted from request.params.

• Database Lookup: The route queries the PostgreSQL database (via db.select().from(urlsTable).where(eq(urlsTable.code, shortCode))) to find a matching URL entry based on the shortCode. It specifically selects the targetUrl.

• Redirection Logic:

  • If no targetUrl is found for the given shortCode, it returns a 404 Not Found error, indicating an invalid URL.

  • If a targetUrl is found, response.redirect(targetUrl) is used to issue an HTTP redirect to the user's browser, sending them to the original long URL.

This route is public (not authenticated), allowing anyone to visit a shortened link. The session demonstrates testing this functionality using Postman (or a web browser), showing successful redirections for valid short codes and 404 errors for invalid ones. This solidifies the core value proposition of our URL shortener service.

This session implements the GET /user/urls route for our URL shortener service, allowing authenticated users to view only the short URLs they have generated. This route showcases user-specific data retrieval based on authentication and authorization.

The /urls route is added to url.routes.js as a GET endpoint.

• Authentication: The ensureAuthenticated middleware is applied, ensuring only logged-in users can access this route. If req.user.id is not present (meaning the user isn't authenticated), a 401 Unauthorized response is returned.

• User-Specific Query: Inside the route handler, req.user.id (populated by the authentication middleware from the JWT payload) is used to filter the database query. It uses db.select().from(urlsTable).where(eq(urlsTable.userId, req.user.id)) to retrieve only those URLs where the userId matches the currently authenticated user's ID.

• Response: The filtered list of short URLs is returned as a JSON array.

This implementation ensures that each user has access only to their own generated short URLs, a crucial aspect of data privacy and authorization in multi-user applications. The session demonstrates testing this with different user tokens to verify that only the respective user's URLs are displayed.

To wrap up our URL shortener service, this session implements the delete route, focusing on ensuring that users can only delete URLs they own. This reinforces the concept of authorization within our Node.js Express.js API.

The delete route (router.delete('/:shortCode') is added to url.routes.js.

• Authentication: The ensureAuthenticated middleware is applied, making sure only logged-in users can attempt deletions.

• Authorization (Ownership Check): Inside the route handler, it extracts the shortCode from request.params and the userId of the authenticated user from req.user.id. The database query (db.delete(urlsTable).where(and(eq(urlsTable.code, shortCode), eq(urlsTable.userId, userId)))) attempts to delete a URL only if both the shortCode and the userId match.

• Response: If the deletion query successfully removes a record, it returns a 200 OK status with deleted: true. If no record matches (meaning either the short code doesn't exist or the current user doesn't own it), the database operation results in zero affected rows, and a 404 Not Found or 200 OK (with deleted: false) could be returned. In the demonstration, a simple deleted: true is returned if the query runs, and the UI logic implicitly handles non-existent URLs.

This robust implementation prevents unauthorized deletion of URLs, ensuring data integrity and user privacy. The session concludes by assigning a final task: implement an update route for existing short URLs.