DEV Community: Amrishkhan Sheik Abdullah

Promise.all() Is Not Parallelism — And It Can Break Your System

Amrishkhan Sheik Abdullah — Sat, 09 May 2026 06:56:00 +0000

Promise.all() looks innocent.

It is one of those JavaScript features most developers learn early and start using everywhere.

Fetch multiple APIs? Use Promise.all().

Insert multiple rows? Use Promise.all().

Upload multiple files? Use Promise.all().

Call GitHub API for many blobs? Use Promise.all().

At first, it feels clean.

await Promise.all(items.map(item => processItem(item)));

One line. Beautiful. Fast. Modern.

But here is the uncomfortable truth:

Promise.all() is not a performance strategy. It is a concurrency trigger.

And if you use it blindly, it can quietly break your system.

The Problem Is Not Promise.all() Itself

Promise.all() is not bad.

It is useful, powerful, and perfectly fine when the number of promises is small and controlled.

The problem starts when developers use it like this:

await Promise.all(users.map(user => sendEmail(user)));

Looks harmless.

But what if users.length is:

Now the same line behaves very differently.

That one line can suddenly create:

1,000 API requests
1,000 database queries
1,000 file operations
1,000 network connections
1,000 memory allocations

All at once.

That is where systems start to fail.

Promise.all() Does Not Mean “Run Safely in Parallel”

This is the biggest misunderstanding.

A lot of developers think:

“Promise.all() runs things in parallel.”

Not exactly.

JavaScript does not magically create safe parallel execution for your workload.

What actually happens is:

all async operations are started immediately
JavaScript keeps references to all promises
the runtime waits until all resolve
if one rejects, Promise.all() rejects immediately

That means Promise.all() does not control load.

It does not limit concurrency.

It does not respect API rate limits.

It does not care about your database pool.

It does not protect your server memory.

It simply starts everything.

The Hidden Cost of Starting Everything at Once

Let’s say you are processing 5,000 records.

await Promise.all(
  records.map(record => processRecord(record))
);

This may look efficient.

But internally, you might be doing:

async function processRecord(record: RecordItem) {
  const user = await db.user.findUnique({
    where: { id: record.userId }
  });

  const response = await externalApi.send(user);

  await db.auditLog.create({
    data: response
  });
}

Now multiply that by 5,000.

Suddenly you are not just running 5,000 promises.

You may be creating:

5,000 DB reads
5,000 external API calls
5,000 audit log writes
thousands of objects in memory
thousands of open sockets

This is not optimization.

This is a traffic accident.

1. Concurrency Explosions

A concurrency explosion happens when your code starts more async work than the system can safely handle.

The dangerous part is that the code often looks clean.

await Promise.all(files.map(uploadFile));

But if there are 2,000 files, you just started 2,000 uploads.

A better question is not:

“Can JavaScript run this?”

The better question is:

“Can every system behind this operation handle it?”

Because your code may depend on:

database pool limits
third-party API limits
CPU availability
memory capacity
disk I/O
network stability
cloud provider throttling

Promise.all() ignores all of that.

2. Rate Limiting Problems

Third-party APIs usually do not like sudden request spikes.

If you call an API 500 times at once, you may hit:

429 Too Many Requests
temporary bans
request throttling
degraded responses
random timeouts

Example:

await Promise.all(
  users.map(user => paymentProvider.createCustomer(user))
);

This may work in development with 5 users.

Then fail badly in production with 5,000 users.

The code did not change.

The data size did.

That is why Promise.all() bugs often appear only under real traffic.

3. Memory Spikes

Promise.all() keeps track of all promises and their results.

If each result is small, that is fine.

But if each operation returns a large object, file buffer, API response, or parsed payload, memory usage can spike quickly.

Example:

const results = await Promise.all(
  largeFiles.map(file => readAndParseFile(file))
);

If each parsed file is 20 MB and you process 100 files, you may suddenly hold gigabytes of data in memory.

That can lead to:

slow garbage collection
process crashes
container restarts
server instability
out-of-memory errors

Sometimes the safer solution is to process data in batches or streams instead of loading everything together.

4. Database Connection Exhaustion

This one is extremely common.

Most databases use connection pools.

For example, your app may have a pool limit of 10, 20, or 50 connections.

Now imagine doing this:

await Promise.all(
  orders.map(order =>
    db.order.update({
      where: { id: order.id },
      data: order
    })
  )
);

If orders.length is 1,000, your code tries to schedule 1,000 DB operations immediately.

But your database pool may only support 20 active connections.

The rest wait.

Then things start piling up.

You may see:

connection timeout
slow queries
locked rows
deadlocks
pool exhaustion
failed transactions

Again, Promise.all() is not aware of your database limit.

It will happily overload it.

5. API Throttling and Socket Errors

I faced a real version of this while working with GitHub APIs.

Creating blobs through the GitHub API looked simple at first.

The tempting version was:

await Promise.all(
  files.map(file => github.createBlob(file))
);

Clean, yes. Safe, no.

With many files, this could trigger network instability, throttling, or random failures such as:

socket hang up
write EPIPE
ECONNRESET
request timeout
temporary GitHub API failures

The fix was not to “make Promise.all better.”

The fix was to stop launching everything at once.

Instead, the safer approach was:

limit concurrency
process files in small batches
retry only retryable failures
fail fast for validation errors
avoid retrying 400 Bad Request
use exponential backoff
reduce concurrent blob creation

That changed the mindset completely.

The goal was no longer:

“How do I make this as parallel as possible?”

The goal became:

“How do I make this fast enough without destroying reliability?”

That is the real engineering question.

6. Retries Can Make the Problem Worse

Retries sound like a solution.

But careless retries can multiply the damage.

Imagine this:

await Promise.all(
  requests.map(request =>
    retry(() => callApi(request))
  )
);

If 500 requests fail due to rate limiting, and each one retries 3 times, you may have created 1,500 more requests.

Now your retry logic is attacking the same system that already asked you to slow down.

Retries need discipline.

Good retry logic should consider:

which errors are retryable
how many times to retry
how long to wait
whether to use exponential backoff
whether to add jitter
whether the API returned 429
whether the operation is idempotent

Not every error deserves a retry.

if (error.status === 400) {
  throw error;
}

Retrying bad requests only wastes time and increases load.

7. Partial Failures Are Harder Than They Look

Another issue with Promise.all() is failure behavior.

If one promise rejects, Promise.all() rejects.

await Promise.all([
  uploadFile(file1),
  uploadFile(file2),
  uploadFile(file3),
]);

If file2 fails, the entire Promise.all() rejects.

But what about file1 and file3?

They may have already completed.

Now your system is in a partial success state.

This matters when you are doing things like:

payment operations
database writes
file uploads
email sending
inventory updates
GitHub commits
external integrations

You need to ask:

“If 7 out of 10 operations succeed, what should happen?”

Should you rollback?

Should you retry only failed items?

Should you show partial success?

Should you store failed records for later?

Promise.all() does not answer those questions.

Your architecture has to.

Promise.allSettled() Is Better for Partial Results

When you care about every result, use Promise.allSettled().

const results = await Promise.allSettled(
  files.map(file => uploadFile(file))
);

Then separate success and failure.

const successful = results.filter(
  result => result.status === "fulfilled"
);

const failed = results.filter(
  result => result.status === "rejected"
);

This gives you a complete picture.

But remember:

Promise.allSettled() solves visibility. It does not solve concurrency.

It still starts everything at once.

The Better Pattern: Limit Concurrency

Instead of launching everything together, process with a concurrency limit.

async function processInBatches<T, R>(
  items: T[],
  batchSize: number,
  handler: (item: T) => Promise<R>
): Promise<R[]> {
  const results: R[] = [];

  for (let i = 0; i < items.length; i += batchSize) {
    const batch = items.slice(i, i + batchSize);

    const batchResults = await Promise.all(
      batch.map(item => handler(item))
    );

    results.push(...batchResults);
  }

  return results;
}

Usage:

const results = await processInBatches(
  files,
  5,
  uploadFile
);

Now instead of 1,000 uploads at once, you run 5 at a time.

That is slower than unlimited concurrency.

But it is much safer.

And in production, safe usually wins.

Queue Patterns Are Even Better for Heavy Workloads

For large or long-running workloads, batching may still not be enough.

A queue-based approach is often better.

A queue gives you:

controlled concurrency
retry policies
delayed jobs
observability
pause/resume behavior
backpressure
better recovery

Instead of:

await Promise.all(items.map(processItem));

You can push jobs into a queue:

for (const item of items) {
  await queue.add("process-item", item);
}

Then workers process with controlled concurrency:

const worker = new Worker(
  "process-item",
  async job => {
    await processItem(job.data);
  },
  {
    concurrency: 5,
  }
);

That is a much healthier model for serious workloads.

When Promise.all() Is Actually Fine

This article is not saying never use Promise.all().

It is perfectly fine when:

the number of items is small
the workload is predictable
there are no strict rate limits
memory usage is low
failures should fail the whole operation
all operations are independent

Example:

const [user, settings, permissions] =
  await Promise.all([
    getUser(userId),
    getSettings(userId),
    getPermissions(userId),
  ]);

This is a good use case.

The danger starts when the number of promises is dynamic and unbounded.

A Simple Rule I Follow Now

Before using Promise.all(), I ask:

“How many promises can this create in production?”

If the answer is:

3
5
10

Fine.

If the answer is:

unknown
hundreds
thousands
depends on user input
depends on database size

Then I stop and redesign.

Because at that point, I do not need raw Promise.all().

I need one of these:

batching
concurrency limiting
queue processing
streaming
pagination
retry strategy
backpressure handling
partial failure tracking

The Real Lesson

Promise.all() is not dangerous because it is broken.

It is dangerous because it is too easy.

It makes risky concurrency look elegant.

It hides operational complexity behind a beautiful one-liner.

But production systems do not care how clean your code looks.

They care about:

load
limits
memory
failure modes
retries
recovery
reliability

The best engineers do not just ask:

“Can I run these together?”

They ask:

“How much concurrency can this system safely handle?”

That is the difference between writing async code and designing resilient systems.

Final Thought

Promise.all() is a tool.

A very useful one.

But it should not be your default answer for every async workload.

Sometimes the fastest code is the code that finishes first in development.

But the best code is the code that survives production.

Use Promise.all() when the work is small and controlled.

Use queues, batches, and concurrency limits when the system matters.

Because Promise.all() is not parallelism.

It is pressure.

And if you do not control that pressure, your system eventually will.

About the Author

I’m Amrish Khan — a full-stack engineer focused on building fast, privacy-conscious, developer-first applications.

I’m currently exploring the future of:

local-first developer tooling
browser-native processing
AI-efficient workflows
offline-capable applications
privacy-focused architectures

I’m also building Aruvix — a growing ecosystem of local-first developer tools designed to process data directly in the browser without unnecessary uploads.

You can follow my work and thoughts here:

Portfolio: amrishkhan.dev
LinkedIn: linkedin.com/in/amrishkhan

Why I’m Building Local-First Developer Tools

Amrishkhan Sheik Abdullah — Fri, 08 May 2026 15:26:21 +0000

The Industry Is Quietly Rebalancing Toward Local-First Applications

There’s a strange irony happening in software right now.

The Industry Is Quietly Rebalancing Toward Local-First Applications

There’s a strange irony happening in software right now.

For years, the industry pushed everything toward the cloud.

Cloud IDEs. Cloud databases. Cloud storage. Cloud AI. Cloud editors. Cloud collaboration. Cloud “smart” everything.

Somewhere along the way, we normalized sending enormous amounts of personal, sensitive, and often unnecessary data across the internet for even the smallest tasks.

Need to format JSON? Upload it.

Need to compare two files? Upload them.

Need to test an API? Upload the request history.

Need AI help? Send your codebase.

Need productivity? Give another app permanent access to your life.

And most developers accepted this because, honestly, we got used to convenience.

But over the last few years, I started noticing something: the more “cloud-native” our tools became, the slower, heavier, more invasive, and more expensive they started feeling.

That realization is one of the biggest reasons I started building local-first developer tools. Not because it sounds trendy, but because I genuinely think the industry is starting to realize that cloud-everything might not actually be the ideal future we imagined.

What “Local-First” Actually Means

A lot of people misunderstand local-first architecture.

It does not mean:

