I definitely didn’t.

So I built a small tool that fixes this tiny but annoying problem.
It’s called slothcommit , an AI-powered CLI that generates commit messages for you.

yeah so i decided to write this blog on " my first npm package" , why I built it, and what I learned along the way.

The Problem: Writing Commit Messages is Annoying

My typical workflow looked something like this:

1. Write some code

2. Stage the files

git add .

1. Then get stuck writing a commit message.

Sometimes I would write something lazy like:

fix stuff

Or something even worse:

update

When I did want a good commit message, the workflow was painful:

1. Copy my code changes

2. Paste them into ChatGPT

3. Ask it to generate a commit message

4. Copy the result back

5. Finally run git commit

It worked but thing is it was slow and repetitive and focus am lazy asf so i wanted a more lazier way to do this git commit message thing.

So I thought:

Why can't a CLI tool just do this automatically?

That idea became slothcommit.

The Idea Behind Slothcommit

The idea was simple.

Instead of manually writing commit messages, a CLI tool should:

1. Look at the git diff

2. Send it to an AI model

3. Generate a clean conventional commit message

4. Run the commit automatically

So the workflow becomes:

git add .
sloth

And that's it.

workflow diagram :

What Slothcommit Does (or how it works)

slothcommit is an AI-powered Git commit assistant.

It analyzes your staged changes and generates a commit message using the Conventional Commit format.

Example output:

feat(auth): add refresh token middleware

and while am writing this blog the package is now getting 100+ downloads every week, which is really encouraging to see!

If you haven’t tried it yet, check it out here:
https://www.npmjs.com/package/slothcommit

and in case you like it ? do give it a star https://github.com/anshumancodes/sloth

Now to start with the whole deployment thing that we gonna do , first Install the Google Cloud CLI (gcloud) from the official site and run gcloud init to authenticate. after that enable billing on a new or existing GCP project . Dont worry you dont have to pay anything upfront as new users get $300 free credits from google , anyways after that just ensure APIs like Cloud Run and Cloud Build are enabled with gcloud services enable run.googleapis.com cloudbuild.googleapis.com.

Grant the Cloud Build service account the roles/run.builder role using gcloud projects add-iam-policy-binding PROJECT_ID --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com --role=roles/run.builder.

our sample backend app

before we go more into the gcp thing lets create a sample backend using python which we are going to deploy because ofc we need a app to deploy lol. alright now to do so :

Create a directory my-backend and add main.py inside it.

inside main.py paste this:

import os
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
    return f"Hello from GCP backend! (Port: {os.environ.get('PORT', 8080)})"
if __name__ == "__main__":
    app.run(host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))

Add requirements.txt with Flask~=3.0 and gunicorn~=23.0 for production serving.

Containerize Your App

Cloud Run automatically builds from source using buildpacks, eliminating the need for a Dockerfile for Python applications—this is managed by the gcloud run deploy command. However, for Docker users, such as those using Node.js, it is necessary to create a Dockerfile that exposes port 8080 and specifies CMD ["gunicorn", "main:app"]. To test locally, use gcloud run services deploy --source . --local after installing the necessary dependencies.

Deploy to Cloud Run

In your app directory, run:

gcloud run deploy my-backend --source . --region us-central1 --allow-unauthenticated --port 8080

Accept prompts for service name, region (e.g., asia-south1 near users), and public access. Deployment builds the container, pushes to Artifact Registry, and provides a URL like https://my-backend-xyz.run.app , cool now visit the url to verify to make sure everything is running fine.

Cloud Run scales to zero when idle, fitting free tier limits (e.g., 2 million requests/month).

Configure and Scale

Set environment variables with --set-env-vars KEY=VALUE or CPU/memory via --cpu 1 --memory 512Mi during deploy. For production, add authentication (--no-allow-unauthenticated), custom domains, or connect to Cloud SQL for databases via VPC connectors. Monitor logs in GCP Console under Cloud Run > Logs; auto-scales based on traffic (up to 1000 instances).

Connect Database

To utilize Cloud SQL with MySQL or PostgreSQL, first create an instance in the Console and obtain the connection string. During deployment, include the option --add-cloudsql-instances INSTANCE_CONNECTION_NAME.

