Forem: Ankit

`useSyncExternalStore` — The React Hook You Didn't Know You Needed

Ankit — Tue, 07 Apr 2026 19:08:24 +0000

A deep dive into React's most underrated hook — what it is, why it exists, and how to use it like a pro.

The Problem It Solves
What Is useSyncExternalStore?
API Signature
A Simple First Example — Browser Tab Visibility
Understanding the Three Arguments
Server-Side Rendering & the getServerSnapshot
Real-World Use Cases
- Subscribing to a Custom Store
- Reading from localStorage Reactively
- Syncing with a Third-Party Library
- Network Online/Offline Status
Why Not Just Use useState + useEffect?
Tearing — The Core Problem This Hook Solves
Building a Mini State Management Library
Performance Considerations
Common Mistakes & Pitfalls
Compatibility & Polyfill
Summary

The Problem It Solves

Before we jump into the API, let's understand why this hook was introduced in the first place.

React 18 shipped with Concurrent Mode — a new rendering engine that can pause, resume, and prioritize renders. This is fantastic for performance, but it introduced a subtle bug in how React components read from external (non-React) state sources.

Imagine you have a global store (like a Redux store, a Zustand store, or even a plain JS Map) and two components read from it. In Concurrent Mode, React might render these components at different points in time, meaning one component reads the old value while the other reads the new one. This inconsistency in the UI is called tearing, and it's visually jarring.

useSyncExternalStore was built specifically to eliminate tearing when subscribing to external stores.

What Is `useSyncExternalStore`?

useSyncExternalStore is a React 18 hook that lets your components safely subscribe to external data sources — anything that lives outside of React's own state management (useState, useReducer, useContext).

External sources include:

Custom global stores
Browser APIs (navigator.onLine, document.visibilityState, localStorage)
Third-party libraries (Zustand, Redux, Valtio, etc.)
Any pub-sub observable

It was formally introduced in React 18 but is also available as a standalone package (use-sync-external-store) for React 16 and 17.

API Signature

const snapshot = useSyncExternalStore(
  subscribe: (callback: () => void) => () => void,
  getSnapshot: () => Snapshot,
  getServerSnapshot?: () => Snapshot
);

Three arguments, one return value. Clean and minimal.

A Simple First Example

Let's start with a classic: tracking whether the browser tab is visible or hidden.

import { useSyncExternalStore } from 'react';

function subscribe(callback: () => void) {
  document.addEventListener('visibilitychange', callback);
  return () => document.removeEventListener('visibilitychange', callback);
}

function getSnapshot() {
  return document.visibilityState;
}

function usePageVisibility() {
  return useSyncExternalStore(subscribe, getSnapshot);
}

// Usage in a component
function StatusBadge() {
  const visibility = usePageVisibility();

  return (
    <span>
      Tab is: <strong>{visibility === 'visible' ? '👁 Visible' : '🙈 Hidden'}</strong>
    </span>
  );
}

This is already cleaner and safer than the classic useEffect + useState approach. No race conditions, no tearing, and the subscribe function can be defined outside the component — meaning it doesn't get recreated on every render.

Understanding the Three Arguments

`subscribe(callback)`

This function is called once by React when the component mounts. It should:

Attach a listener to your external store.
Call callback whenever the store changes.
Return a cleanup function that removes the listener.

function subscribe(callback: () => void) {
  window.addEventListener('online', callback);
  window.addEventListener('offline', callback);
  return () => {
    window.removeEventListener('online', callback);
    window.removeEventListener('offline', callback);
  };
}

Critical rule: subscribe must be a stable reference (defined outside the component or wrapped in useCallback). If you pass a new function reference on every render, React will keep re-subscribing — causing an infinite loop.

`getSnapshot()`

This function is called by React to read the current value from the store. React calls it:

During rendering to get the current value.
After every store update to check if the value has changed.

function getSnapshot() {
  return navigator.onLine; // returns true or false
}

Critical rule: getSnapshot must return the same value when called multiple times if the store hasn't changed. React uses Object.is comparison. If you return a new object reference every time (return { ...state }), React will re-render infinitely.

`getServerSnapshot()` (optional)

This is for Server-Side Rendering (SSR). Since browser APIs aren't available on the server, you need to provide a fallback value. If omitted and you use SSR, React will throw an error.

function getServerSnapshot() {
  return true; // assume online on the server
}

Server-Side Rendering & the `getServerSnapshot`

If your app uses SSR (Next.js, Remix, etc.), the getServerSnapshot argument is not optional — it's essential.

Here's the full pattern for a safe, SSR-compatible hook:

import { useSyncExternalStore } from 'react';

function useNetworkStatus() {
  return useSyncExternalStore(
    (callback) => {
      window.addEventListener('online', callback);
      window.addEventListener('offline', callback);
      return () => {
        window.removeEventListener('online', callback);
        window.removeEventListener('offline', callback);
      };
    },
    () => navigator.onLine,     // client snapshot
    () => true                  // server snapshot (assume online)
  );
}

On the server, React uses getServerSnapshot. On the client, it uses getSnapshot. This ensures hydration matches.

Real-World Use Cases

1. Subscribing to a Custom Store

Let's build a simple reactive counter store and consume it with useSyncExternalStore.

// store.ts
type Listener = () => void;

let count = 0;
const listeners = new Set<Listener>();

export const counterStore = {
  getSnapshot: () => count,
  subscribe: (listener: Listener) => {
    listeners.add(listener);
    return () => listeners.delete(listener);
  },
  increment: () => {
    count++;
    listeners.forEach((l) => l());
  },
  decrement: () => {
    count--;
    listeners.forEach((l) => l());
  },
};

// Counter.tsx
import { useSyncExternalStore } from 'react';
import { counterStore } from './store';

