DEV Community: Shivam Yadav

Call me back its a promise

Shivam Yadav — Wed, 06 May 2026 20:41:22 +0000

hey its me shivam

todays topic of blog is callback and promise

so lets start without wasting any time lets move to actual work

soooo the story starts from two things

async operation
sync operation

before understanding callback and promise we first need to understand why async programming even exist

because if u directly jump into promise and callback then trust me u will memorize it

not understand it 😭

Sync Operation

so in this the code run line by line yes this is the simplest explanation of sync operation

for example

console.log("Start");

console.log("Task 1");

console.log("Task 2");

console.log("End");

so the output will be

Start
Task 1
Task 2
End

and execution might look like this

Start
 ↓
Task 1
 ↓
Task 2
 ↓
End

JavaScript waits for one task to finish before moving to the next.

simple

clean

straight

like a good boy following rules 😭

The Problem With Synchronous Code

now the problem is imagine a heavy task

like this

console.log("Start");

for (let i = 0; i < 1e9; i++) {}

console.log("Done");

JavaScript is kinda blocked after start because the loop is kinda like infinite

so at this time:

UI might freeze
button don't work
server cannot handle other request

this is called blocking code

and this is dangerous in backend too

because one blocked request can slow other users request too

and users nowadays have patience level of goldfish 💀

Async Operation

now comes the async operation in this

in this the code start executing line by line and whenever the heavy code like this is seen then it is executed but rather than standing there as a dumb

the JavaScript will run another task after that line

and when the execution of heavy task is done then the output is thrown out

example

console.log("Start");

setTimeout(() => {
  console.log("Timer Finished");
}, 2000);

console.log("End");

output

Start
End
Timer Finished

Execution flow:

Start
 ↓
setTimeout registered
 ↓
End
 ↓ (after 2 sec)
Timer Finished

so basically sync code is like good boy walking straight forward

and async code is like:

"i will not wait i busy (he not) call me when the task is done till then i will execute another baddies"

😭

Why Async Code Exists in Node.js

Node.js is built around:

non-blocking architecture
asynchronous execution
handling multiple request together

Imagine if every API request blocked the server.

then server would literally die handling large traffic

instead Node.js says:

"start the task and call me later when done"

that is the whole philosophy behind async programming

now i will explain callback and promise

i know i know it was lengthy but it was necessary guy i cannot do anything

sooooooo..........

let understand

callback
promise

What is Callback?

callback is a function which is passed as a parameter into another function so that it can call it later

yes this what callback is

this how it look's like

function greet(name) {
  console.log("Hello " + name);
}

function processUser(callback) {
  const name = "Shivam";

  callback(name);
}

processUser(greet);

Output:

Hello Shivam

What Happened Here?

processUser(greet);

We passed the greet function as an argument.

Inside:

callback(name);

The callback function gets executed later.

that is literally callback

a function waiting for another function to call it later

like me waiting for motivation to study 😭

Callback Execution Chain

Start Async Task
        ↓
Continue Other Code
        ↓
Task Completes Later
        ↓
Callback Added To Queue
        ↓
Event Loop Executes Callback

this is where Node.js event loop also enters into picture

because callback don't magically execute

event loop handles that execution

but event loop itself is another huge topic 😭

Callback Hell

while learning about callback i got to know callback hell

like this not seen much nowadays but it exist

so what is callback hell

imagine multiple task are depended on each other

example

Get user
Fetch posts
Fetch comments
Save logs

Using callbacks:

getUser(id, (user) => {
  getPosts(user.id, (posts) => {
    getComments(posts[0].id, (comments) => {
      saveData(comments, () => {
        console.log("Done");
      });
    });
  });
});

The Callback Hell Problem

This structure creates:

Deep nesting
Poor readability
Difficult debugging
Complex maintenance

This is famously called:

Callback Hell

Pyramid of Doom

because code shifts endlessly to the right.

bro this code literally starts looking like staircase 😭

So To Solve This Problem We Got Promise

so what is promise

promise is a special object used to handle asynchronous operation

it represent the eventual result of an operation that may:

complete
fail

in the future

it can be:

API request
DB calls
file reading
network communication

etc

A promise acts as a placeholder for a value that is not available immediately but will be available later.

Why Promises Are Needed?

JavaScript performs many operations asynchronously, such as:

API requests
Database queries
File reading
Timers
Network communication

These operations take time to complete.

Instead of blocking the execution of the program while waiting, JavaScript continues executing other code and uses promises to handle the result later.

Promises basically made async code cleaner and more manageable

because callback hell was becoming a horror movie 💀

States of a Promise

A promise can exist in one of three states:

State	Meaning
Pending	Initial state; operation is still running
Fulfilled	Operation completed successfully
Rejected	Operation failed

State Transition

Pending
   ↓
Fulfilled  OR  Rejected

Once fulfilled or rejected, the promise becomes permanently settled and its state cannot change again.

Promise Resolution

A promise produces a result through:

resolve()

Used when the operation succeeds.

reject()

Used when the operation fails.

Example of Promise

function fetchData() {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve("User data");
    }, 2000);
  });
}

the promise return an object which will be having:

state
returned output(data)

so to handle that we use .then().catch() syntax

which looks like this

fetchData()
  .then((data) => {
    console.log(data);
  })
  .catch((err) => {
    console.log(err);
  });

Promise Lifecycle Flow

Promise Created
        ↓
Pending
   ↓         ↓
Resolved   Rejected
   ↓           ↓
.then()     .catch()

Promise Chaining

but here there is another problem like callback hell

that is promise chain

so in this the promise is chained with .then() function

like this

fetchUser()
  .then((user) => {
    return fetchPosts(user.id);
  })
  .then((posts) => {
    return fetchComments(posts[0].id);
  })
  .then((comments) => {
    console.log(comments);
  })
  .catch((err) => {
    console.log(err);
  });

this is still way cleaner than callback hell

because now code moves downward instead of becoming pyramid

which means:

readability improve
debugging improve
maintenance improve

and developer cry little less 😭

Important Clarification

Promises do NOT make code asynchronous.

Node.js async APIs already work asynchronously.

Promises simply provide:

Better structure
Better readability
Better async management

this is very important thing

many beginner think promises create async behavior

they just manage async behavior better

under the pant thing

😭

Async/Await Comes from Promises

Modern JavaScript uses:

async/await

But internally:

async/await is built on top of promises.

Example:

async function readFile() {
  try {
    const data = await fs.readFile("demo.txt", "utf-8");

    console.log(data);
  } catch (err) {
    console.log(err);
  }
}

This looks synchronous but still works asynchronously underneath.

and this is why async/await became so popular

because human brain likes readable code 😭

Callback vs Promise Readability

Callback

getUser(id, (user) => {
  getPosts(user.id, (posts) => {
    getComments(posts[0].id, (comments) => {
      console.log(comments);
    });
  });
});

Promise

fetchUser()
  .then((user) => fetchPosts(user.id))
  .then((posts) => fetchComments(posts[0].id))
  .then((comments) => console.log(comments))
  .catch((err) => console.log(err));

Promise version clearly looks cleaner

less nesting

less chaos

less depression 💀

The Evolution of Async JavaScript

Synchronous Code
        ↓
Callbacks
        ↓
Promises
        ↓
Async/Await

Final Understanding

Callbacks introduced asynchronous programming in Node.js by allowing functions to execute later after tasks completed.

But nested callbacks created readability and maintenance problems.

Promises improved async programming by providing:

Cleaner structure
Easier chaining
Better error handling
Improved readability

The core idea behind all of them remains the same:

Start task
      ↓
Continue execution
      ↓
Handle result later

That non-blocking philosophy is what makes Node.js powerful for modern backend applications.

in the end

so in the end this is my bye

good night if u are reading this at night because i am writing this at night

and if u understood callback and promise after reading this

then my mission successful 😭

bye bye

Understanding React Virtual DOM Internally

Shivam Yadav — Wed, 06 May 2026 10:20:26 +0000

hey reader its me shivam

