Forem: Om Vaja

Node JS - The Event Loop

Om Vaja — Tue, 19 Nov 2024 10:42:00 +0000

We have discussed why Node JS is single-threaded and also multi-threaded in our article called "Node Internals". It’ll give you a solid foundation on Node’s architecture and set the stage for understanding the magic of the Event Loop!

Node js could be considered single-threaded because of the Event Loop. But, what is the event loop?

I always start with the restaurant analogy because I think it becomes easy to understand technical details.

So, In the restaurant main chef takes orders from the order list and gives them to the team of assistants. When food is ready the chef serves the food. If any VIP customers come then the chef prioritize this order.

If we take this analogy into our consideration then we can say that...

In the context of Node JS Event Loop.

Chef is the Event Loop that manages tasks and delegating work.
Team of Assistance is a worker thread or the OS that handles the execution of the delegated tasks to them.
Order List is a task queue for tasks waiting for their turn.
VIP customer is a Microtask that has high priority and is completed before regular tasks.

To, Understand Event Loop we have to first understand the difference between Microtasks and Macrotasks.

Microtask

Microtask means tasks that have some high priority and are executed after the currently executing Javascript code completes, but before moving to the next phase of the Event Loop.

Example:

process.nextTick
Promises (.then, .catch, .finally)
queueMicrotask

Macrotask

These are lower-priority tasks queued for execution at a later phase in the Event Loop.

Example:

setTimeout
setInterval
setImmediate
I/O operations

The Event Loop

When we run asynchronous tasks in Node.js, the Event Loop is at the heart of everything.

Thanks to the Event Loop, Node.js can perform non-blocking I/O operations efficiently. It achieves this by delegating time-consuming tasks to the operating system or worker threads. Once the tasks are completed, their callbacks are processed in an organized manner, ensuring smooth execution without blocking the main thread.

This is the magic that allows Node.js to handle multiple tasks concurrently while still being single-threaded.

Phases

There are six phases in an Event Loop and each phase has its own queue, which holds specific types of tasks.

1.Timers phase

In this phase timer related callbacks are handled such as setTimeout, and setInterval.

Node js checks the timer queue for callbacks whose delay has expired.

If a timer delay is met, its callback is added to this queue for execution.

console.log('Start');

setTimeout(() => {
  console.log('Timer 1 executed after 1 second');
}, 1000);

setTimeout(() => {
  console.log('Timer 2 executed after 0.5 seconds');
}, 500);

let count = 0;
const intervalId = setInterval(() => {
  console.log('Interval callback executed');
  count++;

  if (count === 3) {
    clearInterval(intervalId);
    console.log('Interval cleared');
  }
}, 1000);

console.log('End');

Output:

Start
End
Timer 2 executed after 0.5 seconds
Timer 1 executed after 1 second
Interval callback executed
Interval callback executed
Interval callback executed
Interval cleared

2.I/O callback phase

This phase's purpose is to execute callbacks for completed I/O (Input/Output) operations, such as reading or writing files, querying databases, handling network requests, and other asynchronous I/O tasks.

When you any asynchronous I/O operation in Node.js (like reading a file using fs.readFile) comes then, the operation is delegated to the operating system or worker threads. These I/O tasks are executed outside the main thread in a non-blocking manner. Once the task is completed, a callback function is triggered to process the results.

The I/O Callbacks Phase is where these callbacks are queued for execution once the operation finishes.

const fs = require('fs');

console.log('Start');

fs.readFile('example.txt', 'utf8', (err, data) => {
  if (err) {
    console.log('Error reading file:', err);
    return;
  }
  console.log('File contents:', data);
});

console.log('Middle');

setTimeout(() => {
  console.log('Simulated network request completed');
}, 0);

console.log('End');

Output

Start
Middle
End
Simulated network request completed
File contents: (contents of the example.txt file)

3.Idle phase

In this phase, no user-defined work is performed instead in this phase event loop gets ready for the next phases. only internal adjustments are done in this phase.

4.Poll phase