Now For serverless applications, consider using Firestore(its very convient for new users), and it like offers like 1 GiB of free storage and 50,000 reads per day. Also ensure your application code is updated to incorporate the SQLAlchemy or google-cloud-firestore libraries in the requirements.txt file.Best Practices

Use CI/CD with Cloud Build triggers on Git pushes for auto-deploys. Monitor costs via Billing dashboard—stay under free tier by deleting unused services with gcloud run services delete my-backend. For traffic splitting or rollbacks, use GCP Console's versioning; secure with Cloud Armor if needed.​

Troubleshooting

If the build fails, start by checking the logs in the Cloud Build section to see what went wrong. In many cases, the issue is simply that the application isn’t exposing PORT=8080, which Cloud Run expects by default. If you encounter permission errors, try running the required IAM role grants again and give it a minute or two for the changes to propagate. If the application deploys but doesn’t respond, double-check the health checks and startup probes, making sure the service is actually listening on port 8080.

It’s also helpful to understand how this differs from App Engine deployments. Cloud Run provides much more flexibility because it runs containers, but that flexibility means you need to configure things like the listening port yourself. App Engine, on the other hand, is more opinionated and simpler for many Python projects you typically just define the configuration in app.yaml and deploy with gcloud app deploy.

Before we dive into how sharding and partitioning work and how they help with scaling, let's check out what a database server looks like and how it operates

So, a database server is basically just a process or service running on a computer that uses the machine's disk to store data. Let's say you're running a MySQL or Postgres process on your AWS EC2. It runs on a port of that machine and opens up that port so your server or API can communicate with it.

Now, once your database is up and running in production and serving real users, you probably started with a small server with limited hardware because, honestly, why would you go for a big one when you don't have many users yet?

Now, imagine your app is getting tons of traffic, and your database server just can't keep up anymore. Your small server can handle about 120-150 writes per second, but you're getting 200 write requests per sec, and you're seeing bad metrics like longer query times and stuff. But you still need to keep your users happy, so you decide to beef up your current database server with more power—more RAM, more CPU, and more disk space. What you just did is called vertical scaling, which helps you handle more write requests. But now you're facing another problem: even though your writes are capped at 200, your reads have increased a lot. Using just that beefed-up server will increase costs, so what do you do? Well, you can create a read replica—a copy of the existing database that only handles reads.

For now the issue seems solved with this solution .

So, let's say your app is getting even more traffic, and you're hitting 1000 writes per second. Just like before, you think about scaling up your main database server to handle it, and bam, it works! Your database can now handle 1000 writes per second, and everything's running smoothly. But then, requests go up again, and now you have to handle 1250 writes per second. You'd think about scaling up your main database server again, right? But nope, your cloud provider says you've hit the limit and can't add more power. So, what do you do now? How are you going to keep serving your users?

This is when it's time to switch to horizontal scaling because vertical scaling has its limits. You can only upgrade one server so much. So, what's the plan? We split your write requests between two database servers, each handling 700 writes per second, and spread the data across these two nodes. Now, we can easily handle 1250 requests with two database servers.

Now, by adding one more server, we've split the load across two servers, so our system runs more efficiently.

So, here's the deal with sharding—when a database is sharded, it means the data is split up across a bunch of machines (often called computes, nodes, or servers). Each shard holds a chunk (a subset) of the entire data. So, if you've got 2 shards, you've got at least 2 different computes (physical or virtual) holding those shards.

In the example above, we added a new data node/server, made a shard, and split the data evenly across the shards, 50%-50%.

Partitioning = breaking data into parts, within a single database system

But wait, what truly makes a database a database?

When we think of databases, isn't it interesting that SQL often pops into our minds first? Yet, what really defines a database isn't just the query language—it's the architecture, the engine working behind the scenes. SQL is merely the tip of the iceberg.

