DEV Community: Ashitosh Lavhate

I Finally Understood Why Database Indexes Make Queries Faster

Ashitosh Lavhate — Sun, 23 Aug 2026 05:09:39 +0000

I used to think adding an index to a database was basically a magic “make this query faster” button.

Then I understood what was actually happening underneath.

Imagine a users table with 1 million records.

If we run:

SELECT * FROM users
WHERE email = 'ash@example.com';

Without an index, the database may have to check rows one by one until it finds the match.

That's basically:

“Let me search through everything.” 😭

Now add an index:

CREATE INDEX idx_users_email
ON users(email);

The database can use a specialized data structure to locate the matching value much more efficiently.

It's similar to the difference between:

📚 Searching every page of a book
vs.
🔖 Using the index at the back of the book

But here's the part I didn't realize:

Indexes aren't free.

Every index takes storage, and when you INSERT, UPDATE, or DELETE data, the database may also need to update the indexes.

So blindly adding indexes isn't the solution.

A better approach is:

Find queries that are actually slow.
Check how the database executes them.
Add indexes to columns frequently used for filtering, joining, or sorting.
Measure the improvement.
Remove indexes that aren't providing value.

For example, if your application constantly does:

SELECT * FROM users
WHERE email = ?;

then indexing email makes a lot of sense.

But creating indexes on every column?

Probably not.

The lesson I took away

Database performance isn't just about writing faster SQL.

It's about understanding how the database finds your data.

And honestly, learning this changed the way I think about backend development.

Don't optimize blindly. Understand what the database is doing first.

You Press Enter After Typing a URL. Here's Everything That Happens Next.

Ashitosh Lavhate — Sat, 22 Aug 2026 05:40:43 +0000

You type:

https://example.com

Press Enter.

A few milliseconds later, the website appears.

Simple, right?

Not really. 😄

Behind that single Enter key is a chain of networking, security, server-side processing, and browser rendering.

Here's what actually happens.

1. The Browser Checks: "Do I Already Know This?"

Before asking the internet anything, your browser checks whether it already has useful information cached.

It may check:

Browser cache
Operating system DNS cache
Router cache

If the IP address is already available, it can skip a DNS lookup.

If not, it's time to ask DNS.

2. DNS Turns the Domain Into an IP Address

Humans use names like:

example.com

Computers need an IP address.

DNS acts like the internet's phonebook:

example.com → 93.184.216.34

Your request may involve multiple DNS servers before the correct IP address is found.

Now the browser knows where to send the request.

3. A Connection Is Established

For most HTTPS websites, the browser needs to establish a connection with the server.

Traditionally, this begins with TCP's famous three-way handshake:

Browser → SYN → Server
Browser ← SYN-ACK ← Server
Browser → ACK → Server

Now both sides are ready to communicate reliably.

4. HTTPS Adds a Security Layer

Because we're visiting:

https://example.com

the browser also needs to establish an encrypted connection.

This involves a TLS handshake.

During this process, the browser verifies the server's certificate and both sides establish encryption keys.

After this, the data exchanged between your browser and the server is encrypted.

That's why HTTPS matters.

5. The Browser Sends the HTTP Request

Now the browser can finally ask for the page.

Something conceptually like this:

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html

That request travels across the internet to the server.

6. The Server Starts Doing Its Job

What happens next depends on the application.

The request might go through:

Load Balancer
      ↓
Web Server
      ↓
Backend Application
      ↓
Database / Cache / External Services

For example, in a NestJS application:

Request
  ↓
Middleware
  ↓
Guard
  ↓
Controller
  ↓
Service
  ↓
Database
  ↓
Response

The server processes the request and sends something back.

7. The Browser Receives HTML

Imagine the server returns:

<html>
  <head>
    <link rel="stylesheet" href="/styles.css">
  </head>
  <body>
    <h1>Hello World</h1>
    <script src="/app.js"></script>
  </body>
</html>

The browser doesn't just instantly display this.

It starts parsing it.

8. HTML Becomes the DOM

The browser converts HTML into the DOM (Document Object Model).

Conceptually:

HTML
 ↓
Parser
 ↓
DOM Tree

At the same time, it discovers other resources.

For example:

styles.css
app.js
images
fonts

And begins fetching them.

9. CSS Builds the CSSOM

CSS is also parsed into a structure called the:

CSS Object Model (CSSOM)

So now the browser has:

DOM + CSSOM

