Forem: Nitin N.

I Thought I Understood Async — Until I Built a Real Task Runner in Node.js

Nitin N. — Sun, 18 Jan 2026 10:34:35 +0000

If you’ve ever written this:

await Promise.all(tasks.map(t => t()));

You’ve probably told yourself:

“That’s concurrency.”

I used to believe that too.

Then I tried to build something that behaved like a real system — not a tutorial.

What I wanted was simple on paper:
A Node.js task runner that could:

Run tasks concurrently
Retry failures
Never overload the system
Always reach a terminal state

What I got instead was a lesson in engineering humility.

The Problem That Started It

I wasn’t trying to optimize performance.
I was trying to build trust into my system.

In production, this is what really matters:

APIs fail
Networks lie
Logs deceive
Retries spiral out of control

So I asked myself:

If this were a job queue or microservice worker — would I trust it at 3 AM?

That question shaped everything.

What a “Task” Really Is

In my system, a task is not a promise.

It’s a function that returns a promise.

Why that matters:
Because retries require re-execution, not re-awaiting.

type Task<T> = () => Promise<T>;

This single design choice eliminated:

Stale promises
Broken retries
Phantom concurrency bugs

The Fake API That Told the Truth

Instead of mocking success, I mocked reality:

const fakeApi = (id, delay, shouldSucceed) => {
  const start = Date.now();
  console.info(`STARTING Task ID: ${id}`);

  return new Promise((resolve, reject) => {
    setTimeout(() => {
      const end = Date.now();
      if (shouldSucceed) {
        console.log(`SUCCEEDED Task ID: ${id} | Duration ${end - start}ms`);
        resolve(id);
      } else {
        console.error(`FAILED Task ID: ${id} | Duration ${end - start}ms`);
        reject(new Error(`${id} failed`));
      }
    }, delay);
  });
};

This gave me:

Real durations
Real failures
Real concurrency pressure

No illusions. Only evidence.

The Real Engineering Problem

The hard part wasn’t “running tasks.”

It was enforcing three laws:

1. Concurrency is a Hard Ceiling

Never more than MAX_CONCURRENT_TASKS running — even during retries.

2. Retries Must Be Deterministic

A failed task can retry — but it must never exist twice in-flight.

3. Everything Must End

Every task must reach:

Success
Or retry exhaustion

No zombies. No silent failures.

The Breakthrough Moment

The moment it clicked wasn’t when my code worked.

It was when my logs told a story:

STARTING Task ID: 2
FAILED Task ID: 2
STARTING Task ID: 2
FAILED Task ID: 2

That wasn’t noise.

That was controlled failure.

That’s what real systems do.

What This Taught Me About Backend Engineering

Concurrency isn’t about parallelism.
It’s about governance.

Retries aren’t about recovery.
They’re about discipline.

Logs aren’t for debugging.
They’re for truth.

Why This Pattern Matters in Production

This architecture maps directly to:

Job queues
Worker pools
Microservice orchestrators
API batch processors
Event-driven systems

If you can control this — you can control load, cost, and reliability.

Final Thought

Most developers learn async.

Engineers learn systems behavior.

This project pushed me from one side to the other.

Repo link - Concurrency Task Runner

[Boost]

Nitin N. — Fri, 26 Dec 2025 07:42:47 +0000

LineIcons

Apr 15 '25

Top 10 Icon Libraries for Next.js - 2026

#icons #nextjs #webdev #programming

Comments 4

6 min read

[Boost]

Nitin N. — Fri, 26 Dec 2025 06:39:04 +0000

Rowsan Ali

Feb 26 '25

How to Use @layer for Advanced Styling in Tailwind CSS

#webdev #programming #javascript #beginners

Comments 1

4 min read

Swapping Authentication Strategies Without Touching UI: A Frontend Architecture Demo

Nitin N. — Wed, 24 Dec 2025 17:34:41 +0000

When frontend applications grow, authentication is often the first place where architectural cracks appear.