no internet
outdated desktop software
isolated systems
anti-cloud ideology

Local-first simply means:

Your device becomes the primary place where computation happens.

The browser. Your machine. Your storage. Your CPU. Your memory.

The cloud becomes optional infrastructure, not the center of your entire digital existence. That changes everything.

The Browser Became Far More Powerful Than Most People Realize

Modern browsers are ridiculously capable now.

Today, browsers can:

process massive JSON files
run databases
execute AI models
compress files
render large editors
stream data
run WASM applications
perform encryption
manipulate media
cache huge datasets
work offline
run local transformations

In many cases, browsers are now powerful enough to replace entire categories of backend-heavy applications.

But many tools still behave like it’s 2014. Every button triggers a network request. Every feature requires an API. Every interaction depends on a server somewhere.

And that creates problems developers are finally starting to feel.

Cloud-Everything Has a Cost Nobody Talks About

Cloud architecture solved many important problems, but it also introduced a completely different set of problems we rarely discuss openly.

Many modern systems genuinely require:

distributed infrastructure
observability
collaboration
auditability
synchronization
enterprise orchestration

But we’ve also normalized using cloud infrastructure for workflows that often don’t benefit from it at all. That distinction matters.

Privacy Became an Afterthought

This is one of the biggest issues.

Developers routinely paste:

production payloads
API keys
customer data
logs
authentication tokens
internal configs
business documents

...into random online tools.

Not because they’re careless. Because the industry normalized it.

But once your data leaves your machine, you lose a level of control over it. Even if a service claims:

“We do not store your data”

The data was still transmitted. That matters.

Especially for:

enterprise systems
healthcare
finance
aviation
internal tooling
government systems

One of the core ideas behind local-first tooling is simple:

Many developer tasks never needed the cloud in the first place.

Formatting JSON should not require uploading private payloads. Diffing files should not require transmission. Testing APIs should not require syncing your entire workspace to a remote account.

Local-first applications do not automatically make software “secure,” but they do minimize unnecessary exposure surfaces. In many workflows, that’s a meaningful improvement.

Performance Is Quietly Getting Worse

Many modern applications feel slower than older software despite massive hardware improvements.

Why?

Because modern apps often depend on:

authentication layers
analytics tracking
remote synchronization
telemetry
server-side processing
feature flags
subscriptions
multiple API chains

Sometimes a simple interaction travels halfway across the world before returning to your screen. That creates avoidable latency.

For many single-user workflows, local-first applications eliminate that overhead completely. No upload step. No waiting for server processing. No unnecessary round trips.

The difference becomes especially obvious with developer tooling. A large JSON formatter is a perfect example: uploading massive payloads to a server just to reformat text is often slower than processing directly in the browser. The browser already has the data. Why move it?

Offline Capability Is Massively Underrated

We built an industry where software often stops functioning the moment connectivity drops. That’s a surprisingly fragile model.

Developers work:

on flights
in trains
inside unstable networks
in VPN-heavy environments
during outages
inside restricted enterprise systems

Yet many modern applications become unusable offline.

Local-first apps flip that model. The application works first. Connectivity enhances it. That distinction matters.

Offline capability is not just about convenience. It’s about:

resilience
continuity
graceful degradation
reliability

The best tools should not collapse entirely because a server became unavailable.

AI Is Quietly Making Local Processing More Important

This is the part I think most people are underestimating.

AI changes the economics of software dramatically.

Every unnecessary cloud operation now has:

compute cost
token cost
latency cost
inference cost

And developers are starting to notice it.

Many AI workflows today are incredibly wasteful. Huge payloads get sent to LLMs when only tiny transformations were actually needed.

People are burning tokens on:

formatting data
restructuring objects
validating syntax
converting formats
cleaning logs
filtering payloads

...for operations that should often happen locally before AI is even involved.

This is where local-first architecture becomes extremely powerful.

Imagine:

local preprocessing
local parsing
local filtering
local compression
local semantic chunking

before AI requests even happen.

You reduce:

token usage
API costs
response times
hallucination surfaces
unnecessary context size

Local-first preprocessing does not replace cloud AI, but it dramatically improves how efficiently AI gets used. In the AI era, that becomes an economic advantage.

Browser-Native Processing Is the Future

I genuinely believe we’re entering an era where the browser becomes the operating system for a huge class of applications.

Not because servers disappear, but because browsers became capable enough to own far more responsibility.

The old model was:

Browser → Server → Processing → Response

The emerging model is:

Browser → Local Processing → Optional Cloud Enhancement

That shift changes product architecture completely.

Not every workload belongs in the browser, but far more workloads can now run there efficiently than most applications currently allow.

Real Examples of Where Local-First Makes Sense

JSON Formatting

Traditional flow:

upload payload
process on server
return formatted response

Local-first flow:

process entirely in browser
no upload
instant feedback
no privacy concerns

API Testing

Instead of syncing everything to the cloud:

request history can stay local
collections can stay encrypted locally
sync can become optional

AI Workflows

Instead of sending raw noisy payloads directly to AI:

preprocess locally
filter irrelevant data
compress context
chunk intelligently

Then send only meaningful information to the model.

That reduces:

token waste
AI costs
latency
context overload

Local-First Does NOT Mean Anti-Cloud

This part is important.

I’m not anti-cloud.

The cloud is incredible for:

collaboration
backups
synchronization
distributed systems
scalable APIs
team workflows
shared state
large-scale AI inference

But not every operation deserves cloud involvement.

The future probably isn’t fully cloud or fully local. It’s hybrid.

Smart systems will decide:

what should stay local
what should sync
what should process remotely
what should never leave the device

That’s where things get exciting.

Developers Are Starting to Care Again

You can already see the shift happening.

Developers increasingly care about:

ownership
privacy
low-latency tooling
offline workflows
AI efficiency
minimalism
local control

People are getting tired of:

unnecessary subscriptions
forced accounts
cloud lock-in
telemetry overload
bloated apps
“AI-enhanced” features nobody asked for

There’s a growing desire for tools that simply:

open fast, work fast, respect privacy, and stay out of the way.

That’s not nostalgia. That’s good engineering.

Why This Became My Direction

When building tools like:

JSON formatters
API utilities
diff tools
transformers
developer workflows

...I kept asking myself:

“Does this operation truly need a server?”

In many cases, the answer was no.

That question slowly evolved into a philosophy. A local-first mindset.

A belief that developer tools should:

respect the user’s machine
minimize unnecessary transmission
reduce dependency chains
process data where it already exists
optimize for responsiveness
preserve ownership

That philosophy now shapes almost everything I build.

The Industry Isn’t Moving Backward — It’s Rebalancing

I don’t think the future is less connected. I think the future is becoming more intentional about connectivity.

We spent years pushing computation away from users.

Now we’re starting to realize: modern devices are incredibly powerful, modern browsers are incredibly capable, and users increasingly want more control back.

Local-first applications are not a step backward. They’re the next correction.

And honestly, I think we’re only at the beginning of that shift.

About the Author

I’m Amrish Khan — a full-stack engineer focused on building fast, privacy-conscious, developer-first applications.

I’m currently exploring the future of:

local-first developer tooling
browser-native processing
AI-efficient workflows
offline-capable applications
privacy-focused architectures

I’m also building Aruvix — a growing ecosystem of local-first developer tools designed to process data directly in the browser without unnecessary uploads.

Here's a detailed blog on Aruvix: Read More

You can follow my work and thoughts here:

Portfolio: amrishkhan.dev
LinkedIn: linkedin.com/in/amrishkhan

Final Thoughts

The future isn’t cloud-only. The future is intentional computing.

Faster where possible. Local where meaningful. Cloud where necessary.

The Most Underestimated Function in JavaScript: `reduce()`

Amrishkhan Sheik Abdullah — Fri, 08 May 2026 06:01:54 +0000

Most Developers Meet `reduce()` at the Wrong Time

Usually, it happens through some terrifying one-liner like this:

const result = arr.reduce((a, b) => a + b, 0)

And the immediate reaction is:

"Why not just use a loop?"

Fair question.

Because honestly, most tutorials completely fail to explain what reduce() actually is.

They usually teach:

sum of array values
average calculation
maybe grouping

But they never explain the real thing.

reduce() is not a math utility.

It is one of the most powerful state transformation primitives in JavaScript.

Once you truly understand it, you start seeing it everywhere:

Redux reducers
React state management
parsers
compilers
async pipelines
aggregation systems
permission engines
data normalization
event processing

This article is not another "sum array values" tutorial.

We are going deep into:

how reduce() actually works internally
why developers struggle with it
how it differs from map(), forEach(), and loops
simple examples
advanced real-world patterns
performance considerations
readability tradeoffs
when not to use it

By the end, reduce() will stop feeling magical and start feeling obvious.

What `reduce()` Actually Means

Forget syntax for a second.

The real meaning is:

Take many values and progressively transform them into one value.

That "one value" can be anything:

object
array
tree
promise chain
lookup map
grouped structure
state machine
cache
HTML
SQL query
dependency graph

The important part is this:

reduce() evolves state step by step.

That is the key mental model.

How `reduce()` Actually Works

array.reduce((accumulator, currentItem) => {
  return updatedAccumulator
}, initialValue)

Let’s slow this down properly.

Visualizing the Flow

const numbers = [1, 2, 3, 4]

const total = numbers.reduce((sum, current) => {
  return sum + current
}, 0)

Iteration flow:

// Initial state
sum = 0

// Iteration 1
current = 1
sum = 0 + 1 // 1

// Iteration 2
current = 2
sum = 1 + 2 // 3

// Iteration 3
current = 3
sum = 3 + 3 // 6

// Iteration 4
current = 4
sum = 6 + 4 // 10

Final result:

What Makes `reduce()` Different?

The accumulator survives between iterations.

That is the entire magic.

Unlike map() or forEach(), reduce() carries evolving state forward.

That makes it fundamentally more powerful.

`reduce()` vs `map()`

`map()`

map() transforms items independently.

const doubled = [1, 2, 3].map(x => x * 2)
// [2, 4, 6]

Each item has no awareness of previous items.

`reduce()`

reduce() remembers previous iterations.

const runningTotal = [1, 2, 3].reduce((sum, x) => {
  return sum + x
}, 0)
// 6

The result depends on previous state.

That is a completely different concept.

`reduce()` vs `forEach()`

`forEach()`

forEach() is side-effect oriented.

const result = []

users.forEach(user => {
  result.push(user.name)
})

You mutate external state.

`reduce()`

reduce() keeps transformation self-contained.

const result = users.reduce((acc, user) => {
  acc.push(user.name)
  return acc
}, [])

That becomes:

more composable
more predictable
easier to refactor
easier to test

Why Developers Fear `reduce()`

Because most examples are terrible.

For example:

arr.reduce((a, b) => ({ ...a, [b.id]: b }), {})

This is:

hard to read
allocates objects repeatedly
hides intent
looks academic

So developers conclude:

"reduce is unreadable"

No. Bad reducers are unreadable.

Good reducers are incredibly expressive.

The Golden Rule of `reduce()`

The accumulator should represent evolving state clearly.

Bad:

(a, b)

Good:

(usersById, user)

Naming changes everything.

Simple Real-World Example: Grouping Data

Suppose you have:

const users = [
  { name: "John", role: "admin" },
  { name: "Sarah", role: "user" },
  { name: "Mike", role: "admin" }
]

You want:

{
  admin: [
    { name: "John", role: "admin" },
    { name: "Mike", role: "admin" }
  ],
  user: [
    { name: "Sarah", role: "user" }
  ]
}

Traditional Loop

const grouped = {}

for (const user of users) {
  if (!grouped[user.role]) {
    grouped[user.role] = []
  }

  grouped[user.role].push(user)
}

Using `reduce()`

const grouped = users.reduce((groups, user) => {
  if (!groups[user.role]) {
    groups[user.role] = []
  }

  groups[user.role].push(user)
  return groups
}, {})

The intent becomes:

Transform users into a grouped structure.

That is much more declarative.

Why This Scales Better Mentally

In large applications, most code is not business logic.

Most code is about:

reshaping APIs
transforming data
aggregating state
building structures

reduce() becomes extremely useful there.

Advanced Example: Permission Engine

Imagine RBAC permissions.

Input:

const permissions = [
  { screen: "sales", action: "view" },
  { screen: "sales", action: "edit" },
  { screen: "inventory", action: "delete" }
]