These are combined to determine what should actually appear on the screen.

10. The Browser Creates the Page You See

The browser goes through several rendering steps:

DOM + CSSOM
        ↓
    Render Tree
        ↓
      Layout
        ↓
      Paint
        ↓
    Compositing
        ↓
   🎉 Website appears

Layout

The browser calculates:

Where should every element go?

Paint

It draws:

Text, colors, borders, shadows, images...

Compositing

Different layers are combined and displayed on your screen.

And finally...

You see the website.

The Crazy Part?

All of this happens after you press one key:

Enter

Your browser may perform DNS resolution, establish secure connections, send requests, receive responses, download resources, execute JavaScript, calculate layouts, and render pixels...

Often in less than a second.

The next time a website takes "just a few seconds" to load, remember:

A lot has to happen before even one pixel appears on your screen.

The Full Journey

Type URL
   ↓
Check Cache
   ↓
DNS Lookup
   ↓
Connect to Server
   ↓
TLS Handshake
   ↓
HTTP Request
   ↓
Server Processing
   ↓
HTTP Response
   ↓
Parse HTML → DOM
   ↓
Parse CSS → CSSOM
   ↓
Fetch JS / Images / Fonts
   ↓
Render Tree
   ↓
Layout
   ↓
Paint
   ↓
Compositing
   ↓
Website 🎉

Understanding this flow changed the way I think about web development.

A frontend isn't just "sending an API request."

A backend isn't just "returning JSON."

And a browser isn't just "showing a page."

They're all part of one incredibly coordinated system.

The web feels simple because an absurd amount of complexity is hidden behind one URL.

💬 What part of this journey do you find the most interesting: DNS, HTTPS, backend processing, or browser rendering?

Why Does Go Have Goroutines? Understanding Go’s Lightweight Concurrency

Ashitosh Lavhate — Sat, 15 Aug 2026 15:46:42 +0000

When I started exploring Go, one feature immediately stood out:

go doSomething()

Just adding go before a function call can run it concurrently.

That got me thinking: what exactly is a goroutine, and why does Go need it?

So, I decided to learn the basics. Here's what I found. 👇

First, what is concurrency?

Imagine you have multiple tasks:

Fetching data from an API
Processing a file
Handling user requests
Writing data to a database

If your program handles them one after another, one task may spend a lot of time waiting while everything else is blocked.

Concurrency allows a program to make progress on multiple tasks during overlapping periods of time.

This is especially useful when programs need to handle lots of work efficiently.

What is a goroutine?

A goroutine is a function that runs concurrently with other goroutines.

Creating one is surprisingly simple:

package main

import "fmt"

func sayHello() {
    fmt.Println("Hello from a goroutine!")
}

func main() {
    go sayHello()

    fmt.Println("Hello from main!")
}

The only difference is this:

go sayHello()

The go keyword tells Go to start sayHello() as a goroutine.

But there's a problem 👀

If you run the previous example, you might not always see:

Hello from a goroutine!

Why?

Because once main() finishes, the program exits.

The goroutine may not get enough time to complete.

A simple way to wait for goroutines is using sync.WaitGroup.

package main

import (
    "fmt"
    "sync"
)

func main() {
    var wg sync.WaitGroup

    wg.Add(2)

    go func() {
        defer wg.Done()
        fmt.Println("Task 1 completed")
    }()

    go func() {
        defer wg.Done()
        fmt.Println("Task 2 completed")
    }()

    wg.Wait()

    fmt.Println("All tasks completed")
}

Here:

wg.Add(2) tells the WaitGroup to wait for 2 tasks.
go starts each function as a goroutine.
defer wg.Done() signals that a task has finished.
wg.Wait() prevents main() from exiting until both tasks are complete.

Why not just create multiple threads?

This is where Go becomes particularly interesting.

Goroutines are not simply traditional OS threads.

They are lightweight units of concurrent execution managed by the Go runtime. The runtime schedules goroutines onto OS threads, which means you can work with large numbers of goroutines without manually creating and managing a thread for every task.

That's one of the reasons Go is popular for systems and services that need to handle many concurrent operations.

Concurrency vs Parallelism

One thing I also learned while reading about goroutines:

Concurrency and parallelism are not exactly the same thing.

Concurrency: Structuring a program so multiple tasks can make progress independently.
Parallelism: Actually executing multiple tasks at the same time using multiple processing resources.

A program can be concurrent without every task literally running at the exact same instant.