JWTs, cookies, sessions, headers — each change tends to ripple through components, hooks, and state logic. Over time, the UI becomes inseparable from the authentication mechanism.

I wanted to explore what it looks like when that doesn’t happen.

The Goal

Build a frontend demo where:

The UI does not know how authentication works
Switching between cookie-based auth and JWT-based auth requires no UI changes
The swap happens at the composition boundary, not inside components

This demo is built on top of my frontend-foundation template, which enforces strict separation between UI, hooks, services, and implementations.

The Setup

The application exposes a single hook to the UI:

useAuth(client)

Everything downstream depends on a stable contract:

login()
logout()
getSession()

The UI never imports:

cookie logic
JWT logic
storage APIs
auth libraries

Two different clients implement the same contract:

cookieClient
jwtClient

Each client is passed into useAuth independently, allowing both strategies to run side-by-side on the same page.

Why This Matters

In many real-world projects:

Switching auth strategies means rewriting hooks
Components start branching on auth type
State logic leaks implementation details

This demo proves that those problems are architectural, not inevitable.

If auth is treated as an implementation detail behind a contract, the UI becomes resilient to change.

Repositories

Demo app: Frontend Foundation Auth Swap Demo

Template: Frontend Foundation Starter Kit

Closing Thoughts

If swapping core infrastructure feels risky, it’s usually a signal that the UI is coupled too tightly to implementation details.

The fix isn’t a new library — it’s better boundaries.

Swapping Redux and Jotai Without Touching UI: A Production-Grade Frontend Pattern

Nitin N. — Wed, 24 Dec 2025 04:47:23 +0000

Introduction

Frontend teams often debate Redux vs Jotai vs Zustand.

The real problem is not which library you choose — it’s how hard it is to change later.

This article demonstrates a compile-time state swap pattern using a frontend template I built, validated with a real demo app.

The Usual Problem

In most projects:

UI components import store-specific hooks
Business logic leaks into reducers or atoms
Changing state libraries means rewriting half the app

That is not scalable.

The Core Idea

UI should depend on contracts, not implementations.

In this template:

UI consumes a single useCounter() hook
That hook is the only swap boundary
Redux and Jotai both conform to the same outward shape

{
  count: number
  increment(): void
  decrement(): void
}

No UI changes.
No page-level changes.
No runtime assumptions.

State Swap in Action

The demo app contains:

One Counter page
One hook boundary
Two implementations:
- Redux Toolkit
- Jotai

Swapping engines means changing one import, nothing else.

Template Repo: Frontend Foundation Template Kit
State Swap Demo: State Management Swap Demo App

Why This Matters in Real Teams

This pattern:

Reduces long-term technical risk
Makes architectural decisions reversible
Allows teams to adopt new libraries safely
Fits enterprise and startup codebases alike

Closing Thoughts

Libraries will change. Frameworks will evolve.

Your architecture must survive those changes.

This template is my attempt to codify that principle. If this resonates, I’d love to hear your thoughts.

Why I Built a Frontend Template That Makes Swapping Libraries Boring

Nitin N. — Tue, 23 Dec 2025 09:38:28 +0000

Frontend projects rarely fail because of bad code.
They fail because change becomes expensive.

In many codebases:

UI imports fetch directly
State libraries leak into components
Infrastructure decisions become permanent

I wanted a different default.

I built Frontend Foundation, a minimal Next.js template designed around one constraint:

UI code should never care how data is fetched or stored.

The template enforces simple boundaries:
UI → hooks → services → clients

To validate this, I created a separate demo repository.

In that demo:

The UI renders a list of posts
Data can be fetched using fetch or axios
A button switches the implementation at runtime
No UI, hook, or service code changes

The swap happens behind a stable contract.

This is not a pattern for demos only. This is how long-lived frontend systems stay flexible.

The template itself stays intentionally minimal. Each project adds what it needs. Nothing is locked in.