and today i am all researching about DOM and how React works, why am i learning it, what benefit do i get after learning it

so with this many thoughts i really got to know about what is Virtual DOM and how things internally work in React

so i am not going to bore u or anything so lets start

First let see the problem statement

so population is growing ( people are doing too much sex )

as well the user of web has also grown

and in web application there is constant changes happening like:

notification
message loading
forms validation
comments
likes
realtime updates

etc

if browser update the page directly for every changes the application would become slow and kinda heavy

this is exactly the problem faced by facebook developer

so they created REACT and react's virtual DOM was designed to solve this problem

now this was the story for React that u have heard many time

now lets start understanding of REACT working

The Problem : Direct DOM Manipulation is Expensive

before understanding Virtual DOM, first lets understand Real DOM

what is real DOM

the real DOM is the browser tree structure representing the HTML in element

Example:

<div>
  <h1>Hello</h1>
  <button>Click</button>
</div>

Browser converts this into a tree-like structure:

div
 ├── h1
 └── button

The browser basically create a tree from your HTML

and every single element becomes a node inside memory

the issue is:

updating the real DOM is Expensive ( now this sound out of the box but it is Expensive )

things like:

repainting
reflow
layout recalculation
css recalculation

Even changing a small thing in HTML can cause heavy loading

see for example there are 100's of node/html element now u want to add one more element at 98

now what browser DOM will do?

he will just reload everything create a new DOM tree and while creating it will add the new added element at 98'th place

as u can see the unnecessary loading of all 97 element is doing

parsing of HTML, then css calculation, applying

it sound heavy then imagine the actual implementation

and yes browser is fast...

but modern UI are even faster 💀

this is where React enters into the picture

imagine a social media feed

every second:

likes increase
message arrive
notification popup
comments loading

are happening now with each updating, performance would collapse

React solve this by:

creating a Virtual DOM tree
comparing changes effectively
updating only changed node

yes i know sound technical but lets see something here

What is Virtual DOM?

As the name implies, the Virtual DOM is a much lighter replica of the actual DOM in the form of objects.

it is basically a lightweight JavaScript representation of UI

this is how the object looks like

{
  type: "div",
  props: {
    children: [
      {
        type: "h1",
        props: {
          children: "Hello"
        }
      }
    ]
  }
}

The virtual DOM can be saved in the browser memory and doesn’t directly change what is shown on the user’s browser.

Implemented by several other frontend frameworks, like Vue, React’s declarative approach is unique.

this is the cool part

nothing is directly touching the browser DOM instantly

React first prepares everything virtually

like writing rough work before final answer 😭

this is what React do ( Master React )

if u understand this u will get almost 90% of React working

React is working in three stages

1) Rendering

when ever a component state or props changes, React re-render the component UI to generate a new Virtual DOM tree

this tree is kinda representation of UI component in plain JavaScript object

it is kinda same as browser DOM but omitting the browser detail

kinda help being fast

things to be known:

there are three DOM now

the previous Virtual DOM
the new updated Virtual DOM
the actual browser DOM

2) Diffing

once the new Virtual DOM is created now React perform the diffing process

it start comparing the new tree with the previous version to identify exactly which element have changed

in short it find out diff between new and old Virtual DOM

the comparison matches element types using keys and list item helps on quickly pinpointing changes

now it will only isolate the difference, significantly minimizing the number of update needed

Example of Diffing

Old tree:

<h1>0</h1>

New tree:

<h1>1</h1>

React notices:

h1 tag is same
Only text changed

So React updates only text content.

Minimal Real DOM Update

Instead of rebuilding everything:

<h1>0</h1>

becomes:

<h1>1</h1>

Only the changed node updates.

This is the key optimization.

Diagram : Diffing Process

Old Virtual DOM
      ↓
Compare
      ↓
New Virtual DOM
      ↓
Find Difference
      ↓
Update Only Changed Node

things to be known:

this process is also called reconciliation
in simple words it does comparing two Virtual DOM trees to find what changed

some people think Virtual DOM itself is the magic