The bigger picture

Goroutines become even more powerful when combined with channels, which allow goroutines to communicate and synchronize.

So the Go concurrency model is not just:

"Run everything at the same time."

It's about making concurrent programs easier to structure using tools built directly into the language and its runtime.

What I learned today

My biggest takeaway was this:

Goroutines make concurrency feel simple, but Go's runtime is doing a lot of work behind the scenes to manage them efficiently.

What starts with:

go doSomething()

opens the door to learning about scheduling, synchronization, channels, race conditions, parallelism, and scalable systems.

I'm still learning Go, but this was a really interesting first step into understanding how it handles concurrency. 🚀

What Go concept should I explore next: Channels, Interfaces, defer, or something else?

Your Database Is Probably Doing More Work Than It Needs To 🗄️⚡

Ashitosh Lavhate — Wed, 12 Aug 2026 17:13:51 +0000

When an application becomes slow, developers often look at the frontend first.

Maybe the React component is rendering too many times.

Maybe the API is slow.

Maybe the server needs more CPU.

But sometimes the real problem is much simpler:

Your database is doing way more work than necessary.

And the scary part?

Your application can work perfectly while still making terrible database queries.

Here are some common mistakes I've started paying much more attention to.

1. Stop Using `SELECT *` Everywhere

This is probably one of the easiest things to overlook.

Instead of:

SELECT * FROM users;

ask for only what you actually need:

SELECT id, name, email FROM users;

Why?

Imagine your users table contains:

profile images
addresses
preferences
metadata
timestamps
large JSON fields

If you only need the user's name and email, fetching everything is unnecessary work.

Simple rule:

Fetch what you need, not everything available.

2. Indexes Can Change Everything

Imagine you have a table containing millions of users.

You frequently search by email:

SELECT * FROM users
WHERE email = 'user@example.com';

Without an appropriate index, the database may need to inspect a huge number of rows.

An index can make this dramatically more efficient:

CREATE INDEX idx_users_email
ON users(email);

But there's an important catch.

Don't index every column.

Indexes also consume storage and add overhead when rows are inserted or updated.

Index columns that you frequently:

search
filter
sort
join

And verify your assumptions with query plans.

For example:

EXPLAIN SELECT *
FROM users
WHERE email = 'user@example.com';

3. Beware of the N+1 Query Problem

This one can quietly destroy performance.

Imagine you fetch 100 posts:

Get 100 posts

Then your application separately asks the database for the author of each post:

Get author 1
Get author 2
Get author 3
...
Get author 100

Now you've potentially made:

101 database queries.

Instead of doing that, use a proper join or ORM relation loading strategy.

For example:

SELECT posts.title, users.name
FROM posts
JOIN users
ON posts.user_id = users.id;

One query can often replace dozens or hundreds of database calls.

4. Don't Query the Same Data Repeatedly

Sometimes the database isn't slow.

We're just asking it the same question again and again.

For example:

Request → Database
Request → Database
Request → Database
Request → Database

If the data doesn't change frequently, caching can help.

A simplified architecture might look like:

Client
   ↓
API
   ↓
Cache
   ↓
Database

The application checks the cache first.

If the data exists there, the database doesn't need to do the work again.

Tools such as Redis are commonly used for this kind of caching.

But remember:

Caching is not a replacement for fixing bad queries.

5. Pagination Is Not Optional at Scale

Imagine your API returns every user:

SELECT * FROM users;

That might work when you have 100 users.

What happens when you have:

10 million users?

Your database has to retrieve a massive amount of data, and your server then has to process and send it.

Instead, paginate:

SELECT id, name, email
FROM users
LIMIT 20 OFFSET 0;

Then:

Page 1 → 20 records
Page 2 → 20 records
Page 3 → 20 records

For very large datasets, cursor-based pagination can be more efficient than large offsets.

6. Don't Optimize Blindly

One of the biggest lessons in performance optimization:

Don't guess. Measure.

Before changing your query, find out what the database is actually doing.

Use tools such as:

EXPLAIN

or:

EXPLAIN ANALYZE

Depending on your database.

Look for things like:

Full table scans
Missing indexes
Expensive joins
Sorting large datasets
Excessive rows being examined
Slow execution time

Optimization becomes much easier when you can see the actual problem.

A Simple Performance Checklist 🚀

Before blaming your backend for a slow application, ask:

[ ] Am I fetching unnecessary columns?
[ ] Do frequently searched columns have appropriate indexes?
[ ] Am I accidentally creating N+1 queries?
[ ] Am I making the same query repeatedly?
[ ] Am I returning too many records?
[ ] Do I need pagination?
[ ] Have I checked the query execution plan?
[ ] Am I optimizing based on measurements rather than assumptions?

The Bigger Lesson

Database performance isn't always about buying a bigger server.

Sometimes the biggest improvement comes from simply asking the database to do less work.

A query that takes 2 seconds might become 200ms.

A query that runs 100 times might become one query.

A response containing 50 unnecessary fields might become 5 useful ones.

That's why database optimization often starts with a surprisingly simple question:

“Does the database really need to do all of this?”

Before adding more infrastructure, check the query.

You might already have enough power.

You just might be using it inefficiently. ⚡

What database optimization trick has saved you the most performance?

I'd love to hear what you've encountered in your own projects. 👇

⚡ Stop Writing Code Immediately — Plan First, Code Faster

Ashitosh Lavhate — Tue, 11 Aug 2026 13:42:53 +0000

One of the biggest mistakes I made as a developer was thinking that good developers code faster.

They don't necessarily code faster.

They spend less time coding the wrong thing.

When I first started building projects, my approach was pretty simple:

Open VS Code → Start coding → Get stuck → Search Google → Change things → Break something else → Rewrite it 😭

And honestly, this works... until your projects become bigger.

That's when I realized something important:

Before writing code, I should spend some time understanding what I'm actually building.

🧠 Step 1: Understand the Problem

Before touching the keyboard, ask:

What exactly am I trying to build?
Who is going to use it?
What should happen when the user performs an action?
What data do I need?
What should the final result look like?

It sounds obvious.

But skipping this step can lead to writing a lot of code for the wrong problem.

🧩 Step 2: Break It Into Smaller Problems

Instead of thinking:

"I need to build a messaging system."

Break it down:

Messaging System
│
├── Authentication
├── Conversations
├── Sending Messages
├── Receiving Messages
├── Message Storage
├── File Uploads
├── Notifications
└── Error Handling

Suddenly, the huge problem becomes a collection of smaller problems.

And smaller problems are much easier to solve.

⚠️ Step 3: Think About Edge Cases

Don't only think about the happy path.

For example:

User sends message
        ↓
      Works ✅

That's great.

But what if:

No internet connection?
Empty message?
Server error?
User logged out?
Database unavailable?
Message too large?

Thinking about these cases before coding can save you from a lot of debugging later.

🛠️ Step 4: Choose the Simplest Solution

Developers love building complicated things.

Sometimes unnecessarily complicated things. 😂

Before implementing something, ask:

"Is there a simpler way to solve this?"

You don't always need:

another library
another abstraction
another database
another design pattern
500 lines of code

Sometimes the simplest solution is the best solution.

💻 Step 5: Then Start Coding

Now open VS Code.

At this point, you aren't blindly writing code.

You already know:

What → Why → How → Edge cases

So the coding process becomes much more focused.

Instead of:

Code → Problem → Rewrite → Problem → Rewrite

you move closer to:

Understand
    ↓
Plan
    ↓
Build
    ↓
Test
    ↓
Improve

🚀 The Biggest Lesson

Planning doesn't mean spending hours designing everything before writing a single line of code.

Sometimes 5–10 minutes of thinking can save an hour of coding.

The goal isn't to predict every possible problem.

The goal is to reduce uncertainty before you start.

Because being a good developer isn't just about knowing how to write code.

It's also about knowing:

What code actually needs to be written.

💭 What about you?

Do you usually:

A) Start coding immediately and figure things out along the way?

B) Plan everything first and then start coding?

I'm somewhere in between — and I'm slowly learning that a little planning saves a LOT of debugging. 😭

थाळी — An Interactive Thali, Built Entirely in CSS

Ashitosh Lavhate — Mon, 10 Aug 2026 22:14:14 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.

Inspiration

I'm Maharashtrian, and in our homes food never really arrives one dish at a time, it arrives as a थाळी. A steel plate, rice in the center, a ring of vaatis around it holding varan, bhaji, koshimbir, amti, a curl of lonche on the side, and always something to drink alongside — a glass of taak or lassi. That's what "comfort food" has always meant to me. Not one hero ingredient on a plate, but the whole spread landing in front of you at once, still steaming.

