DEV Community: Dhaval Agr'vat

The Origin of Why 🤔

Dhaval Agr'vat — Sun, 24 Aug 2025 13:02:48 +0000

Let's look into The Birth of Questions 🔮❓

So I'm currently reading the book called Sophie's World 📖, a beginner entry-level book for philosophy.

And if you want to start reading and learning about philosophy, this is something you should start with.

Well, at the staring of book there were questions. First one was:

Who are you? 🪞

Which led me to think for quite a few days - knowing who I am actually, apart from these fancy job titles 👔 and self-proclaimed mysterious terms defining my nature, which I assumed or my perception of what others think of me. But actually, who am I as an entity or a living being 🌱? I've wrote about this in one of my blogs.

But the main turning point was the statement:

As we grow older, we forget to be amazed. We get so tangled in ourselves, our work, our routines ⏳, that we stop questioning our surroundings 🌍.

Why does water from different places taste different? 💧

Why does a chameleon change its color 🦎 - what's happening in its nervous system that makes it possible?

And why am I still thinking about all this on a Sunday midnight 🌙, when I've got work tomorrow and barely enough sleep 😴? I'm going to be cooked… but I just can't let go.

So the thing was - we should start asking why again ❓.

And then, like some mysterious old sage emerging from the darkness 🧙‍♂️, whispering wisdom, I felt the urge to learn. The first thing I wanted to know was:

Where does this "why" come from?

This sounds stupid at start 😅, doesn't it? But it gets exciting as you dig more 🔍.

So for answers, I thought - why shouldn't I start with my own religion? 🙏

I'm a Hindu, born into a family of priests (sādhu lineage) 🕉️. My father and forefathers deeply believed in gods and the Vedic roots 📜. And so do I. But I've always tried to make logic out of it.

🌌 The Multiverse in Hinduism

Let me fascinate you with something: Hinduism described the multiverse long, long ago.

It begins with the great Lord Vishnu.

In the beginning, in the endless cosmic ocean (Kṣīra Sāgara) 🌊, there lies a serpent with countless heads - this is Ananta Śeṣa, the eternal one 🐍.

On the coils of this serpent rests Lord Vishnu himself, the preserver of all that exists 🙏.

From the navel (nābhi) of the Lord emerges a lotus 🌸. And on each petal of that lotus lies a universe 🌍. Think of it as countless bubbles, each floating in the vast sea of eternity.

Inside every universe, the divine trinity takes form:

Brahmā, the creator 👷‍♂️
Vishnu, the preserver 🌿
Mahesh (Shiva), the destroyer 🔥

Brahmā begins the cycle of creation in his universe. He gives birth to stars ✨, planets 🪐, beings 👤, and the endless play of life. Vishnu maintains the balance ⚖️ - nurturing worlds, guiding dharma 📖, sustaining the flow of existence. And when the time ripens, Mahesh dissolves it all back into the cosmic nothingness 🕉️.

But here's where it gets really mind-bending 🤯: this isn't a one-time story. Each universe breathes in cycles.

A single day of Brahmā (called a Kalpa) lasts billions of human years ⏳.
His night lasts just as long 🌑.
When he wakes ☀️, creation begins anew.
When he sleeps 😴, the universe dissolves into the great ocean 🌊.

Now imagine this: Brahmā lives for 100 of his own years. At the end of that lifespan, even the entire universe he governs comes to an end 💨. This is called a Maha-Pralaya - the great dissolution 💀, only to be reborn again with the cosmic breath of the ultimate Vishnu.

✨ With one breath of the Great Lord Vishnu, infinite universes emerge, and with another, infinite universes dissolve.

Creation, preservation, and destruction - it's an infinite cycle, like breathing in and out 🌬️. Universes are born, live out their time, and fade away, only to be reborn with the next breath of Vishnu 🙏.

In this vision:

Brahmā → Personification of Creation
Vishnu → Personification of Preservation
Mahesh (Shiva) → Personification of Destruction
Supreme Vishnu → Personification of the Multiverse itself

Honestly, this is the closest religion-based description I've ever found that comes near modern science's theory of a multiverse 🧬🔭.

Science says: there may be countless universes, each with its own laws ⚛️, its own birth and death 🌌. Hinduism has been telling a very similar story for thousands of years, wrapped in symbols, poetry, and philosophy 📜.

But now you're thinking: what does this have to do with the origin of why? 🤔

Well, this leads to the next question:

If Brahmā, Vishnu, Shiva 🕉️ and the cosmic ocean 🌊 all exist - where did they come from?
Who created them?
Is there an entity above them? ✨

To find answers to these questions, I started looking back at where it all began - or at least, where it was first written down: the Vedas 📜.

Now, in Rig Veda you'll find the Nasadiya Sukta, also called the Hymn of Creation 🌌.

And this answers our questions - or let me say, it's going to create more questions 🔄.

So let's dive deep into what the oldest book's Hymn of Creation says about the origin of why ❓

The Nasadiya Sukta - The First "Why" 🔮❓

Unlike later scriptures, the Nasadiya Sukta doesn't tell you what to believe. It doesn't hand over fixed answers. Instead, it asks questions with such raw honesty that even today, 3,000 years later, they feel alive, urgent, and modern.

Let's walk through its verses.

Verse 1 🌌

नासदासीन्नो सदासीत्तदानीं
नासीद्रजो नो व्योमा परो यत्।
किमावरीवः कुह कस्य शर्मन्न
अम्भः किमासीद्गहनं गभीरम्॥

"Then, there was neither existence nor non-existence.  
There was no air, no sky beyond it.  
What covered it? Where? In whose protection?  
Was there water, deep and unfathomable?"

The hymn begins by breaking our logic. We usually think in pairs: existence vs. non-existence, light vs. dark, life vs. death. But here, the seer says there was neither. Nothing to hold on to. No sky, no ground, not even space.

This sounds strangely close to what modern physics suggests about the state "before" the Big Bang: even time and space themselves did not exist. Asking "before" the Big Bang is meaningless, because time itself hadn't yet begun.

Verse 2 🕉️

न मृत्युरासीदमृतं न तर्हि
न रात्र्या अह्न आसीत्प्रकेतः।
आनीदवातं स्वधया तदेकं
तस्माद्धान्यन्न परः किंचनास॥