If you’ve ever avoided refactoring because “it would touch too much,”
this approach is worth exploring.

Template repo:
frontend-foundation

HTTP swap Demo repo:
frontend-foundation-http-swap-demo

Frontend Foundation: A Swap-Friendly Next.js Starter Template

Nitin N. — Mon, 22 Dec 2025 11:25:13 +0000

Frontend developers often struggle with long-lived projects where UI becomes tightly coupled to state libraries, HTTP clients, or backend frameworks.

Frontend Foundation solves this by:

Decoupling UI from all implementations
Allowing library swaps without changing any frontend code
Using Tailwind CSS design tokens for scalable, maintainable styling

Key Features:

Next.js 14 App Router + TypeScript strict mode
Token-driven Tailwind CSS (dark/light themes via next-themes)
Clear folder responsibilities (hooks, services, clients, stores)
Documentation baked in via GitHub Pages

How to see it in action:

Template repo: https://github.com/NitinNair89/frontend-foundation
Sample apps (coming soon)

This starter kit is ideal for senior engineers and teams aiming for global-scale frontend architecture.

NextJS #TailwindCSS #WebDev #TypeScript #FrontendArchitecture

Fixing Unwanted Re-renders in a Nested Component Tree Using React Context

Nitin N. — Sat, 13 Dec 2025 11:44:04 +0000

*Not all React performance issues show up as errors.
*
Some appear quietly during development, when a simple UI interaction feels heavier than it should.

This article walks through a real dev-time issue caused by prop drilling and poor state placement — and how restructuring state fixed unnecessary re-renders, API calls, and heavy UI updates.

This was a React application where a parent component handled:

Fetching data from an API
Rendering a Highcharts-based visualization (expensive to re-render)

Deep in the component tree (2–3 levels down), there was a child component with a button.

Requirement:

When the button is clicked, show a modal.

Simple on paper.

The Initial Implementation

The modal state was defined in the parent component.

const Parent = () => {
  const [isModalOpen, setIsModalOpen] = useState(false);

  useEffect(() => {
    fetchData();
  }, []);

  return <Child setIsModalOpen={setIsModalOpen} />;
};

The setIsModalOpen function was passed down multiple levels via props until it reached the button.

<button onClick={() => setIsModalOpen(true)}>
  Open modal
</button>

Functionally, this worked.

Architecturally, it was problematic.

What I Observed During Testing

While casually testing the feature in development, I noticed:

A visible UI pause on button click
Highcharts re-rendering
API calls being triggered again

Every click caused a parent state update, which meant:

Parent component re-rendered
Side effects tied to the parent executed again
Expensive UI re-initialized unnecessarily

Nothing was broken — but the cost was real.

The Root Cause

The issue was state placement.

The modal state was UI-only.
It lived in a parent component responsible for data fetching and heavy rendering.
Prop drilling tightly coupled a local interaction to global side effects
This is a common architectural leak in React applications as they grow.

The Fix: Isolate UI State with Context

The solution was to remove modal state from the parent entirely and introduce a dedicated Context for modal visibility.

const ModalContext = createContext(null);

export const ModalProvider = ({ children }) => {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <ModalContext.Provider value={{ isOpen, setIsOpen }}>
      {children}
    </ModalContext.Provider>
  );
};

The provider was placed at the top-most boundary where modal state made sense.

Components that needed to open or close the modal consumed the context directly.

const { setIsOpen } = useContext(ModalContext);

No prop drilling. No parent involvement.

The Result

After this change:

Parent components no longer re-rendered on modal open
API calls executed only when explicitly intended
Highcharts remained stable
UI interactions felt immediate and predictable

The behavior was the same for users, but the architecture was cleaner and more performant.

Key Takeaways

Prop drilling can hide performance issues, even when code is correct
UI-only state should not live alongside data-fetching logic
If a button click triggers unrelated side effects, state boundaries are wrong
Context API is not just for global data — it is effective for isolating UI concerns