So when this challenge said "comfort food," I didn't want to draw one bowl of something. I wanted to draw the entire thali — the way it actually lands on the table at home — and build it purely out of CSS.

Demo

Hover over any dish for a quick description of what's in it, and try dragging one item onto another — they'll swap places on the plate.

Journey

Every piece of this — the brushed-gold steel plate, the katoris, the rice mound, the naan on its banana leaf, the lassi tumbler — is built from gradients, box-shadows, and clip-paths. No images anywhere. A few techniques I leaned on a lot:

Layered conic-gradient + radial-gradient for the brushed metal look of the plate and steel bowls
Stacked box-shadow values as a cheap way to scatter garnish — cilantro flecks, chili flakes, pistachio bits — without extra markup
clip-path for the tapered lassi tumbler and its ridged, fluted sides
Irregular border-radius values (different on every corner) so the rice mound and naan feel hand-shaped instead of like perfect circles

The one feature that pushed past "pure CSS" was letting people drag a dish and drop it on another to swap their places, with a smooth spring-like transition. The contest rules allow a light sprinkle of JS for CSS Art as long as the visuals stay CSS-driven, so I used Pointer Events just to track drag position and swap two items' coordinates — nothing about how the dishes actually look comes from JS.

The best bug of the whole build: after wiring up hover tooltips and drag, nothing responded — no hover cards, no dragging. Turned out a decorative etched-rim pattern on the plate, built as a ::after pseudo-element and masked down to a thin ring, was still sitting on top of everything in paint order. CSS mask makes pixels transparent, but it doesn't stop an element from intercepting clicks — so an "invisible" ring was quietly blocking every dish underneath it. One pointer-events: none later, everything came alive.

This one felt personal to build. Thanks for putting this challenge together! 🍛

The Bug Wasn't in My Code --- It Was in My Assumptions 🤯

Ashitosh Lavhate — Mon, 10 Aug 2026 21:10:10 +0000

We've all been there.

The code looks correct.

No obvious syntax errors.
The logic seems fine.
You read the same function 10 times.

And somehow...

It still doesn't work. 😭

After wasting way too much time debugging situations like this, I
realized something:

Sometimes the bug isn't in your code. It's in what you assumed about
your code.

The classic debugging trap

Imagine you're calling an API and expecting this:

{
  "user": {
    "name": "Ash"
  }
}

So naturally, you write:

const name = response.user.name;

Everything looks perfectly reasonable.

But the actual response is:

{
  "data": {
    "user": {
      "name": "Ash"
    }
  }
}

Now you're staring at your JavaScript wondering:

"Why is user undefined?!"

The JavaScript isn't necessarily the problem.

Your assumption about the API response was.

This happens everywhere

It's not just API responses.

You can make incorrect assumptions about:

What data a function receives
Whether a value can be null
What an API actually returns
Environment variables being available
File paths
Database records
Authentication state
Time zones
User input
Production vs development environments
What a third-party library actually does

And these assumptions can create some seriously confusing bugs.

My new debugging approach

Instead of immediately changing the code, I try to verify my assumptions
first.

1. What do I think is happening?

Write down your assumption.

For example:

"The API is returning the user object."

2. What is actually happening?

Inspect the data.

console.log(response);

Don't guess.

Look at it.

3. Where does reality differ from my assumption?

Maybe the API response changed.

Maybe the value is undefined.

Maybe the environment variable isn't loaded.

Maybe the backend is returning an error that the frontend isn't
handling.

4. Fix the actual problem

Only after understanding the mismatch should you change the code.

This saves a surprising amount of time.

The debugging rule I now follow

When something doesn't make sense, I ask:

"What am I assuming right now that I haven't verified?"

That question is surprisingly powerful.

Because debugging isn't always about finding the broken line.

Sometimes it's about finding the wrong mental model.

A simple debugging checklist

Next time you're stuck, check:

☐ What input am I actually receiving?
☐ What output am I actually getting?
☐ Did I verify the API response?
☐ Could this value be undefined/null?
☐ Are my environment variables loaded?
☐ Am I testing the same environment as production?
☐ Did the data structure change?
☐ Am I assuming something instead of checking it?

Final takeaway

Good debugging isn't just:

"Find the broken code."

It's:

"Find the difference between what I expected and what is actually
happening."

Once you start debugging your assumptions, some of those
"impossible" bugs become surprisingly easy to solve.

And honestly...

Sometimes the most useful debugging tool isn't another console.log.

It's asking:

"Wait... how do I know that's actually true?" 👀