Desired output:

{
  sales: {
    view: true,
    edit: true
  },
  inventory: {
    delete: true
  }
}

Using reduce():

const permissionMap = permissions.reduce((map, permission) => {
  if (!map[permission.screen]) {
    map[permission.screen] = {}
  }

  map[permission.screen][permission.action] = true
  return map
}, {})

Now permission checks become:

permissionMap.sales.edit

Which is:

extremely fast
scalable
easy to cache

This is where senior engineers start appreciating reducers deeply.

`reduce()` Can Build Trees

Example input:

const categories = [
  { id: 1, parent: null, name: "Electronics" },
  { id: 2, parent: 1, name: "Phones" },
  { id: 3, parent: 1, name: "Laptops" }
]

You can reduce this into a hierarchical structure.

This is how many CMS systems work internally.

Async Power: Sequential Promise Execution

One of the coolest reduce() patterns:

tasks.reduce(async (previousTask, currentTask) => {
  await previousTask
  return currentTask()
}, Promise.resolve())

This forces tasks to execute sequentially.

Useful for:

rate-limited APIs
database migrations
ordered workflows
queue systems

Most developers never realize reduce() can do this.

The Biggest Misconception

People think:

"reduce is just a shorter loop"

No.

That is not the point.

The point is:

reduce() centralizes transformation logic into a predictable state evolution flow.

That is a huge architectural difference.

Performance Discussion

Is `reduce()` Faster?

Not automatically.

Sometimes a plain loop is faster.

For example:

for (let i = 0; i < arr.length; i++) {
  // work
}

can outperform:

arr.reduce(...)

in tight benchmarks.

But real-world engineering is not usually microbenchmark-driven.

The real advantages are:

composability
maintainability
predictability
transformation clarity

Where `reduce()` Becomes Extremely Useful

1. Single-pass transformations

Instead of:

arr.filter(...).map(...).sort(...)

you can sometimes do:

arr.reduce(...)

in one pass.

Less iteration. Less memory allocation.

2. Avoiding temporary arrays

map() creates arrays.

filter() creates arrays.

reduce() can avoid that.

3. Data normalization

Huge backend and frontend systems constantly normalize data.

Reducers are excellent for this.

But Don’t Abuse It

This is critical.

Not everything should become a reducer.

Bad:

const names = users.reduce((acc, user) => {
  acc.push(user.name)
  return acc
}, [])

Cleaner:

const names = users.map(user => user.name)

Use the simplest tool possible.

Senior developers do not worship reduce().

They respect where it fits.

A Good Rule of Thumb

Use reduce() when:

the output shape differs from the input
the transformation depends on previous state
you are building lookup structures
you are aggregating data
you are composing workflows

Avoid it when:

map() is clearer
filter() is clearer
a loop is simpler
readability suffers

Why Senior Engineers Love It

Because eventually you realize:

Most software engineering is state transformation.

And reduce() is one of the cleanest abstractions for expressing state evolution.

That is why reducers appear everywhere:

React reducers
Redux
compiler passes
parsers
stream processing
aggregation engines
event sourcing
CQRS systems

Even databases conceptually perform reduction-like operations internally.

Final Thoughts

reduce() is underestimated because developers are introduced to it too early and explained too poorly.

People memorize syntax before understanding the idea.

Once you understand this:

reduce() evolves state across a sequence

everything changes.

You stop seeing it as:

confusing syntax
functional programming gimmick
"smart developer code"

and start seeing it for what it really is:

A foundational data transformation primitive.

And honestly? Once it clicks, you begin noticing reducers everywhere in software architecture.

About the Author

I’m Amrish Khan — a full-stack engineer focused on building fast, privacy-conscious, developer-first applications.

I’m currently exploring the future of:

local-first developer tooling
browser-native processing
AI-efficient workflows
offline-capable applications
privacy-focused architectures

I’m also building Aruvix — a growing ecosystem of local-first developer tools designed to process data directly in the browser without unnecessary uploads.

Here's a detailed blog on Aruvix: Read More

You can follow my work and thoughts here:

Portfolio: amrishkhan.dev
LinkedIn: linkedin.com/in/amrishkhan

Why I Built Aruvix — One Local-First Toolkit for Every Developer Workflow

Amrishkhan Sheik Abdullah — Thu, 07 May 2026 07:08:08 +0000

A privacy-first, offline-first toolkit for JSON formatting, API testing, schema generation, frontend workflows, QA tooling, and developer productivity.

Official Website: https://www.aruvix.com

Aruvix is a powerful, privacy-first, browser-based suite of developer tools designed to keep your workflows fast, secure, and entirely local. Built for developers who are tired of juggling dozens of disconnected online utilities, Aruvix brings everything into one unified workspace.

Whether you are formatting complex JSON, testing APIs, comparing payloads, generating schemas, converting formats, or debugging responses, Aruvix helps you do it faster without sacrificing privacy or performance.

And most importantly: don't waste your AI tokens for simple deterministic tasks.

Formatting JSON, decoding JWTs, converting XML, testing regex, or generating schemas should not require sending payloads to expensive LLMs. Aruvix handles these operations instantly inside your browser with zero uploads and zero token consumption.

Why Aruvix? Better than the Alternatives
JSON Formatter
JSON Compare
API Client
Visualize
Schema Generator
Query (JSONPath)
Code Translator
Converter Tools
Dev Tools
Frontend & CSS Tools
QA Tools
Who Is Aruvix For?

Why Aruvix? Better than the Alternatives

Unlike many existing online tools — which often upload sensitive payloads to remote servers — or heavyweight desktop applications that consume massive resources for simple workflows, Aruvix follows an offline-first, browser-local architecture.

Modern developer workflows are fragmented.

One tab for JSON formatting.

Another for API testing.

Another for JWT decoding.

Another for Base64.

Another for YAML conversion.

Another for regex testing.

Eventually your browser becomes a collection of disconnected utilities with inconsistent UX, privacy concerns, ads, rate limits, and slow processing.

Aruvix was built to solve exactly that problem:

One unified toolkit. One consistent workflow. Everything local-first.

What makes it better

Absolute Privacy: Your JSON, API responses, tokens, configs, schemas, and debugging payloads never leave your browser. No hidden uploads. No unnecessary backend processing.
Speed & Efficiency: Most tools execute instantly with zero server round trips. Large payloads are processed locally using optimized browser-native techniques for maximum responsiveness.
Unified Workspace: No need to juggle 15 different websites for formatting, JWT decoding, Base64 encoding, API testing, schema generation, and conversions. Everything exists inside one cohesive environment.
Cost-Effective: Save your AI tokens for actual problem solving instead of wasting them on deterministic formatting and conversion tasks.

Use AI where intelligence is actually needed.

Let tooling handle tooling.

JSON Formatter

🔗 Tool Link: https://www.aruvix.com/json-formatter

The JSON Formatter is the heart of Aruvix, designed to help developers clean, validate, repair, inspect, and minify JSON effortlessly.

Features

Beautify and format JSON
Minify payloads
Validate JSON syntax
Repair malformed structures
Syntax-highlighted editing

Options Available

Tree View for nested exploration
Table View for arrays
Type View for inferred structures
Raw text editing mode

The Aruvix Advantage

Most online JSON formatters struggle with large payloads, freeze on malformed structures, or require uploading sensitive data to external servers.

Aruvix focuses heavily on:

Large payload usability
Responsiveness
Local execution
Repair capabilities
Smooth editing workflows

Everything happens directly inside your browser.

Whether you are debugging API responses, inspecting production logs, validating webhook payloads, or cleaning third-party integrations, the formatter is designed to keep large JSON payloads readable and manageable without slowing down your browser.

Malformed payloads are common when dealing with legacy systems or manually edited responses. Instead of failing immediately, Aruvix attempts to help developers recover and repair invalid structures quickly.

Try the JSON Formatter here:

👉 https://www.aruvix.com/json-formatter

JSON Compare

🔗 Tool Link: https://www.aruvix.com/json-diff

A side-by-side comparison workspace to quickly identify changed values, missing keys, nested differences, and structural mismatches between JSON objects.

Features

Side-by-side editors
Automatic structural comparison
Path-level difference inspection
Difference summaries

Options Available

Added/removed/changed node summaries
Minified vs formatted comparison support
Deep nested object comparison

The Aruvix Advantage

Traditional text diff tools often highlight formatting changes instead of actual data changes.

Aruvix parses JSON structurally and highlights semantic differences only, helping developers identify meaningful changes faster.

This becomes especially useful when comparing:

API responses across environments
Before/after transformation outputs
Webhook payload changes
Configuration differences
Regression testing snapshots

Instead of manually scanning thousands of lines, developers can focus directly on meaningful structural changes.

Try the JSON Compare tool here:

👉 https://www.aruvix.com/json-diff

API Client

🔗 Tool Link: https://www.aruvix.com/api-tester

A lightweight yet powerful REST API client running entirely inside your browser.

Features

Send HTTP requests
Inspect headers, status, and responses
Import cURL commands
Generate OpenAPI documentation
Pre-request and post-request scripting

Options Available

Environment variables
Request collections
Reusable variables
Proxy support for local testing

The Aruvix Advantage

For quick API testing, developers often do not need a massive Electron-based application consuming huge amounts of memory.

Aruvix provides a lightweight alternative focused on:

Speed
Simplicity
Local workflows
Minimal resource usage

Perfect for:

Quick endpoint testing
Internal API debugging
Webhook validation
Authentication testing
Local development workflows
Lightweight request inspection

The goal is not to replace enterprise collaboration platforms, but to provide an extremely fast and focused API workflow for day-to-day engineering tasks.

Aruvix also works great as a lightweight Postman alternative for developers who prefer fast local-first tooling over heavyweight desktop applications.

Try the API Client here:

👉 https://www.aruvix.com/api-tester

Visualize

🔗 Tool Link: https://www.aruvix.com/visualize

Explore deeply nested JSON objects visually through interactive structures and graph-based inspection.

Features

Interactive node graph views
Search across keys and values
JSONPath inspection
Zoom and pan navigation

Options Available

Export/share visual views
Path tracing
Collapsible nested structures

The Aruvix Advantage

Large nested payloads become difficult to understand in raw text form.

The Visualizer transforms deeply nested hierarchies into intuitive visual structures that are significantly easier to inspect and debug.

When payloads become deeply nested, traditional text editors force developers into endless collapsing, scrolling, and searching.

Visualization makes relationships between nodes, arrays, and structures immediately understandable.

Try the Visualizer here:

👉 https://www.aruvix.com/visualize

Schema Generator

🔗 Tool Link: https://www.aruvix.com/schema

Generate JSON Schema definitions directly from sample payloads.

Features

Generate starter schemas
Validate JSON against schemas
Inspect validation failures
Edit generated schemas

Options Available

Copy/download schemas
Validation reports
Rule customization

The Aruvix Advantage

Instead of manually writing large schema definitions, developers can instantly generate standardized contracts from real payload data.

This accelerates:

API documentation
Validation workflows
Contract-first development

This is especially useful when working with:

Frontend/backend contracts
Validation middleware
API documentation
Mock servers
Automated testing pipelines

Developers can bootstrap schema definitions within seconds instead of manually building large validation structures from scratch.

Try the Schema Generator here:

👉 https://www.aruvix.com/schema

Query (JSONPath)

🔗 Tool Link: https://www.aruvix.com/query

Search, filter, and extract values from deeply nested JSON structures using JSONPath expressions.

Features

Run JSONPath queries
Filter arrays
Extract nested values
Inspect matched paths

Options Available

Live query testing
Match highlighting
Result previews
One-click copy support

The Aruvix Advantage

Developers can visually test JSONPath queries against real payloads before integrating them into production systems.

This significantly reduces debugging time and query trial/error cycles.

Useful for extracting:

Nested IDs
Filtered arrays
Deeply buried attributes
Analytics fields
Transformed API responses

Live query testing dramatically reduces iteration time when building backend transformations or frontend selectors.

Try JSONPath Query here:

👉 https://www.aruvix.com/query

Code Translator

🔗 Tool Link: https://www.aruvix.com/code-translator

Convert JavaScript into TypeScript starter code directly inside the browser.

Features

JS → TS conversion
Type inference
Warning generation
Starter migration assistance

Options Available