but actually reconciliation is the real beast behind React 😭

Virtual DOM is just the data structure

reconciliation is the brain

3) Patching

so now after knowing the changes React generate a minimal instruction and applies the changes to the actual DOM

this process is known as patching

things to be known:

it is also known as commit phase

instead of re-rendering the entire DOM tree, only the modified parts are updated

help in reducing performance overhead with full DOM updates

and this is why React apps feel smooth most of the time

unless u forgot dependency array in useEffect

then may god help your CPU 💀

NOW lets deep dive in more of rendering

How re-rendering impacts performance

DOM operations are very fast, light operations.

However, when the app data changes and triggers an update, re-rendering can be expensive.

Let’s simulate re-rendering a page with the JavaScript code below:

const update = () => {
 const element = `
  <h3>JavaScript:</h3>
  <form>
   <input type="text"/>
  </form>
  <span>Time: ${new Date().toLocaleTimeString()}</span>
 `;

 document.getElementById("root1").innerHTML = element;
};

setInterval(update, 1000);

The DOM tree representing the document looks like the following:

now this setInterval() callback is triggering the rendering in each second as can see in the GIF

so basically the DOM element are getting rebuild and painted on each update(second)

and the text input in UI also loses its state due to the re-render

soo as u can see the problem clearly like really clearly

when ever the UI update the things written on input is getting wiped out like it was never there

basically the state is getting changed

so to solve this problem different JS framework provide different solution

React implement the concept of the Virtual DOM

As the name implies, the virtual DOM is a much lighter replica of the actual DOM in the form of objects.

this is how the object looks like

The virtual DOM can be saved in the browser memory and doesn’t directly change what is shown on the user’s browser.

how React implement the Virtual DOM

To understand the Virtual DOM strategy, we need to understand the two major phases that are involved:

rendering
reconciliation

When we render an application UI, React creates a Virtual DOM tree representing that UI and stores it in memory.

On the next update, or in other words, when the data that renders the app changes, React will automatically create a new Virtual DOM tree for the update.

To further explain this, we can visually represent the Virtual DOM as follows:

The image on the left is the initial render.

As the Time changes, React creates a new tree with the updated node, as seen on the right side.

Remember:

the Virtual DOM is just an object representing the UI

so nothing gets drawn on the screen directly.

After React creates the new Virtual DOM tree, it compares it to the previous snapshot using a diffing algorithm called reconciliation to figure out what changes are necessary.

After the reconciliation process, React uses a renderer library like ReactDOM, which takes the different information to update the rendered app.

This library ensures that the actual DOM only receives and repaints the updated node or nodes.

As seen in the image above, only the node whose data changes gets repainted in the actual DOM.

The GIF below further proves this statement:

The React Diffing Process

When React diffs two Virtual DOM trees, it begins by comparing whether or not both snapshots have the same root element.

If they have the same elements, like in our case where the updated nodes are of the same span element type, React moves on and checks the attributes.

If attributes are same then React moves deeper into child nodes.

Upon seeing that the Time text node has changed, React will only update the actual node in the real DOM.

Different Element Type Case

if both snapshots have different element types, React will destroy the old DOM nodes and build a new one.

For instance:

<span>Time: 04:36:35</span>

becomes

<div>Time: 04:36:38</div>

now React cannot optimize this because the element type itself changed

so React rebuilds that section

Example using React State

import { useState } from "react";

const App = () => {
 const [open, setOpen] = useState(false);

 return (
  <div className="App">
   <button onClick={() => setOpen((prev) => !prev)}>toggle</button>

   <div className={open ? "open" : "close"}>
    I'm {open ? "opened" : "closed"}
   </div>
  </div>
 );
};

export default App;

Updating the component state re-renders the component.

However, as shown below, on every re-render, React knows only to update:

the class name
the text that changed

This update will not hurt unaffected elements in the render.

and this is why React feel smooth

otherwise every button click would feel like windows XP restarting 😭

How React Diffs Lists

When we modify a list of items, how React diffs the list depends on whether the items are added at the beginning or the end of the list.

Consider this list:

<ul>
  <li>item 3</li>
  <li>item 4</li>
  <li>item 5</li>
</ul>

On the next update, lets append an item 6 at the end:

<ul>
  <li>item 3</li>
  <li>item 4</li>
  <li>item 5</li>
  <li>item 6</li>
</ul>

React compares the items from the top.

It matches:

item 3
item 4
item 5

and only insert item 6

This computation is straightforward for React.

easy work for React

But now comes the real issue

what if we prepend item 2?

<ul>
  <li>item 2</li>
  <li>item 3</li>
  <li>item 4</li>
  <li>item 5</li>
</ul>

Similarly, React compares from the top, and immediately realizes that item 3 doesn’t match item 2 of the updated tree.

now React compares from top and sees:

item 3 ≠ item 2

so React think:

"bro everything changed 💀"

and it may rebuild the whole list

This is why React Keys Matter

Instead of rebuilding the entire list, we want the DOM to compute minimal operations by only prepending item 2.

React lets us add a key prop to uniquely identify items.

<ul>
  <li key="3">item 3</li>
  <li key="4">item 4</li>
  <li key="5">item 5</li>
</ul>

<ul>
  <li key="2">item 2</li>
  <li key="3">item 3</li>
  <li key="4">item 4</li>
  <li key="5">item 5</li>
  <li key="6">item 6</li>
</ul>

With keys, React understands:

item 2 is new
item 6 is new
existing items are same

As a result, it would work to preserve the items that are already available and add only the new items in the DOM.

so only minimal updates happen

this is why senior developers scream:

"PUT KEYS IN LIST"

now u know why 😭

How is Virtual DOM Different from Real DOM?

A common misconception is that the Virtual DOM is faster than or rivals the actual DOM.

However, this is untrue.

In fact, the Virtual DOM’s operations support and add on to those of the actual DOM.

Essentially, the Virtual DOM provides a mechanism that allows the actual DOM to compute minimal DOM operations when re-rendering the UI.

For example, when an element in the real DOM is changed, the DOM will re-render the element and all of its children.

When it comes to building complex web applications with a lot of interactivity and state changes, this approach is slow and inefficient.

Instead, in the rendering process, React employs the concept of the Virtual DOM, which conforms with its declarative approach.

Therefore, we can specify what state we want the UI to be in, after which React makes it happen.

After the virtual DOM is updated, React compares it to a snapshot of the virtual DOM taken just before the update, determines what element was changed, and then updates only that element on the real DOM.

This is one method the Virtual DOM employs to optimize performance.

Real DOM	Virtual DOM
Heavy	Lightweight
Direct browser updates	JS object
Expensive updates	Efficient diffing
Causes repaint/reflow	Minimal updates
Hard manual manipulation	Declarative updates

The Virtual DOM abstracts manual DOM manipulations away from the developer, helping us write more predictable code so that we can focus on creating components.

Thanks to the Virtual DOM, you don’t have to worry about state transitions.

Once you update the state, React ensures that the DOM matches that state.

For instance, in our last example, React ensures that on every re-render, only Time gets updated in the actual DOM.

Therefore, we won’t lose the value of the input field while the UI update happens.

Fun Fact : Virtual DOM Isn’t Always the Fastest

I know, bold statement.

But sometimes manual DOM updates are faster, especially for static-heavy pages.

Libraries like Svelte skip the Virtual DOM altogether, compiling updates directly to the DOM at build time.

React trades a bit of raw speed for:

developer happiness
maintainability
scalability

And lets be honest

we love that.

Think of Virtual DOM Like a Draft System

Think of the Virtual DOM as your favorite todo app.

You write down what changed.

Then review and edit before committing.

Only after reviewing, you update the real list.

Same with React.

Draft first (Virtual DOM)
Diff and plan (reconciliation)
Then update reality (Real DOM)

The Virtual DOM is often credited for React’s speed, but the real hero behind the scenes is reconciliation.

it’s what determines:

what to update
when to update
how to sync efficiently

A poor reconciliation strategy can significantly impact your app’s performance.