What about you?

What's a bug that took you way too long to fix because you were making
the wrong assumption?

Drop it in the comments 👇

Before You Add Another npm Package, Ask Yourself These 5 Questions

Ashitosh Lavhate — Sun, 09 Aug 2026 04:18:35 +0000

Installing an npm package takes a few seconds.

npm install some-package

And that's exactly why it's so easy to overuse them.

Need a date formatter? Install one.

Need a UUID? Install one.

Need to validate an email? Install one.

Need to check if an array contains something? 😭

There's probably a package for that too.

But every dependency you add becomes part of your project.

So before running npm install, I started asking myself five questions.

1. Do I actually need a package?

This is the first question.

Sometimes the functionality you need is already available in JavaScript.

For example, you don't need a package just to remove duplicates from an array:

const unique = [...new Set(numbers)];

Or to check whether an array contains a value:

numbers.includes(10);

The point isn't:

"Never use packages."

The point is:

Don't add a dependency just because it saves you three lines of code.

If a package solves a genuinely complex problem, absolutely use it.

2. Is the package actively maintained?

Before installing something, check its repository.

Look at:

Last release
Open issues
Pull requests
Recent commits
Number of maintainers
Documentation
Compatibility with your version of Node.js

A package with millions of downloads isn't automatically a good package.

What matters is whether the project is healthy enough for your use case.

3. How many dependencies does it bring with it?

You install one package:

npm install package-a

But that package might depend on dozens of other packages.

Your dependency tree can quickly become:

your-app
 └── package-a
      ├── package-b
      │    ├── package-c
      │    └── package-d
      ├── package-e
      └── package-f

You're not only trusting package-a.

You're also trusting the ecosystem underneath it.

You can inspect your dependency tree with:

npm ls

4. What does this dependency cost my project?

"Cost" doesn't only mean money.

A dependency can cost you:

Bundle size — especially important for frontend applications.
Performance — some libraries do far more work than you actually need.
Security — every dependency is another piece of third-party code.
Maintenance — packages can become deprecated or abandoned.
Complexity — a tiny utility shouldn't require an entire library.

Instead of asking:

"Does this package work?"

Ask:

"Is this package worth having in my project?"

5. Can I remove it later?

This is probably the question developers ask the least.

Imagine your project has 80 dependencies.

Then one day you realize that five of them are only being used for tiny utility functions.

Removing them can become surprisingly difficult because you have to figure out:

Where they're used
Whether they're used indirectly
What breaks after removal
Whether another package depends on them
Whether the replacement changes behavior

A dependency is easiest to remove when you never needed it in the first place.

A Simple Rule I Follow

Before installing a package, I try this:

Can JavaScript already do this?
        ↓
      YES → Use native JavaScript
        ↓
       NO
        ↓
Is the problem complex enough to justify a dependency?
        ↓
      YES
        ↓
Is the package maintained and trustworthy?
        ↓
      YES
        ↓
Check size + dependencies + license
        ↓
      Install

This doesn't mean you should reinvent everything.

If you're building authentication, payments, database access, validation, image processing, or other complex functionality, established libraries can save enormous amounts of time.

The goal is simply to make dependencies intentional.

The `npm install` Reflex

One thing I've noticed while building projects is how easy it is to develop an npm install reflex.

You encounter a problem.

You search Google.

You find a package.

You install it.

Problem solved.

But sometimes the better engineering decision is to stop for 30 seconds and ask:

"Do I really want this dependency in my project?"

That 30-second decision can save you hours of maintenance later.

Final Thought

Dependencies are not bad.

Unnecessary dependencies are.

Use packages when they provide real value.

But don't turn every small problem into another entry in package.json.

Your future self — the one debugging the project six months from now — will probably thank you. 😭

What's one npm package you can't live without?

Drop it in the comments. I'm curious what everyone is using. 👇

I Deployed My Backend to Render… and Then Everything Broke 💀

Ashitosh Lavhate — Sat, 08 Aug 2026 03:02:28 +0000

I Deployed My Django App to Render… and Then Everything Broke 💀

Deploying an application sounds simple.

Push the code.

Configure the service.

Deploy it.

Done.

Yeah… not exactly. 💀

I recently deployed one of my Django applications to Render, and the deployment itself looked successful.

The service was live.

Gunicorn started.

Render gave me a live URL.

But when I actually opened the application and started making requests…

500 Internal Server Errors.

