DEV Community: Prajwal Gaonkar

How the JavaScript Event Loop Creates the Illusion of Multithreading

Prajwal Gaonkar — Sat, 04 Apr 2026 16:22:56 +0000

If you’ve worked with JavaScript, you’ve probably heard:

“JavaScript is single-threaded.”

And then immediately wondered:

“Then how does it handle multiple things at once?”

This confusion usually comes from one misleading idea:

JavaScript does NOT simulate multithreading — it achieves concurrency by avoiding blocking.

Let’s break this down clearly.

The Core Truth

JavaScript runs on a single thread.

That means:

One call stack
One task at a time
No parallel execution of your JS code

So if that’s true… how does it handle multiple tasks?

The Real Trick: Don’t Do the Work

Instead of running everything itself, JavaScript:

Executes fast tasks immediately
Delegates slow tasks to the runtime (browser / Node.js)
Continues executing other code
Handles results later

This is the entire model.

The System Behind It

JavaScript relies on four components:

1. Call Stack

Executes code
One function at a time

2. Runtime (Browser / Node.js)

Handles timers, network, etc.
Uses background threads internally

3. Callback Queue

Stores completed async tasks

4. Event Loop

Moves tasks from queue → stack when stack is empty

Step-by-Step Example

console.log("Start");

setTimeout(() => {
  console.log("Async Task");
}, 1000);

console.log("End");

Execution Flow

Step 1: Run synchronous code

Start
End

Step 2: Delegate async work

Timer is handled by runtime
JavaScript does NOT wait

Step 3: Continue execution

JS thread is now free

Step 4: Task completes in background

Callback goes to queue

Step 5: Event loop executes it

Async Task

Why This Feels Like Multithreading

From the outside, it looks like:

Multiple tasks are in progress
Results come back later
Nothing blocks execution

This creates the illusion:

Task A running
Task B running

But internally, it’s actually:

Delegate Task A
Run Task B
Handle Task A result later

Important Distinction: Concurrency vs Parallelism

Java (Multithreading → Parallelism)

Multiple threads run at the same time
Execution overlaps

Thread 1: █ █ █ █
Thread 2: █ █ █ █

JavaScript (Event Loop → Concurrency)

One task at a time
No overlap in execution

Main Task: ██████
Async Task:      ██████

Why Your Loop Example Didn’t Look Concurrent

setTimeout(() => {
  for (let i = 0; i < 3; i++) {
    console.log("Async Task:", i);
  }
}, 0);

for (let i = 0; i < 3; i++) {
  console.log("Main Thread:", i);
}

Output:

Main Thread: 0
Main Thread: 1
Main Thread: 2
Async Task: 0
Async Task: 1
Async Task: 2

Why?

The loop is blocking
JavaScript cannot pause it
Event loop runs only after it finishes

JavaScript never interrupts a running task

Where Multithreading Actually Exists

JavaScript itself is single-threaded, but the environment is not.

Background threads are used for:

Timers
Network requests
File system (Node.js)

But:

Your JavaScript code never runs in parallel unless you explicitly use workers

When JavaScript Truly Becomes Multithreaded

You need:

Web Workers (browser)
Worker Threads (Node.js)

Only then do you get:

Parallel execution
Interleaved output

Why This Design Works

This model gives:

Non-blocking execution
High performance for I/O
Simpler mental model (no locks, no race conditions)

But:

CPU-heavy tasks will block everything

Final Takeaway

JavaScript handles multiple tasks without multithreading by:

Delegating slow work to the runtime
Continuing execution immediately
Using the event loop to process results later

One-Line Summary

JavaScript doesn’t run multiple tasks at once — it avoids waiting by offloading work and scheduling callbacks efficiently.

The Real Reason Behind Arrow Functions in JavaScript

Prajwal Gaonkar — Sat, 28 Mar 2026 18:48:17 +0000

The Real Difference Between Normal Functions and Arrow Functions (Node.js)

I’ve watched a lot of explanations about arrow functions on YouTube, and almost all of them say the same thing: “they’re just shorter functions.”

That explanation feels incomplete, and honestly, a bit misleading.

The problem is, it focuses only on syntax and ignores what actually changes under the hood. In JavaScript, functions are not just reusable code blocks—they also define an execution context, and a big part of that context is this.

With normal functions, this is dynamic. It is not fixed when you write the function. Instead, it is decided later, at the moment the function is called. That means the same function can behave differently depending on how it is invoked.