Auto-run translation
Editable output
Copy/download support

The Aruvix Advantage

The entire conversion process happens locally, ensuring proprietary code never leaves your machine while still accelerating TypeScript migrations.

The translator is designed as a migration accelerator rather than a perfect one-click replacement.

It helps developers move faster during large JavaScript → TypeScript transitions by generating a reliable starting point for refinement.

Try the Code Translator here:

👉 https://www.aruvix.com/code-translator

Converter Tools

🔗 Tool Link: https://www.aruvix.com/json-to-csv

A comprehensive suite for converting between multiple developer-friendly data formats.

Features

JSON ↔ XML
JSON ↔ YAML
CSV conversion
JSONL conversion
Dart conversion
TOON conversion

Options Available

Auto-convert on paste
Source validation
Download output
Copy to clipboard

The Aruvix Advantage

Instead of opening multiple ad-heavy converter websites, developers can handle all transformations locally inside a single workflow.

Fast. Consistent. Private.

Developers frequently work with multiple formats across APIs, databases, integrations, logs, and export systems.

Aruvix simplifies these transitions without requiring separate conversion platforms for every format.

Explore Converter Tools here:

👉 https://www.aruvix.com/json-to-csv

Dev Tools

🔗 Tool Link: https://www.aruvix.com/dev-tools

A dedicated collection of utilities for debugging, inspection, and payload analysis.

Included Tools

JWT Decoder
Base64 Encoder/Decoder
URL Encoder/Decoder
Regex Tester
Duplicate Key Finder
Timestamp Scanner
JSON Merge
JSON Patch
Structure Analyzer

The Aruvix Advantage

Instead of opening random utilities across the web, Aruvix centralizes the entire debugging workflow into a single consistent interface.

Decode tokens, test regex patterns, inspect payload structures, and analyze responses without leaving the ecosystem.

Small debugging operations consume surprising amounts of developer time throughout the day.

Aruvix centralizes these repetitive micro-workflows into a single environment so engineers can stay focused instead of context switching across tabs.

Explore Developer Utilities here:

👉 https://www.aruvix.com/dev-tools

Frontend & CSS Tools

🔗 Tool Link: https://www.aruvix.com/color-picker

Everything frontend developers need to accelerate UI workflows.

Included Tools

Color Picker
CSS to Tailwind Converter
Design Token Generator
HTML/SVG to JSX Converter
CSS Formatter
CSS Specificity Calculator
Box Shadow Generator
Gradient Generator
Flexbox/Grid Generators

The Aruvix Advantage

Frontend developers constantly rely on fragmented generators and conversion websites during daily workflows.

Aruvix consolidates those repetitive utilities into a single streamlined experience with consistent UX and local execution.

Frontend development often involves repetitive experimentation with layouts, spacing, gradients, color systems, and utility conversions.

Aruvix helps speed up these workflows while keeping everything accessible from one consistent workspace.

Instead of searching for isolated CSS generators, frontend engineers can iterate directly within the same ecosystem used for APIs, payloads, and debugging.

Explore Frontend & CSS Tools here:

👉 https://www.aruvix.com/color-picker

QA Tools

🔗 Tool Link: https://www.aruvix.com/test-data-generator

A dedicated toolkit for QA engineers and testers to validate faster and generate better reports.

Included Tools

Test Data Generator
Bug Report Generator
API Assertion Generator
HAR Viewer
UUID Generator
Fake User/Data Generator

Options Available

CSV/SQL/JSON export
Configurable row counts
Jira/GitHub markdown formatting
Structured regression reporting

The Aruvix Advantage

QA teams should not need separate utilities for generating test data, formatting reports, validating APIs, and inspecting payloads.

Aruvix centralizes these workflows while keeping all generated data local and private.

QA engineers frequently need to generate large amounts of realistic test data while maintaining privacy and consistency across environments.

Aruvix enables rapid dataset generation directly inside the browser without external dependencies.

This becomes particularly useful during regression testing, staging validation, and automated test preparation.

Explore QA Tools here:

👉 https://www.aruvix.com/test-data-generator

Who Is Aruvix For?

Aruvix is designed for:

Backend developers
Frontend engineers
QA teams
API developers
DevOps engineers
Full-stack developers
Developers working with large JSON payloads
Teams looking for privacy-first workflows

Whether you are debugging APIs, formatting JSON, generating schemas, testing regex, converting formats, or building frontend workflows — Aruvix keeps everything fast, local-first, and privacy-focused.

Final Thoughts

Aruvix is built around a simple philosophy:

Developer tools should feel fast.
Your data should remain yours.
Simple tasks should not consume AI tokens.
And workflows should stay unified instead of fragmented across dozens of disconnected tools.

One toolkit.
One workflow.
Everything local-first.

Build faster.
Debug smarter.
Waste fewer tokens.

Explore Aruvix

🌐 Official Website: https://www.aruvix.com

JSON Formatter → https://www.aruvix.com/json-formatter
JSON Compare → https://www.aruvix.com/json-diff
API Client → https://www.aruvix.com/api-tester
Schema Generator → https://www.aruvix.com/schema
Visualizer → https://www.aruvix.com/visualize

Build faster.
Debug smarter.
Waste fewer tokens.

About the Author

I’m Amrish Khan — a full-stack engineer focused on building fast, privacy-conscious, developer-first applications.

I’m currently exploring the future of:

local-first developer tooling
browser-native processing
AI-efficient workflows
offline-capable applications
privacy-focused architectures

You can follow my work and thoughts here:

Portfolio: amrishkhan.dev
LinkedIn: linkedin.com/in/amrishkhan

Unlocking the Power of the Browser Console: A Developer's Guide

Amrishkhan Sheik Abdullah — Fri, 17 Oct 2025 11:25:49 +0000

For web developers, the browser's developer console is an indispensable tool. It's more than just a place to spot error messages; it's a powerful debugging and development companion that can significantly streamline your workflow and enhance your productivity. This article delves into the depths of the console object, exploring its popular methods and uncovering creative ways to leverage them.

What is the Console and Why is it Your Best Friend?

The console object provides access to the browser's debugging console, allowing you to log information, inspect objects, and analyze your code's execution. It's like having a direct line of communication with your application, providing invaluable insights into what's happening under the hood. By mastering the console, you can:

Debug with Ease: Quickly identify and resolve issues by logging variable values, tracking function calls, and examining object properties.
Understand Code Flow: Trace the execution of your code to pinpoint where things go wrong or to simply understand how different parts of your application interact.
Monitor Performance: Time and measure the performance of your code to identify and optimize bottlenecks.
Enhance Productivity: Utilize advanced console features to organize output, create interactive logs, and streamline your debugging process.

The Most Popular Console Methods You Should Know

While the console object boasts a wide array of methods, a few stand out as the workhorses of every developer's toolkit.

1. `console.log()`: The Classic All-Rounder

The console.log() method is the most frequently used and versatile method. It allows you to output any type of data to the console, from simple strings and numbers to complex objects and arrays.

const name = "John Doe";
const age = 30;
const user = { name, age };

console.log("User's name:", name);
console.log("User's age:", age);
console.log("User object:", user);

Console Output:

2. `console.error()`, `console.warn()`, and `console.info()`: Adding Context to Your Logs

These methods are similar to console.log(), but they provide a visual distinction in the console, making it easier to categorize and filter your logs.

console.error(): Displays an error message, typically with a red background, to indicate a problem that needs immediate attention.
console.warn(): Displays a warning message, often with a yellow background, to highlight potential issues that may not be critical but should be addressed.
console.info(): Displays an informational message, usually with a blue or gray icon, to provide general information.

console.error("This is an error message!");
console.warn("This is a warning message.");
console.info("This is an informational message.");

Console Output:

3. `console.table()`: Visualizing Data in a Structured Way

When working with arrays of objects, console.table() is a game-changer. It displays your data in a clean, interactive table, making it easy to read and analyze.

const users = [
  { name: "John Doe", age: 30 },
  { name: "Jane Doe", age: 25 },
  { name: "Peter Jones", age: 35 },
];

console.table(users);

Console Output:

4. `console.group()` and `console.groupEnd()`: Organizing Your Console Output

For complex applications with a lot of logging, the console can quickly become cluttered. console.group() and console.groupEnd() allow you to create collapsible groups of log messages, keeping your console organized and readable. You can even use console.groupCollapsed() to create a group that is initially collapsed.

console.group("User Details");
console.log("Name: John Doe");
console.log("Age: 30");
console.groupEnd();

Console Output:

Level Up Your Productivity with Advanced Console Techniques

Beyond the basics, the console object offers several advanced features that can significantly boost your productivity.

1. `console.assert()`: Conditional Logging

console.assert() allows you to log an error message only if a specified condition is false. This is particularly useful for validating data and catching unexpected behavior.

const x = 5;
const y = 10;

console.assert(x > y, { x, y }, "x is not greater than y");

Console Output:

2. `console.trace()`: Tracing the Call Stack

When you need to understand how a particular function was called, console.trace() comes to the rescue. It outputs a stack trace, showing the entire call path that led to the console.trace() call.

function foo() {
  function bar() {
    console.trace();
  }
  bar();
}

foo();

Console Output:

3. `console.time()` and `console.timeEnd()`: Measuring Performance

To measure the time it takes for a piece of code to execute, you can use console.time() and console.timeEnd(). Simply call console.time() with a label before the code you want to measure, and then call console.timeEnd() with the same label after the code.

console.time("myTimer");
for (let i = 0; i < 100000; i++) {
  // some code
}
console.timeEnd("myTimer");

Console Output:

4. Styling Your Console Output with `%c`

Did you know you can style your console output with CSS? By using the %c directive, you can add custom styles to your log messages, making them more visually appealing and easier to read.

console.log(
  "%cThis is a styled message!",
  "color: blue; font-size: 20px; font-weight: bold;"
);

Console Output:

Conclusion

The browser's console object is a powerful and versatile tool that is essential for modern web development. By mastering its various methods and exploring its advanced features, you can significantly improve your debugging process, gain a deeper understanding of your code, and ultimately become a more productive and effective developer. So, the next time you're working on a web project, don't forget to open up the console and put these techniques into practice!

Demystifying SOLID: 5 Principles for Building Robust and Maintainable Software

Amrishkhan Sheik Abdullah — Tue, 14 Oct 2025 11:25:16 +0000

In the world of software development, some principles stand the test of time. Among the most influential are the SOLID principles, a set of five design guidelines that empower developers to create software that is more understandable, flexible, and maintainable. Coined by Robert C. Martin (Uncle Bob), SOLID isn't a silver bullet, but rather a powerful framework for thinking about object-oriented design.

Let's break down each principle with practical examples.

S - Single Responsibility Principle (SRP)

"A class should have only one reason to change."

This principle advocates for a class to have a single, well-defined purpose. If a class has multiple responsibilities, changes to one responsibility might inadvertently affect others, leading to unexpected bugs and a tangled codebase.

Bad Example (Violates SRP)

Imagine a Report class that's responsible for both generating the report data and printing it.

Python 🐍

class Report:
    def __init__(self, data):
        self.data = data

    def generate_report(self):
        # Logic to process report data
        return f"Report Data: {self.data}"

    def print_report(self):
        report_content = self.generate_report()
        print(f"Printing: {report_content}")

JavaScript 📜

class Report {
    constructor(data) {
        this.data = data;
    }

    generateReport() {
        // Logic to process report data
        return `Report Data: ${this.data}`;
    }

    printReport() {
        const reportContent = this.generateReport();
        console.log(`Printing: ${reportContent}`);
    }
}

Why it's bad: This class has two reasons to change: a change in the data generation logic or a change in the printing mechanism (e.g., printing to a file, sending an email).

Good Example (Adheres to SRP)

We split these responsibilities into separate classes.

Python 🐍

class ReportGenerator:
    def generate(self, data):
        return f"Report Data: {data}"

class ReportPrinter:
    def print(self, report_content):
        print(f"Printing: {report_content}")

# Usage
generator = ReportGenerator()
printer = ReportPrinter()
report_data = generator.generate("Sales Figures")
printer.print(report_data)

JavaScript 📜

class ReportGenerator {
    generate(data) {
        return `Report Data: ${data}`;
    }
}

class ReportPrinter {
    print(reportContent) {
        console.log(`Printing: ${reportContent}`);
    }
}