function Counter() {
  const count = useSyncExternalStore(
    counterStore.subscribe,
    counterStore.getSnapshot
  );

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={counterStore.increment}>+</button>
      <button onClick={counterStore.decrement}>-</button>
    </div>
  );
}

Any number of Counter components rendered anywhere in your tree will always see the same value — no tearing, no stale reads.

2. Reading from `localStorage` Reactively

localStorage is a classic external store. Here's a hook that keeps a value in sync:

import { useSyncExternalStore, useCallback } from 'react';

function useLocalStorage<T>(key: string, initialValue: T) {
  const subscribe = useCallback(
    (callback: () => void) => {
      window.addEventListener('storage', callback);
      return () => window.removeEventListener('storage', callback);
    },
    []
  );

  const getSnapshot = useCallback((): T => {
    const item = localStorage.getItem(key);
    return item ? JSON.parse(item) : initialValue;
  }, [key, initialValue]);

  const getServerSnapshot = useCallback((): T => initialValue, [initialValue]);

  const value = useSyncExternalStore(subscribe, getSnapshot, getServerSnapshot);

  const setValue = useCallback(
    (newValue: T) => {
      localStorage.setItem(key, JSON.stringify(newValue));
      // Dispatch a storage event manually for same-tab updates
      window.dispatchEvent(new Event('storage'));
    },
    [key]
  );

  return [value, setValue] as const;
}

Note: The native storage event only fires across tabs, not within the same tab. The manual dispatchEvent handles same-tab updates.

3. Syncing with a Third-Party Library

Say you're using a third-party pub-sub or observable. Here's how to wrap it:

import { useSyncExternalStore } from 'react';
import { someExternalEmitter } from 'some-library';

function useExternalData() {
  return useSyncExternalStore(
    (callback) => {
      const unsubscribe = someExternalEmitter.on('change', callback);
      return unsubscribe;
    },
    () => someExternalEmitter.getCurrentValue()
  );
}

This is the pattern that state management libraries like Zustand and Redux use internally.

4. Network Online/Offline Status

import { useSyncExternalStore } from 'react';

const subscribe = (callback: () => void) => {
  window.addEventListener('online', callback);
  window.addEventListener('offline', callback);
  return () => {
    window.removeEventListener('online', callback);
    window.removeEventListener('offline', callback);
  };
};

export function useIsOnline() {
  return useSyncExternalStore(
    subscribe,
    () => navigator.onLine,
    () => true
  );
}

// In a component
function NetworkBanner() {
  const isOnline = useIsOnline();
  if (isOnline) return null;

  return (
    <div style={{ background: 'red', color: 'white', padding: '8px', textAlign: 'center' }}>
      You are offline. Some features may not be available.
    </div>
  );
}

Why Not Just Use `useState` + `useEffect`?

This is the most common question. You've probably written this pattern before:

// The classic pattern — looks fine, but has issues
function useIsOnline() {
  const [isOnline, setIsOnline] = useState(navigator.onLine);

  useEffect(() => {
    const handleOnline = () => setIsOnline(true);
    const handleOffline = () => setIsOnline(false);

    window.addEventListener('online', handleOnline);
    window.addEventListener('offline', handleOffline);

    return () => {
      window.removeEventListener('online', handleOnline);
      window.removeEventListener('offline', handleOffline);
    };
  }, []);

  return isOnline;
}

This seems reasonable. But it has three subtle problems:

Problem 1 — The initial value might be stale. By the time the effect runs (after paint), the network status could have already changed. There's a window where the component renders with a stale value.

Problem 2 — Tearing in Concurrent Mode. In React 18 with Concurrent rendering, two components using this hook could read different values of isOnline if a network change happens mid-render.

Problem 3 — No SSR safety. Calling navigator.onLine inside useState initializer will throw during SSR because navigator doesn't exist on the server.

useSyncExternalStore solves all three of these at the framework level.

Tearing — The Core Problem This Hook Solves

Let's make tearing concrete. Imagine two components read a global variable externalCount:

React starts rendering Component A → reads externalCount = 5
...concurrent pause happens...
externalCount changes to 6
...rendering resumes...
React renders Component B → reads externalCount = 6

Now your UI shows two different values for the same piece of data. That's tearing. It's a race condition baked into the rendering model.

useSyncExternalStore tells React: "When you render any component subscribed to this store, make sure all of them see the same snapshot." React guarantees this by synchronizing the render.

This is what the word "Sync" in the hook name means — it forces React to synchronize with the external store, even in Concurrent Mode.

Building a Mini State Management Library

Let's go further and use useSyncExternalStore to build a fully functional, type-safe, minimal state manager in ~40 lines:

// createStore.ts
import { useSyncExternalStore } from 'react';

type SetState<T> = (updater: Partial<T> | ((prev: T) => Partial<T>)) => void;
type Selector<T, R> = (state: T) => R;

export function createStore<T extends object>(initialState: T) {
  let state = initialState;
  const listeners = new Set<() => void>();

  const getState = () => state;

  const setState: SetState<T> = (updater) => {
    const partial =
      typeof updater === 'function' ? updater(state) : updater;
    state = { ...state, ...partial };
    listeners.forEach((l) => l());
  };

  const subscribe = (callback: () => void) => {
    listeners.add(callback);
    return () => listeners.delete(callback);
  };

  function useStore(): T;
  function useStore<R>(selector: Selector<T, R>): R;
  function useStore<R>(selector?: Selector<T, R>): T | R {
    return useSyncExternalStore(
      subscribe,
      selector ? () => selector(state) : getState
    );
  }

  return { getState, setState, subscribe, useStore };
}

// Usage
const { useStore, setState } = createStore({
  user: null as string | null,
  theme: 'light' as 'light' | 'dark',
  count: 0,
});