"There was no death then, nor immortality.  
No sign of night or day.  
That One breathed without breath, by its own power.  
Beyond that, nothing else existed."

Now Here appears a mysterious principle: "Tad Ekam" - The One. Not a god in human form, but an unnamed, undefined force or reality that simply was.

This can be seen as the singularity in cosmology - the unified state before the universe expanded. Not material, not immaterial, just a potential.

Even "death" and "immortality" are human categories. Before creation, those words had no meaning.

Verse 3 🌑🔥

तम आसीत्तमसा गूळमग्रे
प्रकेतं सलिलं सर्वमा इदम्।
तुच्छ्येनाभ्वपिहितं यदासी
त्तपसस्तन्महिना जायतेऽकम्॥

"Darkness was hidden by darkness at the beginning.  
All this was an unillumined sea.  
The void was hidden in emptiness.  
By the power of heat, the One arose."

Now, pause for a second. Doesn't that sound strangely familiar?

In the hymn, the word "tapas" is used. It literally means "heat" or "austerity," but here, we can imagine it as a cosmic energy - a raw, infinite potential waiting in silence.

Out of that void, this energy began to stir.

With imbalance, with chaos, something had to give - and in that burst, universes were born.

Science today calls this the Big Bang: an unimaginable explosion of heat and density, from which space, time, and matter unfolded.

💡 In one breath, the sages were describing what modern physics took millennia to catch up with - the idea that everything we see comes from nothing, ignited by energy.

Verse 4 💭🌱

कामस्तदग्रे समवर्तताधि
मनसो रेतः प्रथमं यदासीत्।
सतो बन्धुमसति निरविन्दन्
हृदि प्रतीष्या कवयो मनीषा॥

"Desire came upon that One in the beginning.  
It was the first seed of mind.  
The sages, searching in their hearts with wisdom,  
discovered the bond between being and non-being."

This verse takes things to another level.

Up until now, we were talking about existence and non-existence. But here something new appears - Kāma (Desire).

Before creation, there was no form, no sound, no light.

Then, a spark appeared - not physical, but mental.

That spark was desire. The universe itself, in a way, wanted to exist.

Think of it like this:

Desire → Motion → Creation.

The will to "become" led to movement, and movement unfolded into everything we see.

The Vedic seers saw Kāma as the bridge between nothing and something.

Even today, cosmologists ask the same question: why did the universe not just remain empty? What pushed it into existence?

The hymn gives a poetic answer: it was Kāma - the primal urge, the first intention.

So, according to this vision, the very first act of creation wasn't material at all. It was consciousness stirring with purpose.

🔥 In one line: The universe didn't just happen - it desired to happen.

Verse 5 🌌

तिरश्चीनो विततो रश्मिरेषामधः
स्विदासीदुपरि स्विदासीद्।
रेतोदा आसन्महिमान आसन्
स्वधा अवस्तात् प्रयतिः परस्तात्॥

"Across them stretched the cord of creation.  
Was there a below? Was there an above?  
There were seed-bearers, mighty forces.  
There was self-power below, and impulse above."

This verse imagines creation as if a cosmic thread or cord was stretched out across the emptiness - like weaving or tying the universe together.

It asks: Was there an "above" and a "below"? - suggesting the first sense of direction, order, or structure being formed.

There were forces carrying seeds - meaning sources of life or beginnings of creation.

Beneath was self-power (raw energy), and above was impulse (drive, intention).

So in short Creation wasn't random chaos. It began like a web being stretched, with energy below and purpose above, setting the stage for life to appear.

Verse 6 ✨

को अद्धा वेद क इह प्रवोचत्
कुत आजाता कुत इयं विसृष्टिः।
अर्वाग्देवा अस्य विसर्जनेनाथा
को वेद यत आबभूव॥

"Who truly knows, and who can here declare it?  
Whence it was born, whence came this creation?  
The gods are later than this world's formation.  
Who then knows from where it first arose?"

This verse is strikingly humble.

It says: Nobody really knows the origin of the universe.

Even the gods we worship came after creation, so they can't tell us how it all began.

The question remains: Where did it all come from?

In short: The mystery of the beginning is deeper than even divine knowledge. It reminds us to stay humble in our search for truth.

Verse 7 - The Bold Ending ⚡❓

यो अस्याध्यक्षः परमे व्योमन्त्सो अङ्ग वेद यदि वा न वेद॥

"He, the overseer in the highest heaven - only He knows.  
Or perhaps, even He does not know."

This is the most powerful and daring verse of the hymn.

It asks: Was the universe made by a higher being - or did it just happen by itself?

Even if there is a supreme overseer (God, Brahman, or cosmic intelligence) …

The hymn admits: Maybe He knows, or maybe even he doesn't!

And it ends with a stunning paradox. The highest being - the overseer - may know the truth of creation… or perhaps even he does not.

This is the radical courage of the Nasadiya Sukta: the recognition that uncertainty may be the ultimate truth.

The Lesson of Nasadiya Sukta 🕉️🔮

What I like most about the Nasadiya Sukta is its honesty. It doesn't tell you a story to memorize or a belief to follow. Instead, it hands us questions that are timeless, probing, and almost defiant.

The hymn teaches us:

Uncertainty is natural. Not knowing is not weakness - it's the starting point.
Questions are sacred. Even before creation, there was a "why." Inquiry itself is essence of existence.
Creation is intentional yet mysterious. Desire, tapas, and the cosmic impulse set the stage, but the final "answer" remains elusive, leaving room for wonder, imagination, and exploration.

In short, It reminds us that asking why is not only natural but essential to our existence.

Bridging Vishnu and the Nasadiya Question 🌌🙏

Now, let's connect this back to the multiverse story of Vishnu. In the lotus that emerges from Vishnu's navel, countless universes exist. Each universe has its own cycles of birth, preservation, and dissolution. And yet, the Nasadiya Sukta asks: where did even that cosmic breath come from?

Vishnu's imagery gives us symbolic understanding.

The Nasadiya Sukta gives us skeptical probing.

Both exist side by side in Hindu thought. One gives us a vision to hold on to, the other reminds us not to hold too tightly. Together, they show that Hindu philosophy embraces both imagination and inquiry, the mythic and the analytical, the heart and the mind.