// Usage
const generator = new ReportGenerator();
const printer = new ReportPrinter();
const reportData = generator.generate("Sales Figures");
printer.print(reportData);

Now, ReportGenerator only cares about generating data, and ReportPrinter only cares about printing. Each has one, and only one, reason to change.

O - Open/Closed Principle (OCP)

"Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification."

This principle suggests that you should be able to add new functionality without altering existing, working code. This is typically achieved through abstraction and polymorphism.

Bad Example (Violates OCP)

Consider a function to calculate the total area of shapes, but it has to know about every concrete shape type.

Python 🐍

# Violates OCP
def calculate_total_area(shapes):
    total_area = 0
    for shape in shapes:
        if isinstance(shape, Circle):
            total_area += 3.14 * shape.radius ** 2
        elif isinstance(shape, Rectangle):
            total_area += shape.width * shape.height
        # To add a Triangle, we must modify this function!
    return total_area

JavaScript 📜

// Violates OCP
function calculateTotalArea(shapes) {
    let totalArea = 0;
    for (const shape of shapes) {
        if (shape.type === 'circle') {
            totalArea += Math.PI * shape.radius ** 2;
        } else if (shape.type === 'rectangle') {
            totalArea += shape.width * shape.height;
        }
        // To add a Triangle, we must modify this function!
    }
    return totalArea;
}

Why it's bad: Every time a new shape is introduced, the calculate_total_area function needs to be modified. It's not closed for modification.

Good Example (Adheres to OCP)

We use polymorphism. Each shape knows how to calculate its own area.

Python 🐍

class Shape:
    def calculate_area(self):
        raise NotImplementedError

class Circle(Shape):
    def __init__(self, radius): self.radius = radius
    def calculate_area(self): return 3.14 * self.radius ** 2

class Rectangle(Shape):
    def __init__(self, width, height): self.width, self.height = width, height
    def calculate_area(self): return self.width * self.height

# We can add new shapes without changing calculate_total_area
class Triangle(Shape):
    def __init__(self, base, height): self.base, self.height = base, height
    def calculate_area(self): return 0.5 * self.base * self.height

def calculate_total_area(shapes):
    return sum(shape.calculate_area() for shape in shapes)

JavaScript 📜

class Circle {
    constructor(radius) { this.radius = radius; }
    calculateArea() { return Math.PI * this.radius ** 2; }
}

class Rectangle {
    constructor(width, height) { this.width = width; this.height = height; }
    calculateArea() { return this.width * this.height; }
}
// We can add new shapes without changing calculateTotalArea
class Triangle {
    constructor(base, height) { this.base = base; this.height = height; }
    calculateArea() { return 0.5 * this.base * this.height; }
}

function calculateTotalArea(shapes) {
    return shapes.reduce((sum, shape) => sum + shape.calculateArea(), 0);
}

Now, the calculate_total_area function is closed for modification. To add new shapes, we simply extend our system with new classes.

L - Liskov Substitution Principle (LSP) Good Example

The best way to adhere to LSP in the shape example is to avoid making Square a subtype of Rectangle. Instead, both should inherit from a common abstraction like Shape that doesn't define setters that could be misused, ensuring the behavior of the derived classes is consistent with what the client expects from the base class.

Good Example (Adheres to LSP)

Both Circle and Rectangle (and Square, if needed) are substitutes for the general Shape base type, as neither breaks the contract defined by Shape's calculate_area method.

Python 🐍

class Shape:
    # Base class defining the expected contract: calculation of area
    def calculate_area(self):
        raise NotImplementedError

class Circle(Shape):
    def __init__(self, radius): self.radius = radius
    # Behavior is extended, not broken
    def calculate_area(self): return 3.14 * self.radius ** 2

class Rectangle(Shape):
    def __init__(self, width, height): self.width, self.height = width, height
    # Behavior is extended, not broken
    def calculate_area(self): return self.width * self.height

# A function that expects a Shape will work correctly with any subtype (LSP is maintained)
def check_area(shape: Shape):
    # The client only calls a method that is correctly implemented by all subtypes
    print(f"Calculated area: {shape.calculate_area()}")

# Usage: Both Circle and Rectangle are substitutable for Shape
circle = Circle(5)
rectangle = Rectangle(4, 6)
check_area(circle)
check_area(rectangle)

JavaScript 📜

// A common base class/interface is used.
class Shape {
    calculateArea() {
        throw new Error("calculateArea must be implemented");
    }
}

class Circle extends Shape {
    constructor(radius) { super(); this.radius = radius; }
    // Behavior is extended, not broken
    calculateArea() { return Math.PI * this.radius ** 2; }
}

class Rectangle extends Shape {
    constructor(width, height) { super(); this.width = width; this.height = height; }
    // Behavior is extended, not broken
    calculateArea() { return this.width * this.height; }
}

// A function that expects a Shape (i.e., an object with a calculateArea method)
function checkArea(shape) {
    // The client only calls a method that is correctly implemented by all subtypes
    console.log(`Calculated area: ${shape.calculateArea()}`);
}

// Usage: Both Circle and Rectangle are substitutable for the abstract Shape contract
const circle = new Circle(5);
const rectangle = new Rectangle(4, 6);
checkArea(circle);
checkArea(rectangle);

By ensuring that derived classes don't alter the assumptions made by the client code when dealing with the base class (by using immutable properties or constructors), we uphold the Liskov Substitution Principle.

I - Interface Segregation Principle (ISP)

"Clients should not be forced to depend on interfaces they do not use."

This principle suggests that large, monolithic interfaces should be broken down into smaller, more specific ones. This way, classes only need to implement methods that are relevant to their functionality.

Bad Example (Violates ISP)

Imagine a single, "fat" Worker interface.

Python 🐍

class Worker:
    def work(self): raise NotImplementedError
    def eat(self): raise NotImplementedError

class Human(Worker):
    def work(self): print("Human working")
    def eat(self): print("Human eating")

class Robot(Worker):
    def work(self): print("Robot working")
    def eat(self): pass # Robots don't eat, but must implement the method.

JavaScript 📜

class Worker {
    work() { throw new Error("Method not implemented!"); }
    eat() { throw new Error("Method not implemented!"); }
}
class Human extends Worker {
    work() { console.log("Human working"); }
    eat() { console.log("Human eating"); }
}
class Robot extends Worker {
    work() { console.log("Robot working"); }
    eat() { /* Robots don't eat, but must implement the method. */ }
}

Why it's bad: The Robot class is forced to implement an eat method it doesn't need. This creates an unnatural dependency.

Good Example (Adheres to ISP)

Segregate the interfaces into smaller, role-specific ones.

Python 🐍

class Workable:
    def work(self): raise NotImplementedError

class Eatable:
    def eat(self): raise NotImplementedError

class Human(Workable, Eatable):
    def work(self): print("Human working")
    def eat(self): print("Human eating")

class Robot(Workable): # Only implements what it needs
    def work(self): print("Robot working")

JavaScript 📜

// In JS, this is often done with composition or smaller classes.
const workable = {
    work() { console.log(`${this.name} working`); }
};
const eatable = {
    eat() { console.log(`${this.name} eating`); }
};

class Human {
    constructor(name) { this.name = name; }
}
Object.assign(Human.prototype, workable, eatable);

class Robot {
    constructor(name) { this.name = name; }
}
Object.assign(Robot.prototype, workable); // Only implements what it needs

const human = new Human("Alice");
const robot = new Robot("C-3PO");
human.work(); // Alice working
human.eat();  // Alice eating
robot.work(); // C-3PO working
// robot.eat(); // TypeError: robot.eat is not a function

Now, Robot only depends on the Workable behavior. Clients can depend on smaller, more focused abstractions.

D - Dependency Inversion Principle (DIP)

"1. High-level modules should not depend on low-level modules. Both should depend on abstractions."
"2. Abstractions should not depend on details. Details should depend on abstractions."

This principle is about decoupling. Instead of high-level logic depending directly on concrete low-level implementations, both should depend on an abstraction (like an interface). This is often achieved through Dependency Injection.

Bad Example (Violates DIP)

A PasswordReminder (high-level) module is directly coupled to a MySQLDatabase (low-level) module.

Python 🐍

class MySQLDatabase:
    def connect(self): print("Connecting to MySQL...")
    def get_user_data(self): return "User data from MySQL"

class PasswordReminder:
    def __init__(self):
        self.db_connection = MySQLDatabase() # <-- Direct dependency!

    def get_user(self):
        self.db_connection.connect()
        return self.db_connection.get_user_data()

JavaScript 📜

class MySQLDatabase {
    connect() { console.log("Connecting to MySQL..."); }
    getUserData() { return "User data from MySQL"; }
}

class PasswordReminder {
    constructor() {
        this.dbConnection = new MySQLDatabase(); // <-- Direct dependency!
    }
    getUser() {
        this.dbConnection.connect();
        return this.dbConnection.getUserData();
    }
}

Why it's bad: The PasswordReminder is completely tied to MySQLDatabase. If we want to switch to a PostgreSQL database or use a mock database for testing, we have to change the PasswordReminder class.

Good Example (Adheres to DIP)

We introduce an abstraction that both modules can depend on. The dependency is "injected" into the high-level module.

Python 🐍

class DatabaseConnection: # The Abstraction
    def connect(self): raise NotImplementedError
    def get_user_data(self): raise NotImplementedError

class MySQLDatabase(DatabaseConnection): # A Detail
    def connect(self): print("Connecting to MySQL...")
    def get_user_data(self): return "User data from MySQL"

class PostgreSQLDatabase(DatabaseConnection): # Another Detail
    def connect(self): print("Connecting to PostgreSQL...")
    def get_user_data(self): return "User data from PostgreSQL"

class PasswordReminder: # High-level module
    def __init__(self, db_connection: DatabaseConnection): # Depends on abstraction
        self.db_connection = db_connection

    def get_user(self):
        self.db_connection.connect()
        return self.db_connection.get_user_data()

# We can now 'inject' any database that follows the contract.
mysql = MySQLDatabase()
reminder = PasswordReminder(mysql)

JavaScript 📜

// In JS, the abstraction is often an implicit contract (duck typing).
// We expect any database object to have `connect` and `getUserData` methods.

class MySQLDatabase { // A Detail
    connect() { console.log("Connecting to MySQL..."); }
    getUserData() { return "User data from MySQL"; }
}

class PostgreSQLDatabase { // Another Detail
    connect() { console.log("Connecting to PostgreSQL..."); }
    getUserData() { return "User data from PostgreSQL"; }
}

class PasswordReminder { // High-level module
    constructor(dbConnection) { // Depends on the abstraction (the contract)
        this.dbConnection = dbConnection;
    }
    getUser() {
        this.dbConnection.connect();
        return this.dbConnection.getUserData();
    }
}

// We can now 'inject' any database that follows the contract.
const mysql = new MySQLDatabase();
const reminder = new PasswordReminder(mysql);
console.log(reminder.getUser());

By depending on an abstraction, our PasswordReminder is now decoupled from the specific database implementation, making it more flexible, reusable, and testable.

Conclusion

Adopting the SOLID principles is an investment in the long-term health of your codebase. It might seem like more work upfront, but it leads to software that is easier to scale, refactor, and understand. By building systems with single responsibilities, that are open to extension, with substitutable parts, lean interfaces, and inverted dependencies, you create a foundation for truly robust and elegant software. Happy coding!

GitHub Code Setup: Choosing Your Workflow (HTTPS, SSH, Terminal, & Desktop)

Amrishkhan Sheik Abdullah — Wed, 08 Oct 2025 14:38:01 +0000

Getting a codebase from GitHub onto your local machine is the first step in any development project. While the core action is always a "clone," the method you choose affects your daily workflow, security, and integration with the GitHub platform.

Here's a detailed guide to the four main ways you can set up your code environment, complete with steps and examples for each.

1. The Git Protocol Choice: HTTPS vs. SSH 🔑

Before you even pick a tool (Terminal or Desktop), you must decide how your machine will authenticate with GitHub.

A. HTTPS (The Simple Way)

HTTPS uses your standard GitHub username and password, often combined with a Personal Access Token (PAT) for authentication, or relies on a local credential manager.

Pros	Cons
Simple Setup: No key generation required.	Token Reliance: Requires authentication (password or PAT) for every push/pull unless a credential manager is used.
Universal: Works everywhere without configuration.	PATs can expire and require occasional regeneration.