function ThemeToggle() {
  const theme = useStore((s) => s.theme); // only re-renders when theme changes

  return (
    <button onClick={() => setState({ theme: theme === 'light' ? 'dark' : 'light' })}>
      Switch to {theme === 'light' ? 'Dark' : 'Light'} Mode
    </button>
  );
}

function Counter() {
  const count = useStore((s) => s.count); // only re-renders when count changes

  return (
    <button onClick={() => setState((s) => ({ count: s.count + 1 }))}>
      Count: {count}
    </button>
  );
}

That's a fully working, selector-based, tear-free state manager in ~40 lines of code. This is essentially what Zustand does under the hood.

Performance Considerations

Define subscribe outside the component. Defining it inside causes a new function reference on every render, which triggers React to re-subscribe. Move it to module scope or wrap it in useCallback.
getSnapshot must be pure and stable. React calls it frequently. Keep it fast — just return a value, don't compute expensive things inside it.
Use selectors for large stores. Instead of subscribing to the entire store object, narrow down with a selector. React uses Object.is to compare snapshots, so if the selected slice hasn't changed, no re-render happens.
Avoid returning new objects from getSnapshot. This is the most common performance bug:

// ❌ BAD — returns a new object reference every call
const getSnapshot = () => ({ ...store.state });

// ✅ GOOD — returns a stable primitive or the same reference
const getSnapshot = () => store.state.count;

Common Mistakes & Pitfalls

Mistake	Why It's a Problem	Fix
Defining `subscribe` inside the component	New reference every render → infinite re-subscriptions	Move to module scope or use `useCallback`
Returning new objects from `getSnapshot`	`Object.is` always false → infinite re-renders	Return primitives or stable references
Forgetting `getServerSnapshot` in SSR apps	React throws a hydration error	Always provide it for any browser API access
Not returning the cleanup function from `subscribe`	Memory leak — listeners pile up indefinitely	Always `return () => removeListener(...)`
Using `getSnapshot` to compute derived state	Can cause subtle bugs with stale closures	Compute derived values outside the hook

Compatibility & Polyfill

useSyncExternalStore is available natively in React 18+.

For React 16.8–17, use the official shim:

npm install use-sync-external-store

// For React 16/17
import { useSyncExternalStore } from 'use-sync-external-store/shim';

// With server snapshot support
import { useSyncExternalStore } from 'use-sync-external-store/shim/with-selector';

The shim is maintained by the React team and is fully compatible.

Summary

useSyncExternalStore is the right tool whenever your component needs to read from anything that's not React state. It's not a niche hook for library authors only — it's a fundamental primitive for anyone doing:

Custom hooks that read from browser APIs
Integrating third-party stores or observables
Building micro state management solutions
Avoiding tearing in concurrent-mode apps

Here's the mental checklist: if you find yourself writing useEffect(() => { externalThing.subscribe(...) }, []) to keep local state in sync with something outside React — reach for useSyncExternalStore instead. It's safer, cleaner, and React 18-compatible from the ground up.

Happy building. Keep your stores external and your snapshots stable.

Shallow Copy vs Deep Copy in JavaScript (Explained Like You’re Five) — By Ankit Mehta

Ankit — Sat, 13 Dec 2025 04:39:03 +0000

Have you every copied something in JavaScript…

…changed one small thing…

…and suddenly your original data also changed?

If yes, then you’re welcomed to the Shallow Copy vs Deep Copy problem.

When I first learned JS, this concept confused me so badly that i felt JS was betraying me. So i finally sat down, understood, and here’s the simplest explanation you’ll ever find.

Let’s start with ‘ What ’ Question.

⭐What Does “ Copying ” Even Mean ?

If someone asks you to “copy” your homework, you’ll probably create a new page, right?

However, In JavaScript, copying works a little differently depending on whether the data is:

👉Primitive → numbers, strings, booleans

👉Non-primitive → arrays and objects

And things get a little weird with non-primitives.

⭐The Core Idea ( Point To Remember! )

There’s a golden rule:

A shallow copy copies the reference.
A deep copy copies the value.

Simple.

But to fully understand i’ll break it down with an analogy.

⭐The Pizza Analogy (So Simple You’ll Never Forget)

Just Imagine, you and your friend share a pizza.

Shallow Copy = You both get the SAME pizza.

If your friend eats a slice → your pizza also shrinks.

Deep Copy = You each get your OWN pizza.

Your friend eats → your pizza is safe.

And That’s it.

This is the entire concept.

Now let’s look at JavaScript examples.

⭐Shallow Copy in JavaScript

A shallow copy looks like a new copy…

..but inside, it still points to the same memory.

Example:


const original = { name: "Ankit" };

const copy = original; //not a real copy

if you change copy.name, the original also changes.

copy.name =  "Ankit"

console.log(original.name); // "Ankit"

Why?

Because both original and copy point to the same object in memory.

⭐Real Shallow Copy Methods in JavaScript

These create a new object/array…

…but only the top level values are copied.

Become a member
Array shallow copies

const arr = [1, 2, 3];
const shallow = [...arr];
// OR arr.slice();

Object shallow copies

const obj = { a: 1, b: 2 };
const shallow = { ...obj };
// OR Object.assign({}, obj);

But the trap:

If the object contains nested objects, those nested ones are STILL shared.

const user = {
  name: "Ankit",
  hobbies: ["coding", "gaming"],
};

const shallowCopy = { ...user };

shallowCopy.hobbies.push("fitness");

console.log(user.hobbies);  
// ["coding", "gaming", "fitness"] 😱

Because inside the object, hobbies is still the same array.

⭐Deep Copy in JavaScript

A deep copy makes a completely new object.

Nothing is shared.
Changes in the copy never affect the original.

Example:

const original = { name: "Ankit", skills: ["JS", "C++"] };

const deepCopy = JSON.parse(JSON.stringify(original));

deepCopy.skills.push("Node.js");

console.log(original.skills); 
// ["JS", "C++"] ✔️ unchanged

⭐Ways to Do Deep Copy

some common methods are:

1. JSON.parse( JSON.stringify() )
✔️easy

❌does NOT work for functions, dates, undefined, etc.

2. structuredClone() (Modern JS — BEST)

const deepCopy = structuredClone(original);

✔️ perfect deep copy
✔️ handles nested data
✔️ keeps types
✔️ fastest, cleanest
❌ not supported in very old browsers

3. Lodash cloneDeep()

if you use lodash:

const deepCopy = _.cloneDeep(obj);

When Should You Use What?

Use Shallow Copy when:

no nested objects inside
performance matters
the data is simple
you just need a quick copy

Use Deep Copy when:

there are nested objects/arrays
modifying the copy shouldn’t touch original
you’re dealing with APIs, forms, configs, Redux state, etc.

Key Points (Remember This!)

Shallow copy → copies reference
Deep copy → copies actual value
Spread operator (...) is shallow
structuredClone() is the best deep copy method
If your nested data is changing unexpectedly → you made a shallow copy by mistake

❤️Lastly…

If you are learning JavaScript, you will face bugs caused by shallow copying.

I faced them too. Everyone does.

But once you understand the difference between shallow and deep copy, your debugging will become easier, your code becomes cleaner and JS starts to make sense.

This article is not just for readers, it helped me understand the topic too.

Two birds, one stone.

npm Supply Chain Attack: A Wake-Up Call for JavaScript Developers

Ankit — Wed, 10 Sep 2025 11:04:05 +0000

On September 9th, 2025, the JavaScript world got a reminder that our tools are only as safe as the people who maintain them. A phishing email tricked a well-known developer, Josh Junan (aka Quicks Online), the maintainer of widely-used packages like chalk and debug. That one click gave attackers access to his npm account, and from there, they pushed out malicious updates.

What actually happened?

The malicious code wasn’t just random spam. It was a crypto clipper, a sneaky bit of malware that swaps out wallet addresses when users send cryptocurrency. To make it even trickier, it used the Levenshtein distance algorithm to generate fake addresses that looked almost identical to the real ones.

In plain English: imagine copying your friend’s wallet address to send them Ethereum, and at the last second, the malware replaces it with a scammer’s address that looks the same at a glance. That’s what happened at scale.

Within just a couple of hours, these compromised packages were downloaded millions of times.

The damage (and the irony)

You’d think with that reach, attackers would walk away with millions. In reality, they only got about $50 worth of ETH. Pretty anticlimactic, but the real cost here isn’t the money it’s trust.

Developers are now (once again) asking: how safe is our supply chain? If even widely trusted packages can be compromised so quickly, what does that say about the security practices across the ecosystem?

Some have even joked about renaming npm install to npm prey. Funny, but also a little too real.

Lessons worth taking seriously

If you’re a developer, this incident is a reminder to:

Don’t trust every email (even if it looks “official”).
Enable 2FA on your npm and GitHub accounts non negotiable.
Audit dependencies when possible, especially for critical apps.
Keep an eye on security advisories in the community.

Open-source thrives on trust, and that trust is fragile. Security isn’t something we bolt on at the end it has to be part of the workflow.

🔒 At the end of the day, this attack wasn’t about the $50. It was a loud reminder: our supply chain is only as strong as its weakest link.

JavaScript vs Python for AI Product Development: Which One Should You Choose?

Ankit — Thu, 04 Sep 2025 15:26:20 +0000

Artificial Intelligence (AI) is shaping the future of software products—but one question developers often face is: Should I use Python or JavaScript for AI product development?

Why Python?

Python has long been the backbone of AI and machine learning.

Rich libraries: TensorFlow, PyTorch, scikit-learn

Simplicity in syntax → faster prototyping

Strong community in research & academia

Best use-case: building, training, and experimenting with AI models.

Why JavaScript?

While Python dominates research, JavaScript powers the web.

Frameworks like TensorFlow.js & ONNX.js bring AI directly to browsers

Ideal for deploying models to millions of users without heavy backend

Perfect for building interactive, real-time AI products

Best use-case: integrating AI into scalable, user-facing applications.

So, which one to choose?

If you want to research and prototype AI models → Python is unmatched.

If you want to ship AI products to end-users quickly → JavaScript shines.

Final Thought

Think of it this way:

👉 Python builds the brain.
👉 JavaScript brings the brain to life on the web.

For modern AI product development, the smartest path may not be choosing one over the other—but knowing when to use both together.

Introduction to System Design

Ankit — Mon, 01 Sep 2025 06:50:28 +0000

System design involves understanding various components like load balancers, API gateways, caching, queue systems, and microservices to build robust, scalable, and highly available systems.
This guide provides a beginner-friendly overview of how these components work together in a real-world production environment.

Core Components: Client and Server

A client is any device (e.g., mobile, laptop, IoT device) that uses an application and sends requests to a server.
A server is a machine capable of running 24/7 with a public IP address, which is a unique address on the internet for reaching the server.
Cloud providers like AWS offer virtual machines that act as servers, providing 24/7 availability and public IPs, as it's impractical for personal computers to serve this role.

DNS (Domain Name System)

A DNS server is a global directory that maps human-readable domain names (e.g., amazon.com) to their corresponding IP addresses.
When a user types a domain name, the initial request goes to the DNS server, which returns the IP address, a process known as DNS resolution.

Scaling Strategies

Servers can become overwhelmed by increased user traffic, leading to crashes if their physical resources (CPU, RAM) are insufficient.
To handle high loads and ensure fault tolerance, systems must implement scaling.

