DEV Community: Muiz

Every API endpoint returned 500 errors. The logs revealed two MongoDB issues I wasn't expecting.

Muiz — Mon, 20 Jul 2026 04:40:34 +0000

Today started with a nightmare scenario for any backend developer.

Every API endpoint in my application suddenly started returning 500 Internal Server Errors.

At first, I assumed it was something I had recently deployed. I reviewed the latest commits, checked the deployment pipeline, verified environment variables, and inspected application logs.

Nothing obvious stood out.

Then I enter the VPS. Check the docker logs.

I noticed repeated MongoDB errors appearing throughout the logs:

DNSException: querySrv ESERVFAIL
_mongodb._tcp.cluster0.mongodb.net

Naturally, I thought the outage was caused by a MongoDB connectivity issue. The symptoms matched perfectly: database failures, followed by API failures.

But after digging deeper, another error kept showing up:

MongoServerError: Index build failed

E11000 duplicate key error
collection: roles
index: id_1
dup key: { id: null }

This turned out to be the real clue.

MongoDB was attempting to build a unique index on the id field, but multiple documents already existed with id: null. The index build failed, which caused repository initialization issues and eventually surfaced as 500 errors across the application.

What made this incident interesting was how misleading the symptoms were.

The API looked broken.

The database connection looked broken.

But the actual root cause was a data integrity issue hiding inside the collection.

A few reminders I took away from today's debugging session:

✅ When every endpoint fails, look for shared dependencies.

✅ The first error you see isn't always the root cause.

✅ Database indexes deserve the same attention as application code.

✅ A single bad document can trigger failures across an entire system.

Debugging distributed systems is often less about fixing code and more about following evidence until the story finally makes sense.

Today, that story ended with a duplicate MongoDB index failure hiding behind a wall of 500 errors.

While debugging this from the frontend side, I used a tool I built for inspecting network traffic Network Spy, which helped me trace the root cause faster: Check it here

AI can make developers faster — and also dangerously less observant

Muiz — Mon, 20 Jul 2026 04:40:11 +0000

I have a project that is (debatably, like any real-world system) well-structured and follows solid engineering practices. Clear separation of concerns, proper build pipeline, and strict rules around what should and shouldn’t be committed.

A new developer joins the project.
They are eager. Productive. And like many developers today, they have AI tools like Claude Code in their workflow.

At first, everything looks fine.

Code is being written fast. Features are landing quickly. The velocity looks great.

Then I start noticing something small — but important.

Version-controlled files begin including artifacts like:

storybook-static/
build outputs
generated files that should never be committed

This is where things get interesting.

Because the system already defines what should and shouldn’t be tracked in Git. There are rules, .gitignore, and established conventions.

So the real question becomes:

Why wasn’t this the first thing caught before committing?

The shift I’ve noticed with AI-assisted development

From what I observe, tools like Claude Code, Copilot, or agent-based workflows change the development pattern:

Instead of:

write code → think → review → commit

It becomes:

ask AI → accept output → commit → move on

And if you're not careful, one subtle behavior emerges:

“It works, so I ship it.”

But “it works” is not the same as “it’s correct for the system.”

A real workflow gap

In my own experience using tools like Opencode, I noticed a pattern:

Once I ask it to commit, the next instruction often becomes:

just commit everything that changed

That is extremely powerful — but also dangerous.

Because it subtly removes a critical step:

human verification of what is actually being committed

And that’s exactly where things like build artifacts, debug files, or unintended changes slip in.

Not because the AI is wrong —
but because the human stopped reviewing deeply.

The real problem isn’t AI

AI is not the issue.

The issue is delegated responsibility without retained awareness.

When developers start trusting AI outputs blindly, the workflow shifts from engineering to execution:

AI writes
AI prepares commit
AI suggests changes
Human approves without deep inspection

That’s where subtle but serious mistakes start appearing in production systems.

What this teaches me

This experience reinforced a few important principles:

1. Review and re-review

Every commit matters — even if it was generated by AI.

2. Always be the second pair of eyes

AI can be the first author.
You must always be the reviewer.

3. You are still the engineer

AI gives you speed, not judgment.

You might now have “100 hands” to write code —
but that doesn’t mean you stop thinking.

If anything, you need to think more, not less.

The uncomfortable truth about “vibe coding”

This is also why many “vibe-coded” applications look fine at first — but slowly accumulate:

security issues
misconfigurations
leaked build artifacts
inconsistent architecture decisions

Not because developers are incapable.

But because:

they stop inspecting what they didn’t personally write.

Final thought

AI didn’t make development worse.

But it did change the failure mode:

From:

“I wrote bad code”

To:

“I didn’t review what was written”

And that is a much harder problem to notice — until it reaches production.

Why I still don’t use Claude (and why a “cheap model” is enough for me)

Muiz — Mon, 20 Jul 2026 04:39:50 +0000

In most discussions today, it feels like using advanced AI models has become a status signal:

higher usage, bigger bills, “Claude maxed out again”, etc.

But my experience has been a bit different.

I still primarily use a cheap model setup, and it has been enough for my workflow.

