DEV Community: The Creative CodeFlow

Your API Might Be Doing 100 Database Queries Instead of 1

The Creative CodeFlow — Sun, 18 Oct 2026 18:40:59 +0000

Imagine loading a page that displays 100 users.
Simple, right?
But what if your backend makes 101 database queries just to display them?
This is called the N+1 query problem.
Here's a simplified example:
const users = await db.user.findMany();

for (const user of users) {
user.posts = await db.post.findMany({
where: { userId: user.id }
});
}

If you have 100 users, this can execute:

1 query to fetch users
100 queries to fetch their posts Total: 101 queries. That's a lot of unnecessary database communication. A better approach is to fetch the posts for all users in one query: const users = await db.user.findMany();

const posts = await db.post.findMany({
where: {
userId: { in: users.map(user => user.id) }
}
});

Now you've reduced the example to 2 queries instead of 101.
You still need to group the posts by user before returning the response, but you've eliminated the repeated database calls.
The actual improvement depends on your database, data size, indexes, and query patterns.
The lesson?
Sometimes your API isn't slow because your code is complicated.
It's slow because your code keeps asking the database the same kind of question again and again.
Next time an API feels slow, check how many database queries it executes.
You might discover that the biggest performance improvement requires less querying, not more code.

JavaScript Has a Weird Trick: [] == false Is True

The Creative CodeFlow — Mon, 12 Oct 2026 17:51:50 +0000

JavaScript Has a Weird Trick: [] == false Is True
What do you think this prints?
console.log([] == false);
console.log([] === false);

The output is:
true
false

Wait… how can an empty array equal false?
The answer is JavaScript's type coercion.
When you use ==, JavaScript may convert values to different types before comparing them.
In this example:
[] == false

JavaScript converts false to 0, and the empty array to an empty string, which becomes 0 when converted to a number.
So the comparison becomes:
0 == 0 // true

But === checks both value and type without performing this kind of type conversion.
[] === false // false

An array and a boolean are different types.
Here's the lesson: JavaScript sometimes does more work behind the scenes than your code suggests.
For predictable comparisons, prefer === unless you specifically need the conversion behavior of ==.
Try these yourself:
console.log("" == false);
console.log("0" == false);
console.log([] == ![]);

Can you predict all three outputs before running the code?

Why const Doesn't Mean What Most JavaScript Beginners Think

The Creative CodeFlow — Sun, 11 Oct 2026 18:29:04 +0000

You use const because you don't want a variable to change.
But JavaScript has a surprise for you. 👀
const user = {
name: "Rahul"
};

user.name = "Alex";

console.log(user.name);

Output:
Alex

Wait… wasn't user declared with const?
Here's the trick.
const prevents you from reassigning the variable. It doesn't make the object itself immutable.
This works:
user.name = "Alex";

But this doesn't:
user = { name: "Sam" };

Why?
Because const keeps the variable bound to the same object, but the object's properties can still change.
Think of it like this:
You can't replace the box, but you can change what's inside it.
Want to prevent accidental changes to an object's top-level properties?
Try:
Object.freeze(user);

Remember, Object.freeze() is shallow. Nested objects can still change unless you freeze them separately.
The takeaway: const doesn't mean "nothing can change." It means "this variable can't be reassigned."
Did you know this already, or did JavaScript trick you too?

Your API Can Be Slow Even When Your Code Is Fast

The Creative CodeFlow — Thu, 08 Oct 2026 15:41:22 +0000

You optimized your function.
It runs in 5ms.
But your API still takes 2 seconds.
Why?
Because your function isn't the only thing your API is doing.
A request might look like this:
Client
↓
API
↓
Database
↓
External API
↓
Response

Your code could be extremely fast while the database or external service is slow.
For example:
const user = await getUserFromDatabase();
const weather = await getWeatherFromAPI();

If the database takes 500ms and the weather API takes 800ms, your API is already waiting more than a second.
And that's before adding other work.
One simple improvement is doing independent operations in parallel:
const [user, weather] = await Promise.all([
getUserFromDatabase(),
getWeatherFromAPI()
]);

Instead of:
Database → 500ms
↓
Weather → 800ms

Total ≈ 1300ms

You can potentially get closer to:
Database ─── 500ms ──┐
├──→ Response
Weather ───── 800ms ─┘

Total ≈ 800ms

The exact result depends on the services and other work involved.
The important lesson:
Don't optimize only your code.
When an API is slow, ask:
"Where is the time actually being spent?"
Sometimes the slowest part of your API isn't your code at all.

Your console.log() Might Be Hiding Your Real Bug

The Creative CodeFlow — Wed, 07 Oct 2026 11:13:34 +0000

You see this in your code:
console.log(user);

And the console shows:
{name: "Rahul", age: 21}

Looks fine, right?
But when you're debugging objects, there is something easy to miss.
For example:
console.log(user);

user.name = "Changed";

When you later expand an object in the browser console, you may not always be looking at the exact state you expected at the moment of logging.
If you want a simple snapshot, you can log the object as JSON:
console.log(JSON.stringify(user));

Now you're seeing the serialized value at that point in time.
The bigger lesson?
Don't just ask:
"Did I log the variable?"
Ask:
"Am I actually seeing its value at the moment the bug happened?"
Sometimes debugging isn't about adding more logs.
It's about understanding what your logs are actually showing you.
Try it yourself: log an object, change it immediately afterward, and inspect the console.
You might be surprised.