Vertical Scaling

Increasing the physical resources (CPU, RAM, disk space) of a single existing server or virtual machine.

Pros

Improves capacity of a single machine to handle more traffic.

Cons

Requires down time (server restart) to add physical resources, making it unsuitable for applications requiring zero downtime during traffic spikes.
Can lead to resource waste and increased costs during periods of low traffic, as resources are provisioned for peak load.

Horizontal Scaling

Adding more identical servers (replicas) to distribute the workload, rather than increasing resources of a single server.

Pros

Provides zero down time during scaling, as new machines boot up while existing ones handle traffic.
Offers greater fault tolerance and resilience, as the failure of one server does not bring down the entire system.

Cons

Requires an additional component, a load balancer, to effectively distribute traffic among the multiple server replicas, as DNS can only return one IP address.

Load Balancers

A load balancer is a critical component placed in front of horizontally scaled servers to distribute incoming requests efficiently.
The DNS maps the domain name to the load balancer's IP address, which then intelligently routes requests to individual servers. s s
Load balancers use various algorithms (e.g., Round Robin, which distributes requests sequentially) to balance the load across servers.
They perform health checks to ensure that servers are active and ready to handle traffic before routing requests to them.
In cloud environments like Amazon, this service is often referred to as an Elastic Load Balancer (ELB), designed to be highly available and manage its own internal resources effectively.

Microservices and API Gateway

In a microservice architecture, an application is decomposed into smaller, independent services (e.g., authentication, orders, payments).
Each microservice can be independently scaled horizontally and typically has its own dedicated load balancer.
An API Gateway serves as a centralized entry point for all client requests, acting as a reverse proxy that routes requests to the appropriate microservice's load balancer based on defined rules (e.g., /auth requests go to the authentication service).
It can also integrate an authenticator service (e.g., Auth0) to authenticate users before routing their requests. s

Asynchronous Communication

For tasks like sending bulk emails or processing large data uploads, batch processing and background services are essential, as synchronous calls would overwhelm the system.
Synchronous communication, where a service waits for a response from another service, is not scalable for time-consuming operations.
Asynchronous communication allows services to interact without waiting, significantly improving system scalability and responsiveness.

Queue Systems (e.g., Amazon SQS)

Queue systems provide an asynchronous, First-In-First-Out (FIFO) communication channel between services.
A service pushes events (e.g., order IDs) into the queue, and dedicated worker processes pull and process these events independently.
This approach increases parallelism (multiple workers processing events concurrently) and enables rate limiting to manage dependencies on external APIs (e.g., limiting email sends to 10 per second to avoid hitting API limits).
Worker processes can use pull mechanisms to retrieve messages: short polling (frequent, short-duration checks) or long polling (waiting for a longer period, blocking until messages arrive or a timeout occurs).
Queue systems offer acknowledgment of message processing and support Dead Letter Queues (DLQ) for failed messages, allowing for retries and guaranteed processing.
SQS guarantees that each message is processed exactly once by a single consumer.

Pub/Sub Model (e.g., Amazon SNS)

The Pub/Sub (Publish/Subscribe) model is used when a single event needs to notify multiple services (one-to-many communication).
A service publishes an event (e.g., payment completed) to a notification service (topic), and all subscribed services receive and process it.
This forms the basis of an event-driven architecture. s s
A key limitation is the lack of inherent acknowledgment or retry mechanisms; if a subscriber fails to process a message, it might be lost without a built-in recovery process.

Fan-out Architecture

The Fan-out architecture combines the Pub/Sub model (SNS) with Queue systems (SQS) to achieve both multi-service notification and reliable message processing.

Rate Limiting

Rate limiting is essential to protect systems from being overwhelmed by excessive requests, including malicious DDoS/DoS attacks.
It defines how many requests a user or system can send within a specific time frame (e.g., 5 requests per second), blocking additional requests once the limit is hit.
Common strategies include Leaky Bucket and Token Bucket algorithms, which control the flow of requests to maintain system stability.

Database Optimization

A single database can become overwhelmed by a high volume of read and write requests from increasing services.
Read Replicas are copies of the primary database that handle read operations, especially for tasks like analytics or logging where slight data delay is acceptable.
All write operations and real-time data reads are directed to the primary (master) node to ensure consistency.
This strategy significantly reduces the load on the primary database, improving overall performance.

Caching

Caching stores frequently accessed data or results of complex computations in a faster, in-memory database (e.g., Redis) to reduce direct calls to the main database.
When data is requested, the system first checks the cache. If found, it's returned immediately; otherwise, it's fetched from the main database, stored in the cache, and then returned.
Caching dramatically optimizes system performance and reduces the load on backend databases.

Content Delivery Network (CDN)

A Content Delivery Network (CDN), such as Amazon CloudFront, deploys edge machines (micro machines) globally to serve content closer to users, minimizing latency.
These edge locations are internally routed to the main load balancer, and a single Anycast IP can be assigned to multiple CDN edges, directing users to the nearest available server.
CDNs cache content (e.g., images, videos) at these edge locations.
If a user requests content that is already cached in their regional
edge, it is served directly from the cache, bypassing the origin
server.
This process significantly improves user experience by reducing latency, saves network bandwidth, and decreases the load on the origin servers.

This process significantly improves user experience by reducing latency, saves network bandwidth, and decreases the load on the origin servers. ...
Here is a mind map illustrating the benefits of a CDN:

An event is published to an SNS topic, which then automatically delivers copies of the message to multiple SQS queues.
Each SQS queue is processed by its dedicated workers, benefiting from SQS's reliable features like acknowledgment, retries, and DLQs, ensuring that each downstream service reliably processes its part of the event.
This pattern is ideal for scenarios where one event triggers multiple independent and reliable actions, such as uploading a video and simultaneously triggering processes for transcription, different resolutions, and thumbnail generation.
There are ultimate physical limits to how much a single machine can be upgraded.
IP addresses are difficult to remember, prompting the need for user-friendly domain names.