Arrow functions change this behavior completely. They do not create their own this at all. Instead, they capture this from the surrounding scope at the time they are created, and that value never changes.

So the real difference is not about shorter syntax. It is about how this is handled at a fundamental level:

Normal functions decide this at call time (dynamic binding)
Arrow functions fix this at creation time (lexical binding)

This is the part most explanations skip, but it is the reason arrow functions were introduced in the first place.

The Core Difference

Normal functions and arrow functions differ in how this is determined.

Normal Function

Has its own this
this is decided at call time
Depends on who calls the function

Arrow Function

Does not have its own this
this is taken from the surrounding scope
Fixed at creation time

Example in Node.js

Normal Function

const user = {
  name: "Alice",
  greet() {
    setTimeout(function () {
      console.log(this);
    }, 1000);
  }
};

user.greet();

Output

Timeout {
  _idleTimeout: 1000,
  ...
}

Explanation:

The function inside setTimeout is called by Node
So this becomes a Timeout object

Arrow Function

const user = {
  name: "Alice",
  greet() {
    setTimeout(() => {
      console.log(this);
    }, 1000);
  }
};

user.greet();

Output

{ name: 'Alice', greet: [Function: greet] }

Explanation:

Arrow function does not create its own this
It uses this from greet, which is user

Side-by-Side Summary

Feature	Normal Function	Arrow Function
Own `this`	Yes	No
`this` decided	Call time	Creation time
`this` depends on	Caller	Surrounding scope

Final Mental Model

Normal function:
"I will decide this when I am called"

Arrow function:
"I will use this from where I was created"

How AI IDEs Actually Work - Under the Hood

Prajwal Gaonkar — Sun, 22 Mar 2026 09:59:18 +0000

When we ask an agentic IDE like antigravity to “explain this” or “write code like this”, what actually changes?

And how does it return exactly what we asked for?

Let’s break down what’s happening under the hood.

Overall Workflow

User Prompt
↓
Context Builder (files, code, selection, search)
↓
LLM (predicts next action)
↓
Tool Call (if needed)
↓
Execution Layer (file update / command run)
↓
Result returned
↓
LLM again (decides next step)
↓
Final response / more actions

1. It Starts With Context — Not Your Prompt

The IDE does NOT send only your prompt.

It constructs a combined input:

Prompt + Code + Context + Tools

Context includes:

Current file
Selected code
Nearby code
Related files (via search)
Available tools

2. Context Window — Why Results Differ

LLMs operate within a limited context window.

They:

only see what is provided
do not understand your entire project
do not know your intent beyond context

there is a reason why IDE's perform better with developers then so called non devs as the context differs in both cases.

3. No Explain Mode vs Write Mode

There is no mode switch.

The model predicts the best output format.

Explain:

Input: Explain this function
Output: Plain text

Modify:

Input: Fix password validation
Output: Tool call

4. Tools — The Execution Layer

AI does NOT modify files directly.
Tools are just predefined functions.
It calls tools like:

read_file
search_code
apply_patch
run_terminal

Example:

{
  "tool": "apply_patch",
  "args": {
    "path": "auth.js",
    "patch": "- if (password == null)\n+ if (!password || password.length < 6)"
  }
}

5. How Code Is Edited

AI uses pattern-based editing.

Example:

- if (password == null)
+ if (!password || password.length < 6)

Why not line numbers?

They change
Code shifts
Patterns are more stable

6. Feedback Loop

Think → Act → Observe → Repeat

7. Final Understanding

AI decides
Tools execute
Context drives everything

Conclusion

AI only knows what you show it
Better context → better output
Real skill = giving the right context
these IDE's are more than what i mentioned but this part is the one of the most interesting and important part to learn.

What’s Next

As we now understood abt tools the best thing to know next is MCP protocols
.

stayy tunedd!!!

You Can’t Secure Public APIs — You Can Only Control Them

Prajwal Gaonkar — Sat, 21 Mar 2026 04:55:05 +0000

While building my public form system, I initially thought security meant restricting frontend access, using tokens, and enabling CORS.

But after going deeper, I realized something fundamental: I was securing the frontend… not the API.

Attackers don’t use your frontend. They don’t click buttons. They go straight to your API.

1. The CORS Illusion

I assumed CORS would protect my API. But CORS is a browser-only safety rail. It does NOT block requests; it only blocks browsers from reading responses.

This still works perfectly:
curl https://your-api.com/submit

