DEV Community: Raj Tejaswee

Why Single-Threaded Servers (Like Node.js) Even Work

Raj Tejaswee — Wed, 31 Dec 2025 00:29:58 +0000

Context :Many beginners assume software works like this:

User sends a request
App starts processing
CPU stays busy until work is done
App sends a response

That mental model is wrong for most web applications.
Modern web apps are not CPU-bound most of the time. They are I/O-bound.

What Web Applications Really Do

A typical web request looks like this:

User sends a request
App validates input
App asks the database for data
App waits 5 .Database responds
App sends response to user

The key insight:

The application spends most of its time waiting, not computing.

While waiting for:

Database queries
Network calls
Disk I/O

The CPU usage is effectively 0%.

How Multithreaded Servers Handle This:

Traditional servers (Java, C++, Go, etc.) usually do this:

One request → one thread
That thread waits for DB/network
Memory is allocated for each thread
Stack, heap, context switching overhead

This works fine, but comes with costs:

Threads consume memory
Thread creation isn’t free
Context switching adds overhead

So you end up with many threads doing nothing, just waiting.

The Event Loop (Single-Threaded Model):

Instead of creating threads that wait, the event loop does this:

Send DB request
Move on to next request
When DB responds, handle it
Send response
Repeat

In other words:

While waiting, the server does something else.

No thread is blocked.
No stack is wasted.
No context switching.

Latency is similar to multithreaded servers because:

Database response time dominates anyway.

This is why Node.js can handle many concurrent requests efficiently.

“But How Is This Parallel?”

This part confuses most people.
Node.js itself is single-threaded, but:

The database is multi-threaded
The OS kernel is multi-threaded
Network I/O happens in parallel elsewhere

So Node.js is effectively:

Coordinating work across other multi-threaded systems.

It’s not doing everything alone — it’s orchestrating.

Where Single-Threaded Servers Fail

Single-threaded models fail badly when:

You do heavy CPU work
Video encoding
Image processing
Cryptography
Machine learning
Large mathematical computations

Why?
Because:

CPU work blocks the event loop
No other requests can be handled
Only one CPU core is used

This is why Node.js is bad for CPU-heavy tasks inside the request lifecycle.

Where Multithreaded Servers Fail

Multithreaded servers struggle when:

Each request allocates lots of memory
Frameworks create many objects
Threads need large stacks
You embed other runtimes (PHP, Ruby, Python)

Problems:

High RAM usage
Slower memory allocation (malloc)
Fewer concurrent requests possible

This is why Node.js often beats traditional servers in web workloads.

Hybrid Approaches (Best of Both Worlds)

Real systems don’t choose extremes.

Example 1: Nginx / Apache

Multiple threads
Each thread runs an event loop
Load balanced across threads

Example 2: Node.js Clustering

Multiple Node.js processes
One per CPU core
Load balancer distributes traffic

Effectively:

Event-driven + multi-core utilization

The Real Takeaway

The debate is not:
Single-threaded vs multi-threaded

The real distinction is:

I/O-bound vs CPU-bound workloads
Web apps → I/O-bound → event loops shine
Heavy computation → CPU-bound → threads/processes needed

Both models are valid.
Both models exist everywhere.
They’re mirror images solving the same problem differently.

I Knew Web Dev, But I Couldn’t Build Anything — Here’s What I Changed

Raj Tejaswee — Sat, 13 Dec 2025 20:30:33 +0000

If you’re a fresher or someone who has gone through countless tutorials, courses, and playlists but still hasn’t built a project on your own — this post is for you.

I’ve been there. Watching videos, reading docs, understanding things in isolation, but never feeling confident enough to start something independently. The common excuse is always the same:

“I don’t know enough yet.”

The truth is, you’ll never feel “ready.”
What you need is a structured way to learn just enough, apply it, and move forward.

This post documents what I’ve learned while relearning web development — and how you can follow the same path to build your first real project, even if it’s basic.

Note: This guide is not about perfection. It’s about building something that works. If you can complete this once on your own, you’ll be capable of building more complex projects later.

Who This Guide Is For

Freshers who are overwhelmed by full-stack tutorials
People stuck in tutorial hell
Those who “know” MERN but can’t start a project
Absolute beginners who want a clear, end-to-end path

If that sounds like you, keep reading.

Phase 1: Minimum HTML/CSS, Maximum JavaScript Understanding.

Don’t overinvest in HTML and CSS at the start.

Learn only the essentials:

Basic HTML tags
Basic CSS
Flexbox

Your real focus should be JavaScript.

And here’s the important distinction:
Don’t just learn JavaScript — understand how it works internally.

Things that actually matter:

How code executes
What will be the output of a given snippet
async / await
Promises
Arrow functions
Scope and closures
Call stack and event loop (at least conceptually)

JavaScript doesn’t click by reading alone. It clicks when you:

Predict outputs
Write small snippets
Break code
Fix your misunderstandings

Phase 2: Learn Backend First (This Is Where Most People Skip)

Now comes the grind — backend first, in this order:

Node.js
HTTP servers
Express.js
Postman (testing APIs properly)
Middlewares
Headers & query parameters
Authentication (write your own auth endpoints)
JWT & authorization
MongoDB (basic CRUD is enough)
Password hashing
Zod / input validation

Don’t aim for mastery here.
Aim for working knowledge.

If you can write routes, protect them with auth, store data, and test everything in Postman — you’re doing well.

Phase 3: Build a Basic Backend Project (No AI, No Shortcuts)

Now build a basic backend project(any one):

Todo app
Simple e-commerce backend
Any CRUD-based system

Yes, it will feel basic.
Yes, AI can generate it in seconds.

But here’s the truth:

If you can build this without AI, you’re already ahead of most beginners.

Do it like engineers did before ChatGPT:

Read docs
Google errors
Use Stack Overflow
Debug manually

Design:

Your own database schema
Auth flow
Controllers
Routes

Test everything in Postman.

If it works — congratulations.
You’ve already covered 70% of backend development.

Phase 4: Learn React (This Is the Last Big Bump)

Now your backend needs a frontend.

This is the perfect time to learn:

React
Tailwind CSS

React feels overwhelming to most freshers — and that’s normal.

The difference now is:

You already have a backend
You know what data you need
You have a real goal

Your task is simple:
Build a frontend for the backend you already created.

This is where AI actually helps:

Ask GPT how to structure components
Ask doubts
Compare approaches
But don’t blindly copy.
Read
Understand
Rewrite it yourself

Over time, React will stop feeling magical and start feeling logical.

Phase 5: Level Up With TypeScript and Real Databases

Once you’re comfortable:

Learn:

TypeScript
WebSockets
PostgreSQL
Prisma

Now build your second project:
A basic chat application**

Same approach:

Database modeling
Auth
Controllers
Routes
Postman testing

At this point — yes — you’ve covered 95% of practical web development.

You can understand and contribute to most company codebases.

The Remaining 5% (What the Market Actually Wants)

That last 5% is about productization.
Learn:

Next.js
Monorepos / Turborepo
Basic DevOps
CI/CD
Docker
Kubernetes (conceptual understanding)

This is what turns a developer into an engineer who can:

Build
Deploy
Maintain
Scale

The market values people who understand a product end to end — not just code.

Final Thoughts

This path isn’t glamorous.
It’s not fast.
And it’s definitely not perfect.

But if you complete this once, on your own, you’ll never be stuck again.

You won’t fear new projects.
You won’t fear codebases.
You won’t fear interviews as much.

Because at that point, you’re no longer following tutorials —
you’re building.

My Beginner-Friendly Debugging Checklist for Any Node.js API Issue

Raj Tejaswee — Sun, 23 Nov 2025 18:39:39 +0000

Debugging backend issues used to feel chaotic when I first started working with Node.js and Express. Errors seemed random, console logs looked useless, and I often had no idea whether the problem was in the route, middleware, controller, or database.

Over time, I built a simple debugging checklist that works consistently.

This guide is meant for beginners but follows a clean, professional approach you can rely on even as you grow.

1. Verify the Request First

Most bugs come from the client, not the server.

Before touching your backend code, check:

Is the body structured the way your API expects?
Are you sending JSON while forgetting express.json()?
Missing headers or wrong token format?
Incorrect URL or query parameters?

Use tools like:

Postman / Thunder Client to test raw requests
Browser Network tab to inspect actual payloads

If the request is wrong, every downstream step breaks.

2. Add Clear, Minimal Console Logs

Avoid the common beginner mistake of spamming logs everywhere.

Instead, log at key checkpoints:

When the request reaches the route
After input validation
Before the database query
After the database returns data
Before sending the final response

Example:

console.log("POST /login hit");
console.log("Body:", req.body);
console.log("User lookup result:", user);

This creates a clean, readable flow of what your backend is doing.