So, what's the origin of why? 🤔

The first "why" was born with the universe itself. Or maybe, with the multiverse 🌌.

And the biggest why:

Why did the universe not just remain empty?

The Hymn of Creation doesn't hand us clear answers. Instead, it leaves us with deeper questions:

What is this mysterious Tad Ekam, the One beyond existence and non-existence?
Who is the Overseer - the great one watching over creation?
Does this overseer even know about our existence… or perhaps not?
What exactly is tapas, the cosmic energy, that gave rise to everything?

The beauty of the Nasadiya Sukta is that it doesn't force a belief on you. It invites you to wonder, to think, to explore. It opens doors rather than closing them.

For me, the takeaway is simple yet profound: the "why" is part of creation itself. From the very first spark of desire, from the cosmic heat, from the breath of Vishnu - questions have always been woven into existence.

And maybe, that's the point. The universe doesn't just exist to give us answers. It exists to make us ask better questions. 🌱✨

I'd love to know what you think. Do you believe the universe has a purpose, or is it all just a beautiful accident? Share your thoughts in the comments.

Your API is Cute, But Where's the Reliability Layer?

Dhaval Agr'vat — Sun, 17 Aug 2025 06:31:07 +0000

So, I recently binged The Bear. 🍽️🐻
If you haven't - no worries, let me set the table (pun fully intended).

The Bear is a TV series about a Michelin-star-level chef, Carmen "The Bear" Berzatto, who inherits his late brother's chaotic, debt-ridden sandwich shop, The Original Beef of Chicagoland.

What follows is the chaos of trying to turn it around - and eventually, the transformation of the shop into his dream restaurant, The Bear.

🔥 What you’ll see: burnt beef, clashing egos, unpaid bills, and a crew that runs more on instinct than systems. If you're into series that mix kitchen intensity with human drama, give it a try - it's one of the most raw depictions of work culture I've seen on screen.

Now, restaurants (and especially Carmy’s) don't just operate on recipes. They operate on communication rituals:

👨‍🍳 Carmy calls: “Fire two chickens, table two!”
👩‍🍳 Sydney (the sous chef) replies: “On it.”
🙌 Someone shouts: “Hands!” when food’s ready for pickup.
🔥 When moving hot pans behind a coworker, you'll hear "Behind!"
↔️ Moving through a tight corner? “Corner!”

It’s a kitchen symphony of short signals. Not polite small talk - just enough signal to keep everyone in sync, safe, and efficient.

In software development, we don’t (usually) yell “🔥 Fire!” across the room when an API crashes - but we do have logs, alerts, and monitoring.

Those are our kitchen shouts. They tell us when a service is down, when a payment fails, or when an API call took way too long to plate up.

In this part, we'll dig into:
🧾 Logging - different log types, structured logs, and dev vs. prod setups
⚡ Alerts - catching fires before they burn the whole kitchen down (Slack, email, etc.)
📊 Monitoring - watching your systems like a head chef watches the pass, using tools like Grafana & Prometheus

Because a good chef doesn’t just cook. They watch every plate, every ticket, and every timer.

So Let Me Cook....

🧾 Logging: The Kitchen Notes

Remember those order tickets flying out of the printer in The Bear? That’s logging.

But imagine if Carmy’s tickets just said:

Something went wrong.

That’s useless.

Instead, they need to be structured:

Table 5: Chicken Parm, no cheese, extra sauce  
Time: 7:35pm  
Chef: Syd  
Status: Fired

That’s structured logging.

Just like chefs shout what’s leaving the pass, devs shout through logs. Different logs serve different purposes:

🪓 Debug logs → "I’m chopping onions now" (too much detail for customers, but lifesaving for devs)
ℹ️ Info logs → "Order up!" (standard status updates, like a dish leaving the kitchen)
⚠️ Warning logs → "We’re running low on stock" (not critical yet, but worth watching)
❌ Error logs → "Stove’s broken, can’t cook this dish" (something failed, attention needed)
💀 Fatal logs → "Kitchen’s on fire!" (system crash, total failure)

In Node.js:

Use Winston or Pino for structured logs. Add context (request ID, user ID, endpoint, timestamp). Don’t just say “error occurred”. Say what, where, and why.

Example (Winston):

const winston = require("winston");

const logger = winston.createLogger({
  level: "info",
  format: winston.format.json(),
  transports: [
    new winston.transports.Console(),
    new winston.transports.File({ filename: "errors.log", level: "error" }),
  ],
});

logger.info("Order #1245 placed successfully");
logger.error("Payment failed for Order #1245");

Dev vs. Prod Logs:

Dev logs → noisy, detailed, like practice runs in the kitchen. You want all the chatter to debug.
Prod logs → clean, focused, like service time. Only critical shouts (warnings, errors, structured info).

⚠️ Monitoring & Alerts: When the Stove Catches Fire

Picture this:
The kitchen’s humming. Suddenly, a flame bursts up from the fryer.

If no one sees it? The kitchen’s gone.
If someone yells “🔥 Fire in the hole!” right away? Crisis contained.

That’s monitoring and alerts.

Monitoring = watching the stove.
Alerts = shouting before everything burns down.

In backend land:

Prometheus scrapes metrics like error rate > 5% or API latency > 2s.
Alertmanager (works with Prometheus) fires alerts when thresholds are crossed.
Alerts can hit Slack, email, PagerDuty (or all three).

Example alert rule (Prometheus):

groups:
- name: backend-alerts
  rules:
  - alert: HighErrorRate
    expr: rate(http_requests_total{status="500"}[5m]) > 0.05
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "High error rate on backend"
      description: "More than 5% of requests are failing."

This could ping your team’s Slack:

🚨 “Heads up: 500s are spiking - 5%+ error rate for last 2 minutes!”

That’s the kitchen equivalent of Carmy yelling:
🔥 “Fire in the fryer, corner! Get the extinguisher!”

🐻 The Bear (Literally): When Monitoring Saves You

Let’s stretch this out. Imagine The Bear without callouts:

Richie’s rushing hot plates but doesn’t yell “Behind!” → Marcus collides, chicken parm splatters everywhere.
Tina doesn’t yell “Corner!” → Sydney crashes into her with soup, burns both.
Nobody says “Hands!” → Plates sit, food gets cold, customers complain.