in the end

is it really fast?

i asked this from my senior and he said at initial level u will see it as just extra working:

rendering
diffing
patching

but when we start talking about millions of nodes handling then the magic of React appears

at small level u might not notice the difference much

but at scale?

that architecture matters a lot

and that all from my side

if u find this blog interesting and knowledgeable please feel free to drop a like and comment down what can be better

i am really in need of improving

bye

see u in the next blog

till then bye bye

URL Parameters vs Query Strings in Express.js Explained from Scratch

Shivam Yadav — Fri, 01 May 2026 10:18:38 +0000

hey reader hii

today we are i mean to say u and me are going to talk about URL Parameters vs Query Strings in Express.js

yaaa yaaa its boring but let me make it intresting for u

first lets start from starting

everyone know about Tim Berners-Lee creator of URL , HTML and HTTP

he created this thing mostly to share document easily to any one

but we are going to focus on URL

why did he create URL ?

so the problem was how will we identify the document in this www or internet world

so he end up making a unique string (yes a basic developer thinking)

let decode how the first URL looks like

http://info.cern.ch/hypertext/WWW/TheProject.html

yes yes this is how it look like it is messy but everything is messy at first gradually it will get clean that what history sayy

okay okay let come back to the main topic

so in this URL

http://
this act as a protocol
tell system to use this protocol to communicate with this system
info.cern.ch
this is host
/hypertext/WWW/TheProject.html
this is path

so if u see this carefully u can see that this kinda a looking like a file system path

why ? because developer are familiar with this strcuture

so he did not made something new he just reused a familiar structure

but till now this URL is not having the params and query

Where query strings came from ?

with development the static website get converted into a dynamic website

DB gets involve, search systems came in

dynamic content was needed, people want condition baised data

That’s where query strings appeared