The Poll Phase checks whether there are pending I/O events (like network activity or file system events) that need to be processed. It will immediately execute the callbacks associated with these events.

If no I/O events are pending, the Poll Phase can enter a blocking state.

In this blocking state, Node.js will simply wait for new I/O events to arrive. This blocking state is what makes Node.js non-blocking: It waits until new I/O events trigger callback executions, keeping the main thread free for other tasks in the meantime.

Any callbacks for completed I/O operations (such as fs.readFile, HTTP requests, or database queries) are executed during this phase. These I/O operations may have been initiated in previous phases (like the Timers Phase or I/O Callbacks Phase) and are now completed.

If there are timers set with setTimeout or setInterval, Node.js will check if any timers have expired and if their associated callbacks need to be executed. If timers have expired, their callbacks are moved to the callback queue, but they will not be processed until the next phase, which is the Timers Phase.

const fs = require('fs');
const https = require('https');

console.log('Start');

fs.readFile('file1.txt', 'utf8', (err, data) => {
  if (err) {
    console.log('Error reading file1:', err);
    return;
  }
  console.log('File1 content:', data);
});

fs.readFile('file2.txt', 'utf8', (err, data) => {
  if (err) {
    console.log('Error reading file2:', err);
    return;
  }
  console.log('File2 content:', data);
});

https.get('https://jsonplaceholder.typicode.com/todos/1', (response) => {
  let data = '';
  response.on('data', (chunk) => {
    data += chunk;
  });
  response.on('end', () => {
    console.log('HTTP Response:', data);
  });
});

console.log('End');

Output:

Start
End
File1 content: (contents of file1.txt)
File2 content: (contents of file2.txt)
HTTP Response: (JSON data from the HTTP request)

5.Check phase

After the Poll Phase has completed its tasks. This phase mainly handles the execution of setImmediate callbacks, which are scheduled to run immediately after the I/O events are processed in the Poll Phase.

setImmediate callbacks are often used when you want to perform an action after the current event loop cycle, such as making sure some task is executed after the system is not busy processing I/O events.

The Check Phase has higher priority over the Timers Phase (which handles setTimeout and setInterval). This means that setImmediate callbacks will always be executed before any timers even if their timers have expired.

setImmediate guarantees that its callback will run after the current I/O cycle and before the next timer cycle. This can be important when you want to ensure that I/O-related tasks are completed first before running other tasks.

const fs = require('fs');

console.log('Start');

fs.readFile('somefile.txt', 'utf8', (err, data) => {
  if (err) {
    console.error(err);
    return;
  }
  console.log('File content:', data);
});

setImmediate(() => {
  console.log('Immediate callback executed');
});

setTimeout(() => {
  console.log('Timeout callback executed');
}, 0);

console.log('End');

Output:

Start
End
Immediate callback executed
Timeout callback executed
File content: (contents of the file)

6.close phase

The Close Callbacks Phase typically executes when an application needs to clean up before exiting or shutting down.

This phase deals with events and tasks that need to be executed once a system resource, like a network socket or file handle, is no longer needed.

Without this phase, an application might leave open file handles, network connections, or other resources, potentially leading to memory leaks, data corruption, or other issues.

const http = require('http');

const server = http.createServer((req, res) => {
  res.write('Hello, world!');
  res.end();
});

server.listen(3000, () => {
  console.log('Server is listening on port 3000');
});

setTimeout(() => {
  console.log('Closing the server...');
  server.close(() => {
    console.log('Server closed!');
  });
}, 5000);

process.on('exit', (code) => {
  console.log('Process is exiting with code', code);
});

console.log('End of the script');

Output:

End of the script
Server is listening on port 3000
Closing the server...
Server closed!
Process is exiting with code 0

There is one more special phase in the Event Loop of Node JS.

Microtask Queue

process.nextTick() and promises to execute their callbacks in a special phase in the Event Loop.

process.nextTick() schedules a callback to be executed immediately after the current operation completes, but before the event loop continues to the next phase.

process.nextTick() is not part of any phase in the event loop. Instead, it has its own internal queue that gets executed right after the currently executing synchronous code and before any phase in the event loop is entered.