Everything You Need to Know About new in JavaScript

Ankit — Thu, 28 Aug 2025 05:34:14 +0000

1. What does new do?

When you use new, Javascript:
Creates a new empty object: {}
Sets the new object's prototype to the constructor's prototype (obj.__proto__ = Constructor.prototype)
Runs the Constructor function with this bound to the new object
Returns the new object (unless the constructor explicitly returns another object)

2. Using new with a Constructor Function

function Person(name) {
  this.name = name;
}

const user = new Person("Ankit");
console.log(user.name); // "Ankit"

If you call person("Ankit") without new:

It won't create a new object.
this will refer to the global object (or undefined in strict mode)
name will be set on the wrong thing → Bug! That's why new is important.

3. Using new with a Class

class Car {
  constructor(brand) {
    this.brand = brand;
  }
}

const c1 = new Car("Tesla");
console.log(c1.brand); // Tesla

Your must use new with classes, or Js will throw an error.

4. What if the Constructor Returns Something?

If it returns an object, that object is returned instead of the new one.
If it returns a primitive (string, number, etc.), it's ignore, and the new object is returned.

function Test() {
  this.value = 10;
  return { msg: "I override!" };
}

const t = new Test();
console.log(t); // { msg: "I override!" }

5. Built-in Objects that use new

Many built-ins in JS can be created with new:

let now = new Date();
let regex = new RegExp("abc");
let obj = new Object();
let arr = new Array(3); // [empty × 3]

But some are fine without new:

let str = String(123); // "123"
let num = Number("5"); // 5

6. When NOT to use new:

Don't use new with normal functions that are not constructors.

function greet() {
  console.log("Hello!");
}

new greet(); // Works but makes no sense → {}

Building a Full-Stack App with Next.js & Prisma: Part 1 – Setting Up the Database Client

Ankit — Tue, 26 Aug 2025 11:45:15 +0000

0) Mental Model - What happens on a request?

User hits a route → middleware.ts checks whether they’re logged in and whether the route is public/protected/auth.
If sign-in is needed, user goes to /auth/sign-in and chooses Google or GitHub.
NextAuth + PrismaAdapter look up the user; if new, create User + Account; if existing, link the provider.
Callbacks enrich the JWT and session with id and role.
Client now has session.user.id and session.user.role for RBAC and UI.

1) Database Client (Prisma) — `lib/db.ts`

import { PrismaClient } from "@prisma/client"

const globalForPrisma = globalThis as unknown as { prisma: PrismaClient }

export const db = globalForPrisma.prisma || new PrismaClient()

if (process.env.NODE_ENV !== "production") globalForPrisma.prisma = db

At first glance, this may look a bit tricky. Let’s break it down.

import { PrismaClient } from "@prisma/client"

PrismaClient is the main tool you use to talk to your database
Think of it like a “bridge” that connects your code with your database (MySQL, PostgreSQL, SQLite, etc.).

const globalForPrisma = globalThis as unknown as { prisma: PrismaClient }

In Next.js (or any serverless environment), new instances of the code can spin up frequently.
If you create a new database client every time, you risk having too many open connections.
To prevent this, we attach Prisma to the global object (globalThis), so it can be reused.

This ensures that if Prisma is already created, we don’t create it again.

export const db = globalForPrisma.prisma || new PrismaClient()

Here, we check:
- If a Prisma instance already exists (globalForPrisma.prisma), use it.
- Otherwise, create a new one (new PrismaClient()).

This is the key step that prevents multiple Prisma clients from being created unnecessarily.

if (process.env.NODE_ENV !== "production") globalForPrisma.prisma = db

In development mode, your app refreshes and hot-reloads often.
Without this line, Prisma would create a new connection each time, eventually causing errors like: “Too many connections”.
This line ensures the same db instance is reused during development.

In production, Next.js doesn’t hot-reload, so we don’t need this safeguard.

So Why Does This Matters

✅ Prevents performance issues caused by too many connections.
✅ Works well with Next.js serverless functions.
✅ Shows professionalism: any recruiter or developer reviewing your code will see you understand real-world database issues.

Finally

This small snippet may look simple, but it solves a very common real-world problem.

JavaScript Event Loop: Microtasks vs Macrotasks Explained

Ankit — Fri, 22 Aug 2025 15:15:10 +0000

JavaScript is single-threaded. That means it can only do one thing at a time. So how does it handle asynchronous operations like setTimeout, fetch, or Promise? The answer lies in the Event Loop.

1. The Call Stack

JavaScript executes code line by line in the call stack. Once a function finishes, it gets popped off the stack. Simple enough — but async tasks can’t block the stack forever.

2. The Event Loop

The Event Loop is like a traffic cop. It constantly checks:

Is the call stack empty?
If yes, are there any pending tasks waiting in queues?

If so, it pushes them into the stack for execution.

3. Task Queues

Not all tasks are equal. They are divided into Macrotasks and Microtasks.

🔹 Macrotasks

Examples: setTimeout, setInterval, setImmediate, DOM events
They are scheduled in the Macrotask queue.
Executed one per loop iteration.

🔹 Microtasks

Examples: Promise.then, process.nextTick (Node.js), MutationObserver
Stored in the Microtask queue.
All microtasks are executed before the event loop continues to the next Macrotask.

4. Example in Action

console.log("Start");

setTimeout(() => console.log("Macrotask: setTimeout"), 0);

Promise.resolve().then(() => console.log("Microtask: Promise"));

console.log("End");

Output:

Start
End
Microtask: Promise
Macrotask: setTimeout

👉 Even though setTimeout was given 0ms, the Promise runs first because microtasks have higher priority.

5. Why It Matters

Misunderstanding this order can cause hard-to-debug async issues.
Knowing it helps optimize performance, avoid race conditions, and write predictable async code.

6. Key Takeaways

JavaScript runs one task at a time (single-threaded).
Event Loop decides what runs next.
Microtasks > Macrotasks in priority.
Promises resolve before timers.

⚡ Mastering the Event Loop is not trivia — it’s critical to writing reliable async JavaScript.

Why AI Won't Take Your Job, But Someone Using AI Will

Ankit — Wed, 20 Aug 2025 04:02:06 +0000

We've all seen the headlines. "AI Will Replace 300 Million Jobs!"

"Developers Obsolete by 2030!" "The Robot Apocalypse is Here!" But here's the thing: after working with AI tools daily and watching this transformation unfold in real-time, I've realized we're asking the wrong question.
The question isn't "Will AI take my job?" It's "Am I learning to work with AI fast enough?"

The Automation Paradox We've Seen Before

Remember when calculators were going to make mathematicians obsolete? Or when IDEs would eliminate the need for programmers because "anyone could code"?
What actually happened was more nuanced. These tools didn't replace professionals—they amplified the capable ones and left behind those who refused to adapt.
Today's AI revolution follows the same pattern, but at warp speed.

Why AI Alone Can't Replace You (Yet)

Let's be honest about what current AI can and can't do:
What AI excels at:

Generating boilerplate code faster than you can type
Explaining complex concepts in multiple ways
Debugging obvious syntax errors
Creating initial drafts of documentation
Brainstorming solutions to well-defined problems

What AI struggles with:

Understanding business context and stakeholder needs
Making architectural decisions that scale
Navigating office politics and client relationships
Knowing when to break the rules (and which rules to break)
Learning your team's specific workflows and conventions
Taking responsibility when things go wrong

AI is incredibly powerful, but it's still a tool. A very sophisticated tool, but a tool nonetheless.

The Real Threat: Your AI-Powered Colleague

Here's where it gets interesting. While AI won't replace you directly, someone who's mastered AI might.
Picture two developers applying for the same role:
Developer A writes code the same way they did five years ago. Solid skills, reliable, but their productivity hasn't changed much.
Developer B uses AI to:

Generate first drafts of functions and let them focus on architecture
Quickly prototype multiple approaches to compare solutions
Create comprehensive tests faster
Explain their code to stakeholders in plain English
Learn new technologies at 3x speed

Who do you think gets the job? Who gets the promotion? Who becomes indispensable to their team?

The AI Multiplication Effect

The developers I know who've embraced AI aren't just a little more productive—they're operating on a different level entirely. They're:

Shipping features faster because they spend less time on boilerplate
Exploring more solutions because iteration is cheaper
Learning continuously because AI makes unfamiliar codebases approachable
Communicating better because AI helps them explain technical concepts
Taking on bigger challenges because they have a powerful thinking partner

Meanwhile, developers who avoid AI are essentially choosing to compete with one hand tied behind their back.

How to Become the AI-Powered Developer

The good news? Learning to work effectively with AI isn't about mastering complex new technologies. It's about developing new habits and mindsets.

1. Learn to Prompt Like a Pro
Bad prompt: "Make a login function"
Good prompt: "Create a secure login function in Node.js with bcrypt hashing, rate limiting, and proper error handling. Include JSDoc comments and handle edge cases like empty inputs and SQL injection attempts."
The difference? Specificity, context, and clear expectations.

2. Use AI as a Thinking Partner, Not a Replacement
Don't ask AI to solve your problems. Ask it to help you think through them:

"What are the pros and cons of using Redis vs. Memcached for this use case?"
"What potential security vulnerabilities should I consider with this approach?"
"How would you refactor this function for better testability?"

3. Master the Feedback Loop
AI's first answer is rarely its best. Learn to iterate:

Get an initial solution
Ask for improvements or alternatives
Request explanations for parts you don't understand
Have AI review and critique its own work

4. Know When to Ignore AI

This might be the most important skill. AI can be confidently wrong, and knowing when to trust your expertise over the AI's suggestion is crucial.

The Skills That Matter More Than Ever

As AI handles more routine tasks, certain human skills become incredibly valuable:

Systems thinking: Understanding how pieces fit together in complex architectures
Product sense: Knowing what users actually need vs. what they ask for
Communication: Translating between technical and business stakeholders
Judgment: Making decisions with incomplete information
Creativity: Finding novel solutions to unique problems
Leadership: Guiding teams through ambiguous challenges

The Future is Collaborative

The most successful developers of the next decade won't be those who fight AI or those who surrender to it. They'll be the ones who learn to dance with it.
Think of AI as the ultimate junior developer: incredibly fast, vast knowledge, but needs direction and oversight. Your job isn't to compete with it—it's to conduct the orchestra.

Start Now, Start Small

You don't need to revolutionize your workflow overnight. Start with these small steps:

This week: Try using AI to explain a piece of code you didn't write
This month: Use AI to generate unit tests for an existing function
Next month: Have AI help you learn a new framework or library
Ongoing: Pay attention to which AI suggestions you accept vs. reject, and why

The Bottom Line
AI won't take your job, but it will fundamentally change what your job looks like. The question isn't whether this transformation will happen—it's whether you'll be leading it or scrambling to catch up.
The developers who thrive in the AI era won't be the ones with the most impressive GitHub profiles or the deepest knowledge of obscure frameworks. They'll be the ones who learned to amplify their human intelligence with artificial intelligence.
Don't fear the AI revolution. Join it.

What's your experience working with AI tools? Are you seeing similar patterns in your workplace? Share your thoughts in the comments below.