Now imagine the bear 🐻 itself (not Carmy, an actual bear) walking into the kitchen.

Without monitoring → Nobody notices until the bear is flipping tables.
With observability → You’d see paw prints early.
With alerts → Slack message: 🚨 “Unusual traffic spike: Bear detected in kitchen. Act fast.”

Everyone scrambles, crisis managed. No lawsuits from diners mauled mid-dinner.

That’s why monitoring matters: You don’t wait until the bear’s at the door. You spot it pacing outside — and you lock the back entrance.

📊 Observability: Seeing What's Cooking

Observability isn't just "logging some errors." It's knowing what's happening inside your system without cracking it open.

In the kitchen:

You can see the steak sizzling, hear the ticket machine spitting out new orders, and smell when something's starting to burn. You don’t need to rip open the oven mid-service to check if the bread’s rising. You already know from your senses.

In your backend:

Observability is the combination of metrics, logs, and traces that let you see, hear, and smell what your system is doing.

Instead of guessing why a request is slow, you trace it across services.
Instead of hoping memory isn’t leaking, you watch metrics tick upward in real time.

💡 Tools to start with:

Prometheus → collects your system’s metrics (CPU, memory, request durations, error counts).
Grafana → your wall of kitchen screens. Dashboards showing "orders in flight," "burnt dishes," and "prep times."

📈 Grafana & Prometheus: Your Kitchen TV Screens

Practical setup:

Prometheus = the chef writing down every stat (oven temp, ticket counts, plate times).
Grafana = the big kitchen TV showing it all in real time.

Example dashboards in Grafana:
🔥 Orders per second (API RPS)
🥵 Error rate (dishes ruined)
⏱️ Latency (how long dishes take to leave the pass)
🧯 Alert triggers (fires in the stove)

A Grafana panel might show:

CPU usage climbing like a Saturday night rush.
Database queries spiking like too many tickets dropped at once.

And the best part? Grafana can ping you:
🔔 ALERT: DB latency above 2s for last 5m

Now you don’t just hope you catch the problem — you’re actively notified before customers complain.

🥡 Wrapping It Up

At the end of the day, logs, metrics, and alerts aren’t optional add-ons — they’re the corner calls, behind shouts, and fire drills of your system.

✅ Logs = Order tickets (structured, detailed, trackable). → Winston, Pino
✅ Metrics = Oven temp, ticket counts, stock levels. → Prometheus
✅ Dashboards = Big kitchen TV showing what’s burning & flowing. → Grafana
✅ Alerts = “Corner!”, “Behind!”, “🔥 Fire in fryer!” — Slack pings, emails, PagerDuty wake-ups.

Without these?
👉 You’re Carmy on opening night at The Bear - no printer, no callouts, no system. Just chaos and burnt beef.

With them?
👉 You’re running a Michelin-star kitchen where every plate is tracked, timed, and served with precision.

🔑 Observability = backbone of reliability. You don’t just cook - you watch, listen, and react before the fire spreads.

🔜 Up Next: Retries, Backoff & Rate Limiting

Now that we can see what’s cooking (and burning), the next step is learning how to respond to failure without burning out the whole kitchen.

In the next chapter, we’ll dive into:
🍲 Retry Logic & Backoff → When a dish fails, you don’t just keep tossing it in the oven. You cool down, reset, and try again smartly.
🚦 Rate Limiting & Throttling → Sometimes the problem isn’t the food, it’s too many orders hitting the kitchen at once.

Think of it as the kitchen traffic control system: deciding which orders to cook, when to retry, and how to keep the whole service flowing smoothly.

Stay tuned - because your API might be cute, but without retries and throttling, it’s about as reliable as Richie running the pass on his own.

📝 TL;DR (Too Long; Didn’t Read)

For the skimmers 👀 - here’s your quick takeaway:

🧾 Logs → Your kitchen tickets. Keep them structured & detailed.
📊 Metrics → Oven temp, ticket counts, wait times. (Prometheus)
📺 Dashboards → Kitchen TV showing live service flow. (Grafana)
⚠️ Alerts → “🔥 Fire!” warnings before chaos spreads. (Slack, PagerDuty, Email).
🐻 Without these → Chaos, burnt beef, customers yelling.
⭐ With these → Michelin-star precision, happy customers, stable APIs.

👉 Observability isn’t optional. It’s the difference between Carmy’s chaos and a smooth-running kitchen.

Hope this helps make your monitoring a bit tastier 🍳! Sit back, try it out, and let me know your thoughts in the comments 👇.

Your API is cute, but is it secure?

Dhaval Agr'vat — Sun, 27 Jul 2025 08:36:42 +0000

Your API is Cute, But Where's the Real Backend? - Part 2 🤔

In Part 1, we ran the kitchen - took orders, routed them to the right chefs, and served our hungry users.
But now it's time to secure the place.
Because a solid backend without security is like a fancy restaurant with the doors wide open and your secret sauce recipe taped to the front window.

Soo... Let Me Cook 👨🏻‍🍳 !!!

🧾 1. JWTs - Who's Allowed In?

A guy in a stained T-shirt walks through the back door claiming he's "new kitchen staff."
No apron. No ID. Just vibes 🤨.
Would you:
a) Hand him the spatula? 🍳
b) Call the manager? 📞
c) Chuck him out? 🚫

In a restaurant, identity matters. So does it in your backend.

Think of JWTs (JSON Web Tokens) as guest passes. Without one, you're not getting a seat, let alone the special menu.

🧂 How it works:

// User logs in → you give them a signed token
{
  "userId": "12345",
  "role": "admin",
  "exp": 1724102400
}

// Client sends it in every request
Authorization: Bearer <token>

// You verify it on every incoming request

🔐 No token, no service. Go grab a reservation.

🧾 2. Validate Everything - Trust No Ingredient

An order slip comes in:
"One 🍔 burger with alert("HAH!") sauce and a DROP TABLE fries 🍟💣."
Your chef pauses. This ain't food - it's sabotage 🧨.

Never trust raw input. That's how you end up with broken dishes and food poisoning (aka bugs and exploits) 🤢.

Why I use Zod:

TypeScript-friendly.
Clear schema definitions.
Instant, helpful error messages.

import { z } from "zod";