And that's where the real debugging started.

🚀 Deploying the Application to Render

My application had a frontend and a Django backend.

The basic flow looked like this:

User
  ↓
Frontend
  ↓
Django Backend
  ↓
Database

Everything was working correctly on my local machine.

So I connected the repository to Render and configured the deployment.

The build completed successfully, and the server started with Gunicorn.

Render even showed the service as live.

At this point, I thought:

"Okay, we're done."

I was very wrong. 😭

💥 The Actual Problem Started After Deployment

Once the application was live, I started seeing requests returning:

500 Internal Server Error

There were also other requests returning 400 errors.

The important part was that the deployment itself wasn't necessarily failing.

The application was running, but the application was failing when handling requests.

That distinction was important.

Instead of immediately changing random code, I went back to the Render logs.

🔍 The Render Logs Were the First Place I Looked

The logs showed that Gunicorn was starting successfully:

Gunicorn starting
Listening for requests

So the server process itself was alive.

But then requests started showing errors like:

GET ... 500
GET ... 500
GET ... 400

This made me realize something:

A deployment being marked as "Live" doesn't mean every part of the application is working correctly.

The next step was to find out why the requests were failing.

📁 Then I Found a Frontend Build Problem

One of the warnings in the logs was:

No directory at: /opt/render/project/src/frontend/dist/

This immediately caught my attention.

My project did have a frontend directory in the repository.

So I initially thought:

"But the folder exists. Why is Render saying it doesn't?"

And that's where deployment environments become interesting.

Having the source directory in your repository doesn't necessarily mean the production build output exists at the exact path your backend expects.

The backend was expecting:

frontend/dist/

But that directory wasn't available in the deployed environment at runtime.

So I had to look at the actual build process.

🧩 Source Code vs Build Output

This was an important distinction for me.

Having:

frontend/

in your repository is one thing.The application was running, but the application was failing when handling requests.

Having:

frontend/dist/

after the production build is another.

For example:

Project
├── frontend/
│   ├── src/
│   ├── package.json
│   └── ...
│
└── backend/
    ├── manage.py
    └── ...

doesn't automatically mean:

frontend/dist/

will exist.

The build process has to actually generate it.

That means your deployment configuration needs to make sure the frontend build happens before Django tries to serve those files.

⚙️ The Build Command Matters

This made me look much more carefully at the Render build command.

A deployment isn't simply:

git push → Render → done

There can be multiple steps:

Install dependencies
        ↓
Build frontend
        ↓
Collect/build backend assets
        ↓
Start application

If one of those steps is missing, the application can start successfully but still fail later.

That's exactly the kind of problem that is easy to miss when everything works locally.

🔐 Environment Variables Were Another Important Part

Production also has a completely different environment from my local machine.

Locally, Django might be using values from my .env file.

On Render, those values need to be configured as environment variables in the service.

Things such as:

SECRET_KEY=...
DATABASE_URL=...
ALLOWED_HOSTS=...

need to be correctly configured for production.

For example, Django needs to know which hosts are allowed to access the application.

So configuration is just as important as the code itself.

🧠 The "Works on My Machine" Problem

This deployment taught me why developers joke about:

"But it works on my machine." 😂

Because technically, it did.

My local environment had:

The dependencies
The environment variables
The generated files
The local database configuration
The expected directory structure

Production was different.

The server had to build the application from scratch and use only what I explicitly configured.

So a better mental model is:

LOCAL

Code
 ↓
Dependencies
 ↓
Environment
 ↓
Application


PRODUCTION

Repository
 ↓
Build commands
 ↓
Environment variables
 ↓
Generated files
 ↓
Server
 ↓
Actual requests

Every step can introduce a new failure.

🛠️ How I Started Debugging It

Instead of randomly changing things, I started checking the deployment layer by layer.

1. Check whether the service starts

If Gunicorn isn't starting, the problem is with the application startup.

2. Check the Render build logs

Look for failed commands, missing packages, or missing build output.

3. Check the runtime logs

A service can start successfully while requests still return 500.

4. Check generated files

If Django expects:

frontend/dist/

make sure the deployment actually creates it.

5. Check environment variables

Make sure production variables are present and correct.

6. Check Django configuration

Things like:

ALLOWED_HOSTS
DATABASE_URL
SECRET_KEY

need to work in production.

7. Test the backend directly

Don't only look at the frontend.

Test the API itself and identify exactly which request is failing.

💡 The Biggest Lesson