so there are many parameter in an url like path , query , hash (#) ,etc

we are going to focus on path which is params and another is query

so lets start with params

so this how it look in url

/users/123/posts/456

This is not random. It follows a hierarchical structure

/resource/identifier

Where did this structure come from?

this was designed directly from file system (Unix)

/home/shivam/file.txt

so basically it means

Go inside:

users
user 123
posts
post 456

General structure pattern

Basic form:

/collection/:id

Nested form:

/collection/:id/subcollection/:subId

How Express understands this

When you write:

app.get('/users/:id', (req, res) => {
  console.log(req.params);
});

Internally Express converts it to:

/users/([^/]+)

it means match after any things comes after users/
and till the next /

BTW one more thing express does not see the :id it see what is comming next after the users/ and till the next /

so :id is only showing as a wrapper code to identify it in a code so the developer can use the value in his code

how to use in express

so if first thing u have to do is to pass the name of the params so that in your code u can use it for accessing it

it look like this

/user/:id

so if u want to access it u can use

let id = req.params.id

Request:

/users/123

Extracted:

req.params = { id: "123" }

Multiple params structure

app.get('/users/:userId/posts/:postId', ...)

Request:

/users/123/posts/456

Output:

{
  userId: "123",
  postId: "456"
}

how lets talk about query

so the first AIM of query is to show data to user depending on condition

A query string is the part of a URL that comes after ? and is made of key=value pairs

this is how it looks like

/search?q=express&sort=latest&page=2

? starts the query string
& separates parameters
= assigns value to a key

{
  q: "express",
  sort: "latest",
  page: "2"
}

Original purpose

“Provide additional data to the resource without changing its identity.”

That’s why

/users/123 means the user which is identity

/users?age=20 means filtered list which is instruction

if u look closely u can the query parameter is inspired by SQL COMMAND

example

SELECT * FROM users WHERE age = 20

Query string became the web version of that

/users?age=20

4. Full structure

General format

?key=value&key2=value&key3=value

Important rules

1. every one need starting point so as query so it becames ?

/users?age=20

2. there can be multiple query parameter so we use &

/users?age=20&active=true

3. keys should be unique

/users?age=20&age=30

Allowed but it can create ambiguity

one of the most important point

Everything is text

?age=20

comes as

"20"

not number

How query parsing works internally

Step by step

Split after ?

age=20&active=true

Split by &

["age=20", "active=true"]

Split by =

age becomes 20
active becomes true

Create object

{
  age: "20",
  active: "true"
}

In Express.js

so in params u first have to declare the params but not in this

it will directly given into the req.query so access it from there

app.get('/users', (req, res) => {
  console.log(req.query);
});

Request

/users?age=20&active=true

Output

{
  age: "20",
  active: "true"
}

Important detail

Express uses parsers like

querystring which is basic
qs which is advanced

Advanced query formats

Arrays

/products?category=electronics&category=books

/products?category[]=electronics&category[]=books

Parsed

{
  category: ["electronics", "books"]
}

Nested objects

/user?filter[name]=shivam&filter[age]=20

Parsed

{
  filter: {
    name: "shivam",
    age: "20"
  }
}

Boolean or numbers

?active=true

Still string

"true"

You must convert

const active = req.query.active === 'true';

Real-world use cases

Search

/search?q=nodejs

Filtering

/products?price=low&brand=apple

Pagination

/posts?page=2&limit=10

Sorting

/posts?sort=latest

Feature toggles

/dashboard?darkMode=true

14. Internal philosophy

Query params follow this principle

“Same resource, different representation”

Example

/products?sort=price
/products?sort=rating

Same resource but different view depending on how you request it

15. Final mental model

Burn this

Query means how you want the data

Example

/users/123?include=posts&limit=5

/users/123 means what resource you are targeting

?include=posts&limit=5 means how you want that data to be returned

Final closure

so if u look at everything from starting to now

you will realize that nothing in URL design is random

everything is built on simple thinking

first identify the resource clearly using path

then modify or filter the data using query

params give you the exact thing you want

query helps you control how that thing should behave

this separation is the reason why APIs today are clean predictable and scalable

if u mix them randomly then your API will work but it will not be understandable and not maintainable

and that is the difference between just making something work and actually designing it properly

so next time when you design an API do not just write routes

think what is the resource and how it should be accessed

that is where real backend engineering starts

What Arranged Marriage Taught Me About JavaScript Promises

Shivam Yadav — Sun, 01 Mar 2026 08:42:21 +0000

Promises, Rishtas, Aur Thoda Sa Intezaar

Har Indian ghar mein ek phase aata hai.

Shaam ka time.
Mummy chai bana rahi hoti hain.
TV pe daily soap chal raha hota hai.

Aur beech mein casually ek line aati hai

“Beta… Sharma ji ka phone aaya tha.”

Bas.

Background music change.

Aapko samajh aa jaata hai.

Shaadi season officially shuru ho chuka hai.

Riya bhi ussi phase mein thi.

Job stable.
Salary theek.
Life sorted.

Par ghar walon ke hisaab se—

“Ab settle ho jao.”

Aur yahin se shuru hoti hai Promises ki kahani.

Promise Kya Hota Hai?

Promise matlab

“Abhi answer nahi milega.
Par milega.
Ya toh haan mein milega.
Ya seedha mana.”

Beech mein koi confusion nahi.

Jaise rishta.

Ya pakka.
Ya cancel.

JavaScript ne is waiting ko naam diya Promise.

Promise.all() “Sabki Haan Zaroori Hai”

Riya ka pehla rishta aaya.

Ladka achha tha.
Salary impressive thi.
Family decent thi.

Par Indian shaadi emotional nahi hoti.

System hota hai.

Checklist hoti hai.

Riya ko ladka pasand?
Mummy ko family pasand?
Papa ko job pasand?
Kundli match?

Sab green tick chahiye.

Ek bhi red cross?

Game over.

Yeh hai Promise.all().

Sab promises successful honge tabhi result milega.

Code

const riya = Promise.resolve("Riya agreed");
const parents = Promise.resolve("Parents agreed");
const horoscope = Promise.resolve("Horoscope matched");

Promise.all([riya, parents, horoscope])
  .then(() => console.log("Shaadi Pakki "))
  .catch(() => console.log("Rishta Toot Gaya "));

Agar ek bhi reject ho jaye…

Sab khatam.

Promise.allSettled() — “Mujhe Sach Batao”

Do teen rishton ke baad Riya badal gayi.

Ab woh toot’ti nahi thi.

Bas bolti thi

“Thik hai. Batao feedback kya hai.”

Ek ne mana kiya.
Ek ne horoscope issue bola.
Ek ne haan bola.

Pehle rejection insult lagta tha.

Ab woh sirf data tha.

Yeh hai Promise.allSettled().

Yeh kehta hai—

Main sabka result launga.
Jo pass hua woh bhi.
Jo fail hua woh bhi.

Code

const boy1 = Promise.resolve("Good Family");
const boy2 = Promise.reject("Horoscope Issue");
const boy3 = Promise.resolve("Nice Nature");

Promise.allSettled([boy1, boy2, boy3])
  .then(result => console.log(result));

Output:

[
 { status: 'fulfilled', value: 'Good Family' },
 { status: 'rejected', reason: 'Horoscope Issue' },
 { status: 'fulfilled', value: 'Nice Nature' }
]

Maturity is when rejection becomes information.

Promise.race() “Jo Pehle Haan Karega”

Ab ghar wale impatient ho gaye.

Dadi ne declare kar diya—

“Jo pehle haan karega, wahi final.”

Do families baat kar rahi thi.

Delhi wale soch rahe the.
Mumbai wale ready ho gaye.

Decision ho gaya.

Yeh hai Promise.race().

Jo pehle settle hua
Wahi result.

Code

const delhi = new Promise(resolve =>
  setTimeout(() => resolve("Delhi Ready"), 2000)
);

const mumbai = new Promise(resolve =>
  setTimeout(() => resolve("Mumbai Ready"), 1000)
);

Promise.race([delhi, mumbai])
  .then(result => console.log(result));

Speed bhi ek decision hoti hai.

Promise.any() “Bas Ek Haan Kaafi Hai”

Phir ek phase aaya.

Jab Riya ne decide kiya

“Mujhe perfect nahi chahiye.”

“Bas ek insaan chahiye jo mujhe choose kare.”

Paanch ne mana kar diya.

Ek ne haan bola.

Aur us ek haan ne
sab purane mana ko irrelevant bana diya.

Yeh hai Promise.any().

Code

const p1 = Promise.reject("Rejected 1");
const p2 = Promise.reject("Rejected 2");
const p3 = Promise.resolve("He Said Yes ❤️");

Promise.any([p1, p2, p3])
  .then(result => console.log(result))
  .catch(() => console.log("Sabne Mana Kar Diya"));

One success is enough.

Promise.resolve() “Instant Haan”

Kabhi kabhi cheezein simple hoti hain.

Milte hi vibe match.

No drama.

Seedha

“Let’s do this.”

Yeh hota hai Promise.resolve().

Code Example

Promise.resolve("Rishta Pakka ")
  .then(result => console.log(result));

Output:

Rishta Pakka

Immediate success. No waiting.

Promise.reject() “Seedha Mana”

Kabhi kabhi message aata hai

“Sorry. Not interested.”

Bas.

Koi explanation nahi.

Yeh hota hai Promise.reject().

Code Example

Promise.reject("Rishta Cancelled ")
  .catch(error => console.log(error));

Output:

Rishta Cancelled

Immediate rejection.

The 1% Realization

Zindagi synchronous nahi hoti.

Har cheez time leti hai.

Rishtas.
Career.
Dreams.
Replies.
Results.

Aur har jagah wahi patterns milte hain—

Sabka approval → Promise.all()
Full report → Promise.allSettled()
Jo pehle aaye → Promise.race()
Bas ek chance → Promise.any()

Programming sirf syntax nahi hai.

It’s life converted into logic.

Aur jab tum Promises samajh jaate ho…

Tum wait karna seekh jaate ho.

Kyuki intezaar bhi system ka part hai.

Aur jo intezaar samajh gaya…

Woh asynchronous se kabhi nahi darega.