When it comes to SQL databases, the storage engine is like the behind-the-scenes hero that takes care of how data is stored, fetched, and kept in check. Basically, it's the part of the database management system (DBMS) that deals with SQL queries at the disk level, figuring out how tables, indexes, and records are set up. Take MySQL, for example—it has different storage engines like InnoDB and MyISAM, each tuned for specific tasks. InnoDB, which is the default, supports ACID compliance, row-level locking, and foreign key constraints, making it great for transactional apps. It uses a clustered index setup where data is stored with the primary key, allowing for speedy read and write operations.

Now, let's talk about NoSQL databases. These guys ditch the old-school relational model to give you flexible, high-speed data storage that's perfect for today's apps. Interestingly, the underlying engine can be the same for both SQL and NoSQL. Take document-oriented databases like MongoDB, for example—they often use the WiredTiger storage engine. This engine is cool because it supports document-level locking, compression, and checkpointing, which means it can handle lots of tasks at once and use disk space efficiently. WiredTiger uses a B-Tree data structure with a log-structured merge-tree (LSM) approach to make writing data faster by batching writes in memory before saving them to disk.

On the other hand, wide-column stores like Apache Cassandra are built around LSM trees, which let them handle fast writes.

What differentiates SQL and NoSQL databases

At a high level, the core difference between SQL and NoSQL databases comes down to data model, schema flexibility, and consistency guarantees.

1. Data Model

• SQL databases (also known as relational databases) use a structured, table-based format. Data is stored in rows and columns, and relationships are maintained via foreign keys and joins.

• NoSQL databases ditch the rigid structure and can be document-based (e.g., MongoDB), key-value (e.g., Redis), columnar (e.g., Cassandra), or graph-based (e.g., Neo4j). The format is flexible and can adapt to unstructured or semi-structured data.

2. Schema

• SQL requires a fixed schema—you define your tables, columns, and data types before inserting any data. Changes require migrations.

• NoSQL databases are schema-less or have dynamic schemas, allowing you to store different structures in the same collection or bucket without predefined schemas.

3. Scalability

• SQL databases are typically vertically scalable—you scale by upgrading hardware (CPU, RAM).

• NoSQL databases are horizontally scalable—you scale by adding more servers/nodes, which is great for distributed and cloud-native applications.

4. Transactions and Consistency

• SQL systems follow ACID properties (Atomicity, Consistency, Isolation, Durability), ensuring strong consistency and reliable transactions.

• NoSQL systems often follow BASE principles (Basically Available, Soft state, Eventually consistent), prioritizing availability and partition tolerance, often at the cost of immediate consistency (as per the CAP theorem).

5. Query Language

• SQL uses the Structured Query Language (SQL) for querying data—standardized and powerful, especially for complex joins.

• NoSQL databases use custom query APIs or languages tailored to their model (e.g., MongoDB uses a JSON-like query language, Redis uses command-based access).

If you're building something with strict transactional needs—like banking—SQL is your go-to. But for high-speed, flexible, large-scale applications—think social media, IoT, analytics—NoSQL might be the better fit.

One of the main things that set SQL and NoSQL databases apart is the guarantees and trade-offs they decide to make. When someone is creating a new database system, they're usually targeting a specific problem or niche. It's all about the purpose. Depending on what they need, they might think, “I want features A, B, and C, but I can skip D, E, and F.” With SQL databases, these trade-offs are pretty strict because of standardization—a relational database needs to stick to certain rules: ACID compliance, a table format, and a fixed schema. But with NoSQL, there’s no such enforcement. That’s where NoSQL shines with its flexibility. Developers get to choose which constraints to let go of and which strengths to boost.

For example, RocksDB and LevelDB were created as embedded databases—they're built to run right inside an app without needing a big server. They weren't made to be super relational or transactional, but to provide quick, low-latency storage right at the edge. Similarly, some databases focus entirely on speed and minimal persistence by keeping everything in RAM instead of on a disk—Redis is the classic example. Originally designed as an in-memory key-value store, Redis skips durability guarantees for super-fast performance, making it ideal as a cache or for temporary data. This kind of flexibility—picking trade-offs based on what you actually need—is what makes NoSQL stand out. It’s not about one-size-fits-all; it’s about whatever works best for the job.

How indexing and Join happen in SQL and NoSQL databases