When to use it: For quick, one-off projects, or when you are on a machine where you cannot set up SSH keys.

Crucial Missing Step: Setting up the Credential Manager (Recommended)

To avoid entering your PAT or password constantly, you should configure Git to store your credentials securely.

Generate a PAT: Go to GitHub $\rightarrow$ Settings $\rightarrow$ Developer settings $\rightarrow$ Personal access tokens $\rightarrow$ Tokens (classic). Generate a new token with appropriate permissions (usually repo). Copy this token immediately; you won't see it again.
Configure Credential Manager: This command tells Git to use your OS's built-in credential manager (like macOS Keychain or Windows Credential Manager).
```
git config --global credential.helper store
```
First Clone & Authentication: The very first time you push or pull after running the above command, Git will prompt you. Enter your GitHub username and the PAT you generated as the password. The credential manager saves it for future use.

Example Clone Command:

git clone https://github.com/username/repo-name.git

B. SSH (The Secure Way)

SSH (Secure Shell) uses a pair of cryptographic keys: a private key stored securely on your machine and a public key uploaded to GitHub. This method is the most secure and convenient once set up.

Pros	Cons
Highly Secure: Uses key pairs; your private key never leaves your machine.	Initial Setup: Requires key generation and configuration.
Convenient: Once set up, it requires zero authentication for pushes/pulls (if using an agent).	Requires proper passphrase management.

When to use it: For your daily driver, primary development machine, or any sensitive codebase.

Detailed SSH Setup

This process requires a few crucial steps to work seamlessly:

🔐 Step 1: Generate SSH Key

Open your terminal and run the following command. The -t ed25519 flag uses the recommended secure algorithm.

ssh-keygen -t ed25519 -C "your_email@example.com"

File Prompt: Press Enter to accept the default file location (~/.ssh/id_ed25519).
Passphrase Prompt: Enter a strong, memorable passphrase. This encrypts your private key file.

🔑 Step 2: Add SSH Key to SSH Agent

The SSH agent manages your private keys and keeps them in memory, allowing you to use the key without entering the passphrase for every Git operation.

Start the ssh-agent:
```
eval "$(ssh-agent -s)"
```
Add your private key to the agent:
```
ssh-add ~/.ssh/id_ed25519
```
(You will be prompted to enter the passphrase you created in Step 1.)

📋 Step 3: Copy Your Public Key

Copy the contents of the public key file (.pub extension) to your clipboard using a command like cat (for macOS/Linux/Git Bash):

cat ~/.ssh/id_ed25519.pub

🌐 Step 4: Add SSH Key to GitHub

Go to GitHub Settings: Navigate to your GitHub Profile $\rightarrow$ Settings $\rightarrow$ SSH and GPG keys.
Add New SSH Key: Click the "New SSH key" button.
Title: Give it a descriptive name (e.g., "Home PC").
Key: Paste the public key you copied into the key field.
Click "Add SSH key."

🧪 Step 5: Test SSH Connection

Test the connection from your machine to GitHub to ensure authentication works:

ssh -T git@github.com

You should receive a confirmation message that includes your username.

📥 Step 6: Clone Repository Using SSH

Now clone the repository using the SSH URL:

git clone git@github.com:username/repo-name.git

3. The Tool Choice: Terminal vs. GitHub Desktop 🛠️

Once your chosen protocol is set up, you choose your interface for the git clone command.