3. Trace the Async Flow

A large chunk of Node.js bugs come from incorrect async handling:

Forgetting await
Not marking a function as async
Returning a response before an async operation finishes
Mixing callbacks with promises
Silent promise rejections

Key signs you messed up async flow:

Logs show Promise { <pending> }
Database queries return undefined
Code executes out of order

A missing await or a misplaced async function is often the real cause.

4. Follow the Middleware Path

Express runs middleware in the exact order you define it.

Common problems:

Auth middleware placed after protected routes
Missing next() causing the request to hang
Validation middleware never firing
Route-level middleware not being applied correctly

Debugging tip:

console.log("Auth middleware reached");

If this never logs, the issue is middleware order—not your token, not your logic.

5. Validate Inputs Before Anything Else

Most backend failures are caused by invalid or incomplete inputs, not the logic itself.

Always verify:

Required fields are present
Data types match what your API expects
No empty strings or undefined values
Required headers exist
JWT follows the correct Bearer <token> format

Example validation:

if (!email || !password) {
  return res.status(400).json({ msg: "Missing fields" });
}

This alone prevents a large percentage of avoidable bugs.

6. Inspect Your MongoDB Query Shape

MongoDB failures are often subtle because they don’t always throw explicit errors.

Typical issues include:

Querying fields that don’t exist
Using _id as a plain string instead of an ObjectId
Forgetting to await a .findOne() or .find() call
Schema mismatch between stored data and expected data
Typos in nested paths or query objects

A simple debugging pattern helps reveal the problem:

console.log("Query:", { email });
const user = await User.findOne({ email });
console.log("DB Result:", user);

If user is null, the issue is with your query or your data shape, not the rest of your logic.

ChatGPT said:

7. Use a Global Error Handler

Express does not catch async errors on its own.

If you don’t set up a proper error handler, your server may fail silently or return inconsistent responses.

Make sure your async route handlers use try/catch, and always include a global error-handling middleware:

app.use((err, req, res, next) => {
  console.error("Error:", err);
  res.status(500).json({ msg: "Server error" });
});

If the error never reaches this middleware, it means the error wasn’t thrown or wasn’t passed properly using next(err).

8. Read the Error Message Properly

A lot of debugging time is wasted simply because error messages are skimmed instead of read carefully.

Node.js errors usually tell you exactly what went wrong. They include:

The file where the issue occurred
The line number
The function or variable causing the problem
The type of error (undefined value, type mismatch, invalid argument, etc.)

Instead of guessing or rewriting code blindly, slow down and read the full stack trace.

Most of the time, the fix is already written inside the error message itself.

Learning Web Development With a Better Mindset

Raj Tejaswee — Fri, 14 Nov 2025 17:10:53 +0000

Introduction

I’ve gone through web development before, but not the right way. I knew how to use things, but I couldn’t explain them. Interviews exposed it quickly — I froze on questions I should’ve been able to answer. That was the moment I understood the difference between knowing something and actually understanding it.

The Common Learning Trap

Most beginners — and honestly many CSE grads too — learn web development by rushing:

Following tutorials
Copying snippets
Jumping into React before understanding JavaScript
Letting AI tools fill every gap
It works until you’re asked simple conceptual questions: What problem do promises solve? How does the browser render a page? Why do we use semantic HTML? At that point, you realize you’ve been building without understanding the core ideas behind the technology.

AI as a Tool — Not a Shortcut

AI tools like ChatGPT and Claude are powerful, but they create a new learning problem: we stop thinking. They can generate code, fix errors, and explain anything instantly. That’s great, but not if it replaces your own understanding.
For someone from a non-tech background, AI is a bridge.
For someone like us — CSE students, interns, junior engineers — AI can easily become a crutch.

The right way to use it is simple:
Let AI guide you, not think for you
Compare your code with AI, don’t paste and forget
Use it for clarity, not shortcuts

The goal is to be able to build and explain things even without AI.

The Mindset Shift That Actually Helped

Earlier, I wanted to “finish learning web development.” Now I understand that you don’t finish this field; you understand its foundations and build on them.
My new approach:

Concepts before frameworks
Fundamentals before features
Slow learning, strong retention
Asking “why” before “how” This mindset alone fixes half the problems beginners face.

Key Lessons I Learned

If you don’t understand the underlying problem, you won’t remember the solution.
Basics compound.
Interviews test reasoning, not memorization.
AI should speed up your thinking, not replace it.
Good engineers explain systems, not just code.