Here’s why.

1. I still consider myself the engineer

The core principle for me is simple:

The model is a tool, not the engineer.

As long as the model can:

follow instructions
generate decent code
respect constraints

then it’s usable.

At the beginning, I mainly used ChatGPT web for coding because it was the most consistent option for instruction-following at the time.

Other tools existed, but they weren’t reliable enough in structured tasks.

2. Claude is good — but the limits are real

Claude is genuinely strong in many cases:

good reasoning
clean code generation
strong long-context understanding

But in practice, there’s a constraint that matters a lot:

usage limits.

And once you hit that limit mid-flow, your workflow gets interrupted.

That alone changes how I evaluate tools.

3. Other models improved, but instruction-following is still inconsistent

Over time, more models started appearing — including some cheaper or open alternatives.

Some are fast. Some are cheap. Some are surprisingly capable.

But I consistently noticed a pattern:

They say they will follow instructions
But the actual output drifts
They modify things I explicitly told them not to touch
Tool usage is often simulated, not executed properly

That mismatch makes them harder to trust in structured engineering work.

4. The real requirement: predictable behavior

For my workflow, I don’t need the “smartest” model.

I need the most predictable one.

Because I usually work with:

well-defined architecture
strict boundaries on what should change
clearly scoped tasks
explicit instructions on where NOT to modify anything

In that setup, consistency matters more than raw intelligence.

Right now, tools like DeepSeek V4 / Flash via OpenCode are “good enough” for that.

They follow structure, respect context, and don’t overcomplicate changes.

5. Why I never “had to switch to Claude”

I often see developers talking about:

hitting Claude limits
paying high monthly bills
relying heavily on Claude for everything

But in my case, I never reached that point.

Not because Claude is bad — it’s not.

But because:

my workflow is constrained enough that a cheaper model already satisfies the requirements.

And when the problem is well-defined, you don’t always need the most powerful tool — just the most reliable one.

6. The trade-off people miss

Yes, Claude can be better in many scenarios.

But the trade-off is simple:

Better reasoning → higher cost + limits
Good enough reasoning → stable + cheap + continuous usage

And for engineering work, continuity often wins.

Final thought

I don’t avoid Claude because it’s bad.

I avoid it because:

it is not the most cost-effective tool for the way I structure my work.

At the end of the day, I still believe this:

The best AI tool is the one that reliably follows your instructions — not the one that sounds the smartest.

And so far, for my use case, a cheaper model has been more than enough.

JSON API Response Design: Small Decisions That Save Months of Maintenance

Muiz — Mon, 20 Jul 2026 04:38:53 +0000

Most developers spend a lot of time designing databases, infrastructure, and application architecture.

But surprisingly little time is spent designing something every client consumes:

The API response format.

A poorly designed response structure creates confusion, duplicate code, inconsistent error handling, and unnecessary bugs across frontend, mobile, backend, and QA teams.

Let's explore a practical approach to JSON API response design.

The Problem

Many APIs start like this:

{
  "name": "John Doe",
  "email": "john@example.com"
}

Seems fine.

Until an error occurs:

{
  "error": "User not found"
}

Then another endpoint returns:

{
  "success": false,
  "message": "Invalid token"
}

And another one returns:

{
  "status": "error",
  "detail": "Permission denied"
}

Now every consumer needs special handling for every endpoint.

As the API grows, the problem grows with it.

A Consistent Response Envelope

A common pattern is using a standard wrapper around all responses.

Success:

{
  "success": true,
  "data": {
    "id": 1,
    "name": "John Doe"
  }
}

Failure:

{
  "success": false,
  "error": {
    "code": "USER_NOT_FOUND",
    "message": "User not found"
  }
}

This gives clients a predictable structure regardless of the endpoint.

Include Machine-Readable Error Codes

Avoid relying solely on error messages.

Bad:

{
  "message": "Something went wrong"
}

Better:

{
  "error": {
    "code": "EMAIL_ALREADY_EXISTS",
    "message": "Email already exists"
  }
}

Frontend applications can now implement logic using the code instead of parsing text.

if (error.code === "EMAIL_ALREADY_EXISTS") {
  showEmailError();
}

Messages may change.

Codes should not.

Return Metadata Separately

Avoid mixing business data with metadata.

Bad:

{
  "users": [...],
  "page": 1,
  "total": 500,
  "limit": 20
}

Better:

{
  "data": [...],
  "meta": {
    "page": 1,
    "limit": 20,
    "total": 500
  }
}

This becomes especially useful when implementing pagination, filtering, sorting, and analytics.

Timestamps Should Be ISO 8601

Bad:

{
  "created_at": "06/21/2026 14:30"
}

Good:

{
  "created_at": "2026-06-21T14:30:00Z"
}

ISO 8601 avoids timezone confusion and is supported by nearly every platform.

Avoid Null When Possible

Many APIs return:

{
  "items": null
}

Now clients must handle:

null
undefined
empty array

Instead:

{
  "items": []
}

An empty collection is often easier to reason about than a nullable collection.

Pagination Should Be Explicit

A paginated response should provide enough information for clients to continue fetching.