A. Terminal / Command Line (The Power User's Way)

Using the terminal gives you the fastest, most granular control over Git operations and is the preferred method for most experienced developers.

Prerequisites: Git must be installed, and your chosen protocol (HTTPS/SSH) must be configured.

Setup Example (Using HTTPS and Credential Manager):

Navigate to your Development Folder:
```
cd ~/Projects/
```
Clone the Repository:
(Copy the HTTPS link from the GitHub repo page.)
```
git clone https://github.com/your-user/your-repo.git
```

Start Working:

cd your-repo
# Make changes...
git add .
git commit -m "Initial setup"
git push  # Should prompt for credentials only once, then use the credential manager

B. GitHub Desktop (The Visual Workflow)

GitHub Desktop provides a simplified graphical interface (GUI) that abstracts away complex commands. It's excellent for beginners, visual learners, or for managing branches and commits quickly.

Prerequisites: You must have the GitHub Desktop application installed and be logged into your GitHub account within the app.

Setup Example (Visual Clone):

Open GitHub Desktop.
Go to File $\rightarrow$ Clone Repository.
Select the GitHub.com tab.
Choose the repository you want from your list.
Specify the Local Path where the code should be stored.
Click "Clone".

The application automatically handles the git clone command and uses the authentication it saved when you signed into the app. All subsequent pulls and pushes are done by clicking the Fetch and Push buttons.

4. Quick Reference Table

Method	Interface	Authentication	Complexity	Best For
HTTPS	Terminal	PAT + Credential Manager	Medium	Quick tests, public repos, shared/temporary machines.
SSH	Terminal	SSH Key Pair + Agent	High	Daily driver, maximum security, high-volume pushes/pulls.
GitHub Desktop	GUI	Saved Token / Credentials	Low	Beginners, visual management, non-technical collaborators.

Level Up Your Workflow: Mastering Bulk Actions in Postman

Amrishkhan Sheik Abdullah — Wed, 08 Oct 2025 08:45:23 +0000

Postman is much more than just a tool for sending single API requests; it’s a powerful environment for testing, documenting, and executing complex API workflows. When you need to perform the same operation hundreds of times—like creating a batch of users, testing various data inputs, or migrating configuration—you need bulk actions.

The secret to bulk operations in Postman lies in combining Collections, the Collection Runner, Variables, and external Data Files.

1. The Core Tool: The Collection Runner

The Collection Runner is Postman's built-in feature for executing an entire Collection (or a specific Folder within a Collection) multiple times in a predefined sequence. It's the central hub for all bulk operations.

Key Features for Bulk Actions:

Iteration Count: Tells the Runner how many times to execute the entire collection/folder.
Data Files: Allows you to upload external CSV or JSON files to feed different data into each iteration.
Environment Selection: Ensures consistent bulk operations across development, staging, or production environments.
Test Logging: Logs the results (pass/fail) for every request across every iteration.

2. Technique 1: Data-Driven Testing (Bulk Input)

This is the most common form of bulk action, used to test an API endpoint against a large set of varied inputs (e.g., testing valid/invalid usernames, bulk user creation, or mass data updates).

Step-by-Step Implementation:

A. Prepare the Data File 📊

Create a CSV or JSON file containing all your input data. The column headers in your file will become the variable names Postman uses.

Example CSV (user_data.csv):

id,username,email,expected_status
1,alice_dev,alice@test.com,201
2,bob_tester,bob@test.com,201
3,,invalid_user.com,400

B. Parameterize the Request 🔗

In your Postman request (e.g., a POST /users request), replace the static values in the URL, headers, or body with dynamic variables using the {{variable_name}} syntax.

Part of Request	Before	After (Parameterized)
Request Body	`"username": "static_user"`	`"username": "{{username}}"`
Tests/Assertions	`pm.expect(pm.response.code).to.eql(201);`	`pm.expect(pm.response.code).to.eql(pm.iterationData.get("expected_status"));`

Postman will automatically map the column headers from your CSV/JSON file to these variables during the run.

C. Run the Collection

Click the "Run" button next to your Collection.
In the Collection Runner window, click "Select File" under the Data section and upload your user_data.csv (or JSON).
Postman will automatically update the Iterations count to match the number of rows (data sets) in your file (3 in the example above).
Click "Run [Collection Name]" to start the bulk operation.

The Runner will execute the request three separate times, substituting the variables with the data from each row.

3. Technique 2: Chained Workflows (Sequential Bulk Operations)

Sometimes you need a series of requests to run in bulk (e.g., Login $\rightarrow$ Create Order $\rightarrow$ Get Order Details). The Collection Runner automatically runs requests sequentially, and you can pass data between them using variables.

How it Works:

Request 1 (e.g., Login): Use a Post-response Script to capture a value (like an authentication token) from the response and save it as an Environment Variable.
```
// Post-response Script for Login request
const responseJson = pm.response.json();
pm.environment.set("auth_token", responseJson.token);
```
Request 2 (e.g., Create Resource): Use that variable in the next request's header.

Header Key Header Value

Authorization Bearer {{auth_token}}
When you run the Collection Runner, it executes Request 1, sets the token, and then Request 2 uses that token, all within the same bulk iteration.

Header Key	Header Value
`Authorization`	`Bearer {{auth_token}}`

4. Technique 3: Conditional Looping and Flow Control

For advanced bulk actions like pagination or dynamic flows, you can use the postman.setNextRequest() function in your request scripts.

Use Case: Pagination (Processing all pages of results)

If an API returns data in paginated format (e.g., only 100 records per call), you can't process the whole list in one go. You must loop until there are no more pages.

Request: GET /data?page={{page_number}}

Pre-request Script: Initialize or increment the page number.

// Initialize page_number in environment or pre-request script
if (pm.environment.get("page_number") === undefined) {
    pm.environment.set("page_number", 1);
}

Post-response Script (The Loop Logic):

const response = pm.response.json();
const currentPage = pm.environment.get("page_number");

// Check if there's a next page or total results count
if (response.has_more_pages === true) {
    // Increment the page number for the next iteration
    pm.environment.set("page_number", currentPage + 1);

    // Tell the runner to execute this SAME request again
    postman.setNextRequest(pm.info.requestName);
} else {
    // End the loop by setting the next request to null (or the next item in the collection)
    postman.setNextRequest(null);
}

By setting postman.setNextRequest(), you override the default sequential flow and force the runner to perform a bulk, data-gathering loop.

5. Taking Bulk Actions to CI/CD: Newman

For true automation, Postman provides Newman, its command-line collection runner. Newman allows you to run your bulk operations outside the Postman desktop app, making it perfect for CI/CD pipelines, automated testing, or background tasks.

Newman for Bulk Actions:

Execution: Run collections and bulk data sets directly from a terminal or build server.
Data Injection: Supports the same data file inputs (-d or --data) as the desktop Collection Runner.
Command Example:

# Run a collection 5 times using a specific environment and data file
newman run my_bulk_collection.json \
  -e production_env.json \
  -d bulk_create_data.csv \
  -n 5 \
  --reporters cli,htmlextra

Newman is the professional standard for scaling Postman bulk actions into a fully automated process.

Unraveling the JavaScript Event Loop: A Deep Dive for Developers

Amrishkhan Sheik Abdullah — Tue, 07 Oct 2025 05:24:08 +0000

JavaScript is often described as a single-threaded language, meaning it can only execute one task at a time. This raises a fundamental question: how does it handle long-running operations like network requests, timers, or file I/O without "freezing" the entire application? The answer lies in the Event Loop – a clever mechanism that allows JavaScript to perform non-blocking asynchronous operations, giving the illusion of concurrency.

Understanding the Event Loop is key to writing efficient, responsive, and predictable JavaScript code, whether you're building a frontend UI or a Node.js backend.

The Core Components: What's Involved?

Before we dive into the loop itself, let's understand the main players:

Call Stack (Execution Stack): This is where JavaScript keeps track of functions being executed. When a function is called, it's pushed onto the stack. When it returns, it's popped off. It operates on a LIFO (Last-In, First-Out) principle.
Web APIs (Browser) / C++ APIs (Node.js): These are capabilities provided by the browser (like setTimeout, DOM events, fetch) or Node.js runtime (like fs.readFile, http.request). They are not part of the JavaScript engine itself but allow JS to offload time-consuming tasks.
Callback Queue (Task Queue / Macrotask Queue): When an asynchronous operation (e.g., a setTimeout callback, a click event handler, or a fetch response handler) completes, its callback function is moved to this queue. It's a FIFO (First-In, First-Out) queue.
Job Queue (Microtask Queue): Introduced with Promises, this queue has higher priority than the Callback Queue. Callbacks from Promises (.then(), .catch(), .finally()), queueMicrotask(), and MutationObserver are placed here.
The Event Loop Itself: This is the tireless arbiter. Its sole job is to constantly monitor if the Call Stack is empty. If the Call Stack is empty, it first checks the Job Queue. If there are jobs, it moves them, one by one, to the Call Stack for execution until the Job Queue is empty. Only then does it check the Callback Queue. If there are callbacks, it moves the first one to the Call Stack for execution. This process repeats indefinitely.

The Event Loop in Action: Step-by-Step Flow

Let's illustrate the entire process with a common scenario involving setTimeout and Promises.

console.log('Start'); // 1

setTimeout(() => {
  console.log('setTimeout callback'); // 4
}, 0); // Scheduled with Web API

Promise.resolve().then(() => {
  console.log('Promise microtask'); // 3
});

console.log('End'); // 2

Phase 1: Initial Execution (Synchronous Code)

console.log('Start'); is pushed to the Call Stack, executed, and popped. Output: Start.
setTimeout is encountered. Its callback is passed to the Web API (Timer). The setTimeout function itself is popped.
Promise.resolve().then(...) is encountered. The promise resolves instantly. Its callback is placed into the Job Queue.
console.log('End'); is pushed to the Call Stack, executed, and popped. Output: End.
At this point, the Call Stack is now empty.

Phase 2: Event Loop Kicks In - Prioritizing Microtasks

The Event Loop sees the Call Stack is empty.
It checks the Job Queue and finds the Promise.resolve().then(...) callback.
This callback is moved from the Job Queue to the Call Stack.
console.log('Promise microtask'); is executed and popped. Output: Promise microtask.
The Call Stack is empty again. The Event Loop re-checks the Job Queue; it's empty.

Phase 3: Processing Macrotasks

The Event Loop's job isn't done until all pending tasks are cleared. After the Job Queue is empty, the Event Loop can finally turn its attention to the Macrotask Queue.

While the above was happening, the setTimeout's 0ms delay has expired in the Web API. Its callback (() => { console.log('setTimeout callback'); }) is now moved to the Callback Queue (the Macrotask queue).
The Event Loop sees the Job Queue is empty.
It checks the Callback Queue and finds the setTimeout callback.
This callback is moved from the Callback Queue to the Call Stack.
console.log('setTimeout callback'); is executed and popped. Output: setTimeout callback.

Final Output Order:

Start
End
Promise microtask (Microtasks execute entirely before Macrotasks)
setTimeout callback (Macrotasks are run one per loop cycle)

Why Microtasks Have Priority: Starvation

The core takeaway is that the Job Queue (Microtasks) is processed entirely before the Event Loop moves to the Callback Queue (Macrotasks). This is crucial for predictability and data consistency.

If you use a Promise (.then()) to handle data loaded from a network request, you want that handler to run as soon as possible, ideally before the browser can render, paint, or process a user interaction (which are often Macrotasks). This ensures the application state is updated with high priority.

However, this priority can lead to starvation. If a developer puts an infinite loop of microtasks (e.g., a recursive Promise chain) into the Job Queue, the Event Loop will be stuck serving the Job Queue and will never get to the Callback Queue, effectively blocking all I/O, rendering, and user input.

Feature	Queue Type	Priority	Examples
Microtask	Job Queue	High (cleared completely)	Promises (`.then`, `.catch`), `queueMicrotask`, `MutationObserver`
Macrotask	Callback Queue	Low (one per loop cycle)	`setTimeout`, `setInterval`, `fetch` callbacks, DOM events (`click`, `load`)

Conclusion: Mastering Asynchronous JS

The Event Loop is what transforms single-threaded JavaScript into a powerful, non-blocking language. By offloading time-consuming operations to the Web APIs and orchestrating the execution order through the Call Stack, Job Queue, and Callback Queue, the browser maintains a fluid, responsive user experience.

As developers, keeping the Call Stack empty and respecting the Macrotask/Microtask priority system is the secret to writing clean, high-performance asynchronous JavaScript.

A Developer's Guide to API Types: Architectures, Use Cases, and Code Examples

Amrishkhan Sheik Abdullah — Mon, 06 Oct 2025 11:56:29 +0000

Selecting the right API architectural style is a fundamental decision that determines a project's performance, scalability, and complexity. This guide provides a detailed breakdown of the major API styles, their ideal use cases, and practical code examples.

1. REST (Representational State Transfer)

REST is the most popular architectural style for web services, utilizing standard HTTP methods to perform CRUD (Create, Read, Update, Delete) operations on resources.

Aspect	Detail
Protocol	HTTP/HTTPS
Data Format	JSON (most common), XML
Philosophy	Stateless, resource-oriented (everything is an entity, e.g., a "user" or "order").
Best For	Public-facing APIs, simple mobile/web apps, and basic CRUD operations.

🔍 Example: Fetching a User Profile

Scenario: A client wants to retrieve information for User ID 101.

Action	Request	Response (JSON)
Read	`GET /api/v1/users/101`

json\n{\n "id": 101,\n "name": "Alice Developer",\n "email": "alice@example.com",\n "status": "Active"\n}\n

|
| Create | POST /api/v1/users (with JSON body) | Status: 201 Created |
| Update | PUT /api/v1/users/101 (with new data) | Status: 200 OK |
| Delete | DELETE /api/v1/users/101 | Status: 204 No Content |

2. GraphQL (Graph Query Language)

GraphQL is a data query and manipulation language for APIs that allows clients to specify exactly the data they need. This prevents the problem of over-fetching (receiving unwanted data) common in REST.

Aspect	Detail
Protocol	HTTP (usually via a single endpoint)
Data Format	JSON
Philosophy	Client-driven data fetching; single endpoint, flexible queries based on a strong type schema.
Best For	Mobile apps, complex dashboard UIs, and projects where data consumption needs to be highly optimized.

🔍 Example: Optimized Data Fetching

Scenario: A client needs a user's name, email, and only the title of their last two blog posts.

Action	Request (Query)	Response (JSON)
Query

graphql\nquery UserProfile {\n user(id: "101") {\n name\n email\n posts(limit: 2) {\n title\n }\n }\n}\n

|

json\n{\n "data": {\n "user": {\n "name": "Alice Developer",\n "email": "alice@example.com",\n "posts": [\n { "title": "Intro to GraphQL" },\n { "title": "Why I chose gRPC" }\n ]\n }\n }\n}\n

|
| Mutation | mutation UpdateUser(...) | Similar to a POST or PUT in REST, used for data modification. |

3. gRPC (Google Remote Procedure Call)

gRPC is a high-performance framework based on the Remote Procedure Call (RPC) model. It uses Protocol Buffers (Protobuf) for data serialization and HTTP/2 for transport, making it exceptionally fast for machine-to-machine communication.

Aspect	Detail
Protocol	HTTP/2
Data Format	Protocol Buffers (a binary format)
Philosophy	Contract-first (defined by Protobuf schema); focused on calling a function/method on a remote server.
Best For	Microservices, inter-service communication, real-time data ingestion, and any performance-critical system.

🔍 Example: Inter-Service Communication

Scenario: An Order Processing service calls a remote Inventory service to check stock.

Protobuf Contract (Service Definition)	Client Call (Code Representation)	Server Response (Code Representation)

protobuf\nservice InventoryService {\n rpc CheckStock (StockRequest) returns (StockResponse);\n}\nmessage StockRequest {\n string product_id = 1;\n}\nmessage StockResponse {\n int32 quantity = 1;\n bool in_stock = 2;\n}\n

| inventoryClient.CheckStock({product_id: "P456"}) | StockResponse { quantity: 50, in_stock: true } |

Note: The actual data transfer is a compacted binary message, not readable JSON, which is key to its speed.

4. SOAP (Simple Object Access Protocol)

SOAP is a formal, standardized protocol that relies on XML for structured messaging. It is contract-first, meaning the available operations are rigidly defined in a WSDL (Web Services Description Language) file.

Aspect	Detail
Protocol	HTTP, SMTP, or others
Data Format	XML (enveloped messaging)
Philosophy	Strict contracts, high security, and built-in error handling via SOAP faults.
Best For	Legacy systems, highly regulated industries (banking, healthcare), and environments requiring formal contracts and enterprise-grade security.

🔍 Example: Financial Transaction

Scenario: Submitting a secure payment for Order ID ORD789.

Action	Request (XML)	Response (XML)
Invoke

xml\n<soap:Envelope>\n <soap:Body>\n <SubmitPayment>\n <OrderId>ORD789</OrderId>\n <Amount>99.99</Amount>\n </SubmitPayment>\n </soap:Body>\n</soap:Envelope>\n

|

xml\n<soap:Envelope>\n <soap:Body>\n <SubmitPaymentResponse>\n <Status>Success</Status>\n <TransactionId>TXN12345</TransactionId>\n </SubmitPaymentResponse>\n </soap:Body>\n</soap:Envelope>\n

|

5. WebSocket

WebSocket is a communication protocol that provides a persistent, two-way (full-duplex) channel over a single TCP connection. It is not request/response-based like the others; it's stream-based.

Aspect	Detail
Protocol	WebSocket (starts as HTTP upgrade)
Data Format	Any (usually JSON or Protobuf)
Philosophy	Real-time, event-driven, low-latency, and continuous data push.
Best For	Live chat, multiplayer games, real-time dashboards, and instant notifications.

🔍 Example: Live Stock Ticker

Scenario: A user opens a stock trading app and subscribes to real-time updates for a stock symbol.

Action	Client $\leftrightarrow$ Server	Purpose
Initial Handshake	HTTP Upgrade Request $\rightarrow$ HTTP Switch Protocol Response	Establishes the persistent WebSocket connection.
Client Action	`send('{"action": "subscribe", "symbol": "GOOG"}')`	The client tells the server what data it wants.
Server Response (Real-Time Push)	`push('{"symbol": "GOOG", "price": 175.40, "time": 1678886400}')` (Pushed by server)	The server instantly sends data frames to the client whenever the price changes.

npm vs. Yarn vs. pnpm: A Developer's Guide to Choosing the Right Package Manager

Amrishkhan Sheik Abdullah — Mon, 06 Oct 2025 11:47:30 +0000

In the fast-paced world of JavaScript development, the tools we use can significantly impact our productivity, project performance, and even our sanity. At the heart of this tooling ecosystem lies the package manager, the unsung hero that wrangles our project's dependencies. For years, npm was the undisputed king. Then came Yarn, promising speed and reliability. Now, pnpm has entered the fray, championing efficiency.

So, which one is the best? The answer, as is often the case in tech, is: it depends. Let's break down the architecture, pros, and cons of each to help you make an informed decision for your next project. 👨‍💻

npm: The Original Gangster

npm (Node Package Manager) is the default package manager that comes bundled with every Node.js installation. It's the original, the most widely known, and has the largest registry of packages in the world.

How It Works: Nested & Flat Dependencies

Initially, npm used a nested dependency structure. If you had two packages, A and B, that both depended on lodash, you would get two copies of lodash in your node_modules folder. This caused the infamous "node_modules black hole" problem, leading to deeply nested directories and massive folder sizes.

Since npm v3, it has adopted a flat dependency structure. It hoists all dependencies to the top level of node_modules to avoid duplication. If different packages require different versions of the same dependency, npm will only hoist the compatible version and nest the others where needed.

Real-World Example

Let's install express, a popular web framework that has its own set of dependencies.

# Initialize a project and install express
npm init -y
npm install express

Your node_modules will look something like this (simplified):

node_modules/
├── accepts
├── array-flatten
├── body-parser
├── content-disposition
├── cookie
├── cookie-signature
├── debug
├── ...
└── express  <-- Your direct dependency

Verdict: npm is reliable, easy to use, and deeply integrated into the Node.js ecosystem. Its performance has improved dramatically over the years, making it a perfectly viable and simple choice for most projects, especially for beginners.

Yarn: The Challenger for Speed and Reliability

Yarn was created by Facebook (now Meta) in 2016 to address npm's shortcomings at the time, primarily focusing on performance and security. It introduced a lockfile (yarn.lock) to ensure deterministic installations, meaning every developer on a team gets the exact same dependency tree.

How It Works: Flat Dependencies & More

Like modern npm, Yarn uses a flat dependency structure. However, its installation algorithm was initially much faster and more efficient. Yarn also introduced powerful features like Workspaces for managing monorepos and an offline cache.

Its most innovative feature is Plug'n'Play (PnP), an alternative installation strategy that gets rid of the node_modules folder entirely. Instead of resolving modules by traversing a massive folder, Yarn PnP generates a single .pnp.cjs file that maps package names and versions to their locations on the disk. This results in near-instantaneous startup times and a much cleaner project structure.

Real-World Example

Using Yarn Workspaces in a monorepo is a game-changer. Imagine a project with a shared ui-library and two applications (webapp and mobileapp) that use it.

// package.json in the project root
{
  "private": true,
  "workspaces": [
    "packages/*"
  ]
}

Now, when you run yarn install in the root, Yarn will install all dependencies for all packages and link them together. If you update ui-library, both webapp and mobileapp will get the changes instantly without needing to be published to a registry. This dramatically speeds up development in large, interconnected codebases.

Verdict: Yarn is an excellent choice for complex projects, especially monorepos, where features like Workspaces provide immense value. While its speed advantage over npm has narrowed, its robust feature set keeps it a top contender for professional development teams. 🚀

pnpm: The Efficiency Expert

pnpm stands for "performant npm." Its primary goal is to solve two major problems with node_modules: disk space usage and installation speed. It achieves this with a brilliant and unique architecture.

How It Works: Content-Addressable Storage & Symlinks

pnpm doesn't just flatten your dependency tree; it completely reimagines node_modules. Here’s the magic:

Global Store: When you install a package, pnpm downloads it into a single, content-addressable store on your machine (usually ~/.pnpm-store). It's "content-addressable," meaning a package's content is stored only once, indexed by its hash.
Symlinking: In your project's node_modules folder, pnpm doesn't copy files. Instead, it creates symbolic links (symlinks) to the packages in the global store.

This means if 10 of your projects use lodash@4.17.21, that version of lodash is only physically stored on your disk once. Every project just points to it. This leads to massive savings in disk space and lightning-fast installations, as dependencies are often just linked instead of being copied.

Real-World Example

Let's run the same express installation with pnpm.

pnpm install express

Your node_modules folder will look very different and much cleaner:

node_modules/
├── .pnpm/  <-- Where the magic happens (symlinks to the real files)
└── express -> .pnpm/express@4.18.2/node_modules/express

Only express is directly accessible in the root of node_modules. Its own dependencies are nested within the .pnpm folder, preventing your code from accessing packages that aren't explicitly declared in your package.json—a common source of bugs.

Verdict: For developers concerned with disk space and performance, pnpm is the undisputed champion. Its strict dependency resolution also prevents a class of "phantom dependency" bugs. It's an ideal choice for CI/CD environments, monorepos, and anyone working on multiple projects. 🥇

The Final Showdown: Which is Best for You?

To make your decision easier, here's a concise comparison:

Feature	npm	Yarn	pnpm
Performance	Good	Very Good	Excellent ⚡️
Disk Space	Okay (flat `node_modules`)	Okay (similar to npm)	Excellent (shared global store) 💾
Dependency Model	Flat	Flat (with optional PnP)	Symlinked from a global store
Key Feature	Bundled with Node.js, simplicity	Workspaces, Plug'n'Play (PnP)	Unmatched efficiency, strictness
Best For	Beginners, small-to-medium projects	Large monorepos, professional teams	Performance-critical projects, CI/CD, limited disk

Choosing Your Champion:

Go with npm if you value simplicity, are new to JavaScript development, or are working on smaller projects where the default is perfectly adequate. It's the most common and has the largest community support.
Opt for Yarn if you're managing complex monorepos, need robust workspace features, or are interested in cutting-edge features like Plug'n'Play for highly optimized cold starts.
Embrace pnpm if performance and disk efficiency are paramount. For CI/CD pipelines, machines with limited disk space, or projects where every millisecond counts, pnpm offers a truly superior experience.

No matter your choice, each of these package managers has evolved significantly, offering robust and reliable ways to handle your project's dependencies. Experiment with them, understand their strengths, and pick the tool that empowers you to build the best software possible.

The Postman Alternative Guide: Which API Client is Right for You in 2025?

Amrishkhan Sheik Abdullah — Mon, 06 Oct 2025 11:44:59 +0000

For years, Postman has reigned as the undisputed champion of API clients. Its robust feature set for designing, testing, and documenting APIs has made it an essential tool for millions of developers. But the world of software development is not one-size-fits-all.

As workflows evolve, developers are increasingly seeking tools that are more lightweight, open-source, better integrated with version control, or specialized for protocols like GraphQL and gRPC. If you find yourself wondering what else is out there, you're in the right place.

This guide will walk you through the best Postman alternatives on the market today, helping you find the perfect tool for your specific needs.

The All-Rounder GUI Clients

These are the most direct competitors to Postman, offering a rich, graphical interface for a comprehensive API testing experience.

1. Insomnia

Often hailed as Postman's biggest rival, Insomnia offers a sleek, modern, and highly performant user interface. It excels in its clean design and first-class support for modern API protocols.

Key Features:
- Native support for REST, GraphQL, SOAP, and gRPC.
- Powerful environment and sub-environment management.
- Plugin system to extend functionality (e.g., custom themes, AWS authentication).
- Advanced code generation for over 30 languages and libraries.
Best for: Developers who work heavily with GraphQL or gRPC and appreciate a fast, clean interface.

2. Hoppscotch (formerly Postwoman)

Born from a need for a fast, open-source, and web-based alternative, Hoppscotch has grown into a mature and feature-rich platform. Its ability to run directly in the browser makes it incredibly accessible.

Key Features:
- Completely free and open-source.
- Web-based, installable as a PWA (Progressive Web App).
- Real-time collaboration features with support for teams and shared collections.
- Excellent support for REST, GraphQL, and real-time protocols like WebSocket and MQTT.
Best for: Teams looking for a free, collaborative, and easily accessible solution without requiring a desktop installation.

The Version Control Champions

For developers who believe API tests are code and should be treated as such, these tools offer seamless integration with Git.

Bruno

A rising star in the API client world, Bruno is built with a "Git-friendly" philosophy at its core. It stores all your API collections directly on your local filesystem in plain text files, making version control a breeze.

Key Features:
- Offline-first and completely local storage (no cloud sync unless you use Git).
- Collections are stored in a simple, human-readable markup language (Bru).
- Easy to collaborate on API tests via pull requests.
- Built-in support for scripting and assertions using JavaScript.
Best for: Developers and DevOps engineers who want to manage their API collections and tests within their existing Git workflow.

The Lightweight & In-Editor Heroes

Why leave your code editor? These extensions bring API testing directly into your development environment, streamlining your workflow.

Thunder Client

If you live inside Visual Studio Code, Thunder Client is a game-changer. It’s a lightweight and rest-client extension that provides a clean, Postman-like interface without ever needing to switch windows.

Key Features:
- Fully integrated within VS Code's UI.
- Supports collections, environment variables, and GraphQL.
- Simple interface for testing and viewing responses.
- Git-friendly, as collections can be saved as a JSON file in your project.
Best for: VS Code users who need a fast and convenient way to run API requests without the overhead of a separate application.

The Command-Line Champions

For those who prefer the speed and scriptability of the terminal, these CLI tools are unmatched in power and flexibility.

1. cURL

The original. cURL is the Swiss Army knife of data transfer and is pre-installed on virtually every Linux and macOS system. While it has a steep learning curve, its power for scripting and automation is unparalleled.

Key Features:
- Ubiquitous and incredibly versatile.
- Highly scriptable for use in shell scripts, CI/CD pipelines, and automated tasks.
- Supports a massive range of protocols.
Best for: Automation, scripting, and quick, one-off requests directly from the terminal.

2. HTTPie

HTTPie is designed to be a "cURL for humans." It offers the power of a CLI tool but with a much more intuitive syntax, sensible defaults, and beautiful, colorized output.

Key Features:
- Simple, expressive command syntax (e.g., http GET example.org q=='search term').
- JSON is the default, making it perfect for modern APIs.
- Formatted and colorized terminal output for easy reading.
- Persistent sessions and plugin support.
Best for: Developers who love the command line but want a more user-friendly experience than cURL.

So, Which Tool Should You Choose?

The best API client depends entirely on your workflow. Ask yourself these questions:

Do I need team collaboration? Look at Hoppscotch or the team plans for Insomnia.
Is version control a top priority? Bruno is built from the ground up for this. Thunder Client also works well with Git.
Do I work mostly inside my IDE? Thunder Client for VS Code is your best bet.
Is open-source a must-have? Hoppscotch and Bruno are excellent, fully open-source choices.
Do I need to automate tests in a CI/CD pipeline? cURL, HTTPie, or a dedicated framework like Karate are ideal.

The days of a one-tool-fits-all approach are over. The modern API ecosystem offers a fantastic array of clients, each with unique strengths. Don't be afraid to step outside your comfort zone and try a new tool—you might just find the perfect fit to supercharge your development process.

What's your go-to API client? Share your favorites in the comments below!

DEV Community: Amrishkhan Sheik Abdullah

Promise.all() Is Not Parallelism — And It Can Break Your System

The Problem Is Not Promise.all() Itself

Promise.all() Does Not Mean “Run Safely in Parallel”

The Hidden Cost of Starting Everything at Once

1. Concurrency Explosions

2. Rate Limiting Problems

3. Memory Spikes

4. Database Connection Exhaustion

5. API Throttling and Socket Errors

6. Retries Can Make the Problem Worse

7. Partial Failures Are Harder Than They Look

Promise.allSettled() Is Better for Partial Results

The Better Pattern: Limit Concurrency

Queue Patterns Are Even Better for Heavy Workloads

When Promise.all() Is Actually Fine

A Simple Rule I Follow Now

The Real Lesson

Final Thought

About the Author

Why I’m Building Local-First Developer Tools

The Industry Is Quietly Rebalancing Toward Local-First Applications

The Industry Is Quietly Rebalancing Toward Local-First Applications

What “Local-First” Actually Means

The Browser Became Far More Powerful Than Most People Realize

Cloud-Everything Has a Cost Nobody Talks About

Privacy Became an Afterthought

Performance Is Quietly Getting Worse

Offline Capability Is Massively Underrated

AI Is Quietly Making Local Processing More Important

Browser-Native Processing Is the Future

Real Examples of Where Local-First Makes Sense

JSON Formatting

API Testing

AI Workflows

Local-First Does NOT Mean Anti-Cloud

Developers Are Starting to Care Again

Why This Became My Direction

The Industry Isn’t Moving Backward — It’s Rebalancing

About the Author

Final Thoughts

The Most Underestimated Function in JavaScript: `reduce()`

Most Developers Meet reduce() at the Wrong Time

What reduce() Actually Means

How reduce() Actually Works

Visualizing the Flow

What Makes reduce() Different?

reduce() vs map()

map()

reduce()

reduce() vs forEach()

forEach()

reduce()

Why Developers Fear reduce()

The Golden Rule of reduce()

Simple Real-World Example: Grouping Data

Traditional Loop

Using reduce()

Why This Scales Better Mentally

Advanced Example: Permission Engine

reduce() Can Build Trees

Async Power: Sequential Promise Execution

The Biggest Misconception

Performance Discussion

Is reduce() Faster?

Where reduce() Becomes Extremely Useful

1. Single-pass transformations

2. Avoiding temporary arrays

3. Data normalization

But Don’t Abuse It

A Good Rule of Thumb

Why Senior Engineers Love It

Final Thoughts

About the Author

Why I Built Aruvix — One Local-First Toolkit for Every Developer Workflow

Table of Contents

Why Aruvix? Better than the Alternatives

What makes it better

JSON Formatter

Features

Most Developers Meet `reduce()` at the Wrong Time

What `reduce()` Actually Means

How `reduce()` Actually Works

What Makes `reduce()` Different?

`reduce()` vs `map()`

`map()`

`reduce()`

`reduce()` vs `forEach()`

`forEach()`

`reduce()`

Why Developers Fear `reduce()`

The Golden Rule of `reduce()`

Using `reduce()`

`reduce()` Can Build Trees

Is `reduce()` Faster?

Where `reduce()` Becomes Extremely Useful

1. `console.log()`: The Classic All-Rounder

2. `console.error()`, `console.warn()`, and `console.info()`: Adding Context to Your Logs

3. `console.table()`: Visualizing Data in a Structured Way

4. `console.group()` and `console.groupEnd()`: Organizing Your Console Output

1. `console.assert()`: Conditional Logging

2. `console.trace()`: Tracing the Call Stack

3. `console.time()` and `console.timeEnd()`: Measuring Performance

4. Styling Your Console Output with `%c`