It's executed after the current operation but before I/O, setTimeout, or other tasks scheduled in the event loop.

Promises have lower priority than process.nextTick() and are processed after all process.nextTick() callbacks.

console.log('Start');

process.nextTick(() => {
  console.log('NextTick callback');
});

Promise.resolve().then(() => {
  console.log('Promise callback');
});

setTimeout(() => {
  console.log('setTimeout callback');
}, 0);

console.log('End');

Output:

Start
End
NextTick callback
Promise callback
setTimeout callback

Now, You have an overall idea of how the Event Loop works.

I am giving you one question which answer you can give in the comments.

const fs = require('fs');

console.log('Start');

setImmediate(() => {
  console.log('setImmediate callback');
});

process.nextTick(() => {
  console.log('NextTick callback');
});

setTimeout(() => {
  console.log('setTimeout callback');
}, 0);

Promise.resolve().then(() => {
  console.log('Promise callback');
});

fs.readFile(__filename, () => {
  console.log('File read callback');
});

console.log('End');

Thank you.

Waiting for your answer.

Clustering and Worker Threads - Node JS

Om Vaja — Mon, 18 Nov 2024 17:44:21 +0000

In a previous article " Node JS Internals " we discussed Node JS internal architecture and also discussed why we should node increase Thread Pool size to handle multiple requests concurrently. I have told you that scalability and performance are not related to Thread Pool size.

For scalability and high performance, we can use clustering and worker threads.

Clustering

Let's say you are in a grand wedding and thousands of guests are in the wedding. There is one kitchen and one cook is preparing the food for all these guests. Sounds unpredictable, right? You are not utilizing the kitchen's full resources if you have only one cook.

This is exactly what happens in a Node JS application running on a multicore CPU when only one core is being used to handle all the requests. so, even though our machine has the power of multicores, without clustering, our application runs on just a one-core. One core is responsible for handling all the work.

When in your kitchen multiple cooks are working that's the clustering.

Clustering is a technique that is used to enable the single Node JS application to utilize multiple CPU cores effectively.

To implement clustering you have to use a cluster module from Node JS.

const cluster = require('cluster');

By using this cluster module, you can create multiple instances of our Node JS application. These instances are called workers. All workers share the same server port and handle incoming requests concurrently.

There are two types of processes in the cluster architecture.

1.Master Process:

The Master process is like the main cook in the kitchen who manages workers. It initializes the application, sets up the clustering environment, and also delegates tasks to worker processes. It does not directly handle application requests.

What does the Master process do?

Creates multiple worker processes using the cluster.fork() method. It also restarts workers if they crash or exit unexpectedly.
It makes sure that incoming requests are distributed across all worker processes. On Linux, this is handled by an operating system, and on Windows, Node JS itself acts as the load balancer.
It enables communication between workers via IPC(Inter-Process Communication).

2.Worker Processes:

Worker processes are the instance of the Node JS application created by the master process. Each process runs independently on a separate CPU core and handles incoming requests.

Worker processes cannot directly communicate with each other they communicate via master.

The worker process handles the incoming request and performs some tasks such as database query, computation, or any application logic.

const cluster = require('cluster');
const os = require('os');

if (cluster.isMaster) {
  console.log(`Master ${process.pid} is running`);

  // Fork workers
    cluster.fork();
    cluster.fork();
    cluster.fork();
    cluster.fork();

} else {
  console.log(`Worker ${process.pid} is running`);
  // Worker logic (e.g., server setup) goes here
}

Here, we are checking first this is the master process. if yes then it will create worker processes.

In our code, I am creating a worker process using cluster.fork().

But, this is not an ideal way of creating a worker process.

Suppose, you are creating 4 worker processes and your system has two cores.

To, solve this problem instead of creating worker processes hardcoded first find the CPU cores then consider that data create worker processes.

const cluster = require('cluster');
const os = require('os');