{
  "data": [...],
  "meta": {
    "page": 2,
    "limit": 20,
    "total": 100,
    "has_next": true
  }
}

Or cursor-based pagination:

{
  "data": [...],
  "next_cursor": "eyJpZCI6MTIzfQ=="
}

This avoids guesswork on the client side.

Don't Leak Internal Errors

Never expose raw stack traces.

Bad:

{
  "error": "SQLSTATE[23000]: Integrity constraint violation..."
}

Better:

{
  "error": {
    "code": "INTERNAL_SERVER_ERROR",
    "message": "Something went wrong"
  }
}

Log details internally.

Return safe information externally.

Versioning Matters

APIs live longer than most developers expect.

Instead of breaking existing clients:

/api/v1/users
/api/v2/users

Accept: application/vnd.company.v2+json

A versioning strategy saves painful migrations later.

Example Final Response Format

Success:

{
  "success": true,
  "data": {
    "id": 1,
    "name": "John Doe"
  },
  "meta": {
    "request_id": "req_123456"
  }
}

Error:

{
  "success": false,
  "error": {
    "code": "USER_NOT_FOUND",
    "message": "User not found"
  },
  "meta": {
    "request_id": "req_123456"
  }
}

Notice the request_id.

When a customer reports an issue, support can immediately locate the exact request in logs.

Final Thoughts

A good API response format is not about aesthetics.

It is about reducing complexity across every consumer of the API:

Frontend applications
Mobile applications
QA automation
Integrations
AI agents
Future developers

The best API responses are boring, predictable, and easy to reason about.

Your future teammates will thank you for it.

Tip: When designing or debugging APIs, inspect the actual HTTP traffic instead of relying only on application logs. Seeing the raw request and response often reveals inconsistencies, missing fields, incorrect status codes, and serialization issues much faster.

HTTP Traffic Debugger for AI powered teams | NetworkSpy

Inspect, debug, and understand modern API traffic with NetworkSpy, the network debugger built for GraphQL, streaming, and AI applications.

networkspy.app

Debounce Isn't Just About Performance—It's About Being Nice to Your API

Muiz — Mon, 20 Jul 2026 04:34:46 +0000

Every developer has written something like this:

input.addEventListener("input", () => {
  search(input.value);
});

It works.

Until someone starts typing.

If the user types "Hello", your application sends five requests:

H      → request
He     → request
Hel    → request
Hell   → request
Hello  → request

For a single search.

Why this is a problem

Five unnecessary requests might not sound like much.

Now imagine:

1,000 active users
Search suggestions
AI autocomplete
Product search
Database queries

Your backend suddenly receives thousands of requests that nobody actually wanted.

Most of them become obsolete the moment the next character is typed.

You're spending CPU time, bandwidth, and database resources on results the user will never see.

The solution: Debounce

Instead of calling your function immediately, wait until the user pauses typing.

const debouncedSearch = debounce(search, 300);

input.addEventListener("input", () => {
  debouncedSearch(input.value);
});

Now the interaction becomes:

H
He
Hel
Hell
Hello
      │
   wait 300ms
      │
      ▼
search("Hello")

Only one request is sent.

Better UX too

Debouncing doesn't just help your servers.

It also creates a smoother experience:

Less UI flickering
Fewer loading indicators
Fewer race conditions
Less chance that older responses overwrite newer ones

Your application feels calmer and more responsive.

Verify that it actually works

Don't assume your debounce implementation is correct.

Open your browser, type quickly into your search box, and inspect the network traffic.

Without debounce, you'll see a request for nearly every keystroke.

With debounce, you should see a single request after the user pauses typing.

This simple check can reveal accidental bugs, duplicate requests, or places where debounce isn't applied consistently.

One more thing

Debounce reduces how often requests are started.

It doesn't cancel requests that have already been sent.

If your application fires long-running network requests, combine debounce with request cancellation using AbortController or AbortSignal so outdated requests don't continue consuming resources.

The combination of:

Debounce
Request cancellation
Timeouts

results in a faster UI and a healthier backend.

Final thoughts

Every unnecessary request has a cost.

It consumes bandwidth.
It increases server load.
It slows databases.
It wastes money.

A few hundred milliseconds of patience can save thousands of unnecessary API calls every day.

P.S. If you want to confirm your debounce implementation is actually working, inspect your HTTP traffic with NetworkSpy. Watching the requests in real time makes it easy to spot duplicate calls and ensure you're not putting unnecessary pressure on your API.

A Faster HTTP Toolkit Alternative for Modern API Teams | NetworkSpy

HTTP Toolkit is approachable for web debugging, but modern API teams often need deeper visibility into streaming responses, GraphQL payloads, mobile traffic, and high-volume local workflows. NetworkSpy gives you a fast cross-platform workspace for inspecting, comparing, and understanding complex API behavior.

networkspy.app

Learning HTTP, HTTPS, TLS, and SSL is dauting. Yet I should learn it because its part of the job and I should explain to people. Give me list of good resources to learn!

Muiz — Mon, 04 May 2026 23:50:34 +0000