The biggest lesson I got from this wasn't:

"How to deploy Django to Render."

It was:

Deployment is another environment that your application has to work in.

Your local machine can hide a lot of assumptions.

Production exposes them.

A missing environment variable.

A wrong file path.

A frontend that wasn't built.

A database configuration that doesn't exist.

A host that isn't allowed.

All of these can turn:

Works perfectly locally

into:

500 Internal Server Error 💀

🚀 What I Would Do Differently Next Time

Before deploying another application, I would check these things first:

☑ Build command
☑ Start command
☑ Environment variables
☑ Database configuration
☑ Generated frontend files
☑ Static files
☑ Allowed hosts
☑ Production logs
☑ API endpoints

Most importantly:

I won't consider a deployment finished just because the service says "Live".

I'll actually test the application.

👨‍💻 Final Thought

One of the best ways to learn development is to actually deploy the things you build.

Because locally, everything can look perfect.

Then production comes along and says:

"Let's see about that." 💀

And suddenly you're reading logs, checking environment variables, tracing file paths, and learning things you never had to think about before.

But that's exactly where the learning happens.

Build → Deploy → Break → Debug → Learn → Repeat.

And honestly?

I'm starting to think the broken deployments teach me more than the successful ones. 🚀

Have you ever had an application that worked perfectly locally but broke immediately after deployment?

What was the problem?

Drop it in the comments — I want to know I'm not the only one. 😂

DEV Community: Ashitosh Lavhate

I Finally Understood Why Database Indexes Make Queries Faster

The lesson I took away

You Press Enter After Typing a URL. Here's Everything That Happens Next.

1. The Browser Checks: "Do I Already Know This?"

2. DNS Turns the Domain Into an IP Address

3. A Connection Is Established

4. HTTPS Adds a Security Layer

5. The Browser Sends the HTTP Request

6. The Server Starts Doing Its Job

7. The Browser Receives HTML

8. HTML Becomes the DOM

9. CSS Builds the CSSOM

10. The Browser Creates the Page You See

Layout

Paint

Compositing

The Crazy Part?

The Full Journey

Why Does Go Have Goroutines? Understanding Go’s Lightweight Concurrency

First, what is concurrency?

What is a goroutine?

But there's a problem 👀

Why not just create multiple threads?

Concurrency vs Parallelism

The bigger picture

What I learned today

Your Database Is Probably Doing More Work Than It Needs To 🗄️⚡

1. Stop Using SELECT * Everywhere

Simple rule:

2. Indexes Can Change Everything

3. Beware of the N+1 Query Problem

4. Don't Query the Same Data Repeatedly

5. Pagination Is Not Optional at Scale

6. Don't Optimize Blindly

A Simple Performance Checklist 🚀

The Bigger Lesson

What database optimization trick has saved you the most performance?

⚡ Stop Writing Code Immediately — Plan First, Code Faster

🧠 Step 1: Understand the Problem

🧩 Step 2: Break It Into Smaller Problems

⚠️ Step 3: Think About Edge Cases

🛠️ Step 4: Choose the Simplest Solution

💻 Step 5: Then Start Coding

🚀 The Biggest Lesson

💭 What about you?

थाळी — An Interactive Thali, Built Entirely in CSS

Inspiration

Demo

Journey

The Bug Wasn't in My Code --- It Was in My Assumptions 🤯

The classic debugging trap

This happens everywhere

My new debugging approach

1. What do I think is happening?

2. What is actually happening?

3. Where does reality differ from my assumption?

4. Fix the actual problem

The debugging rule I now follow

A simple debugging checklist

Final takeaway

What about you?

Before You Add Another npm Package, Ask Yourself These 5 Questions

Installing an npm package takes a few seconds.

1. Do I actually need a package?

2. Is the package actively maintained?

3. How many dependencies does it bring with it?

4. What does this dependency cost my project?

5. Can I remove it later?

A Simple Rule I Follow

The npm install Reflex

Final Thought

What's one npm package you can't live without?

I Deployed My Backend to Render… and Then Everything Broke 💀

I Deployed My Django App to Render… and Then Everything Broke 💀

🚀 Deploying the Application to Render

💥 The Actual Problem Started After Deployment

🔍 The Render Logs Were the First Place I Looked

📁 Then I Found a Frontend Build Problem

🧩 Source Code vs Build Output

1. Stop Using `SELECT *` Everywhere

The `npm install` Reflex