Before diving into Indexing and Join, let's first get what a Node is in this context. A node is basically a logical unit of data storage within an indexing or tree structure, designed to make reads, writes, and storage on disk super efficient.

Indexing

Whether you’re using a SQL database like PostgreSQL or a NoSQL database like MongoDB or Cassandra, indexing is fundamentally about one thing: speeding up read operations by minimizing the amount of data scanned.

At its core, the concept of indexing is the same across both paradigms. Think of a dictionary: without an index, you’d read every word one by one. With an index, you know where each letter section begins—making lookup far faster. That’s exactly what databases aim to do: reduce the number of rows or documents scanned to retrieve relevant data.

Joins

Now coming to Joins one of the defining strengths of SQL databases is their ability to perform joins—that is, to combine data from multiple tables based on related keys (like foreign keys). Under the hood, SQL databases like MySQL or PostgreSQL perform joins by leveraging relational integrity, indexes, and optimized query planners. Since the data usually lives on a single machine (vertically scaled) or in a tightly controlled cluster, the database engine can efficiently fetch rows from multiple tables, align them by key, and return the joined result in one pass.

Now, Incase NoSQL databases. They're all about scaling out and spreading data across different places. In systems like MongoDB, Cassandra, or DynamoDB, data is split up across lots of nodes using a partition key. This means that the data you need for a join might be on totally different machines. To make the join happen, you'd have to gather all the data onto one machine, which can crank up network delays, CPU stress, and memory use. It's not just a hassle; it can get crazy expensive if you're dealing with huge datasets. Because of this, NoSQL databases usually skip joins altogether, pushing for denormalized data models or application-level joins. Basically, the code that ties the data together runs in your backend, not in the database itself.

Now concluding, you see when you're picking between SQL and NoSQL databases, it's all about what problem you're trying to solve, not just going with what's trendy or what you've heard. SQL databases like MySQL or PostgreSQL are great if your data is neat, and you need everything to be super reliable with those strong ACID guarantees. They can handle big chunks of data—up to 1–5TB—without making things too complicated with sharding. They're also really good at handling joins because everything's usually on one machine, so it’s quick and reliable.

But if you're dealing with flexible data structures, need to spread your data across lots of servers, or are dealing with tons of writes, like for analytics or caching, NoSQL databases like MongoDB, Cassandra, or Redis are your go-to. Just keep in mind, because NoSQL systems are often spread out, doing joins can get pricey and slow since you have to gather all the data onto one machine, which messes with the whole scaling thing. Both types of databases use similar tricks to speed up searches, and you can tweak them for better performance, but they each have their own pros and cons. You’ve got to weigh those trade-offs, thinking about consistency, availability, and scalability based on what your business needs. In the end, there's no "best" database—just the one that fits your needs the best.

But what exactly is indexing?! Well, let's explore an example of indexing. Have you ever used a dictionary? Yes, the big book, not the Python dictionary :) When you're searching for a word in a dictionary, you begin with the first letter and locate the word from there. The first letter serves as an index. The words in the dictionary are arranged by their first letter at the highest level.

Alright, enough with the analogies and beating around the bush—let's dive into the technical stuff!

In any data-driven application, a well-designed database is the backbone of performance. One of the most critical optimizations is indexing—a technique that can dramatically speed up how quickly your database retrieves data.In this post, we'll see how indexes work behind the scenes and why they are essential for efficient data retrieval.

The Cost of Disk I/O

At its core, a database consists of records stored on disk. Consider a simple SQL table, such as a users table, with columns like id, name, age, bio, and username. Each row in this table is converted into a series of bytes, for instance, 200 bytes per row. Data is written to disk in blocks, often 4 KB or, for our example, 600 bytes. This means that even reading a small piece of data requires loading an entire block into memory.

Imagine a table with 100 rows that needs 34 blocks to store all the data. In the worst-case scenario, if you need to scan the entire table, you have to read all 34 disk blocks. Even if each block read takes just one second, your query could take 34 seconds to finish. This is a significant performance cost, especially when dealing with millions of records or frequent queries for a large app.

Here's How Indexes Can Help You Out

Think of indexes as your database's table of contents. Instead of going through every row one by one to find what you need, an index cuts down the number of disk reads you have to do. Here's the scoop:

• Efficient Data Mapping: An index is like a mini table that links key values (like age or name) to where the records are. So, if you're looking for users who are 20 years old, the index has pairs of the indexed field and the row ID.

• Sorted Structure: Since the index is sorted by the column you're interested in, a query can quickly jump to the right spot for any value (like 20) and only read what's needed, saving you from unnecessary reads.Let’s break down a simplified example:

1. Without an Index:

   • The database has to go through all 34 blocks to find every row with age = 20.

2. With an Index:

   • The index is tiny (just 8 bytes per entry in our example) and might only need 2 disk blocks.

   • The database checks these 2 index blocks to find the right row IDs. Then, it only reads the 2 blocks that have the actual data.

   • All in all, this means just 4 disk block reads—a big drop from 34 blocks.

     

This kind of reduction (an 8x improvement in our example) can turn a slow, expensive task into a much quicker one. Just think about the impact in a real-world system where database speed really matters.

Behind the Scenes: How It Works

When you run a query like SELECT * FROM users WHERE age = 20, Here's the lowdown:

• Step 1: Index Scan
  The system quickly checks the small index table to find where the value 20 pops up. Since the index is smaller and sorted, this scan is super fast, using just a couple of blocks.

• Step 2: Data Fetch
  With the row IDs from the index, the system goes straight to the right rows in the main table. This skips the need to scan the whole table.

• Net Result:
  The time it takes to get the query results is way shorter because there are fewer disk I/O operations.

You see in environments where queries are executed frequently or databases are large, optimizing the read operations makes a dramatic difference. Without proper indexing, even a simple query might lead to a full table scan, causing heavy disk I/O that can degrade performance and overwhelm system resources. Conversely, with indexing, the performance gains are substantial, allowing databases to scale and run queries at lightning speeds.

Now as a newbie developer if heard about stateful and stateless auth and you google up and reading this blogpost to know what exactly stateful and stateless auth are lets begin to know what exactly these auth systems are and how to build one ? (at the end).

What is Stateful Authentication?

Stateful authentication is a method where the server retains session state for each authenticated user. This typically involves storing session data on the server, such as a unique session token or ID for each user. When a user logs in, the server verifies their identity by checking this session ID, ensuring both authentication and proper authorization.

The Challenge of Session Management

One key drawback of stateful authentication is that if the session memory is deleted on the backend, the session ID held by the client becomes completely useless. Because of this limitation, stateful authentication is often used for shorter sessions.

In such cases, users may need to log in each time they access the application.To sustain this authentication system, we ultimately have to store and update tokens in a database. Each time a user logs in, a database call is required to validate their credentials. This can lead to a significant number of database read operations, increasing costs and resource consumption.

However there are still usecases for session based auth.

Use Cases for Stateful Authentication

Despite the above stated issues, some applications still rely on stateful authentication. A good example this is banking apps, which prioritize security. In these applications, users must validate their login information every time they access their accounts to ensure maximum security,this why you have login into yono app everytime you want to use it and it automatically logs you out [india specific example]

Advantages of Stateful Authentication

• High Security: Each session has a unique session ID, making it difficult for unauthorized users to gain access.

• Simplicity: The implementation and management of stateful authentication can be pretty straightforward.

Disadvantages of Stateful Authentication

• Resource Intensive: As the number of logged-in users increases, so does the demand on server resources.

• Limited Third-Party Integration: It can be challenging for third-party applications to utilize your credentials effectively.

Now lets look into Stateless Auth.

What is Stateless Authentication?

In contrast to stateful authentication, stateless authentication does not rely on the server to maintain session state. Instead, each request from a client contains all the necessary information to verify the user's identity and authorization. This method typically uses tokens like JSON Web Tokens (JWTs).

but How Stateless Authentication Works?

With stateless authentication, credentials(payload) are stored in tokens that are encrypted using a secret key this key btw can be decrypted by anyone if they have it So, even though anyone can peek at a JWT's payload since it's just base64 encoded, that doesn’t compromise security. The real magic is in the signature. If someone tries to mess with the token, the server will reject it because the signature won’t match. It’s like a tamper-proof seal!.