if (cluster.isMaster) {
  console.log(`Master ${process.pid} is running`);
  const numCPUs = os.cpus().length;

  // Fork workers
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }
} else {
  console.log(`Worker ${process.pid} is running`);
  // Worker logic (e.g., server setup) goes here
}

I am using dual core system so output will look like this.

Master 12345 is running
Worker 12346 is running
Worker 12347 is running
Worker 12348 is running
Worker 12349 is running

Now, you have a question if you have a dual-core CPU then why 4 worker processes created?

This is because the number of logical cores is 4, My CPU supports hyperthreading or Simultaneous Multi-Threading (SMT).

Worker Threads

In the restaurant, the waiter takes the order and gives that order to a team of cooks because cooking takes some time. If table cleaning or any other waiter-related work comes then the waiter does this. When the order is ready the cook gives food back to the waiter and the waiter serves this food to the customer.

This is the same scenario related to worker threads. If any computationally expensive tasks like large-scale data processing, complex calculations, or heavy algorithms comes then the main thread delegates this task to the worker thread. The worker performs this task, not the main thread.

*Why, this is helpful? *

We know that the Node JS event loop is single-threaded and if this heavy computational work is done by the main thread then the event loop will be blocked. If you use these worker threads then these heavy tasks are given to worker threads and worker threads perform these tasks, not the main thread so the event loop does not get blocked.

Worker threads can communicate with the main thread via a message-passing system, and data can be sent between threads using structured cloning (deep copy).

Now, we are trying to mimic the worker threads working.

main.js (Main Thread)

const { Worker } = require('worker_threads');

function startWorker() {
  const worker = new Worker('./worker.js'); // Create a worker using worker.js

  // Listen for messages from the worker
  worker.on('message', (message) => {
    console.log('Message from worker:', message);
  });

  // Handle errors in the worker
  worker.on('error', (error) => {
    console.error('Worker error:', error);
  });

  // Handle worker exit
  worker.on('exit', (code) => {
    console.log(`Worker exited with code ${code}`);
  });

  // Send a message to the worker
  worker.postMessage({ num: 100 });
}

startWorker();

worker.js (Worker Thread)

const { parentPort } = require('worker_threads'); // Access parentPort to communicate with the main thread

// Listen for messages from the main thread
parentPort.on('message', (data) => {
  console.log('Received data from main thread:', data);

  // Perform some processing
  const result = { squared: data.num * data.num };

  // Send the result back to the main thread
  parentPort.postMessage(result);
});

If data contains large structures, it will be deeply cloned and passed over, which might have some performance overhead.

Working of code

The Worker class is used to spawn new threads.
You can send data to the worker using worker.postMessage and listen for messages with worker.on('message', callback).
In the worker thread, parentPort is the primary interface to communicate with the main thread.
You can listen for messages from the main thread (parentPort.on('message')) and send messages back using parentPort.postMessage.

The output will be:

Received data from main thread: { num: 100 }
Message from worker: { squared: 10000 }
Worker exited with code 0

Now, you also have one question: why don't we create hundreds of worker threads?

But, The reason is if you create more threads than the number of cores, threads will compete for CPU time, leading to context switching, which is expensive and reduces overall performance.

When should you use clustering, worker threads, or both in Node.js?

1. When to use Worker threads?

CPU-Bound tasks:

Tasks involve heavy computations, such as Image/video processing, Data compression, or encryption, Machine learning inference, Scientific calculations

Shared Memory is required:

You need to share data efficiently between threads without duplicating it.

Single-core usage:

If your application needs to scale only within a single process but still requires parallelism for CPU-intensive tasks.

2.When to use clustering?

I/O bound:

Tasks involve handling a high number of client requests, such as Web, servers, Chat applications, and APIs. Clustering helps scale horizontally by distributing requests across all CPU cores.

Isolated memory:

Your application doesn’t need to share a lot of data between processes.

Multi-Core Utilization:

You want to utilize all available cores by spawning multiple Node.js processes.

3.When to use both clustering and worker threads?

I/O-Bound + CPU-Bound Tasks:

The application handles HTTP requests but offloads computationally intensive tasks. Example: A web server processes file uploads and performs image resizing or video transcoding.

High Scalability:

You need both process-level and thread-level parallelism for high throughput. In an E-commerce site Clustering ensures multiple processes handle incoming requests. Worker threads process background tasks like generating personalized recommendations.

Thank You.

Feel free to ask the question or give any suggestions.

If you found this informative then like it.

Node JS Internals

Om Vaja — Sat, 16 Nov 2024 16:15:53 +0000

Suppose you go to a restaurant and there is one single chef who promises that "I can cook for hundreds of people at the same time and none of you will go hungry", Sounds impossible, right? You can consider this single check as Node JS which manages all these multiple orders and still serves the food to all the customers.

Whenever you ask someone the question "What is Node JS?", a person always gets back the answer "Node JS is a runtime which is used to run JavaScript outside of the browser environment".

But, What does runtime mean?... The runtime environment is a software infrastructure in which code execution is written into a specific programming language. It has all the tools, libraries, and features to run code, handle errors, manage memory, and can interact with the underlying operating system or hardware.

Node JS has all of these.

Google V8 Engine to run the code.
Core libraries and APIs such as fs, crypto, http, etc.
Infrastructure like Libuv and the Event Loop to support asynchronous and non-blocking I/O operations.

So, we can now know why Node JS is called runtime.

This run time consists of two independent dependencies, V8 and libuv.

V8 is an engine that is also used in Google Chrome and it is developed and managed by Google. In Node JS it executes the JavaScript code. When we run the command node index.js then Node JS passes this code to the V8 engine. V8 processes this code, executes it, and provides the result. For example, if your code logs "Hello, World!" to the console, V8 handles the actual execution that makes this happen.

The libuv library contains the C++ code that enables access to the operating system when we want functionality such as networking, I/O operations, or time-related operations. It works as a bridge between Node JS and the operating system.

The libuv handles following operations:

File system operations: Reading or writing files (fs.readFile, fs.writeFile).
Networking: Handling HTTP requests, sockets, or connecting to servers.
Timers: Managing functions like setTimeout or setInterval.

Tasks like file reading are handled by the Libuv thread pool, timers by Libuv’s timer system, and network calls by OS-level APIs.

Is Node JS single-threaded?

Look at the following example.

const fs = require('fs');
const path = require('path');

const filePath = path.join(__dirname, 'file.txt');

const readFileWithTiming = (index) => {
  const start = Date.now();
  fs.readFile(filePath, 'utf8', (err, data) => {
    if (err) {
      console.error(`Error reading the file for task ${index}:`, err);
      return;
    }
    const end = Date.now();
    console.log(`Task ${index} completed in ${end - start}ms`);
  });
};

const startOverall = Date.now();
for (let i = 1; i <= 4; i++) {
  readFileWithTiming(i);
}

process.on('exit', () => {
  const endOverall = Date.now();
  console.log(`Total execution time: ${endOverall - startOverall}ms`);
});

We are reading the same file four times and we are logging the time to read those files.

We get the following output of this code.

Task 1 completed in 50ms
Task 2 completed in 51ms
Task 3 completed in 52ms
Task 4 completed in 53ms
Total execution time: 54ms

We can see that we completed all four files reading almost at 50th ms. If Node JS is single-threaded then how are all these files reading operations completed at the same time?

This question answers that the libuv library uses the thread pool. the thread pool is a bunch of threads. By default, the thread pool size is 4 means 4 requests can be processed at once by libuv.

Consider another scenario where instead of reading one file 4 times we are reading this file 6 times.

const fs = require('fs');
const path = require('path');

const filePath = path.join(__dirname, 'file.txt');

const readFileWithTiming = (index) => {
  const start = Date.now();
  fs.readFile(filePath, 'utf8', (err, data) => {
    if (err) {
      console.error(`Error reading the file for task ${index}:`, err);
      return;
    }
    const end = Date.now();
    console.log(`Task ${index} completed in ${end - start}ms`);
  });
};