The Reality: Your backend still executes logic. Your database can still be modified. CORS protects users, not your server.

2. Tokens Are Not Enough

I implemented CSPRNG tokens and one-time validation. This made tokens unguessable, but it didn't make them restricted.

If your token endpoint is public, anyone can do:
curl https://your-api.com/get-token

The issue wasn’t token security. It was token issuance.

3. The Shift to Token Binding & DBSC

The idea of Token Binding is that a token should only be usable by the client that received it.

In 2026, we’ve moved past the old TLS Token Binding (which browsers like Chrome removed) to DBSC (Device Bound Session Credentials).

How DBSC Works:

Hardware Key: The device generates a key pair in the TPM (Security Chip).
Binding: The server binds the session token to the public key.
Proof: Every request must be signed by that hardware key.

Does this stop a CLI attacker?

Case 1 (Token Theft): Attacker steals your token. They can't sign the request without your hardware. SUCCESS.
Case 2 (The CLI "Guy"): The attacker uses their own CLI to generate a key, gets a token, and signs the request. FAILURE.

Insight: DBSC prevents misuse, not malicious usage.

4. The Real Solution: Zero Trust

If you cannot stop a CLI attacker from acting like a valid client, you must change your mindset: Assume every request is malicious until proven otherwise.

You don't secure public APIs by blocking access; you secure them by controlling behavior.

5. The "One-Stop" System Design

To protect a public form, you need a layered pipeline that makes abuse expensive and slow.

The Defensive Pipeline:

Rate Limiting: Control the volume.
JS Challenge / Turnstile: Stop simple CLI scripts that can't execute JavaScript.
TLS Fingerprinting (JA4): Identify if the "handshake" comes from a browser or a library like curl.
Token Issuance Control: Only issue tokens after the challenge is passed.
Idempotency: Ensure the same "attack" packet can't be processed twice.

6. Key Techniques for 2026

Reject Early: Do cheap checks (IP Rate Limits) before expensive checks (DB lookups).
Context Binding: Bind tokens to the IP and User-Agent. If they change mid-session, kill the token.
Make it Expensive: Force attackers to use residential proxies and headless browsers (Puppeteer). When the cost of the attack exceeds the value of the data, the attacker leaves.

🔗 Code & Implementation

Check out the full implementation and experiments here:
👉 github.com/OP-Prajwal/publicForm

Building an Unbreakable Public Form: From Concept to Production Backend

Prajwal Gaonkar — Fri, 20 Mar 2026 14:52:34 +0000

If you caught my previous blog post, we explored the high-level concepts of securing public forms: IP blocking, session tokens, idempotency, and CAPTCHAs. We talked about what needed to be done to stop bots and duplicate data.

But conceptual theory only gets you so far. When you sit down to actually write the code, the reality of race conditions, database locks, and user behavior hits you fast. Today, we are going completely under the hood. We're looking at the exact end-to-end system design of how those ideas come together into a real, production-ready Node.js backend.

Want to jump straight to the code? The entire repository is open-source and available here: OP-Prajwal/publicForm

1. The Problem Statement

Building a form for logged-in users is straightforward because you have a user ID. But public forms—like contact pages or recruitment applications—are entirely different.

No Authentication: We don't know who is making the request.
Shared Wi-Fi: We can't strictly ban an IP address permanently without risking locking out an entire dorm room or office of legitimate users.
Bot Spam: Within hours of going live, bots will find your endpoint and try to drop malicious payloads or thousands of fake entries.
The Impatient User: A real human on a laggy 3G connection clicks "Submit", nothing happens instantly, so they furiously click "Submit" six more times. Without safeguards, you now have six identical records in your database.

2. The High-Level Architecture

To solve all of this, we need a layered defense. We can't rely on just a CAPTCHA or just an IP limit. The architecture acts like a funnel, rejecting bad actors at the cheapest possible computing layer before allowing data into the database structure.

Interactive architecture diagram available on Eraser.io

The Pipeline:
User → Rate Limiter → CAPTCHA → Idempotency Check → Token Validation → Database

3. Step-by-Step Request Flow

Here is the exact sequence of events when a user interacts with our system:

User loads the form: The React frontend silently makes a GET request to the backend.
Server generates a secure token: The backend generates a Cryptographically Secure Pseudorandom (CSPRNG) token, saves it to the database, and sends it to the frontend.
User submits the form: The user fills the data, solves the CAPTCHA silently, and hits submit. The frontend generates a unique UUID (the Idempotency Key) and sends everything to the server.
Rate limiting: Express middleware checks if this IP is making too many requests too fast.
CAPTCHA validation: The controller immediately asks Cloudflare if the human actually solved the challenge.
Idempotency check: The database checks if this exact UUID has been seen recently.
Token validation (atomic): The backend verifies the CSPRNG token is valid and immediately burns it so it can never be used again.
Store in DB: Only after surviving this is the data finally inserted into the database.

4. Implementation Details in Node.js

Let's look at how we actually built this backend. We utilized an Express.js middleware-based architecture to keep our routing clean:

router.post("/submit", formLimiter, submitForm);

Behind the scenes:

Token Generation: We used Node's native crypto library to generate tokens (crypto.randomBytes(32).toString('hex')).
Idempotency: When the user clicks submit, the client generates a key using crypto.randomUUID(). We store this key in an Idempotency MongoDB collection.
Atomic Validation: We execute findOneAndUpdate() in Mongoose to verify and "burn" the token in the exact same database operation to prevent race conditions.

5. CSPRNG Tokens: Why Randomness Matters

A session token is only as good as its un-guessability. If you generate tokens using something predictable like Math.random() or a timestamp, a sophisticated bot script can mathematically guess the next token your server will issue, completely bypassing the requirement to load your frontend.

By using a CSPRNG (Cryptographically Secure Pseudorandom Number Generator), we lean on the operating system's entropy pool. It is practically impossible for an attacker to predict a 32-byte hex string.

6. Idempotency Keys: Taming the Double-Click

Idempotency is just a fancy word for a simple concept: doing the exact same thing twice should yield the same result without causing side effects.

When our user double-clicks "Submit", two identical network requests fire simultaneously. Both carry the exact same payload and the exact same idempotencyKey UUID generated by React.

When the backend receives the first request, it logs the key with a status of PROCESSING. If the second request arrives, our system recognizes the UUID and drops the duplicate request without inserting a cloned record into the main database.

7. Defeating Race Conditions

Idempotency sounds easy until you encounter concurrency.

Imagine those two identical requests hit the Node.js server at the exact same microsecond. Both queries check the database. Both queries see that the Idempotency Key doesn't exist yet. Both queries try to insert the record.

If we handled this with standard Javascript if/else logic, both would succeed. To fix this natively, we don't need complex database transactions. We rely on the database layer to act as our atomic lock.

In MongoDB (Mongoose)

We literally just add a unique: true index to the Idempotency Key in our schema:

const idempotencySchema = new mongoose.Schema({
  key: {
    type: String,
    unique: true, // MongoDB enforces atomicity here
    required: true,
  },
  status: { type: String, default: "PROCESSING" }
});

The first request successfully claims the lock and inserts the record. The second concurrent request is instantly slapped down by MongoDB throwing an E11000 Duplicate Key Error. We catch that error in our backend and safely drop the duplicate. Race condition solved.

In SQL (PostgreSQL / MySQL)

If you are building this in a relational database, the exact same principle applies. You create a UNIQUE constraint on the column:

CREATE TABLE idempotency_locks (
    key UUID PRIMARY KEY,
    status VARCHAR(20) DEFAULT 'PROCESSING'
);

-- Or adding it to an existing table:
ALTER TABLE idempotency_locks ADD CONSTRAINT unique_idemp_key UNIQUE (key);

When two identical INSERT commands execute at the exact same time, the first one writes the row, and the database engine blocks the second one from executing, instantly throwing a Unique Violation Error (e.g., Code 23505 in Postgres).

8. Rate Limiting: The Outer Shield

If we have all of these protections, why do we still need Rate Limiting?

Because database queries cost CPU cycles. If a malicious script attempts to submit 5,000 forms a second using fake CAPTCHAs and fake tokens, your Node server is going to spend all of its resources connecting to MongoDB just to reject them.

The Rate Limiter (express-rate-limit) sits at the very outer edge of the middleware. If an IP exceeds 20 requests a minute, it gets blocked entirely before the Node controller even parses the JSON payload.

9. CAPTCHA: The Bouncer

Why is the CAPTCHA validation the very first thing we do inside the main controller?

We use Cloudflare Turnstile to verify humans. Pinging Cloudflare's API is vastly cheaper and safer for our server than running multiple MongoDB queries. If the payload arrives with a missing or invalid CAPTCHA token, we immediately drop the request with a 400 Bad Request. We don't bother checking Idempotency. We don't bother checking the CSPRNG token.