When the server receives a token, it verifies it against this secret key. If any changes are made to the token data (payload) without the secret key, the server will invalidate the token and deny access.

Cool now that we are done with the theory lets build a very simple jwt base auth system in express js which will have signup , signin and a simple auth middleware that allows only authenticated users to access “/protected” route .

# initiate a project by :

mkdir auth-app
cd auth-app
npm init 

#hit enter to everything that comes after npm init

once you are done with setting up the project folder lets install express and jwt and cookie parser

# inside auth-app , lets install express and jwt first

npm i express jsonwebtoken cookie-parser

once you install the express framework , lets create a js file to write our auth app by :

#[bash]
touch app.js

now we are done with all basics and setup lets write our auth app inside app.js :)

const express = require("express");
const fs = require("fs");
const cors = require("cors");
const jwt = require('jsonwebtoken');
const cookieParser = require('cookie-parser');
const JWT_SECRET= "#fhdnenc" // KEEP THIS IN .env file in real project due to security 
const app = express();
app.use(express.json());
app.use(cookieParser());
app.use(cors());

const users = [];

app.get("/", (req, res) => {
  res.send("Welcome to the auth app");
});

function tokengenerator({ payload }) {
  return jwt.sign(payload, JWT_SECRET, { expiresIn: '1h' }); // Use '1h' for clarity
}

app.post("/signup", (req, res) => {
  const { name, email, password } = req.body;
  if (!name || !email || !password) {
    return res.status(400).send("Please fill all fields");
  }

  const user = {
    name,
    email,
    password,
  };

  users.push(user);

  res.status(200).json({ message: "Signup successful", user: { name, email } });
});

app.post("/login", (req, res) => {
  const { email, password } = req.body;
  const user = users.find((user) => user.email === email && user.password === password);

  if (!user) {
    return res.status(400).send("Invalid email or password");
  }

  const token = tokengenerator({ payload: { name: user.name, email: user.email } });
  res.cookie("token", token); // Set the token as a cookie
  return res.status(200).json({ message: "Login successful" });
});

function authvalidator(req, res, next) {
  const token = req.cookies.token; // Retrieve token from cookies

  if (!token) {
    return res.status(401).send("Unauthorized");
  }

  jwt.verify(token, JWT_SECRET, (err, decoded) => {
    if (err) {
      return res.status(400).send("Invalid token");
    }

    req.user = decoded;
    next();
  });
}

app.get("/protected", authvalidator, (req, res) => {
  res.send(`Welcome ${req.user.name} to the protected page`);
});

// Save users periodically
setInterval(() => {
  fs.writeFileSync("data.json", JSON.stringify(users));
}, 3600 * 1000); // Save every hour

app.listen(4000, () => {
  console.log("Server is running on port 4000"); // Corrected port number
});

now lets run the auth-app by :

node app.js

or you can also configure your package.json like this

{
  "name": "express-auth",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "server": "node app.js" #custom 
  },
  "author": "",
  "license": "ISC",
  "description": "",
  "dependencies": {
    "cookie-parser": "^1.4.7",
    "cors": "^2.8.5",
    "express": "^4.21.1",
    "jsonwebtoken": "^9.0.2"
  }
}

and run the app like this

npm run server

in real world application we DONT store the jwt secret in the app.js neither write all the paths and token generator function in a single file for the shake of understanding i have written all the code in single file .

also you can test this app/ api using postman or thunderclient inside vscode.

by : anshumancdx

Let's understand it with an example

Lets take my Nodejs version that is 16.20.2 , Now this version have parts as you can see . To understand this lets break down these individually.
-- first part
the last digit of V16.20.2 in this case 2 signifies minor bug fixes and doesn't have much significance, you can update your nodes to latest or can ignore it if the
last digit of the version is chnaged in changelog.

-- second part
now lets go the 2nd part or digit of V16.20.2 that is 20 now this part of the nodejs Versioning siginifies some feature update ,Bug fixes or security updates so
Updating to the version on release is recommended

-- 3rd part

now we have the 3rd part of the version V16.20.2 that is 16 this siginifies major chnage also known as breaking update that means it can break code incase of version mismatch
so its a must to update or use that version while working on application that uses a specific version