const startOverall = Date.now();
for (let i = 1; i <= 6; i++) {
  readFileWithTiming(i);
}

process.on('exit', () => {
  const endOverall = Date.now();
  console.log(`Total execution time: ${endOverall - startOverall}ms`);
});

The output will look like:

Task 1 completed in 50ms
Task 2 completed in 51ms
Task 3 completed in 52ms
Task 4 completed in 53ms
Task 5 completed in 101ms
Task 6 completed in 102ms
Total execution time: 103ms

Suppose Read operation 1 and 2 completed and thread 1 and 2 become free.

You can see that the first 4 times we get almost the same time for reading the file but when we read this file the 5th and 6th time then it takes almost double the time to complete the read operations from the first four reading operations.

This happens because the thread pool size is by default 4 so four reading operations are handled at the same time but then again 2 (5th and 6th) times we are reading the file then libuv waits because all the threads have some work. When one of the four threads completes execution then 5th read operation is handled to that thread and the same for 6th time read operation will be done. that's the reason why it takes more time.

So, Node JS is not single-threaded.

But, why do some people refer to it as single-threaded?

This is because the main event loop is single-threaded. This thread is responsible for executing Node JS code, including handling asynchronous callbacks and coordinating tasks. It does not directly handle blocking operations like file I/O.

Code execution flow is like this.

Synchronous Code (V8):

Node.js executes all synchronous (blocking) code line by line using the V8 JavaScript engine.

Async Tasks Delegated:

Asynchronous operations like fs.readFile, setTimeout, or http requests are sent to the Libuv library or other subsystems (e.g., OS).

Task Execution:

Tasks like file reading are handled by the Libuv thread pool, timers by Libuv’s timer system, and network calls by OS-level APIs.

Callback Queued:

Once an async task is complete, its associated callback is sent to the event loop's queue.

Event Loop Executes Callbacks:

The event loop picks up callbacks from the queue and executes them one by one, ensuring non-blocking execution.

You can change the thread pool size using process.env.UV_THREADPOOL_SIZE = 8.

Now, I am thinking that if we set the high number of threads then we will able to handle the high number of requests also. I hope you will think like me about this.

But, It is the opposite of what we were thinking.

If we increase the number of threads beyond a certain limit then it will slow down your code execution.

Look at the following example.

const fs = require('fs');
const path = require('path');

// Set UV_THREADPOOL_SIZE to 100 (a high value) for this example
process.env.UV_THREADPOOL_SIZE = 100;

const filePath = path.join(__dirname, 'largeFile.txt');

// Function to simulate reading multiple files asynchronously
const readFileWithTiming = (index) => {
  const start = Date.now();
  fs.readFile(filePath, 'utf8', (err, data) => {
    if (err) {
      console.error(`Error reading the file for task ${index}:`, err);
      return;
    }
    const end = Date.now();
    console.log(`Task ${index} completed in ${end - start}ms`);
  });
};

const startOverall = Date.now();
for (let i = 1; i <= 10; i++) {
  readFileWithTiming(i);
}

process.on('exit', () => {
  const endOverall = Date.now();
  console.log(`Total execution time: ${endOverall - startOverall}ms`);
});

output:

With High Thread Pool Size (100 threads)

Task 1 completed in 100ms
Task 2 completed in 98ms
Task 3 completed in 105ms
Task 4 completed in 95ms
Task 5 completed in 120ms
Task 6 completed in 130ms
Task 7 completed in 135ms
Task 8 completed in 140ms
Task 9 completed in 125ms
Task 10 completed in 150ms
Total execution time: 700ms

Now, the following output is when we set the thread pool size as 4 (default size).

With Default Thread Pool Size (4 threads)

Task 1 completed in 100ms
Task 2 completed in 98ms
Task 3 completed in 105ms
Task 4 completed in 95ms
Task 5 completed in 100ms
Task 6 completed in 98ms
Task 7 completed in 102ms
Task 8 completed in 104ms
Task 9 completed in 106ms
Task 10 completed in 99ms
Total execution time: 600ms