const orderSchema = z.object({
  itemId: z.string().uuid(),
  quantity: z.number().min(1),
  instructions: z.string().optional(),
});

const result = orderSchema.safeParse(req.body);

if (!result.success) {
  return res.status(400).json({ error: result.error });
}

🍅 Bad inputs don't get past the kitchen door.

🧾 3. Request Signatures - Is It Really from the Delivery Partner?

You get a phone call 📞:
"Yeah, send 20 pizzas🍕 to table 12. No, you don't know me. But trust me 🚩."

Sketchy, right?

Stripe, Razorpay, or Twilio send data to your backend. But how do you know it's actually from them?

You verify the signature:

const sig = req.headers['stripe-signature'];
const event = stripe.webhooks.constructEvent(req.body, sig, endpointSecret);

✉️ Fake orders? Not in my kitchen.

🧾 4. Rate Limiting - No One Gets to Hog the Buffet

Imagine an all-you-can-eat buffet 🍽️. Everyone's welcome - but if someone starts hogging the French fries🍟 tray and stuffing it into their bag 🛍️, you're gonna have a problem.

Rate limiting is your gentle-yet-firm waiter 👨‍🍳 who says,
"Sir, you've already had 100 dumplings 🥟. Let's give others a chance."

✅ Keeps your kitchen running smooth.
✅ Stops bad actors from overwhelming the chef.

Protect your kitchen from spammy bots and overly enthusiastic users.

import rateLimit from 'express-rate-limit';

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 100,
});

app.use('/api/', limiter);

🍽️ One plate per person, please.

🧾 5. Sanitization - Clean Those Ingredients

Would you toss dirty, unwashed vegetables 🥬🥕 straight into a customer's meal?
No?
Then don't throw raw user input into your database or HTML either.

This is your sous chef 👨‍🍳 rinsing every tomato 🍅, checking for moldy spinach 🧫, and making sure no one's dropped a cockroach 🪳 in the curry 🍛 (aka <script>alert(1)</script>).

✅ Protects against XSS
✅ Keeps the dish (and your app) safe to serve

Don’t let dangerous code sneak in through user input.

Use xss, sanitize-html, or ORM-level sanitization.
Always escape stuff shown on the frontend.
Never directly plug user input into database queries.

import xss from 'xss';

const cleanComment = xss(req.body.comment);

👨‍🍳 No one wants <script>alert(1)</script> in their lasagna.

🧾 6. Secure Headers - Lid on the Dish

You just made the perfect Curry 🍛.
You don't leave it sitting open near a window where flies and stray cats can jump in 🤢.
You cover it.

Secure headers are the cling film, the plastic lid, the "do not touch" sign.
They tell browsers how to treat your content safely and defensively.

✅ Deflects common exploits
✅ Gives your frontend a safety net

Add security-focused headers to protect your frontend from common attacks (XSS, clickjacking, etc.).

Use helmet for Express
Use next-secure-headers for Next.js

import helmet from 'helmet';

app.use(helmet());

🛡️ It's the cling wrap on your freshly made ravioli.

🧾 7. Secrets & Config — Lock the Pantry

Would you shout your secret sauce recipe across the dining room while the health inspector's watching? 🤷‍♂️
Exactly.

Secrets (like API keys and DB passwords) don't belong in your codebase.

Use:

.env files (but keep them out of Git)
Secret managers (like AWS Secrets Manager, Vercel's UI, etc.)

JWT_SECRET=supersecretkey
STRIPE_KEY=sk_test_abc123

🗝️ Would you leave your house keys taped to the door? Didn't think so.

👨‍🍳 Next Up: Observability, Logging, and Monitoring (Part 3)

The orders are flowing. The doors are locked.
But what if the stove catches fire?

In Part 3, we'll dig into:

📊 Observability: see what's cooking (and what's burning)
🧾 Structured logging with Winston & Pino
⚠️ Monitoring, alerts, and catching bugs in real-time

Because a good chef watches every plate leave the kitchen — and knows when something's burning.

Let me know in comments if your API is now a little more secure 🍜
The kitchen's locked. Now it's time to install smoke alarms and CCTV.
See you in Part 3 🔥📊

The Day I Started Asking 'Why' Again

Dhaval Agr'vat — Sat, 19 Jul 2025 10:17:51 +0000

The last few months? One big blur.

Wake up (late). Guzzle some coffee. Push code. Fix one thing, break two. Hop on calls. Eat whatever's fastest. Scroll mindlessly. Sleep way too late. Repeat. 🐿️

I was deep in a project building a full-on dev ecosystem – deploy platform, AI workspace, Trello-style board, you name it. It was exciting, sure. But it was also… draining. Like running a marathon on a treadmill that never stops.

Then one Sunday evening, something super ordinary snapped me out of it.

I stepped outside and saw a group of kids playing in a pile of sand in front of my house. Just sand, sticks, and wild imaginations. They were building castles, naming towers, laughing like they'd just conquered a kingdom. 🏰

I stood there for a few minutes, just watching them – and suddenly felt something I hadn't in a while: nostalgia.

I used to do that.

As a kid, I'd build things out of nothing, spend hours asking weird questions, imagining wild scenarios. No goal. Just play and wonder.

That moment stirred something inside me. And then the rain came.

No really – like heavy city-shutdown-level rain. 🌧️

Work paused. Roads flooded. I was stuck at home for a couple of days. And for the first time in months, I had silence. Time. Space.

That's when I remembered something I had bookmarked forever ago: Sophie's World. A beginner-friendly intro to philosophy.

Around that same time, I'd been learning bits about Stoicism – reading about Marcus Aurelius and how he handled power, problems, and personal stuff. 🧘‍♂️ Came across Machiavelli too. All of it was interesting, but scattered.

So I thought: let's do this right. Start from the basics.

I picked up the book.

A few pages in, I was hit with a question:

"Who are you?"

I froze.

It's such a simple question, but it felt huge. Not "What's your name?" or "What do you do?"

But… who are you, really? 🤯

I closed the book and just sat with that question for a while.

And that's how the journey began.

🌟 Growing Up Means We Forget to Wonder

There's a line in the book that says:

"The only thing we require to be good philosophers is the faculty of wonder."

That hit hard.

As kids, we ask questions all the time:

🧠 Why is the sky blue?