Antoher thing in the Node.js versioning is the caret (^) is used in the package.json file to specify a range of compatible versions for a dependency. t indicates that you will accept any version that is compatible with the specified version, up to the next major version.
example :^x.y.z: Allows versions from x.y.z up to, but not including, x+1.0.0.

btw you can always check your node version by typing ```node --version```

Hypertext Transfer Protocol (HTTP) is an application-layer protocol used to send documents like HTML. It makes communication between web browsers and web servers possible.

A typical http flow works like : a client makes a request to a server , and the server sends a response message to client, which basically means requests are initiated by the recipient(client), usually the browser. complete document(dom) is reconstructed from the different sub-documents fetched, like text, layout of the web page , images, videos(static resources),scripts etc.

lets understand more on http request and its components.

What is in a HTTP request?

An HTTP request is the way the client asks the information from a web server. When you enter a URL in your browser's address bar, click on a link, or submit a form on a webpage, your browser generates an HTTP request to the server hosting the website.

A HTTP request made carries with it a series of encoded data that carries different types of information like the method, request headers,Optional HTTP body,HTTP version.

lets deep dive into how these requests work, and what role the information in the request play!

HTTP methods

An HTTP method is like a set of instructions telling the server what to do when you ask for something. Think of them as action words, or sometimes people call them HTTP verbs. The two main ones are GET and POST:

- The GET method requests for a data representation of the asked resource. Requests using GET can retrieve data.

- The [POST](http://localhost:5173/blog/(https:/developer.mozilla.org/en-US/docs/Web/HTTP/Methods/POST) method sends data to a server so it may change its state. This is the method often used in html forms to send information or data to server.

HTTP request headers

Request headers contain text information stored in key-value pairs, and they are included in every HTTP request (and response, more on that later). These headers communicate core information, such as what browser the client is using and what data is being requested.

here is how it looks :

What is in an HTTP request body?

The body of an HTTP request is the section that carries the actual data being sent to the server. It includes information like usernames, passwords, or any other data entered into a form on a website. This data is crucial for the server to process and respond accordingly.

For example, when you submit a form on a webpage, the details you enter, such as your name and email address, are included in the body of the HTTP request that gets sent to the server for processing. This separation of headers (containing metadata) and the body (containing actual data) allows for efficient communication between the client and the server on the web.

what is a an HTTP response?

An HTTP response is what clients receive from the server in return of an HTTP request.These responses provides the information around what the client asked for . Now the http response also contains 3 informations or has 3 parts :

1. status code

2. response headers

3. Body

let me break it down further one by one :

HTTP status code : status codes are three-digit codes that provide context about the result of an HTTP request made by a client to a server and there are 5 categories of it like

1. 1xx Informational

2. 2xx Success

3. 3xx Redirection

4. 4xx Client Error

5. 5xx Server Error

and "xx" can be anything from 0-99.

• 2xx (Success): Starting with '2' indicates a successful request. For instance, '200 OK' signifies that the client's request for a webpage was properly completed.

• 4xx (Client Error): Starting with '4' means there was an error on the client side. A common example is '404 NOT FOUND,' which occurs when there's a mistake in the URL, like a typo.

• 5xx (Server Error): Starting with '5' indicates an error on the server side. For example, '500 Internal Server Error' suggests that something went wrong within the server while processing the request.

• 1xx (Informational): Starting with '1' denotes an informational response. However, these codes are not as commonly encountered during regular web browsing.

• 3xx (Redirection): Starting with '3' signifies a redirection. These codes instruct the client to take further action to complete the request.

HTTP Response Headers :

response headers provide additional context on the response and the data being sent in the response body. and it looks something like this :

(got this img from google , because am too lazy to inspect and make a screenshot )

HTTP response body:

When you ask a website for something using your browser, like opening a webpage, the server usually sends back a response. If everything goes well (like a '200 OK' status), the server puts the requested info in the response body. For most web stuff, that info is in the form of HTML, the language browsers use to create webpages. So, your browser takes that HTML and turns it into the webpage you see!

see you in next blog!