Distributed Systems & Node.js

Cheatsheet Content

Short Answer Questions (2 marks each) 1. Define Cookies. Cookies are small pieces of data that a web server sends to a user's web browser while the user is browsing a website. They are stored on the user's computer and are sent back to the server with each subsequent request, allowing the server to remember stateful information (e.g., login status, user preferences, shopping cart contents). 2. Define Sockets. A socket is an endpoint of a two-way communication link between two programs running on the network. It's an abstract representation that allows a program to send and receive data across a network, typically using TCP/IP protocols. 3. What is Time Sharing Operating Systems. A time-sharing operating system allows multiple users to share a single computer system simultaneously. It rapidly switches the CPU among various processes or users, giving the illusion that each user has the entire computer to themselves, maximizing CPU utilization. 4. List out the areas of application for Node.js. Real-time applications (e.g., chat applications, online gaming). Single Page Applications (SPAs). Backend APIs and Microservices. Streaming data applications. Command Line Interface (CLI) tools. Server-side web applications. 5. List out the Benefits of Using Java Servlet. Platform Independence: Runs on any platform with a Java Virtual Machine (JVM). Performance: Faster than CGI scripts as the JVM is already running, and servlets execute as threads. Robustness: Java's memory management and exception handling contribute to robust applications. Scalability: Can handle multiple client requests concurrently using multithreading. Integration: Seamlessly integrates with the Java ecosystem (JSP, EJB, etc.). Detailed Answer Questions (4 marks each) 1. a) Write a Short note on evolution of the distributed systems? Early Days (1960s-1970s): Batch processing, then timesharing systems. Early forms of networking, but applications were mostly centralized. Emergence of Networking (1980s): Local Area Networks (LANs) and Wide Area Networks (WANs) became more common. Remote Procedure Calls (RPC) emerged as a way to execute code on remote machines. Client-Server Model (1990s): Dominant paradigm. Applications split into client (presentation) and server (data/logic). Technologies like CORBA and DCOM tried to standardize distributed object communication. Web Revolution (Late 1990s-2000s): HTTP, HTML, and web browsers led to ubiquitous web applications. Distributed systems became more focused on web services (SOAP, REST). Cloud Computing & Microservices (2010s-Present): Virtualization and cloud platforms (AWS, Azure, GCP) enable highly scalable, elastic distributed systems. Monolithic applications break down into smaller, independently deployable microservices, communicating via lightweight APIs. Containerization (Docker, Kubernetes) further facilitates this. 2. a) Define Sockets. Explain its three types in Details. Definition: A socket is an abstract communication endpoint used for sending and receiving data across a network. It acts as an interface between an application and the network protocol stack. Types of Sockets: Stream Sockets (TCP Sockets): Protocol: Transmission Control Protocol (TCP). Characteristics: Connection-oriented, reliable, ordered, error-checked, flow-controlled. Data is sent as a continuous stream of bytes. Use Cases: Web browsing (HTTP), email (SMTP, POP3, IMAP), file transfer (FTP), secure shell (SSH) – applications where data integrity and order are crucial. Datagram Sockets (UDP Sockets): Protocol: User Datagram Protocol (UDP). Characteristics: Connectionless, unreliable, unordered. Data is sent as independent packets (datagrams) without guarantees of delivery or order. Faster due to less overhead. Use Cases: Online gaming, voice over IP (VoIP), video streaming, DNS lookups – applications where speed is prioritized over absolute reliability, and occasional data loss is acceptable. Raw Sockets: Protocol: Allows direct access to lower-level network protocols (e.g., IP, ICMP). Characteristics: Bypasses the transport layer (TCP/UDP) and allows applications to construct and receive packets at the IP layer. Requires elevated privileges. Use Cases: Network diagnostic tools (ping, traceroute), network sniffers, implementing new network protocols, security testing. 2. b) Write a short note on REPL Terminal. REPL stands for Read-Eval-Print Loop. It is an interactive environment provided by Node.js (and many other programming languages) that allows developers to execute code snippets directly and see the results instantly. Read: It reads the user's input (JavaScript code). Eval: It evaluates the input code. Print: It prints the result of the evaluation to the console. Loop: It then loops back to the "Read" stage, awaiting further input. Usage: You can start the Node.js REPL by simply typing node in your terminal. It's extremely useful for: Quickly testing JavaScript syntax or functions. Experimenting with Node.js APIs and modules. Debugging small code segments. Performing quick calculations or variable assignments. 3. a) How to create a Module in Node.js? Explain in details. In Node.js, modules are reusable blocks of code that encapsulate related functionality. They help organize code, prevent global namespace pollution, and promote code reuse. Node.js uses the CommonJS module system by default. Steps to Create a Module: Create a JavaScript file: This file will contain the module's code. Let's call it myModule.js . // myModule.js const PI = 3.14159; function add(a, b) { return a + b; } const subtract = (a, b) => a - b; class Calculator { multiply(a, b) { return a * b; } } Export the desired functionality: To make functions, variables, or classes available to other files, you must explicitly export them using module.exports or exports . Using module.exports (preferred for exporting a single entity or an object): // myModule.js (Exporting an object) const PI = 3.14159; function add(a, b) { return a + b; } const subtract = (a, b) => a - b; class Calculator { multiply(a, b) { return a * b; } } module.exports = { PI: PI, addFunction: add, // Exporting with a different name subtract, // Shorthand for subtract: subtract CalculatorClass: Calculator }; Using exports (shorthand for adding properties to module.exports ): // myModule.js (Exporting individual properties) exports.PI = 3.14159; exports.add = function(a, b) { return a + b; }; exports.subtract = (a, b) => a - b; Note: exports is a reference to module.exports . If you assign a new object to module.exports , exports will no longer refer to it. Import the module in another file: In another JavaScript file (e.g., app.js ), use the require() function to import the module. // app.js const myMath = require('./myModule'); // Path to your module file console.log('PI:', myMath.PI); console.log('Addition:', myMath.addFunction(5, 3)); console.log('Subtraction:', myMath.subtract(10, 4)); const calc = new myMath.CalculatorClass(); console.log('Multiplication:', calc.multiply(6, 7)); When require('./myModule') is called, Node.js executes myModule.js , and the value of module.exports from that file is returned. 3. b) Write a short note on event – driven programming. Event-driven programming is a paradigm where the flow of the program is determined by events. An event is essentially a signal that something has happened (e.g., a user clicking a button, a file being read, a network request completing). Key Concepts: Events: Occurrences that the program can respond to. Event Emitters: Objects that generate and publish events. Event Listeners (or Handlers): Functions that execute when a specific event is detected. Event Loop: A mechanism that continuously checks for events and dispatches them to their corresponding listeners. How it works (in Node.js): Node.js is inherently event-driven. It uses a single-threaded event loop. When an asynchronous operation (like reading a file or a network request) is initiated, it's offloaded to the operating system. The Node.js main thread continues executing other code. Once the asynchronous operation completes, it emits an event. The event loop picks up this event and places the associated callback function (listener) in the call stack to be executed. Benefits: Non-blocking I/O: Allows the program to remain responsive while waiting for long-running operations. Scalability: Can handle a large number of concurrent connections efficiently with a single thread. Responsiveness: Applications remain interactive as the UI thread (if applicable) isn't blocked. Example (Node.js EventEmitter ): const EventEmitter = require('events'); const myEmitter = new EventEmitter(); // Register a listener for the 'dataReceived' event myEmitter.on('dataReceived', (data) => { console.log('Data received:', data); }); // Emit the 'dataReceived' event myEmitter.emit('dataReceived', { message: 'Hello from event!' }); console.log('Program continues execution.'); 4. a) Explain Benefits of Java Servlets. Platform Independence: Since servlets are written in Java, they inherit Java's "write once, run anywhere" capability. They can run on any web server that supports a Java Servlet container (like Tomcat) and on any operating system that has a JVM. Improved Performance: Unlike traditional CGI (Common Gateway Interface) scripts, which launch a new process for every request, servlets run within the JVM. The servlet container creates a new thread (not a new process) for each request, leading to significantly lower overhead and faster response times. The servlet itself is loaded once. Robustness and Reliability: Java's strong type checking, memory management (garbage collection), and exception handling mechanisms make servlets inherently more robust and less prone to memory leaks or crashes compared to programs written in languages like C/C++. Scalability: The multithreading model allows a single servlet instance to handle multiple client requests concurrently. This makes servlets highly scalable for handling a large number of simultaneous users without significant performance degradation. Integration with Java Ecosystem: Servlets are a core part of the Java EE (Enterprise Edition) platform. They seamlessly integrate with other Java technologies like JavaServer Pages (JSP), Enterprise JavaBeans (EJB), JDBC for database access, and various other Java APIs, enabling the development of complex enterprise applications. Extensibility: The servlet API is designed to be extensible. Developers can easily create custom filters, listeners, and other components to enhance servlet functionality. Security: Java's built-in security features, combined with the security mechanisms provided by servlet containers, help in building secure web applications. Development Productivity: The rich set of libraries and tools available in Java, along with IDE support, contribute to higher developer productivity when building servlet-based applications. 4. b) Write a short note on Session Objects. In web applications, HTTP is a stateless protocol, meaning the server doesn't inherently remember previous requests from the same client. To maintain state across multiple requests from a single user, web frameworks use "sessions." A Session Object (e.g., HttpSession in Java Servlets, req.session in Node.js Express) is an object used by the server to store information about a specific user's interaction with the web application over a period of time. How it works: When a user first accesses the application, the server creates a unique session ID for that user. This session ID is typically sent back to the client and stored in a cookie. On subsequent requests, the client sends this session ID back to the server via the cookie. The server uses the session ID to retrieve the corresponding session object from its memory or persistent storage. Information Stored: Session objects can store any user-specific data that needs to persist across multiple pages or requests, such as: User login credentials/status. Shopping cart contents. User preferences or settings. Temporary data for multi-step forms. Lifecycle: Sessions have a defined lifecycle. They are created, used, and eventually invalidated (either explicitly by the application, or automatically after a period of inactivity/timeout). Benefits: Allows personalized user experiences, maintains state in stateless HTTP, and simplifies application logic by centralizing user data. 5. a) Explain four methods of Java Servlet. The javax.servlet.Servlet interface defines the core methods that a servlet must implement. Here are four fundamental methods: 1. init(ServletConfig config) : Purpose: Called by the servlet container (e.g., Tomcat) exactly once after the servlet is loaded and instantiated, but before it handles any client requests. Functionality: Used for one-time initialization tasks, such as loading configuration parameters, establishing database connections, or initializing resources that will be used throughout the servlet's lifetime. Lifecycle: The servlet is in the "initialized" state after this method completes successfully. Note: If init() throws a ServletException , the servlet will not be put into service. 2. service(ServletRequest req, ServletResponse res) : Purpose: This is the main entry point for handling client requests. The container calls this method for every client request after the servlet has been initialized. Functionality: Reads request parameters (from ServletRequest ), processes them (e.g., interacts with a database, performs business logic), and generates a response (using ServletResponse ) to be sent back to the client. Lifecycle: The servlet remains in the "service" state, handling multiple requests concurrently (each in a separate thread). Note: For HTTP servlets, the generic service() method typically dispatches to more specific doGet() , doPost() , etc., methods based on the HTTP method of the request. 3. doGet(HttpServletRequest req, HttpServletResponse resp) : (Specific to HttpServlet , which extends GenericServlet and implements Servlet ) Purpose: Handles HTTP GET requests from clients. Functionality: Typically used for retrieving information, displaying data, or serving static content. GET requests should be idempotent (multiple identical requests have the same effect as a single request) and safe (don't change server state). Parameters: HttpServletRequest provides access to HTTP-specific request details (headers, URL parameters), and HttpServletResponse allows setting HTTP-specific response details (status codes, headers, writing HTML). 4. doPost(HttpServletRequest req, HttpServletResponse resp) : (Specific to HttpServlet ) Purpose: Handles HTTP POST requests from clients. Functionality: Typically used for submitting data to the server, creating new resources, or modifying existing ones. POST requests are not necessarily idempotent and can change server state. Parameters: Same as doGet() . Input data from forms is usually available through req.getParameter() . Other important methods (briefly): destroy() (called once before servlet is unloaded), getServletConfig() , getServletInfo() . 5. b) Explain the steps in Download and Installing Tomcat Server? Apache Tomcat is an open-source implementation of the Java Servlet, JavaServer Pages (JSP), Java Expression Language, and Java WebSocket technologies. It's a widely used web server and servlet container for Java web applications. Steps to Download and Install Tomcat Server: Prerequisites - Install Java Development Kit (JDK): Tomcat requires a Java Runtime Environment (JRE) to run, and for development, a JDK is recommended. Download the latest stable JDK (e.g., OpenJDK or Oracle JDK) from their official websites. Install the JDK and set up the JAVA_HOME environment variable to point to your JDK installation directory, and add %JAVA_HOME%\bin (Windows) or $JAVA_HOME/bin (Linux/macOS) to your system's PATH variable. Verify installation by running java -version and javac -version in your terminal. Download Apache Tomcat: Go to the official Apache Tomcat website: https://tomcat.apache.org/ . Navigate to the "Download" section and choose the desired stable version (e.g., Tomcat 10, Tomcat 9). Under the "Binary Distributions" section, download the "zip" archive (for Windows) or "tar.gz" archive (for Linux/macOS) for your operating system. Choose the 32-bit or 64-bit version as appropriate. Install Tomcat (Extract the Archive): For Windows: Unzip the downloaded archive (e.g., apache-tomcat-x.y.z.zip ) to a directory of your choice. A common location is C:\Program Files\Apache Software Foundation\Tomcat X.Y or simply C:\Tomcat . Rename the extracted folder to something simple like Tomcat_X.Y . For Linux/macOS: Open a terminal and navigate to your desired installation directory (e.g., /opt or ~/Downloads ). Extract the tar.gz archive: tar -xf apache-tomcat-x.y.z.tar.gz . Move the extracted directory to a suitable location (e.g., /opt/tomcat ): sudo mv apache-tomcat-x.y.z /opt/tomcat . Set CATALINA_HOME Environment Variable (Optional but Recommended): Set an environment variable named CATALINA_HOME to point to your Tomcat installation directory. This is useful for scripts and other tools that rely on it. Windows: System Properties -> Environment Variables -> New System Variable. Linux/macOS: Add export CATALINA_HOME=/opt/tomcat to your ~/.bashrc , ~/.zshrc , or ~/.profile file, then run source ~/.bashrc . Start Tomcat Server: Navigate to the bin directory inside your Tomcat installation (e.g., C:\Tomcat_X.Y\bin or /opt/tomcat/bin ). For Windows: Run startup.bat . For Linux/macOS: Run ./startup.sh . A new terminal window or output in your current terminal should indicate that Tomcat has started. Verify Installation: Open a web browser and navigate to http://localhost:8080 . You should see the Apache Tomcat welcome page. If you do, Tomcat is successfully installed and running. Stop Tomcat Server: Navigate to the bin directory. For Windows: Run shutdown.bat . For Linux/macOS: Run ./shutdown.sh . Long Answer Questions (10 marks each) 1. Explain Remote Procedure Call and steps Execute to complete the RPC. Remote Procedure Call (RPC): RPC is a protocol that allows a program on one computer (the client) to execute a procedure (subroutine or function) on another computer (the server) without the programmer explicitly coding the remote interaction. The client program makes a local call to a "stub" function, which then handles the communication details, making the remote call appear as if it were a local call. This transparency simplifies distributed programming. Goal: To make distributed computing as similar as possible to local computing. Key Components: Client: The program that invokes the remote procedure. Client Stub: A piece of code on the client side that marshals (packs) the parameters into a message, sends the message to the server, and unmarshals the result. Server: The program that executes the remote procedure. Server Stub (or Skeleton): A piece of code on the server side that unmarshals the parameters from the message, calls the actual server procedure, and marshals the result back to the client. RPC Runtime: Handles network communication, message transmission, and reception. Steps to Execute a Remote Procedure Call: Client Invokes Client Stub: The client application makes a normal, local procedure call to the client stub, passing the required parameters. To the client, this looks exactly like calling a local function. Parameter Marshaling: The client stub marshals (serializes) the procedure name and its parameters into a standard message format suitable for network transmission. This involves converting data types into a byte stream. Message Transmission: The client stub passes the marshaled message to the local RPC runtime system. The RPC runtime then transmits the message across the network to the server's machine. Message Reception and Server Stub Invocation: On the server side, the server's RPC runtime receives the message. It passes the message to the appropriate server stub. Parameter Unmarshaling: The server stub unmarshals (deserializes) the message, extracting the procedure name and the parameters, converting them back into their original data types. Server Procedure Execution: The server stub then makes a local call to the actual remote procedure on the server, passing the unmarshaled parameters. The server procedure executes its logic and returns a result. Result Marshaling (Server Side): The server stub marshals the result (and any status information) returned by the server procedure into a message. Result Transmission: The server stub passes this result message to the server's RPC runtime, which then transmits it back across the network to the client's machine. Result Reception and Client Stub Processing: The client's RPC runtime receives the result message and passes it to the client stub. Result Unmarshaling and Return to Client: The client stub unmarshals the result message. Finally, the client stub returns the result to the client application, completing the "remote call." This entire process makes the remote call transparent to the client application, abstracting away the complexities of network communication. 2. Explain Two – Tier Architecture only with advantages and disadvantages with neat diagram. Two-Tier Architecture: A two-tier architecture is a client-server model where the presentation layer (client) runs on a client machine, and the data layer (server) runs on a separate server machine. The application logic can reside on either the client or the server, or be split between them, but there are only two distinct tiers involved in the communication. It's often referred to as "client-server" architecture where the client directly communicates with the database server. Diagram: Client Tier (Presentation & Logic) Server Tier (Data & Logic) Direct Connection Client Application Database Server SQL Queries / Results Types of Two-Tier Architecture: Thin Client: Most of the application logic resides on the server. The client primarily handles presentation. (Less common in direct 2-tier, more in 3-tier). Fat Client (or Thick Client): Most of the application logic resides on the client machine. The server is primarily a database server. This is the more common interpretation of a direct two-tier system. Advantages: Simplicity: It's relatively straightforward to design, develop, and deploy compared to multi-tier architectures, especially for smaller applications. Faster Development: Fewer layers mean less complexity, potentially leading to quicker development cycles. Direct Communication: The client directly communicates with the database, which can reduce network latency and improve response times for simple queries. High Performance for Small Systems: For a limited number of users, direct database access can be very efficient. Lower Initial Cost: Requires fewer servers and less complex infrastructure compared to multi-tier systems. Disadvantages: Limited Scalability: As the number of clients increases, the database server can become a bottleneck due to increased connection load and processing demands. Each client maintains its own connection to the database. Maintainability Issues (Fat Client): If the application logic is on the client, updates require deploying new client software to every user, which can be cumbersome. Security Concerns: Direct client access to the database can pose security risks if not properly managed, as client applications might need to hold database credentials or have significant permissions. Lack of Reusability: Business logic embedded in the client is not easily reusable by other applications or interfaces. Network Traffic: Each client-server interaction might involve complex SQL queries and large data transfers, increasing network traffic. Vendor Lock-in: Tightly coupled to a specific database vendor's client-side drivers. 3. Describe Client Server Communication using CORBA object. CORBA (Common Object Request Broker Architecture): CORBA is an open standard defined by the Object Management Group (OMG) that enables software components written in different languages and running on different platforms to communicate with each other. It's a distributed object standard. Its primary goal is to achieve interoperability and location transparency for distributed objects. Key Concepts in CORBA: Object Request Broker (ORB): The core of CORBA. It acts as a middleware that facilitates communication between clients and servers. When a client invokes a method on a remote object, the ORB intercepts the call, finds the object's implementation, transmits the parameters, and returns the results. Interface Definition Language (IDL): A language-neutral way to define the interfaces of CORBA objects. It specifies the methods, parameters, and return types of remote objects. IDL definitions are compiled into client stubs and server skeletons for specific programming languages. Client Stub (IDL Stub): Generated from IDL, it acts as a proxy for the remote object on the client side. It marshals parameters, sends the request to the ORB, and unmarshals the results. Server Skeleton (IDL Skeleton): Generated from IDL, it's on the server side. It receives requests from the ORB, unmarshals parameters, invokes the actual method on the server object, and marshals the results back. Naming Service: A standard CORBA service that allows clients to look up remote objects by name. Internet Inter-ORB Protocol (IIOP): The standard protocol used by ORBs to communicate over TCP/IP. Client-Server Communication using CORBA Object Steps: Define Interface (IDL): The first step is to define the interface of the remote object using CORBA IDL. This interface specifies the methods that the client can invoke. Example IDL: // MyService.idl interface MyService { string sayHello(in string name); long add(in long a, in long b); }; Compile IDL: The IDL compiler (e.g., idltojava for Java) is used to generate language-specific client stubs and server skeletons based on the IDL definition. These files contain the necessary code for marshaling/unmarshaling and communication. Server Implementation: The server developer implements the actual business logic for the methods defined in the IDL interface. This implementation extends or uses the generated skeleton. The server then registers its object with the ORB, typically by binding it to a name in the CORBA Naming Service. Client Implementation: The client developer uses the generated client stub. The client first initializes its ORB. It then uses the Naming Service to look up the remote object by its registered name, obtaining a reference (stub) to it. Client Invokes Remote Method: The client application makes a seemingly local method call on the client stub, passing parameters. Client Stub Action: The client stub marshals the method name and parameters into a request message. It then uses the ORB to send this request over the network (using IIOP) to the server's ORB. Server ORB and Skeleton Action: The server's ORB receives the request, identifies the target object, and passes the request to the corresponding server skeleton. The server skeleton unmarshals the parameters. It then invokes the actual method on the server object implementation. Server Object Execution and Response: The server object executes the requested method and returns the result. The server skeleton marshals this result into a response message. The server's ORB sends this response back to the client's ORB. Client ORB and Stub Action: The client's ORB receives the response and passes it to the client stub. The client stub unmarshals the result. Finally, the client stub returns the result to the client application, completing the remote method invocation. This process provides location transparency (client doesn't need to know where the object is) and language independence (client and server can be written in different languages, as long as IDL mappings exist). 4. Explain the steps in creating Node.js application. Creating a Node.js application typically involves several steps, from setting up the project to writing and running the code. Here's a detailed breakdown: 1. Initialize the Project: Create a Project Directory: Start by creating a new folder for your application. mkdir my-node-app cd my-node-app Initialize package.json : This file holds metadata about your project and manages its dependencies. Use npm to create it. npm init -y The -y flag answers "yes" to all prompts, creating a default package.json . You can edit it later. 2. Install Dependencies (NPM Packages): Most Node.js applications rely on external libraries (packages). Use npm to install them. Example: To create a web server, you'll likely use Express.js. npm install express This command downloads the express package and its dependencies into a node_modules folder and adds them to the dependencies section of your package.json . 3. Create the Main Application File: Create the primary JavaScript file where your application logic will reside, typically named app.js or index.js . touch app.js 4. Write Application Logic: Open app.js in your code editor and start writing your Node.js code. Example (Simple Express Web Server): // app.js const express = require('express'); // Import the express module const app = express(); // Create an Express application instance const port = 3000; // Define the port number // Define a route for the root URL '/' app.get('/', (req, res) => { res.send('Hello from Node.js Express App!'); }); // Define another route app.get('/about', (req, res) => { res.send('This is a simple Node.js application.'); }); // Start the server and listen for incoming requests app.listen(port, () => { console.log(`Server listening at http://localhost:${port}`); }); 5. Run the Application: Open your terminal, navigate to your project directory ( my-node-app ), and execute your main application file using the node command. node app.js You should see the "Server listening..." message in your console. 6. Test the Application: Open your web browser and go to the URL specified in your console (e.g., http://localhost:3000 ). You should see the "Hello from Node.js Express App!" message. Try navigating to other defined routes (e.g., http://localhost:3000/about ). 7. (Optional) Create a Start Script: For convenience, you can add a "start" script to your package.json . // package.json (inside "scripts" object) "scripts": { "start": "node app.js", "dev": "nodemon app.js" // If you install nodemon for auto-restarts }, Then, you can run your application using: npm start 8. (Optional) Version Control: Initialize a Git repository: git init . Create a .gitignore file to exclude node_modules : // .gitignore node_modules/ .env 9. (Optional) Deployment: Once developed, the application can be deployed to a cloud platform (e.g., Heroku, AWS, DigitalOcean) or a private server. This involves pushing your code, installing dependencies, and starting the Node.js process. 5. Explain NPM and its concepts in details. NPM (Node Package Manager): NPM is the default package manager for Node.js. It's the largest software registry in the world, hosting millions of open-source packages (libraries, modules, tools) that developers can use in their Node.js projects. It consists of three distinct components: The Website: For discovering packages, setting up profiles, and managing user accounts. The CLI (Command Line Interface): The tool developers use to interact with NPM from the terminal. The Registry: A large public database of JavaScript software. Primary Purpose: To help Node.js developers share and reuse code, manage project dependencies, and automate package installation. Key Concepts of NPM: Packages/Modules: A package (or module) is a directory containing one or more program files, along with a package.json file that describes the module. These are reusable pieces of code that provide specific functionalities (e.g., a web framework like Express, a date utility like Moment.js, a testing library like Jest). Developers publish their packages to the NPM registry, making them available for others to use. package.json : This file is the heart of any Node.js project. It's a JSON file that lives in the root directory of a project. Contents: name : Project name. version : Project version. description : A brief description. main : The entry point of the application. scripts : Custom commands that can be run (e.g., "start": "node app.js" ). dependencies : Production dependencies (packages required for the app to run). devDependencies : Development dependencies (packages needed only during development, like testing frameworks or build tools). Creation: Generated using npm init . node_modules : This directory is created in the root of your project when you install packages using NPM. It contains all the installed packages and their own dependencies. It's usually excluded from version control (e.g., via .gitignore ) because its contents can be recreated from package.json and package-lock.json . package-lock.json : Automatically generated and updated by NPM for every operation that modifies node_modules or package.json . It records the exact version of each dependency and sub-dependency that was installed, ensuring that installations are identical across different environments (e.g., between developers or on a production server). This file should always be committed to version control. NPM Commands (CLI): npm init : Initializes a new Node.js project and creates a package.json file. npm install [package-name] : Installs a package locally to the node_modules directory and adds it to dependencies in package.json . npm install [package-name] --save-dev (or -D ): Installs a package as a development dependency. npm install -g [package-name] : Installs a package globally, making its executable available from anywhere in the terminal (e.g., nodemon , create-react-app ). npm install : Installs all dependencies listed in package.json (and uses package-lock.json for exact versions). npm uninstall [package-name] : Removes a package from node_modules and package.json . npm update [package-name] : Updates a package to its latest compatible version. npm run [script-name] : Executes a custom script defined in the "scripts" section of package.json (e.g., npm run start ). npm publish : Publishes a package to the NPM registry. Semantic Versioning (SemVer): NPM adheres to SemVer, a versioning scheme (MAJOR.MINOR.PATCH). ^ (Caret): Allows minor and patch updates (e.g., ^1.2.3 means >=1.2.3 ). This is the default. ~ (Tilde): Allows only patch updates (e.g., ~1.2.3 means >=1.2.3 ). No prefix: Locks to an exact version (e.g., 1.2.3 means exactly 1.2.3 ). NPM is indispensable for modern Node.js development, facilitating efficient dependency management, code sharing, and project setup.