🛏️ What happens when we sleep?

😢 Why do people get sad?

But then we grow up. Get busy. Get used to things. We stop asking.

We start functioning instead of wondering. Performing instead of pausing.

And I realized – maybe I hadn't stopped being curious… I had just buried it under routines and backlogs.

🤔 So… What Is Philosophy, Really?

Honestly? I used to think it was all vague quotes, complicated books, and men in togas asking questions like "Does this table exist?"

But reading Sophie's World made me see it differently.

Philosophy isn't just about big thinkers. It's about pausing. Observing. Asking the kind of questions we usually skip.

Like:

🧐 Why do I live the way I do?

🪞 What do I actually believe?

💡 What really matters to me?

You don't need to be a genius. You don't need a PhD.

You just need to be honest. Open. Willing to sit with questions, even if there are no quick answers.

✍️ Why I'm Writing This

This isn't a guide. Or a deep dive.

This is just me, a developer with a busy brain, who paused one day – and started asking why.

Maybe you're in a similar loop.

Maybe your days feel copy-pasted.

Maybe your curiosity is still there, just a little buried.

This series is for you.

Let's start wondering again. 🌱

🔮 What's Next?

In Part 2, we'll talk about myths – not just the ancient gods, but the stories we tell ourselves every day.

But for now, I'll leave you with the same question that pulled me in:

Who are you?

Not your job.

Not your to-do list.

Not your routine.

Just… you.

Your API is Cute, But Where's the Real Backend?

Dhaval Agr'vat — Sat, 19 Jul 2025 09:57:04 +0000

🛸 Imagine This...
You open a brand-new restaurant. You've got:

A counter
A waiter taking orders
A chef making food
A menu

Great! You're officially serving CRUD:

Create = New orders
Read = View menu or order
Update = Change your order
Delete = Cancel your order

🎉 Congrats! You made a backend!

But here's what happens next:

👥 10 customers walk in. Fine.
🍽️ 100 show up during lunch rush. Okay.
📱 1000 hit your restaurant via a food delivery app. Uh-oh.

Now:

Half want live order tracking
Some cancel midway
A few never pay
Someone's spamming your system with fake orders
Chefs are overwhelmed

💥 Your CRUD-only "backend" crumbles.

🧠 Let's Build the Real Backend

You don't just need a backend - you need a system.

Here's how restaurant operations map to real backend architecture:

🔐 1.Security: No One Walks Into the Kitchen Unchecked

Imagine your restaurant is booming. Orders are flying in. But suddenly… someone walks into the kitchen, swaps ingredients, and walks out.

Or worse - someone pretends to be a waiter and starts serving random food to customers.

That's what happens when your API isn't secured.

Let's break this down 👇

🪪 Identity Checks: Who Are You?

Before anyone touches an order - they need to identify themselves.

In backend terms, this is Authentication.

We do this using:

Access Tokens (JWTs) - Like an ID badge that proves the user is who they say they are.
API Keys - For third-party apps like the delivery service.
OAuth - When users log in via Google or GitHub.

🛡️ Just like a chef won't cook an order without a valid ticket, your backend shouldn't process any request without verifying the token.

💡 Tools like jsonwebtoken in Node.js validate JWT tokens. Frameworks like Express.js or Fastify offer middleware to intercept and verify them.

✅ Access Control: Can You Do That?

Great - they're inside. But can they actually update an order?

This is Authorization.

Think of:

Chefs who can update food status
Waiters who can place/cancel orders
Customers who can only see or track their own order

In the backend, this translates to Role-Based Access Control (RBAC) or Permission-based logic.

💡 Tools like casbin, custom role logic, or even simple conditionals (if (user.role !== 'admin') return 403) help manage who does what.

🧼 Input Validation: No Pineapple in Butter Chicken

Someone tries to order a "Drop All Tables Curry"? 😳

This is where input validation kicks in.

Before you forward an order to the kitchen (a.k.a your database), validate it:

Is it a real menu item?
Are the quantities valid?
Is the request format correct?

We use tools like:

zod, yup, joi – Schema validators to check request bodies
Built-in type systems (like TypeScript) for extra safety

const OrderSchema = z.object({
  item: z.string(),
  quantity: z.number().min(1),
});

💡 Always sanitize and validate inputs to avoid SQL injections, malformed data, or logic-breaking bugs.

🤝 Secure Responses: Don't Reveal the Secret Sauce

Imagine if your waiter yells: "Here's your Chicken Curry! By the way, the chef's password is '1234'!"

Just like requests, your responses must be clean and secure:

Don't leak internal server info (err.stack, .env values, etc.)
Strip sensitive fields like passwords, tokens, or internal IDs
Use HTTP status codes wisely (401, 403, 500) to give just enough feedback

💡 Use libraries like helmet for HTTP headers, or add custom middleware to sanitize responses.

🧾 2. Order Queue → Message Queues (RabbitMQ, SQS, Kafka)

Problem: Your kitchen can't handle 200 orders at once. You need order flow control.

Backend Equivalent:
Use a message broker (RabbitMQ, Kafka, Redis Streams, or AWS SQS) to queue jobs like:

Sending confirmation emails
Cooking order items
Notifying delivery agents

// Example: RabbitMQ Consumer
channel.consume("order_queue", async (msg) => {
  const order = JSON.parse(msg.content.toString());
  await processOrder(order);
  channel.ack(msg);
});

✅ Decouples tasks
✅ Handles burst traffic
✅ Supports retries & backpressure

🔗 Intro to Message Queues

📡 3. Bell in the Kitchen → Webhooks

Problem: Don't cook if the customer hasn't paid.

Backend Equivalent:
Set up webhooks to get notified by external services (e.g., Stripe, Razorpay):

// Incoming webhook payload
{
  "event": "payment.success",
  "order_id": "ORD-9982",
  "amount": 1599
}

✅ Event-driven
✅ Reduces polling
✅ Must handle idempotency and retries

🔗 Handling Stripe Webhooks

📆 4. Daily Inventory Check → Cron Jobs / Scheduled Tasks

Problem: Stock levels must be monitored every night.

Backend Equivalent:
Use cron jobs or serverless schedulers for:

Inventory reports
Auto-expire coupons
Syncing external APIs

Tools:

node-cron
bull / agenda
AWS EventBridge Scheduler