*Performance issues in React are often design issues in disguise.
*

Why Unit Tests in React Catch Bugs the UI Never Shows (Jest Real-World Example)

Nitin N. — Sat, 06 Dec 2025 06:24:05 +0000

Intro

In React applications, many bugs don’t show up as broken UI.
They hide in business logic, only surfacing under specific data conditions.

This is where unit tests in React — especially with Jest — become critical.

Recently, while updating a React component’s business logic, I ran into a situation where:

the UI worked perfectly
new tests passed
existing Jest tests started failing

That failure uncovered a hidden logic bug that manual testing never revealed.

This post walks through:

why this happens in real projects
how Jest and React Testing Library expose these issues
and how unit tests help developers catch bugs before production

The Problem: UI Looks Correct, Tests Don’t

The component showed an empty-state message when data was missing.
In the browser, everything worked as expected.

However, an older Jest test using mocked data failed.

That inconsistency mattered.

If deterministic tests fail while the UI passes, it usually means:
👉 logic behaves differently depending on data shape

This is exactly the kind of issue that unit tests are designed to catch.

Why Mocked Data Finds Bugs Faster Than Manual Testing

Mocked data often triggers scenarios that real accounts don’t.

In this case:

real data followed a happy path
mocked data exposed a processing assumption
the logic worked accidentally, not reliably

The test didn’t fail because the UI was wrong.
It failed because the business logic wasn’t robust.

Without Jest tests:

this bug would’ve slipped into production
or surfaced later during refactoring

Correct Jest Setup for React (Minimal & Practical)

Install dependencies:

npm install --save-dev jest @testing-library/react @testing-library/jest-dom

Configure Jest:

jest.config.js

module.exports = {
  testEnvironment: "jsdom",
  setupFilesAfterEnv: ["<rootDir>/jest.setup.js"],
};

jest.setup.js

import "@testing-library/jest-dom";

This setup mirrors browser behavior closely and avoids false positives.

Writing Unit Tests That Actually Catch Bugs

Avoid testing visuals.
Test conditions and outcomes.

import { getProcessedData } from '@util/helper';

describe('My Component', () => {
  it("shows empty message when data is missing", () => {
    const data = getProcessedData();
    render(<MyComponent data={data} />);
    expect(
      screen.getByText(/no data available/i)
    ).toBeInTheDocument();
  });
});

Tests like this:

validate business rules
protect against regressions
force safer logic paths

Tests like these (the test above is a simplified version for beginners) helped me detect the faulty data processing logic.

The Fix Was in the Logic, Not the UI

Once identified:

data normalization fixed the issue
all tests passed
UI remained unchanged

The key win wasn’t visual correctness — it was logical correctness.

Why React Unit Tests Matter in Production Code

React unit tests help developers:

Catch bugs during development
Reduce reliance on manual testing
Refactor safely
Ship with confidence

Coverage numbers are secondary. Confidence and correctness are the real goals.

If the UI works but tests don’t exist, the bug is just waiting.

I Thought My API Was Secure. I Was Wrong.

Nitin N. — Wed, 26 Nov 2025 17:39:14 +0000

I used to think API security was mostly covered by auth middleware and HTTPS.

If the token is valid, everything is good — right?

Wrong.

A few years ago, I was working on an API flow that looked solid on paper:

Auth
Role checks
Clean endpoints
Tests passing

Then a production issue came in. Not a crash. Not downtime. Something worse.

Data was being accessed… correctly. But by the wrong people.

The endpoints were protected. The logic behind them wasn’t.

We hadn’t violated rules.
We had violated assumptions.

That single incident rewired how I think about security.

Not as locking doors — but as designing systems where misuse is impossible.

Security is not a feature. It’s architecture.

It’s designing for:

the developer who will maintain your code
the user who will misuse it
the attacker you never expected
the API consumer who reads docs too literally

And today, I don’t build APIs assuming users behave correctly.

I build assuming someone will try to break it.