APIs Explained Simply: Talking to Servers like ordering at a Restaurant

Ankit — Tue, 19 Aug 2025 15:25:07 +0000

APIs can sound scary when you first hear about them.“Application Programming Interface” feels like a mouthful, right? But the truth is… you already use APIs every single day without even realizing it.

Let’s break it down with something we all love: food.

*The Restaurant Analogy *🍕

Imagine you’re sitting in a restaurant.

You (the user) are hungry.

The kitchen is where all the magic (data processing) happens.

But you don’t just walk into the kitchen and cook, right?

Instead, you use a waiter. 🧑‍🍳

You tell the waiter what you want: “One pizza with extra cheese, please.”

The waiter (the API) takes your request to the kitchen.

The kitchen prepares the pizza.

The waiter brings it back to you.

That’s exactly how APIs work.

In Tech Terms ⚙️

You (the user/app) → make a request.

The API (the waiter) → delivers your request to the server.

The Server (the kitchen) → does the heavy work.

The Response (your pizza) → comes back to you.

Simple!

A Real-World Example 🌦️

Let’s say you open a weather app.

You want to know today’s temperature.

The app asks the weather API: “Hey, what’s the temperature in Delhi?”

The API runs to the weather server, grabs the info, and serves it back.

Your app shows: “It’s 32°C and sunny 🌞.”

No need for you to dig into satellites or climate databases — the API handles it all.

Why APIs Are Awesome 🚀

They save time (you don’t reinvent the kitchen every time you want pizza).

They create consistency (the menu stays the same even if the kitchen changes).

They connect apps together (Google Maps inside your food delivery app? Yep, API!).

Final Bite 🍴

Next time you hear API, don’t panic. Just think of a waiter at your favorite restaurant — taking your order, talking to the kitchen, and bringing you exactly what you asked for.

APIs are not complicated monsters. They’re just the polite middlemen that keep our tech world running smoothly.

Why 2 Lines of Code Can Be Worse Than 100

Ankit — Sun, 17 Aug 2025 03:53:57 +0000

We often hear developers glorify “short code.” The common belief is: fewer lines = better code. But in reality, short code does not always mean good code. In fact, sometimes 100 lines of code can be far better than 2 lines of code.

Let’s understand this with a simple example:

The 9 Balls Puzzle

Imagine you have 9 balls, where 8 weigh the same and 1 is heavier. Your goal is to find the heavy ball using the minimum number of weighings.

The optimal solution requires just 2 weighings:

Divide the balls into 3 groups of 3.

Compare two groups. Then compare 2 balls from the heavier group.

In real life, this logic is simple when explained step by step.

But imagine if someone compressed the entire logic into two ultra-clever lines of code. Sure, it might run. But will the next developer (or even your future self) be able to read it, debug it, or extend it easily? Probably not.

The Illusion of Fewer Lines

2 lines of code: might look “smart” but can hide the actual thought process. It’s like solving the 9 balls puzzle by blurting out the answer without showing how you reached it. Impressive at first glance, but impossible to follow later.

100 lines of code: may seem long, but if written with clarity, comments, and step-by-step logic, anyone can trace the reasoning. Just like the step-by-step weighing process, it makes the solution transparent.

Readability > Brevity

Code is read far more often than it is written. When debugging at 3 a.m., you’d much rather have 100 clear lines than 2 “magical” ones.

Short code is not always efficient code. Efficient code is code that is easy to understand, maintain, and extend.

In other words:
👉 100 lines that anyone can understand are better than 2 lines that only you understand.

🔥 Nobody Talks About the Mental Debt of Being a Developer

Ankit — Wed, 28 May 2025 10:13:55 +0000

Let's be honest.
We all talk about technical debt - bad code, rushed features, and spaghetti logic that haunts our codebase.
But there's a deeper, darker kind of debt that nobody warns you about:

Mental Debt

-The cost of constantly switching contexts.
-The anxiety of open tabs.
-The guilt of unfinished side projects.
-The burnout masked as "grind".
and the worst part? it's normalized.

Context-Switching Isn’t a Skill - It’s a Trap

Every dev today is juggling:
-Frontend logic
-Backend APIs
-PR reviews
-CI/CD issues
-Slack messages
-"Just a quick call"

We treat multitasking like a flex.
It's not.
It's cognitive sef-harm.
your write 30 lines of code, get interupted,
and then return with zero flow.

But nobody teaches you how to protect your brain from the chaos.
you are expected to "manage"

Learning Never Ends - and That’s Exhausting

Every week, there's a new tool, a new JS framework, or a hot backend trick.
And if you are not constantly learning, then you're "falling behind"

But,
-what if you are tired?
-what if you just want to do good work with what you know?

That's not laziness.
That's sustainability
The pressure to never stop learning can quietly burn you out, even if you love tech.

Side Projects Are Romanticized Guilt Machines

Everyone says: "Build side projects!"
But what they don't say is:

-you"ll doubt yourself halfway through.
-you'll compare it to polished Dribble shots.
-you'll start thinking you're not good enough to build something "worthy".

We made side projects into portfolio, not playgrouds.
We stopped building for fun.

Now we build to prove something.

The Myth of loving what You Do

"you are lucky to code for a living".

Yes we are,
But when passion becomes pressure, it becomes poison|

When "doing what you love" becomes "doing 24/7" - you burn out.

And here's the truth:
You don't have to always love coding.
Your just have respect your boundaries.

The Conclusion is:

We are not robots,
we are not pipelines.
We are people who think, feel, get overwhelmed, and need breaks.

Let's normalize:

-Saying no
-Building slowly
-Logging off
-Not learning every new thing
-Protecting out energy

If you are feeling tired then you are not alone.
And no, you don't need to ship more to matter.