If you aren't human, you don't get past the lobby.

10. The Final System Flow Summarized

When you step back, the elegance of the system reveals itself. We built a heavily guarded fortress for a simple form payload:

CAPTCHA (Is it a bot?) → Rate Limit (Is it spamming?) → Idempotency (Is it a double-click duplicate?) → Token (Is it a forged, headless request?) → Database (Safe and clean).

11. Key Learnings: Layered Defense

The biggest takeaway from building this is the concept of layered defense.

No single security measure is flawless. Rate limits can be bypassed using VPNs or distributed botnets. CAPTCHAs can occasionally be solved by advanced solvers. Tokens can be harvested. But when you stack them sequentially, the cost and difficulty for an attacker skyrocket exponentially. Real-world backend thinking is about assuming every single layer will eventually fail—and ensuring the layer behind it is ready to catch the mistake.

12. Conclusion

What started as an innocent HTML form transformed into a massive system design problem. Public-facing endpoints are arguably some of the most difficult pieces of infrastructure to secure properly because you have absolutely zero trust in the client interacting with it.

If you are just building a quick side project, a simple reCAPTCHA might be enough. But if you want to build at enterprise grade, learning how to juggle atomic databases, idempotency keys, and session validation is invaluable. It shifts your mindset from "How do I make this work?" to "How do I make this unbreakable?"

Making a Public Form Secure: Tokens, Idempotency & Real-World Backend Design

Prajwal Gaonkar — Thu, 19 Mar 2026 06:46:00 +0000

I thought building a form was easy… until I tried making it secure.

While designing a recruitment form for a college club, I realized that the real challenge is not collecting data — it is making sure the system behaves correctly under real-world conditions.

Let’s walk through how I approached this problem step by step.

Understanding the Problem

The form was public. Users could submit it using:

Mobile data
College Wi-Fi

A common beginner approach is to block users based on IP address after submission.

At first glance, this seems reasonable.

But in real-world networks, especially Wi-Fi, multiple users share the same public IP due to NAT.

100 users → 1 IP

If we block that IP, we end up blocking everyone connected to that network.

Clearly, this approach fails.

Solution 1 — IP-Based Blocking

The idea

Track submissions by IP
Block further requests from the same IP

Why it seems useful

Simple to implement
Works in small, isolated environments

Drawbacks

Breaks in shared networks (Wi-Fi, offices, colleges)
Blocks legitimate users
Not reliable in real-world systems

Solution 2 — One-Time Form Tokens

The idea

When a user loads the form, the server generates a unique token
The token is sent to the client
On submission, the server validates and marks the token as used

Why it works

Prevents duplicate submissions
Stops accidental double clicks
Prevents replaying the same request

Drawbacks

Users can reload the page and get a new token
Bots can repeatedly request new tokens
Does not prevent automated spam

Solution 3 — Idempotency Keys

The idea

Each logical request is assigned a unique idempotency key
The server stores the key along with the response
If the same key is used again, the server returns the stored response instead of processing the request again

Example

POST /submit
Idempotency-Key: abc123

Why it works

Prevents duplicate processing
Handles retries safely
Ensures operations execute only once

Drawbacks

Requires additional storage (Redis/DB)
Needs careful handling of request validation
Does not stop bots generating new requests with new keys

Solution 4 — Honeypot Fields

The idea

Add a hidden input field that users cannot see
Bots often fill all fields automatically
If this field is filled, reject the request

Why it works

Very simple to implement
Effectively blocks basic bots

Drawbacks

Advanced bots can bypass it
Not sufficient as a standalone solution

Solution 5 — CAPTCHA

The idea

Verify that the user is human before accepting submission

Examples

“I am not a robot”
Google reCAPTCHA
Cloudflare Turnstile

Why it works

Blocks most automated scripts
Adds a strong verification layer

Drawbacks

Slight friction for users
Can impact user experience if overused

Final Thoughts

What started as a simple form turned into a lesson in backend system design.

The biggest takeaway is:

There is no single solution.

Real systems use layered protection:

IP awareness (but not reliance)
Tokens for request validation
Idempotency for safe retries
Honeypots for bot detection
CAPTCHA for human verification

Each layer solves a different problem.

Even a simple public form can reveal how real-world systems are designed to handle scale, failures, and abuse.