If you work with APIs — for money, identity, or user data —
security is not something you “add later.”

It’s part of your design signature.

Teaching Feature Flags to a Junior Changed How I Think About Architecture

Nitin N. — Mon, 24 Nov 2025 15:57:44 +0000

In a recent sprint, one of my junior developers asked me how *LaunchDarkly * actually fits into our React-Native-Web codebase. Not just the syntax — but the system around it.

It turned into one of my best mentoring sessions this year.

We discussed the fundamentals:

LaunchDarkly’s purpose in multi-platform environments
Why feature flags matter more than config toggles
How variations allow safe experimentation
How rules can target specific user segments
Why controlled rollouts reduce production anxiety
And how our RN-Web setup consumes flags in a unified pattern

What surprised me wasn’t the complexity — it was how powerful these concepts become once a developer truly understands them.

Teaching this reminded me of a simple truth:
Architecture isn’t about writing code. It’s about creating decisions that future developers can trust.

And sometimes, the biggest impact you make isn’t shipping a feature…

It’s helping someone else ship one, safely.

The Day I Learned What Actually Slows Down React Apps

Nitin N. — Sat, 22 Nov 2025 07:09:51 +0000

Every React developer thinks performance issues come from the backend—until they learn the truth.

I learned mine in the middle of a sprint where the backend team kept saying, “API is fast… the UI isn’t.”

They were right.

The Moment of Realization

A junior dev pinged me:

“Why does our UI freeze if the API is super fast?”

I opened the Profiler.

One component—just one—was re-rendering 19 times for one change.

We didn’t have a slow API.
We had unnecessary work.

The Fix

We applied:

React.memo for components with stable props
Debounced handlers
Avoided object spreading
Lazy loading
Bundle splitting

The fix wasn't magic. It was discipline.

The Result

32% faster load.
Smoother UI.
A happier team.

Takeaway

React performance isn’t about doing “more”. It’s about avoiding the unnecessary.

Forem: Nitin N.

I Thought I Understood Async — Until I Built a Real Task Runner in Node.js

The Problem That Started It

What a “Task” Really Is

The Fake API That Told the Truth

The Real Engineering Problem

The Breakthrough Moment

What This Taught Me About Backend Engineering

Why This Pattern Matters in Production

Final Thought

[Boost]

Top 10 Icon Libraries for Next.js - 2026

[Boost]

How to Use @layer for Advanced Styling in Tailwind CSS

Swapping Authentication Strategies Without Touching UI: A Frontend Architecture Demo

The Setup

Why This Matters

Repositories

Closing Thoughts

Other articles in this series

Swapping Redux and Jotai Without Touching UI: A Production-Grade Frontend Pattern

Introduction

The Usual Problem

The Core Idea

State Swap in Action

Why This Matters in Real Teams

Closing Thoughts

Other articles in this series

Why I Built a Frontend Template That Makes Swapping Libraries Boring

Frontend Foundation: A Swap-Friendly Next.js Starter Template

NextJS #TailwindCSS #WebDev #TypeScript #FrontendArchitecture

Fixing Unwanted Re-renders in a Nested Component Tree Using React Context

The Initial Implementation

What I Observed During Testing

The Root Cause

The Fix: Isolate UI State with Context

The Result

Key Takeaways

Why Unit Tests in React Catch Bugs the UI Never Shows (Jest Real-World Example)

Intro

The Problem: UI Looks Correct, Tests Don’t

Why Mocked Data Finds Bugs Faster Than Manual Testing

Correct Jest Setup for React (Minimal & Practical)

Writing Unit Tests That Actually Catch Bugs

The Fix Was in the Logic, Not the UI

Why React Unit Tests Matter in Production Code

I Thought My API Was Secure. I Was Wrong.

Teaching Feature Flags to a Junior Changed How I Think About Architecture

The Day I Learned What Actually Slows Down React Apps

The Moment of Realization

The Fix

The Result

Takeaway