cron.schedule('0 2 * * *', checkInventory); // 2AM daily

⚖️ 5. Hiring More Chefs → Load Balancers & Horizontal Scaling

Problem: One chef isn't enough during rush hours.

Backend Equivalent:
Scale your backend horizontally. Spin up more instances behind a load balancer.

Common setups:

NGINX / HAProxy: Software load balancers
AWS ALB / GCP Load Balancing: Cloud-native
Sticky Sessions for session affinity

🔗 How Load Balancing Works

🔁 6. Failed Orders → Retry Logic + Backoff

Problem: Sometimes a payment fails due to a network glitch. Try again!

Backend Equivalent:
Add retry strategies with exponential backoff:

function retry(fn, attempts = 3, delay = 1000) {
  return fn().catch((err) => {
    if (attempts === 0) throw err;
    return wait(delay).then(() => retry(fn, attempts - 1, delay * 2));
  });
}

✅ Avoids spamming
✅ Handles flakiness

Use libraries like:

axios-retry
BullMQ retry strategies
AWS SDK Retry Config

🧠 7. Prepping Fries in Advance → Caching (Redis, CDN)

Problem: You don't need to check the database every time someone asks for the menu.

Backend Equivalent:
Cache data that doesn't change often:

Menus
Product listings
Session data
Auth tokens

Tools:

Redis for key-value store
CDNs (Cloudflare, Fastly) for static assets

await redis.set("menu", JSON.stringify(menuData), "EX", 3600); // TTL 1hr

🧯 8. No Free Refills → Rate Limiting / API Throttling

Problem: One customer is spamming 1000 orders/sec.

Backend Equivalent:
Add rate limiters per IP / token to control abuse.

Tools:

express-rate-limit
API Gateway throttling
Redis-based counters for speed

// Basic rate limit
limit: 100 requests per 15 minutes per user

🧩 9. Specialized Stations → Microservices

Problem: Dessert chefs shouldn't handle pizzas.

Backend Equivalent:
Split your monolith into bounded services:

orders-service
inventory-service
payments-service
notifications-service

Tech:

REST / gRPC for service-to-service
Use service mesh (Istio, Linkerd) as it grows
Consider event-driven architecture (Pub/Sub)

🧪 10. Today's Specials → Feature Flags

Problem: You want to test a new dish only for VIPs.

Backend Equivalent:
Use feature flags to control access dynamically:

Roll out new features to 10% of traffic
Enable beta access for internal users

Tools:

LaunchDarkly
Unleash
Custom flags table in DB

📊 11. CCTV & Logs → Observability, Logging, Monitoring

Problem: You need to know what failed, when, and why.

Backend Equivalent:
Log everything. Watch metrics. Set alerts.

📈 Tools:

Logs: Winston, Pino, Bunyan
Monitoring: Prometheus + Grafana, Datadog
Errors: Sentry, Rollbar
Tracing: OpenTelemetry, Jaeger

You should know:

Which API took 5 seconds
Why payments dropped at 4PM
How many orders failed in last 24h

🧠 Realization Time

Running a restaurant at scale isn't about CRUD. It's orchestration.
The same goes for your backend.

CRUD is a form.
A real backend is an operational system built for:

✅ Load
✅ Failure
✅ Consistency
✅ Monitoring
✅ Growth

🚀 TL;DR: What's Really Behind a Backend?

Restaurant Concept	Backend Implementation
Menu / Orders / Kitchen	Basic CRUD APIs
Queue Tickets	RabbitMQ / SQS / Kafka
Bell on Payment	Webhooks
Nightly Stock Check	Cron Jobs / Scheduled Tasks
Extra Chefs	Load Balancer + Auto-Scaling
Retry Order	Retry Logic with Backoff
Prepped Fries	Redis / CDN Caching
Spam Guard	Rate Limiting + Validation
Pizza/Dessert Counters	Microservices / Bounded Contexts
Specials Only for VIPs	Feature Flags
CCTV + Logs	Monitoring + Observability
Staff Only Zones	Auth + Role-based Access

🙌 Final Thought

A real backend isn't built for happy paths.
It's built for reality - where users fail, networks flake, traffic spikes, and money's on the line.

CRUD is the starting point.
Resilience is the real job.

🔐 Coming Up Next: Locking Down the Backend (Part 2 of the Series)

So far, we've built the kitchen. But what about keeping it safe?

In the next post, we'll explore how to truly secure your backend, covering topics like:

✅ Real-world JWT-based authentication (and avoiding the usual pitfalls)
🧪 Schema validation using Zod - making sure no weird inputs get through
✍️ Request signatures - validating external payloads before trusting them
🛡️ Common security threats (XSS, CSRF, etc.) and how to prevent them
🔑 Managing secrets, tokens, and environment variables the right way

Because backend development isn't just about scaling and queuing - it's also about trust, safety, and protecting what matters.

Stay tuned - your backend's security game is about to level up.

Docker Is Just Cup Noodles for Code 🍜🐳

Dhaval Agr'vat — Tue, 24 Jun 2025 15:38:06 +0000

By the time your noodles are ready, you'll know exactly what Docker does.

🥢 Real-Life Analogy: The Noodle Disaster

Let's say you made killer noodles at home.
Everyone raved about them.
You declared yourself a noodle ninja.
Later, a friend invites you to a party and says:
"Dude, make those noodles again!"
You agree. Same steps, same effort — but this time, it tastes awful.

What happened?

Their tomato sauce was too tangy
Their soy sauce was more sour
Their stove runs hotter
Even the water tastes different

That’s how software behaves in different environments.
The ingredients might seem the same, but the final result?
Chaos.

🧊 Enter Docker: Cup Noodles for Code

To solve this, you do what every genius chef would do — you invent cup noodles.
Pre-balanced ingredients, exact spices, precise measurements.
Just add hot water, and boom — it tastes perfect every time, no matter where it's made.

Docker is your cup noodles.
It packs:

Code
Libraries
Dependencies
Environment settings

…into one sealed container.
Just run it — anywhere — and it just works.

🧠 What Is Docker (Technically Speaking)

Docker is a tool that lets you package your app and all of its dependencies into a single unit called a container.

A container:

Runs the same on any machine
Has its own OS-level environment
Is fast to spin up and tear down
Doesn’t affect your system’s setup