Why Does Your Code Work After You Restart the Server?

The Creative CodeFlow — Tue, 06 Oct 2026 06:10:23 +0000

Why Does Your Code Work After You Restart the Server?

Have you ever seen this?

Your application is broken.

You stare at the code.

You change something.

Nothing.

Then you restart the server...

And suddenly:

"Wait... it works now?"

This isn't magic.

There are several reasons why restarting an application can appear to fix a problem.

1. Your application has state

Some applications keep information in memory while they are running.

For example:

let count = 0;

count++;

As long as the process is running, count keeps its value.

When you restart the application:

Application running
↓
count = 5
↓
Restart
↓
count = 0

The old memory is gone.

So restarting can remove unexpected state that your code was carrying around.

2. Something is stuck

Your application might have:

an open connection
a pending request
a cached value
a background process
a file handle
a connection pool

Sometimes that state gets into an unexpected situation.

Restarting shuts down the old process and creates a fresh one.

It's basically saying:

"Forget everything and start again."

3. Your environment changed

This happens a lot during development.

You install a package.

Change an environment variable.

Modify a configuration file.

Change a port.

But your currently running process may still be using the old configuration.

Restarting forces the application to load the configuration again.

For example:

.env
↓
Application starts
↓
Environment variables loaded

If .env changes while the application is already running, the running process doesn't automatically become a completely new process with the new environment.

A restart gives you a clean start.

4. Your development server has a problem

Modern development tools often support hot reload.

You save a file.

The tool detects the change.

It updates your application without completely restarting everything.

This is extremely useful.

But it also means your development environment can sometimes end up in a state that doesn't perfectly represent a fresh application startup.

A restart can clear that state.

But here's the important part

Restarting the server is useful.

But it should not become your debugging strategy.

If your solution is always:

Bug
↓
Restart
↓
Works
↓
Move on

you're hiding the problem instead of understanding it.

A better approach is:

Bug
↓
Check logs
↓
Reproduce it
↓
Find the state causing it
↓
Fix the actual problem
↓
Restart only when necessary

A simple debugging habit

The next time restarting fixes your application, stop for a moment.

Ask yourself:

"What changed when I restarted?"

Did the process lose some state?

Did it reload configuration?

Did a connection get recreated?

Did a cache disappear?

Did a background task stop?

Did the application actually start from a clean state?

That question can lead you to the real bug.

The bigger lesson

A running application isn't just your source code.

It's your source code plus:

Memory
+
Configuration
+
Connections
+
Caches
+
Background tasks
+
External services

That's why the same code can sometimes behave differently depending on the state of the running system.

Restarting works because it destroys much of that temporary state and starts a fresh process.

So the next time you say:

"Just restart the server."

Also ask:

"Why did restarting fix it?"

That second question is where the real debugging starts.

What Actually Happens When You Type a URL?

The Creative CodeFlow — Sun, 04 Oct 2026 17:57:27 +0000

What Actually Happens When You Type a URL?

You type:

https://example.com

You press Enter.

A second later, the website appears.

But what actually happened during that one second?

A lot more than you might think.

Let's break it down in simple terms.

1. The browser checks the URL

The browser first understands what you entered.

For:

https://example.com

we have:

https → protocol
example.com → domain

The protocol tells the browser how it should communicate with the server.

2. DNS finds the server

Your computer doesn't directly understand example.com as an address.

It needs an IP address such as:

93.184.216.34

This is where DNS comes in.

DNS is basically like the internet's phone book.

It converts:

example.com
        ↓
93.184.216.34

Your browser can then find where the website is hosted.

3. A connection is created

Now your browser needs to communicate with that server.

For HTTPS websites, the connection also involves encryption using TLS.

This is important because information travelling between you and the website should not simply be readable by anyone who can observe the connection.

4. Your browser sends an HTTP request

Now the browser can actually ask the server for something.

A simplified request looks like:

GET / HTTP/1.1
Host: example.com

In simple words:

"Hey server, give me the homepage of example.com."

5. The server sends a response

The server processes the request and sends something back.

For example:

HTTP/1.1 200 OK
Content-Type: text/html

And then the HTML page is sent to your browser.

But we're still not finished.

6. The browser builds the webpage

The browser reads the HTML.

It might find:

<link rel="stylesheet" href="style.css">
<script src="app.js"></script>
<img src="logo.png">

Now the browser needs to request those files too.

So one page can cause many additional requests.

Something that looks like:

You
 ↓
Browser
 ↓
DNS
 ↓
Server
 ↓
HTML
 ↓
CSS + JavaScript + Images
 ↓
Browser renders the page

And finally...

You see the website.

The interesting part

When you think:

"Google loaded in one second."

Your computer actually performed many different operations behind the scenes.

That's why web development isn't just about HTML, CSS and JavaScript.

It also involves:

DNS
HTTP
networking
TLS
servers
browsers
caching
databases
CDNs

All of these pieces work together to make the web feel almost instant.

Try this yourself

Open your browser.

Press:

F12

Then open the Network tab and refresh a website.

You'll see dozens or even hundreds of requests.

Look at:

Request
Status
Time
Size
Type

Pick one request and inspect it.

Suddenly, the website won't look like "one page" anymore.

It will look like a conversation between your browser and many different systems.

And that's one of the most useful things to understand as a web developer:

A website isn't just something you see.

It's a collection of requests, responses and systems working together in the background.