You can see that the total execution time has a 100ms difference. the total execution time ( thread pool size 4) is 600ms and the total execution time (thread pool size 100) is 700ms. so, a thread pool size of 4 is taking less time.

Why the high number of threads != more tasks can be processed concurrently?

The first reason is that each thread has its own stack and resource requirement. If you increase the number of threads then ultimately it leads to out-of-memory or CPU resources conditions.

The second reason is that Operating systems have to schedule threads. If there are too many threads, the OS will spend a lot of time switching between them (context switching), which adds overhead and slows down the performance instead of improving it.

Now, we can say that it is not about increasing the thread pool size to achieve scalability and high performance but, It’s about using the right architecture, such as clustering, and understanding the task nature (I/O vs CPU-bound) and how Node.js’s event-driven model works.

Thank You for reading.

REST Api

Om Vaja — Fri, 04 Oct 2024 10:37:49 +0000

What is REST API?

REST stands for Representational State Transfer. To, understand REST Api we have to understand the meaning of Representational and State Transfer words in REST Api.

Representational: At the end of the day, the client and server send or receive some data. These data or resources are represented in a format such as JSON, XML, or HTML. For example, if a client requests information about a user, the server might return a JSON representation of the user's data.
State Transfer: When a client requests a resource from the server, the server sends the current state of that resource. The current state of the resource means up-to-date data. The client can then modify that resource by sending updates, and the server will save the new state.

REST API Constraints

It is an architecture pattern for designing network applications. It's helpful to increase scalability, performance, and maintainability.

Client-Server Architecture:
Client-server architecture means the client sends the request to the server and the server responds to this request. The client is responsible for the user interface and the server is responsible for application logic and data handling.
Stateless:
There are two types of communication. 1. Stateless and 2. stateful

Stateless means the server is not storing any information about the client or any previous requests. Each request is treated as an independent request.
Stateful means the server stores the information about the client across multiple requests.

REST Api should be stateless means each request from the client to the server must contain all the necessary information to understand and process the request. If the client wants to get user data then the get request will be sent and the client has to send the user id with the request if the client wants to update the user data then a put or patch request will be sent and again client has to send the user id with the request. so basically, each request is independent no data sharing should be there between requests.

3.Cacheability:
Responses can include information to tell the client whether the response can be cached and for how long, making repeated data access more efficient.

When the server sends a response, it can include headers like:

-Cache-Control: max-age=600: This tells the client that the response can be cached for 600 seconds (10 minutes).

-ETag: "abc123": This is a unique identifier for the version of the resource. The client can use this to check if the data has changed before asking the server again.

4.Layered System:
The architecture can consist of multiple layers (such as security, caching, and load balancing) between the client and server. Each layer operates independently, unaware of other layers.

A proxy or load balancer might be placed between the client and the server to distribute incoming requests without the client being aware of it.

5.Uniform Interface:
Uniform Interface means there are some standardized way for communication between the client and the server.

There are four principles:

Resource Identification:
Each resource should be identified uniquely by a URI, such as '/users/123' or '/products/44'.
Manipulation of Resources Through Representations:
Clients send representations of resources when they want to create or modify them, and the server responds with representations when they retrieve or request resources.

REST uses standard HTTP methods (like GET, POST, PUT, DELETE) to perform actions on resources.

GET: Retrieve data.
POST: Create new data.
PUT: Update existing data.
DELETE: Remove data.

3.Self-descriptive Message:
Every message between the client and server contains all the information to understand what’s happening. This includes status codes like 200 OK or 404 Not Found and the format like JSON or XML.

4.Hypermedia as the Engine of Application State(HATEOAS):
HATEOAS means including links in the response. The server helps the client know what to do next by including links in the response.

Just like if you want to see the followers, follow this link.

If you fetch the GitHub response you will see the following response.

and if you check one of the user data then you will see links that guide the user if he wants to check followers or any other information.

In short, REST APIs are a powerful way to structure communication between clients and servers. By following principles like statelessness, and uniform interfaces, and features like HATEOAS, you can design scalable and flexible systems.

Thank You.