Think of it like shipping your app with its own tiny operating system.
That container runs exactly the same anywhere:
✅ Your laptop
✅ A teammate’s system
✅ A production server
✅ A random server on Mars (as long as it supports Docker)

🧱 How Docker Works — The Basics

Let’s break down Docker’s core building blocks:

Dockerfile: A recipe that tells Docker how to build your app image
Image: A snapshot of your app and its entire environment
Container: A live, running version of the image
Docker Engine: The engine that builds and runs containers
Docker Hub: An online store for prebuilt images

Let’s make it practical.

🧾 Example: Dockerizing a Simple Node App

Here’s a basic Dockerfile for a Node.js app:

# Use Node 18 as base image
FROM node:18-alpine

# Set working directory
WORKDIR /usr/src/app

# Copy dependency files first
COPY package*.json ./

# Install dependencies
RUN npm install

# Copy the rest of the app
COPY . .

# Expose the port the app runs on
EXPOSE 3000

# Command to run the app
CMD ["npm", "start"]

This file tells Docker:

What base environment to use (node:18-alpine)
Where your code lives
What packages to install
How to run the app

🔨 Building & Running It

Step 1: Build the image

docker build -t my-node-app .

This creates a Docker image named my-node-app.

Step 2: Run the container

docker run -p 3000:3000 my-node-app

You can now open http://localhost:3000 and your app is running inside the container.
You didn’t install anything outside. It just works.

🧠 Why Use Docker?

💥 Without Docker

"Works on my laptop" issues
Manual dev setup per machine
Different configs per environment
Complex deployments

🧊 With Docker

Consistent everywhere
Instant onboarding
Same behavior across all setups
Simple, reproducible deployments

It’s like upgrading from “winging it” to “systematically correct every time.”

🧰 Bonus Tool: Docker Compose

When your app needs more than one service (say, backend + database), Docker Compose helps you manage them all.

version: '3.8'
services:
  app:
    build: .
    ports:
      - "3000:3000"
  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_PASSWORD: secret

You can spin up both the app and the DB using:

docker-compose up

Everything comes up. Together. Instantly.

⚠️ Common Pitfalls (and Fixes)

❌ Copying node_modules into the image?
✅ Use .dockerignore to exclude it.
❌ Running as root in the container?
✅ Create a non-root user.
❌ Bloated images?
✅ Use multi-stage builds to slim it down.
❌ No health checks?
✅ Use HEALTHCHECK to monitor app status.
❌ Forgetting image tags?
✅ Use versioned tags like my-app:1.0.2

💡 Why Smart Devs Love Docker

Here’s how experienced developers use Docker to save time, avoid pain, and move faster:

💡 Scenario 1: Redis + PostgreSQL Setup

“We’ll need Redis and PostgreSQL for local testing. Here’s the DB dump.”

Normal dev: Spends 3 hours googling “why is PostgreSQL yelling at me?” while Redis just laughs in binary. 😭

Smart dev:

docker run -d --name redis -p 6379:6379 redis
docker run -d --name postgres -p 5432:5432 -e POSTGRES_PASSWORD=secret postgres

🔥 Both databases are live in minutes.

💡 Scenario 2: Risk-Free DB Migrations

“Here’s a staging DB dump. Test the schema migration before pushing to prod.”

Normal dev: Sweats buckets, accidentally nukes their local DB, cries in the group chat. 😰

Smart dev:

docker run -v $(pwd)/dump.sql:/dump.sql -e POSTGRES_PASSWORD=secret postgres

If something goes wrong? Just delete the container and start fresh.

💡 Scenario 3: Mocking Backend APIs

Frontend dev stuck waiting for the backend team to finish APIs? Not today.

docker run -p 4010:4010 stoplight/prism mock https://api.example.com/openapi.yaml

🔥 Mock server ready instantly.

💡 Scenario 4: Testing Across Versions

Normal dev: Fumbles with multiple Node installs, breaks their system, and questions life choices. 😖

Smart dev:

docker run -v $(pwd):/app -w /app node:14 node app.js
docker run -v $(pwd):/app -w /app node:16 node app.js
docker run -v $(pwd):/app -w /app node:18 node app.js

Test against all three — no installs needed.

💡 Scenario 5: Fullstack Local Testing with Multiple Services

“The app needs backend + DB + Redis to even load.”

Normal dev: Starts one manually, forgets Redis, API fails silently, blames laptop. 🧟‍♂️

Smart dev:

# docker-compose.yml
version: '3.8'
services:
  app:
    build: .
    ports:
      - "3000:3000"
  db:
    image: postgres
    environment:
      POSTGRES_PASSWORD: dev
  redis:
    image: redis

docker-compose up

🚀 Full stack, up and running in one command — same in dev, test, and CI.

🚀 Going Production-Ready

Docker isn’t just a toy — it powers serious infrastructure.

Here’s how to level it up:

✅ Push images to Docker Hub or a private registry
🔐 Don’t store secrets in images — use external vaults
🚢 Use CI/CD to auto-build and deploy containers
⚙️ Orchestrate with Kubernetes (when you scale)
🧪 Scan images for vulnerabilities (Trivy, Snyk)
📈 Monitor containers using Grafana + Prometheus

🧘 Final Thoughts

Docker isn’t just a trendy tool — it’s a shift in how we build, ship, and run software.
Whether you’re managing a complex microservices architecture or just trying to share your weekend project with a friend, Docker gives you predictability, portability, and peace of mind.

It removes the chaos of environment mismatches, simplifies local development, and ensures your app behaves the same on every machine — whether it’s your laptop or a production server halfway across the world.

Much like cup noodles, Docker delivers consistency without the mess — just add the right commands and everything runs exactly the way it should.

If you’ve ever uttered, “It worked on my machine,” Docker is your opportunity to never say that again.

So next time you start a new project, debug a weird setup, or onboard a teammate, think of Docker as your shortcut to sanity — fast, clean, and always reliable.

✨ TL;DR

Docker is your cup noodles of software engineering:

Just add the right commands (instead of hot water)
Get the same result every time
Works anywhere without messing up your kitchen (laptop)

Whether you’re working solo or shipping production apps — Docker brings peace, portability, and far fewer “what went wrong” moments.