DEV Community: Srashti Gupta

DPoP Explained: Making Stolen Access Tokens Useless

Srashti Gupta — Wed, 10 Jun 2026 06:12:28 +0000

Ever had this happen? Someone grabs your access token from the network tab, a log, or a leaked header — pastes it straight into Postman — and your API answers them like nothing's wrong. If that scenario makes you nervous, this post is for you.

A normal access token is a bearer token — like cash. Whoever holds it can spend it. Steal it from a log, an XSS bug, or a leaky proxy, and the thief is in.

DPoP ties the token to a private key only your client has. Now a stolen token alone is worthless — the attacker would also need the key, and the key never leaves the client.

One thing to be clear about up front: DPoP doesn't stop people from calling your API (that's rate limiting / WAF territory). It makes a leaked token un-replayable. That's the whole job — and for high-value or regulated APIs, it's a big one.

Spec: RFC 9449.

A normal OAuth 2.0 access token is a bearer token. The name is the whole story: whoever bears it can use it. The server does not check who is presenting the token — only that the token is valid.

That means a token is exactly like a $100 bill. If it falls out of your pocket and a stranger picks it up, it spends just as well for them as it did for you.

In an API, tokens "fall out of your pocket" more often than you'd think:

An XSS bug reads the token out of localStorage.
A token ends up in a log line, an error report, or an analytics payload.
A misconfigured proxy or a leaky third-party SDK forwards the Authorization header somewhere it shouldn't go.
A token sits in browser history or a shared device.

Once an attacker has the token, they replay it from their own machine and your server happily serves them, because the token is valid.

DPoP fixes this specific problem. It does not stop someone from hitting your endpoints (that's what rate limiting, WAFs, and authn at the edge are for). What it does is make a stolen token worthless to anyone except the client that originally requested it. So if you adopted it "to stop hackers calling your APIs," the precise framing is: a leaked token can no longer be replayed by an attacker. That's a big deal for high-value or regulated APIs — anything where forged calls at scale would be expensive or dangerous.

DPoP — Demonstrating Proof of Possession — is standardized in RFC 9449.

The core idea in one sentence

The client proves, on every single request, that it holds the private key that the token was bound to at the moment it was issued.

A stolen token without the matching private key is useless. To replay it, an attacker would need the token and the private key — and the private key never leaves the client (and, done right, can't be exported at all).

How it works: the moving parts

DPoP introduces three things:

A client-held key pair. The client generates an asymmetric key pair (commonly ES256). The private key stays on the client; the public key gets embedded in proofs.
A DPoP proof JWT. A short-lived, single-use JWT, signed with the private key, sent in a DPoP header on each request. It says "this request, this method, this URL, right now."
A binding on the token. When the token is issued, the authorization server records a thumbprint of the client's public key inside the token (the cnf.jkt claim). Every later request must present a proof signed by the matching private key.

What a DPoP proof actually looks like

The header identifies it as a DPoP proof and carries the public key:

{
  "typ": "dpop+jwt",
  "alg": "ES256",
  "jwk": {
    "kty": "EC",
    "crv": "P-256",
    "x": "l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs",
    "y": "9VE4jf_Ok_o64zbTTlcuNJajHmt6v9TDVrU0CdvGRDA"
  }
}

The payload describes the request it's bound to:

{
  "jti": "f1d9c0a2-7b3e-4c1a-9e2f-1c2b3a4d5e6f",
  "htm": "POST",
  "htu": "https://api.securestrip.example/v1/verify",
  "iat": 1718000000,
  "ath": "fUHyO2r2Z3DZ53EsNrWBb0xWXoaNy59IiKCAqksmQEo"
}

Claim	Meaning
`jti`	Unique ID for this proof — used for replay detection
`htm`	HTTP method this proof is valid for
`htu`	HTTP target URI (scheme + host + path, no query/fragment)
`iat`	Issued-at — proofs are only accepted within a small time window
`ath`	`base64url(SHA-256(access_token))` — ties the proof to a specific token (required when calling a resource server)
`nonce`	A server-supplied value, when the server demands one (more below)

The token binding (`cnf.jkt`)

When the authorization server issues a DPoP-bound access token, it computes the JWK SHA-256 thumbprint of the client's public key and stamps it into the token:

{
  "sub": "device-7741",
  "iss": "https://auth.securestrip.example",
  "aud": "https://api.securestrip.example",
  "exp": 1718003600,
  "cnf": {
    "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"
  }
}

cnf = "confirmation", jkt = "JWK thumbprint." This is the anchor. The resource server later recomputes the thumbprint from the proof's embedded jwk and checks it equals cnf.jkt. Match = the caller holds the right key. No match = rejected.

For opaque access tokens, the AS stores the binding server-side and returns the jkt via token introspection instead of putting it in the token.

One more change: the scheme is `DPoP`, not `Bearer`

A DPoP-bound token is presented like this:

GET /v1/verify HTTP/1.1
Host: api.securestrip.example
Authorization: DPoP eyJhbGciOiJSUzI1NiIsInR5cCI6...   <-- the access token
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZ...                <-- the fresh proof JWT

Two headers: the token (Authorization: DPoP ...) and a freshly minted proof (DPoP: ...).

The full flow, end to end

┌────────┐         1. token request + DPoP proof (key A)         ┌──────────────┐
│ Client │  ───────────────────────────────────────────────────▶ │ Authz Server │
│  (key  │                                                        │              │
│   pair)│ ◀───────────────────────────────────────────────────  │              │
└────────┘    2. access token with cnf.jkt = thumbprint(key A)    └──────────────┘
     │
     │  3. resource request
     │     Authorization: DPoP <token>
     │     DPoP: <proof signed by key A, with ath = hash(token)>
     ▼
┌──────────────────┐
│ Resource Server  │  4. verify proof signature, htm/htu, iat,
│                  │     jti not seen, thumbprint(jwk) == token.cnf.jkt,
│                  │     ath == hash(token)  →  serve or reject
└──────────────────┘

The magic is step 4's thumbprint check: it links the live request back to the key the token was issued for.

The "how": code

I'll use Node and jose, but the concepts map to any language.

Client — create and reuse a key pair

import { generateKeyPair, exportJWK } from 'jose';

// Generate ONCE per session and keep it for the session's lifetime.
const { publicKey, privateKey } = await generateKeyPair('ES256');
const publicJwk = await exportJWK(publicKey);

In the browser, generate the key with the WebCrypto API and mark it extractable: false. The private key then physically cannot be read out by JavaScript — even an XSS payload can ask it to sign, but can't steal the key itself. That's the single most important hardening step on the client.

Client — build a proof for each request

import { SignJWT } from 'jose';
import { createHash, randomUUID } from 'node:crypto';

const base64url = (buf) =>
  buf.toString('base64').replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');

const ath = (accessToken) =>
  base64url(createHash('sha256').update(accessToken).digest());

async function createDpopProof({ htm, htu, accessToken, nonce }) {
  const payload = { htm, htu, jti: randomUUID() };
  if (accessToken) payload.ath = ath(accessToken); // required at the resource server
  if (nonce) payload.nonce = nonce;                // when the server demands one

  return new SignJWT(payload)
    .setProtectedHeader({ typ: 'dpop+jwt', alg: 'ES256', jwk: publicJwk })
    .setIssuedAt()
    .sign(privateKey);
}

Client — call the API

const htu = 'https://api.securestrip.example/v1/verify'; // no query string!
const proof = await createDpopProof({ htm: 'POST', htu, accessToken });

const res = await fetch(htu, {
  method: 'POST',
  headers: {
    Authorization: `DPoP ${accessToken}`,
    DPoP: proof,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ stripId: '...' }),
});

Resource server — verify the proof

import { jwtVerify, importJWK, calculateJwkThumbprint, decodeProtectedHeader } from 'jose';
import { createHash } from 'node:crypto';

// In production use Redis with a TTL, not an in-memory Set (see "Cases" below).
const seenJti = new Set();

const base64url = (buf) =>
  buf.toString('base64').replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');
const ath = (token) => base64url(createHash('sha256').update(token).digest());

async function verifyDpop(req, tokenClaims) {
  const proofJwt = req.headers['dpop'];
  if (!proofJwt) return reject('missing_dpop_proof');

  // 1. Read the embedded public key from the header and verify the signature with it.
  const { jwk } = decodeProtectedHeader(proofJwt);
  const key = await importJWK(jwk, jwk.alg ?? 'ES256');
  const { payload } = await jwtVerify(proofJwt, key, { typ: 'dpop+jwt' });

  // 2. Bind the proof to THIS request.
  if (payload.htm !== req.method) return reject('htm_mismatch');
  const htu = `${req.protocol}://${req.get('host')}${req.path}`; // no query string
  if (payload.htu !== htu) return reject('htu_mismatch');

  // 3. Freshness — small window; widen only if you can't sync clocks.
  const now = Math.floor(Date.now() / 1000);
  if (Math.abs(now - payload.iat) > 30) return reject('proof_expired');

  // 4. Replay protection — each jti is single use.
  if (seenJti.has(payload.jti)) return reject('replay_detected');
  seenJti.add(payload.jti);

  // 5. THE binding check — does the caller hold the key the token was issued for?
  const thumbprint = await calculateJwkThumbprint(jwk);
  if (thumbprint !== tokenClaims.cnf?.jkt) return reject('token_not_bound_to_key');

  // 6. Tie proof to THIS token.
  const presentedToken = (req.headers['authorization'] || '').split(' ')[1];
  if (payload.ath !== ath(presentedToken)) return reject('ath_mismatch');

  return true;
}

That's the entire mechanism. Six checks, one of which (step 5) is the actual sender-constraining magic; the rest stop tampering and replay.

The "all the cases" part: what production actually throws at you

A toy implementation handles the happy path. A real one has to handle these.

Case 1 — Binding at the token endpoint (issuance)

The client sends a DPoP proof to the token endpoint (htu = the token URL). The AS reads the jwk, computes the thumbprint, and stamps cnf.jkt into the issued access token. No proof here ⇒ no binding ⇒ you've gained nothing. This is the root of trust.

Case 2 — Calling a protected resource

Covered above. Key point: the proof here must include ath (the hash of the token). Without it, an attacker who captured a valid proof for endpoint X could pair it with a different stolen token. ath welds proof and token together.

Case 3 — Refresh tokens must be bound too

For public clients (SPAs, mobile, native), the refresh token is also sender-constrained. The client sends a proof (with the same key) on every refresh call. This matters enormously: a stolen refresh token is a long-lived skeleton key. DPoP-binding it means a leaked refresh token can't be redeemed by an attacker either.

Case 4 — Server-supplied nonce (the strongest replay defense)

Relying only on iat + jti means an attacker who grabs a fresh proof has a few-second replay window. To close it, the server can demand a nonce it controls.

Server, when it wants a nonce:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: DPoP error="use_dpop_nonce", error_description="nonce required"
DPoP-Nonce: eyJ7S_zG.bC8...

The client reads DPoP-Nonce, rebuilds the proof with that nonce claim, and retries. Because the server issued the nonce (typically short-lived and single-use), proofs can't be pre-generated or replayed beyond it.

Client retry logic:

let res = await callApi();
if (res.status === 401 && wantsNonce(res)) {
  const nonce = res.headers.get('DPoP-Nonce');
  res = await callApi({ nonce }); // one retry with the fresh nonce
}

Build this retry loop from day one — many DPoP servers rotate nonces and will hand you a new one on responses, expecting it on the next call.

Case 5 — Replay protection at scale (`jti` store)

The seenJti Set above leaks memory and doesn't work across instances. In production:

Store each jti in Redis with a TTL equal to your accepted iat window (e.g. 60s). After that the proof is too old to replay anyway, so you can forget the jti.
Behind a load balancer, all API instances must share that store — otherwise a proof replayed against a different instance won't be caught.

const ok = await redis.set(`dpop:jti:${payload.jti}`, '1', 'EX', 60, 'NX');
if (!ok) return reject('replay_detected'); // NX failed ⇒ already seen

Case 6 — Clock skew and the `iat` window

iat is checked against server time. Mobile devices and browsers drift. Options, best to worst:

Require a nonce (Case 4) — then exact clock sync barely matters.
Allow a small symmetric skew (±30–60s).
Don't be tempted to widen the window to minutes — that's a bigger replay surface.

Case 7 — Key rotation mid-session

If the client rotates its key, the old token's cnf.jkt no longer matches. The client must obtain a new token bound to the new key (e.g. via a DPoP-bound refresh). Plan for "rotate key ⇒ re-bind tokens," and don't rotate more often than your token lifetime needs.

Case 8 — Multiple resource servers

Each resource server validates independently. htu differs per server, and each recomputes the thumbprint against the token's cnf.jkt. The same key pair works across all of them — the client just mints a fresh proof per request with the correct htm/htu.

Case 9 — Opaque tokens

No cnf claim to read locally. The resource server calls the AS introspection endpoint, which returns the bound jkt. Same thumbprint comparison, the binding just arrives via introspection instead of a JWT claim.

Case 10 — Proxies, TLS termination, and `htu` mismatches

The #1 real-world bug: your app sees http://internal-host/path while the client signed https://api.public.example/path. Then htu never matches and every request 401s.

Set app.set('trust proxy', true) (Express) so req.protocol/req.get('host') reflect the public URL.
Normalize htu consistently on both sides: scheme + authority + path, lowercased scheme/host, no default port, no query, no fragment.

Case 11 — Error responses your client must understand

Situation	Status	`error`
Proof malformed / signature bad / `htm`/`htu`/`iat` wrong	401	`invalid_dpop_proof`
Server requires a nonce	401	`use_dpop_nonce` (+ `DPoP-Nonce` header)
Token not bound to presented key	401	`invalid_token`

Your client should retry exactly once on use_dpop_nonce and surface the rest as auth failures.

The "when": should you actually use DPoP?

Reach for DPoP when:

You have public clients — SPAs, mobile apps, native apps — that can't keep a secret and where mTLS is impractical. This is the headline use case.
Your API is high-value or regulated — payments, health, identity, anti-counterfeit verification — where a replayed token causes real damage. (If a leaked token would let someone forge "this product is genuine" calls at scale, DPoP is squarely the right tool.)
You want defense in depth alongside short token lifetimes and good edge controls.

DPoP vs mTLS (RFC 8705): both sender-constrain tokens. mTLS does it at the transport layer with client certificates and needs a PKI — excellent for confidential server-to-server clients, painful for browsers and mobile. DPoP does it at the application layer with no PKI — built precisely for public clients. Many architectures use mTLS between back-end services and DPoP for user-facing apps.

You probably don't need it when:

It's pure server-to-server traffic where mTLS is already in place.
The endpoints are low-risk and a leaked token is cheap to revoke.
You can't yet afford the operational pieces below — in which case ship short token lifetimes + rotation first, then add DPoP.

What DPoP does not solve (set expectations honestly)

It is not a WAF or rate limiter. It doesn't stop traffic, block IPs, or throttle abuse. It makes stolen tokens unusable — that's the entire scope.
It doesn't save you from a fully compromised client. If an attacker is running inside your page/app with access to the signing key, they can sign valid proofs while they're there. Non-extractable keys limit them to while present (they can't exfiltrate the key for later/offline use), but they don't make a compromised client safe. Fix the XSS too.
It binds to a key, not to a TLS channel. That's by design — it's why it works for public clients — but it means transport-level guarantees still matter.
It adds moving parts: key lifecycle, a shared replay store, nonce handling, clock tolerance, and htu normalization behind proxies. Budget for those.

A pragmatic rollout checklist

Generate a non-extractable key pair per session (WebCrypto in browsers).
Bind tokens at the token endpoint and bind refresh tokens for public clients.
Send Authorization: DPoP <token> + a fresh DPoP: proof on every call; include ath.
On the server, verify: signature, typ, htm, htu, iat window, jti (shared store), cnf.jkt thumbprint, ath.
Implement the use_dpop_nonce 401 retry on the client and issue/rotate nonces on the server.
Use Redis (or equivalent) for jti/nonce state, shared across all API instances.
Set trust proxy and normalize htu so it survives TLS termination.
Keep token lifetimes short — DPoP is a complement to rotation, not a replacement.

Wrapping up

Bearer tokens trust possession. DPoP upgrades that to proof of possession: every request carries a fresh, signed challenge proving the caller still holds the private key the token was minted for. Steal the token, and without the key it's a coupon you can't redeem.

It won't keep attackers from knocking on your door — but it makes sure that when they do, the keys they picked up off the floor don't open anything.

Spec: RFC 9449 — OAuth 2.0 Demonstrating Proof of Possession (DPoP). Thumbprints: RFC 7638.

How CNNs Learn to See: A Beginner-Friendly Guide

Srashti Gupta — Tue, 26 May 2026 09:57:00 +0000

Humans don’t inspect every pixel of an image. We notice edges, colors, and shapes quickly.
A Convolutional Neural Network (CNN) works similarly.

This guide explains CNNs in simple terms using a cat photo example.

What is a CNN?

A CNN (Convolutional Neural Network) is a deep learning model built for image data.

It learns visual patterns like:

edges
corners
textures
object shapes
spatial relationships

Why not use a normal neural network?

A fully connected network can take image pixels as input, but it has issues:

treats each pixel as independent
ignores local pixel relationships
uses many parameters
struggles when object position changes

Hence, CNNs are preferred for image tasks.

Why CNNs are better for images

1) Local pattern detection

CNN scans the image in small patches with filters, first detecting simple patterns like edges.

2) Position robustness

A cat shifted left/right/up/down or slightly rotated is still recognized.

3) Efficient learning

The same filters are reused across the whole image, improving learning efficiency.

CNN architecture (simple flow)

Input Image → Convolution → ReLU → Pooling → (repeat) → Flatten → Fully Connected → Softmax

Cat example, step by step

Step 1: Convolution

Low-level layers detect:

ear boundary
whisker lines
fur texture
eye-edge contrast

Step 2: ReLU

ReLU keeps positive activations and removes negatives.

Example: [-3, 4, -1, 8] → [0, 4, 0, 8]

Step 3: Pooling

Max pooling keeps strongest signals and compresses data.

Example 2×2 block: [2, 6, 1, 4] → 6

Step 4: Deeper layers

Later layers detect bigger features:

cat ears shape
two eyes + nose location
body silhouette
cat on table pattern

Now the model understands “cat-like” structure, not just edges.

Step 5: Fully connected + Softmax

Flattened features are combined and final probabilities are produced:

Cat: 0.94
Dog: 0.03
Rabbit: 0.01
Sofa: 0.01
Chair: 0.01

Prediction: Cat (94%)

Tips to improve CNN performance

Batch Normalization: stabilizes training
Dropout: reduces overfitting
Data Augmentation: rotate, flip, crop, brightness change
Transfer Learning: fine-tune pre-trained models (MobileNet, ResNet, EfficientNet)

Common applications

image classification
face recognition
object detection (YOLO, Faster R-CNN)
medical image analysis
handwritten digit recognition (MNIST)
license plate detection
surveillance and retail systems

Conclusion

CNNs work so well with images because they learn hierarchically:
edges → shapes → parts → complete object.

Observability vs Monitoring: What Every Developer Must Know

Srashti Gupta — Thu, 19 Feb 2026 11:11:28 +0000

Observability Explained for Backend Engineers

Modern systems are no longer single applications running on one server.
They are distributed, containerized, and highly dynamic.

When something breaks in production, how do we find the root cause?

This is where observability comes in.

What is Observability?

Observability is the ability to understand the internal state of a system by analyzing its outputs.

In simple words:

Can we detect, debug, and fix production issues without logging into the server?

If yes — your system is observable.

🏗 The Three Pillars of Observability

Metrics

Metrics are numerical values over time.

Examples:

CPU usage
Memory usage
Request per second
Error rate
Latency (p95, p99)

Common tools:

Prometheus
Datadog

Logs

Logs are event-based records that provide detailed information.

Example:

Payment failed due to database timeout

Popular stack:

Elasticsearch
Logstash
Kibana

(Also known as ELK stack)

Traces

Traces track a single request across multiple services.

Example request flow:

User → API Gateway → Auth Service → Payment Service → Database → Response

Tools:

Jaeger
Zipkin
OpenTelemetry

🖼 Observability Architecture

⚖ Observability vs Monitoring

Monitoring answers:

“Is the system healthy?”

Observability answers:

“Why is the system unhealthy?”

Monitoring = Known issues
Observability = Unknown issues

Why Observability Matters in High-Traffic Systems

Imagine your system traffic increases 10×.

Suddenly:

Latency increases
Error rate spikes
Users complain

Without observability:
You guess.

With observability:
You know.

You can check:

CPU saturation
Database latency
Cache hit ratio
External API failures

This reduces Mean Time To Recovery (MTTR).

Advanced Concepts

SLI (Service Level Indicator)
SLO (Service Level Objective)
Error Budget
Structured Logging
Correlation IDs
Distributed Context Propagation

Conclusion

Observability is no longer optional.

In modern microservices and cloud-native systems, it is essential.

If you are building scalable backend systems, observability should be part of your design — not an afterthought.

WHY we use Mapped Types &Conditional Types in TS?

Srashti Gupta — Sun, 14 Dec 2025 09:54:47 +0000

We Use Mapped & Conditional Types in TypeScript (Real-World Examples)

When building real applications, we rarely deal with static types.
Data changes based on:

API responses
User roles
Form states
Backend validations

Mapped Types and Conditional Types help us reuse and transform existing types instead of rewriting them again and again.

Let’s understand why they exist, using simple real-world examples.

1. Why Mapped Types?

Problem (Real Life)

You have a User model coming from the backend:

type User = {
  id: number
  name: string
  email: string
  isActive: boolean
}

Now in real projects, you often need:

A form version (all fields optional)
A readonly version (API response)
A preview version (only some fields)

Without mapped types ❌ you’d rewrite types manually — which is error-prone.

Solution: Mapped Types ✅

Example 1: Form State (All Optional)

type UserForm = {
  [K in keyof User]?: User[K]
}

Now:

Adding/removing fields in User automatically updates UserForm
No duplicate type maintenance

This is exactly what Partial<User> does internally.

Example 2: Read-Only API Response

type ReadonlyUser = {
  readonly [K in keyof User]: User[K]
}

Why?

Prevents accidental mutation of API data
Very common in frontend apps

Example 3: Editable Fields Only

type EditableUser = {
  [K in "name" | "email"]: User[K]
}

Used when:

Only some fields are editable
Others (like id) should not be touched

2. Why Conditional Types?

Problem (Real Life)

Different APIs or functions return different data types based on input.

Example:

If user is "admin" → return full access
If user is "guest" → limited access

Solution: Conditional Types ✅

Example 1: Role-Based Data

type Role = "admin" | "user"

type Permissions<T> = T extends "admin"
  ? { canDelete: true; canEdit: true }
  : { canDelete: false; canEdit: true }

Usage:

type AdminPermissions = Permissions<"admin">
type UserPermissions = Permissions<"user">

Why this matters:

Type safety at compile time
No runtime role mistakes

Example 2: API Response Type

type ApiResponse<T> =
  T extends "success"
    ? { data: string }
    : { error: string }

type Success = ApiResponse<"success">
type Failure = ApiResponse<"error">

This matches how real APIs behave.

3. Why `infer`? (Very Practical Example)

Problem

You want to extract the data type from an API function automatically.

function fetchUser() {
  return { id: 1, name: "Srashti" }
}

Manually writing types ❌ is repetitive.

Solution: `infer` ✅

type ExtractReturn<T> =
  T extends (...args: any[]) => infer R ? R : never

type UserData = ExtractReturn<typeof fetchUser>

Why this is powerful:

Auto-syncs with function changes
No manual updates

This is how ReturnType<T> works internally.

4. Why Distributive Conditional Types?

Problem

You have a union type and want logic applied to each member.

type Input = string | number

Solution

type ToArray<T> = T extends any ? T[] : never

type Result = ToArray<string | number>
// string[] | number[]

Why this is useful:

Validating inputs
Transforming API payloads
Working with union types cleanly

5. Real Use of Utility Types (Behind the Scenes)

All of these are built using Mapped + Conditional Types:

Partial<T>
Pick<T, K>
Omit<T, K>
Exclude<T, U>
Extract<T, U>
ReturnType<T>

Example from real apps:

type UpdateUserPayload = Omit<User, "id">

Used when:

Backend auto-generates id
Frontend shouldn’t send it

6. Real-World Summary (Why We Actually Use Them)

We use Mapped Types when:

One base model has multiple variations
Forms, DTOs, API models differ slightly
We want DRY (Don’t Repeat Yourself) types

We use Conditional Types when:

Output type depends on input
Role-based or state-based logic
API responses vary

Final Thought

Mapped Types and Conditional Types are not “advanced for no reason”.
They exist because real applications are dynamic, and TypeScript helps us model that safely and cleanly.

Once you start using them, you’ll:

Write fewer bugs
Remove duplicate types

* Scale your codebase confidently

Generating Millions of Unique IDs in TypeScript — Fast, Scalable & Collision-Free

Srashti Gupta — Sat, 08 Nov 2025 14:09:15 +0000

✨ Why I Wrote This

While scaling a backend service recently, I hit a challenge — generating billions of unique IDs efficiently, without collisions, and without blowing up memory.
UUIDs were too long, and auto-increment IDs broke under distributed systems.

That’s when I explored Snowflake algorithms and combined them with Base62 encoding — producing short, globally unique IDs that can be generated in crores per minute.

Here’s what I learned 👇

1. Introduction

Ever wondered how Twitter, YouTube, or TikTok generate billions of unique IDs every day — instantly and safely?

Traditional methods like UUID or AUTO_INCREMENT are not scalable across distributed databases.
As systems grow, we need an ID generator that’s:

⚡ Fast
🧠 Memory-efficient
🧩 Collision-free
🔢 Compact & Sortable

Let’s explore how to build one — and even generate crores of unique IDs in seconds using TypeScript.

🧠 2. Key Requirements for a Scalable ID Generator

An ideal ID generator should be:

Unique — zero collision risk
Sortable — time-based for sequencing
Fast — able to generate millions/sec
Compact — fixed length (~13 chars)
Flexible — predictable or opaque

⚙️ 3. Popular Approaches

a) UUID / NanoID

✅ Simple, plug-and-play
❌ Not sortable
❌ UUIDv4 = 36 chars long
⚡ NanoID shorter but slower at massive scale

b) Snowflake Algorithm (used by Twitter, TikTok)

Snowflake generates a 64-bit integer using:

Timestamp
Machine ID
Process ID
Sequence Counter

It’s ultra-fast, distributed-safe, and scales horizontally across servers.

Example in TypeScript:

class Snowflake {
  private lastTimestamp = 0n;
  private sequence = 0n;
  private machineId: bigint;

  constructor(machineId: number) {
    this.machineId = BigInt(machineId) & 0b11111n; // 5 bits
  }

  private timestamp() {
    return BigInt(Date.now());
  }

  nextId() {
    let now = this.timestamp();
    if (now === this.lastTimestamp) {
      this.sequence = (this.sequence + 1n) & 0b111111111111n; // 12 bits
      if (this.sequence === 0n) now++;
    } else {
      this.sequence = 0n;
    }
    this.lastTimestamp = now;

    const id =
      ((now - 1700000000000n) << 17n) | (this.machineId << 12n) | this.sequence;
    return id.toString();
  }
}

🔢 4. Enhancing Snowflake with Base36/Base62 Encoding

To make IDs shorter, URL-safe, and more random-looking, encode them in Base62.

function toBase62(num: bigint): string {
  const chars = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
  let str = "";
  while (num > 0n) {
    const rem = num % 62n;
    str = chars[Number(rem)] + str;
    num = num / 62n;
  }
  return str.padStart(13, "0"); // fixed length 13
}

Now combine both:

const snow = new Snowflake(1);
const id = toBase62(BigInt(snow.nextId()));
console.log(id); // e.g. "00bX5ztuG8p3L"

✨ Result:
Short, unique, URL-safe, and crazy fast 🔥

⚡ 5. Performance Comparison

Method	Length	Sortable	Collision Risk	Speed	Memory Use
UUIDv4	36	❌	Low	Medium	Medium
NanoID	~21	❌	Low	Medium	Medium
Snowflake	19 digits	✅	Very Low	⚡ Very Fast	Low
Snowflake + Base62	11–13 chars	✅	Very Low	⚡⚡ Blazing	Low

🔒 6. Predictability vs Randomness

Snowflake IDs are time-sequential → predictable but easy to sort.
Adding Base62 encoding makes them opaque.
For extra randomness, add a salt or hash layer (SHA1 / MD5 hash slice).

🌍 7. Real-world Usage

🐦 Twitter, 💬 Discord, 📸 Instagram → use Snowflake-like systems
🔗 TinyURL, Bitly → use Base62 for compact links
☁️ Firebase / Firestore → time-based + random push IDs

🧮 8. Generating in Chunks (for Crores of IDs)

You can generate crores of IDs efficiently by batching them into chunks.
This avoids memory overload and stays lightning fast ⚙️

import fs from "fs";

const snow = new Snowflake(1);
const CHUNK_SIZE = 100_000; // 1 lakh IDs
const TOTAL = 10_000_000;   // 1 crore IDs

const output = fs.createWriteStream("ids.txt", { flags: "a" });

async function generateIDs() {
  console.time("Generation");
  for (let i = 0; i < TOTAL; i += CHUNK_SIZE) {
    let chunk = "";
    for (let j = 0; j < CHUNK_SIZE; j++) {
      const id = toBase62(BigInt(snow.nextId()));
      chunk += id + "\n";
    }
    output.write(chunk);
    console.log(`✅ Generated ${i + CHUNK_SIZE} IDs`);
  }
  output.end();
  console.timeEnd("Generation");
}

generateIDs();

💡 This can easily scale to tens of crores of unique IDs with constant memory usage.

🧭 9. Best Choice

Use Case	Recommended Method
Distributed systems (Twitter, Discord)	Snowflake + Base62
Small apps / prototypes	NanoID
Human-readable short links	Random Base62 + Collision Check

🏁 10. Conclusion

A strong ID generation system is the backbone of scalability.

By combining Snowflake with Base62 encoding, we get IDs that are:

⚡ Fast
🧩 Compact
🌍 Globally unique
⏱️ Time-sortable

Perfect for e-commerce, URL shorteners, and microservice architectures.

💬 Would you like me to write a follow-up on multi-threaded ID generation (using Node.js Workers) to scale to 100+ crore IDs? Comment below!

💡 If you found this helpful, follow me for more backend & TypeScript scalability insights!

Mastering Type Annotations in TypeScript: A Beginner’s Guide

Srashti Gupta — Tue, 28 Oct 2025 13:25:17 +0000

TypeScript makes JavaScript smarter — and Type Annotations are the brain behind it. 🧩

💡 What Are Type Annotations?

Type annotations let you explicitly define the type of a variable, function parameter, or return value in TypeScript.
They’re written using a colon (:) followed by the type.

let message: string = "Hello, TypeScript!";

function add(a: number, b: number): number {
return a + b;
}

Here:

message is a string
a and b are numbers
The function add returns a number

🎯 Why Use Type Annotations?

Even though TypeScript can infer types, using explicit annotations gives you more control and clarity.

✅ Clarity & Readability – self-documenting code
✅ Error Detection – catch mistakes before runtime
✅ IDE Support – better autocompletion and refactoring

🔧 Where Type Annotations Are Used

Let’s explore the most common use cases 👇

1. 🧮 Variables & Constants

let name: string = "Alice";
const age: number = 30;
let isActive: boolean = true;

These ensure that each variable holds only the correct type of data.

2. 📦 Arrays

You can annotate arrays in two ways:

let numbers: number[] = [1, 2, 3];
let names: Array = ["Bob", "Charlie"];

Both are valid; pick your preferred style.

3. 👥 Object Types

Anonymous Object Type

function printPerson(person: { name: string; age: number }) {
console.log(Name: ${person.name}, Age: ${person.age});
}

Named Object Type (Using Interface)

interface User {
id: number;
username: string;
}

let user: User = { id: 1, username: "John Doe" };

✅ Tip: Use interfaces when multiple objects share the same structure.

4. 🔢 Function Return Types

Specify what a function should return for safety and clarity.

function multiply(a: number, b: number): number {
return a * b;
}

function logMessage(message: string): void {
console.log(message);
}

Use void for functions that don’t return anything.

5. 🔁 Type Aliases for Functions

A type alias defines a reusable function pattern.

type MathOperation = (x: number, y: number) => number;

let subtract: MathOperation = (a, b) => a - b;

This is perfect for maintaining consistency across multiple operations.

🧩 Summary Table

Concept	Example	Description
Variable Type	`let name: string = "Alice"`	Defines type of variable
Function Params	`function add(a: number, b: number)`	Ensures input types
Return Type	`: number`	Specifies return value type
Array	`let arr: number[] = [1,2,3]`	Defines element type
Interface	`interface User { id: number; name: string }`	Defines object structure
Type Alias	`type Operation = (x: number, y: number) => number`	Function type pattern

🚀 Final Thoughts

Type annotations are the backbone of TypeScript’s type safety.
They turn your JavaScript into a predictable, readable, and maintainable codebase.

💬 As your project grows, explicit type annotations save hours of debugging and make your app scalable.

🧑‍💻 Written by: Srashti Gupta
📅 Published on: October 2025
🏷️ #typescript #javascript #webdev #programming #beginners

TypeScript Important Concepts Every Developer Should Know

Srashti Gupta — Thu, 09 Oct 2025 17:17:37 +0000

TypeScript is an open-source programming language that builds on JavaScript by adding optional static typing and class-based object-oriented programming.

It helps developers write more reliable, scalable, and maintainable code — especially in large-scale projects.

In this article, we’ll explore 10 key TypeScript concepts that every developer should understand.

1. Type Annotations

Type annotations let you specify the data type of variables, function parameters, and return values.
This helps catch errors early and improves code readability.

let age: number = 27;

Here, age must always be a number.
If you try assigning a string to it, TypeScript will throw a compile-time error.

2. Interfaces

An interface defines the shape of an object — its structure and property types.
It ensures consistency across multiple objects.

interface Person {
  name: string;
  age: number;
}

let user: Person = { name: "Srashti", age: 25 };

💡 Tip: Interfaces help enforce structure, making code predictable and self-documenting.

3. Classes

TypeScript supports full object-oriented programming (OOP) through classes.
They serve as blueprints for objects, supporting inheritance, constructors, and access modifiers.

class Animal {
  name: string;

  constructor(name: string) {
    this.name = name;
  }
}

Here, Animal is a class with a property name and a constructor that initializes it.

TypeScript extends JavaScript classes with features like access modifiers (public, private, protected) and readonly properties.

4. Generics

Generics let you write reusable and type-safe functions, interfaces, and classes.
They help avoid code duplication while maintaining flexibility.

function identity<T>(arg: T): T {
  return arg;
}

let output1 = identity<string>("Srashti");
let output2 = identity<number>(25);

✅ Why use Generics?
They allow your functions to work with any data type, ensuring type safety without losing flexibility.

5. Enums

Enums define a set of named constant values — useful when dealing with a predefined list of options.

enum Color {
  Red,
  Green,
  Blue
}

You can also assign specific numeric values:

enum Color {
  Red = 1,
  Green = 2,
  Blue = 4
}

This makes your code more readable and prevents invalid values.

6. Type Inference

TypeScript can infer types automatically based on assigned values.

let age = 27; // inferred as 'number'

Even without explicit type annotations, TypeScript understands that age is a number.

It also infers function return types:

function add(a: number, b: number) {
  return a + b; // inferred as number
}

7. Union and Intersection Types

Union types allow variables to hold multiple possible types.

let age: number | string = 27;
age = "twenty-seven";

Intersection types, on the other hand, combine multiple types into one.

type Dog = { bark(): void };
type Cat = { meow(): void };

type Animal = Dog & Cat;

Here, Animal includes both bark() and meow() methods.

8. Type Guards

Type guards allow you to check variable types at runtime, especially when using unions.

function printValue(value: number | string) {
  if (typeof value === "number") {
    console.log(value * 2);
  } else {
    console.log(value.toUpperCase());
  }
}

Type guards help you safely handle multiple types in a single function.

9. Decorators

Decorators are metadata annotations for classes, methods, or properties.
They are often used in frameworks like Angular and NestJS for dependency injection and configuration.

@deprecated
class MyClass {
  // ...
}

This example marks the class as deprecated.
Decorators are still an experimental feature, so you need to enable them in your tsconfig.json file ("experimentalDecorators": true).

10. Modules

Modules help organize code into smaller, reusable pieces.
They allow you to export and import variables, classes, or functions between files.

// mathUtils.ts
export function add(a: number, b: number) {
  return a + b;
}

// main.ts
import { add } from './mathUtils';
console.log(add(10, 5)); // 15

Modules make code modular, maintainable, and easy to scale.

🎯 Final Thoughts

TypeScript adds a powerful type system and OOP features to JavaScript, helping developers build large, error-free applications.

Mastering these 10 concepts — from type annotations to generics and modules — will greatly improve your ability to write clean, robust, and professional TypeScript code.

🌟 Understanding Generics in TypeScript: The Key to Reusable, Type-Safe Code

Srashti Gupta — Thu, 09 Oct 2025 16:50:55 +0000

Generics are a fundamental feature in TypeScript that allow developers to create reusable, flexible, and type-safe components.
They enable functions, classes, and interfaces to work with different data types without losing type information — ensuring both code reusability and type safety.

🧩 Why Do We Need Generics?

1. Code Reusability

Generics allow you to write a single function, class, or interface that can operate on different data types.

Without generics, you might end up writing multiple versions of the same function for each data type.
Generics solve that problem by using type parameters — placeholders for any type.

function identity<T>(arg: T): T {
  return arg;
}

let output1 = identity<string>("myString");
let output2 = identity<number>(100);

Here, <T> acts as a type variable, allowing the same function to handle both string and number without duplicating logic.

2. Type Safety

Generics enable compile-time type checking, catching errors early in the development process — long before they cause runtime issues.

TypeScript knows exactly what type you’re working with, which improves both reliability and maintainability.

3. Improved Code Readability

By explicitly defining generic types, you make your code’s intent clearer.
Readers and collaborators can easily understand the expected data types and structure.

🧠 Generic Building Blocks

Type Parameters

Generic types use type parameters, usually represented by uppercase letters inside <>:

Symbol	Meaning
`T`	Type
`K`	Key
`V`	Value

⚙️ Generic Functions

A generic function allows you to handle multiple data types with one implementation.

function identity<T>(arg: T): T {
  return arg;
}

let output1 = identity<string>("Srashti");
let output2 = identity<number>(25);

🧾 Generic Interfaces

Generic interfaces define contracts for objects that can work with multiple data types.

interface GenericIdentityFn<T> {
  (arg: T): T;
}

function identity<T>(arg: T): T {
  return arg;
}

let myIdentity: GenericIdentityFn<number> = identity;

This ensures that the identity function only works with the data type defined (number in this case).

🏗️ Generic Classes

A generic class can handle data of different types dynamically.

class GenericNumber<T> {
  zeroValue: T;
  add: (x: T, y: T) => T;
}

let myGenericNumber = new GenericNumber<number>();
myGenericNumber.zeroValue = 0;
myGenericNumber.add = function (x, y) { return x + y };

This makes it easy to create flexible classes that adapt to multiple data types.

🔒 Generic Constraints

Sometimes, you want to restrict what kinds of types can be passed to a generic.
You can use constraints with the extends keyword.

interface Lengthwise {
  length: number;
}

function loggingIdentity<T extends Lengthwise>(arg: T): T {
  console.log(arg.length); // Safe access to 'length'
  return arg;
}

Now, only types that have a length property (like strings or arrays) can be used with this function.

🌐 Generics in TypeScript APIs

When building APIs, generics make your functions and interfaces reusable and type-safe — especially for API responses that share the same structure but contain different data types.

1. Generic Interface for API Response

interface ApiResponse<T> {
  success: boolean;
  data: T;
  message?: string;
}

Here, T represents the type of data returned by the API — it can be User[], Product[], or anything else.

2. Generic Function for Fetching Data

async function fetchData<T>(url: string): Promise<ApiResponse<T>> {
  const response = await fetch(url);
  if (!response.ok) {
    throw new Error(`HTTP error! status: ${response.status}`);
  }
  const result: ApiResponse<T> = await response.json();
  return result;
}

This function adapts to any API endpoint while maintaining strict type safety.

3. Using Generic Types with Different Data

interface User {
  id: number;
  name: string;
  email: string;
}

interface Product {
  id: number;
  name: string;
  price: number;
}

// Fetch Users
async function getUsers() {
  try {
    const userResponse = await fetchData<User[]>('/api/users');
    console.log(userResponse.data); // Type: User[]
  } catch (error) {
    console.error(error);
  }
}

// Fetch Products
async function getProducts() {
  try {
    const productResponse = await fetchData<Product[]>('/api/products');
    console.log(productResponse.data); // Type: Product[]
  } catch (error) {
    console.error(error);
  }
}

💡 Benefits of Using Generics in APIs

✅ Type Safety: Prevents type mismatches and runtime errors.
✅ Reusability: Use the same logic for different endpoints.
✅ Reduced Code Duplication: Write once, use everywhere.
✅ Improved Readability: Clearly define the shape and type of expected data.

🚀 Conclusion

Generics are one of the most powerful features in TypeScript.
They make your code cleaner, safer, and more scalable — perfect for building robust applications or APIs.

Whether you’re creating utility functions, classes, or API handlers, mastering generics will level up your TypeScript skills and help you write professional, production-ready code.

🛠 Common CI/CD Errors in Docker + AWS ECS Deployment (and How to Fix Them)

Srashti Gupta — Tue, 15 Jul 2025 13:31:27 +0000

Facing issues while deploying your Node.js app to AWS ECS with Docker and GitHub Actions? Here’s a complete list of common CI/CD errors and easy, step-by-step solutions with clear explanations. ✅

🔍 Issue & 🛠 Fix Table

🔍 Issue	🛠 Fix
❌ Docker build fails	✅ Check Dockerfile syntax and `.dockerignore` context
❌ Missing secrets	✅ Add all secrets in GitHub → Settings → Actions → Secrets
❌ ECS service fails to deploy	✅ Double-check ECS cluster, task def, and service names
❌ App crashes in ECS	✅ View logs under ECS → Tasks → Logs
❌ Latest image not deployed	✅ Use `--force-new-deployment` in ECS or update image tag

🔍 Error: Docker Build Fails

Message:
Docker build command fails, often with missing file or bad instruction errors.

Cause:

You likely forgot to copy package.json correctly in your Dockerfile (or misplaced the order).

Fix:

COPY package*.json ./
RUN npm install
COPY . .  # copy source only after dependencies

🔍 Error: Missing Secrets or Environment Variables

Message:

MONGO_URI is undefined

Cause:

Your code references secrets/env-vars not passed along in the ECS definition.

How to Fix:

Go to ECS → Task Definitions.
Add required environment variables: e.g., MONGO_URI, JWT_SECRET.
(Alternatively) Use AWS Secrets Manager and reference them in the task.

🔍 Error: ECS Fails to Deploy New Task

Messages:

npm ERR! enoent ENOENT: no such file or directory, open 'package.json'
ServiceNotFoundException
CannotPullContainerError

Cause:

Incorrect ECS cluster/service/task name in your GitHub Actions workflow, or the image/tag does not exist in ECR.

How to Fix:

Double-check the names in your:
- ECS cluster
- ECS service
- Task definition
Ensure the correct image tag exists in the ECR repository.

🔍 Error: App Crashes After Deployment

Symptom:

ECS service stops immediately. No public access or 502 Bad Gateway from load balancer.

How to Fix:

Go to ECS → Tasks → Logs and view the error output.
Make sure your app is listening globally, not just on localhost:

app.listen(3000, '0.0.0.0');

🔍 Error: Docker Image Doesn’t Update

Cause:

You’re using a static latest tag and ECS believes it already deployed it.

How to Fix:

Use --force-new-deployment to trigger ECS to re-pull the image, or update to a different tag.

- name: 🚀 Deploy to Amazon ECS
  run: |
    aws ecs update-service \
      --cluster $ECS_CLUSTER \
      --service $ECS_SERVICE \
      --force-new-deployment

✅ Bonus: Use a `.dockerignore` File

Speed up builds and prevent accidental context issues:

node_modules
.env
.git

🧠 Conclusion

CI/CD is powerful, but small misconfigurations can halt deployments. Be sure to:

Carefully review build logs
Monitor ECS logs
Always verify secrets and naming

Once setup is smooth, your Dockerized Node.js app will deploy automatically to AWS ECS with every push! 🔁

Let me know in the comments if you’d like a template for:

GitHub Actions workflow
Dockerfile
AWS ECS task definition (in JSON)

Happy Deploying! 🚀

React Performance Optimization Techniques

Srashti Gupta — Tue, 08 Jul 2025 15:35:10 +0000

Optimizing React applications is essential for delivering fast, responsive user experiences. Below is an in-depth exploration of the most effective strategies for improving React performance, including practical implementation advice and key considerations.

1. Lazy Loading

Concept:

Load components, modules, or assets only when they are needed, rather than during the initial page load.

Implementation:

Use React.lazy() and `` to load components dynamically.
For images and assets, use the loading="lazy" attribute or libraries like react-lazy-load-image-component.

Benefits:

Reduces initial bundle size.
Improves first paint and time-to-interactive, especially in large apps.

2. React.memo

Concept:

A higher-order component that memoizes functional components, preventing unnecessary re-renders when props have not changed.

Implementation:

Wrap function components with React.memo(Component).
Only re-renders if props change via shallow comparison.

Use Cases:

Useful for components that render frequently with the same props.
Particularly effective for list items, buttons, or visual elements that rarely change.

3. Code Splitting

Concept:

Splitting the application code into smaller chunks that are loaded on demand.

Implementation:

Use dynamic import() statements.
Leverage tools like Webpack, Rollup, or route-based splitting with React Router.

Benefits:

Reduces initial load time.
Allows users to download only what they need, when they need it.

4. Inline Functions

Issue:

Defining functions inside render methods or JSX creates new function instances on every render, which can trigger unnecessary re-renders in child components.

Optimization:

Use useCallback to memoize functions.
Define functions outside the render scope when possible.

5. Lazy Loading Images

Concept:

Defer loading of images until they enter the viewport.

Implementation:

Use the loading="lazy" attribute on `` tags.
For more control, use Intersection Observer API or libraries like react-lazy-load-image-component.

Benefits:

Reduces bandwidth usage.
Speeds up initial render, especially in image-heavy applications.

6. Memoization

Concept:

Cache the results of expensive computations or component renders to avoid redundant work.

Implementation:

Use useMemo() for memoizing values.
Use useCallback() for memoizing functions.

Benefits:

Prevents unnecessary recalculations.
Reduces CPU usage and improves responsiveness.

7. React Fragments

Concept:

Group multiple elements without adding extra nodes to the DOM.

Implementation:

Use <> or ``.

Benefits:

Reduces DOM size and memory usage.
Useful for rendering lists or complex layouts efficiently.

8. Throttling and Debouncing Events

Concept:

Limit how often event handlers (like scroll, resize, or input) are triggered.

Implementation:

Use utility libraries such as Lodash (_.throttle, _.debounce).
Custom hooks can be created for reusable throttling/debouncing logic.

Benefits:

Prevents performance bottlenecks from rapid event firing.
Improves perceived and actual responsiveness.

9. Key Coordination for List Rendering

Best Practice:

Assign unique and stable keys to list items.

Why Important:

Helps React efficiently update and reconcile lists.
Avoids unnecessary re-renders and DOM manipulations.

10. Measuring React Performance

Tools:

React DevTools Profiler: Analyze component render times and re-renders.
Browser Performance APIs: Use window.performance for custom metrics.
Custom logging: Track specific performance bottlenecks.

11. Memoize React Components

How:

Use React.memo for functional components.
Use PureComponent for class components.

Effect:

Prevents unnecessary re-renders by performing shallow prop and state comparisons.

12. Dependency Optimization

Concept:

Carefully manage dependencies in hooks (useEffect, useMemo, useCallback) to avoid redundant executions.

Best Practices:

Only include necessary dependencies.
Avoid creating new objects or functions inside dependencies unless required.

13. Implement PureComponent

Concept:

A class component that implements a shallow comparison of props and state in shouldComponentUpdate.

Benefits:

Prevents unnecessary re-renders for class components.
Useful for optimizing performance in large, complex UIs.

14. List Virtualization

Concept:

Render only the visible portion of long lists, rather than the entire list.

Implementation:

Use libraries like react-window or react-virtualized.

Benefits:

Greatly reduces DOM node count and memory usage.
Improves scroll performance in large lists.

15. useCallback

Concept:

Memoize callback functions so they are not recreated on every render.

Usage:

Wrap functions passed as props to child components.
Reduces unnecessary re-renders in children relying on function identity.

16. Web Workers

Concept:

Offload heavy computations to background threads.

How:

Use the Web Workers API for tasks like data processing, image manipulation, or parsing.

Benefits:

Keeps the UI thread responsive.
Prevents blocking user interactions.

17. Keeping Component State Local

Concept:

Store state as locally as possible, rather than lifting it unnecessarily.

Benefits:

Reduces the number of components that re-render when state changes.
Simplifies component logic and improves maintainability.

18. Use Production Build

Why:

Production builds of React are optimized for performance, with extra checks and warnings removed.

How:

Use npm run build to create an optimized bundle for deployment.

19. React Redux Optimization

Strategies:

Use connect's mapStateToProps efficiently to avoid unnecessary re-renders.
Use selectors (e.g., Reselect) for memoizing derived data.

20. Immutable Data Structures

Concept:

Use immutable objects and arrays for state management.

Benefits:

Makes change detection faster and more predictable.
Helps React efficiently determine when to update components.

By combining these techniques, you can significantly enhance the speed, responsiveness, and scalability of your React applications. Each optimization should be applied judiciously, based on profiling and actual app needs, to achieve the best results.

USE EFFECT HOOK

Srashti Gupta — Wed, 04 Jun 2025 11:10:12 +0000

Here’s a clean, well-structured, and engaging blog post draft about the React useEffect hook, including best practices, examples, and common pitfalls, all based on the latest guidance and real-world scenarios:

Demystifying the useEffect Hook in React

Why I Wrote This Post

When I first started building React apps, I found myself confused about when and how to use the useEffect hook. It’s a powerful tool for handling side effects, but it can also introduce subtle bugs if not used carefully. In this post, I’ll share what I’ve learned about useEffect, show you practical examples, and help you avoid common mistakes—so you can write more predictable and efficient React code.

What Is useEffect?

The useEffect hook lets you perform side effects in your React functional components. Side effects include tasks like:

Fetching data from an API
Setting up event listeners
Updating the DOM directly
Managing timers or subscriptions[1][3][4][17]

Before hooks, these tasks were handled in class components using lifecycle methods like componentDidMount, componentDidUpdate, and componentWillUnmount. With useEffect, you can do all of this in functional components—making your code more concise and easier to manage[1][3][17].

Basic Syntax

useEffect(() => {
  // Side effect logic here

  return () => {
    // Optional cleanup logic here
  };
}, [dependencies]);

Effect function: Runs after every render by default.
Cleanup function (optional): Runs before the effect is re-executed or when the component unmounts—useful for cleaning up subscriptions, timers, or event listeners.
Dependencies array: Controls when the effect runs. If empty ([]), the effect runs only once after the initial render; if omitted, it runs after every render; if you list variables, it runs when any of those variables change[3][4][8][13][15].

Practical Examples

1. Run Once on Mount

useEffect(() => {
  console.log("Component mounted!");
}, []); // Only runs once after the first render

2. Run When a Value Changes

const [count, setCount] = useState(0);

useEffect(() => {
  document.title = `Count: ${count}`;
}, [count]); // Runs every time count changes

3. Fetch Data on Mount

useEffect(() => {
  async function fetchData() {
    const response = await fetch('https://api.example.com/data');
    const data = await response.json();
    setData(data);
  }
  fetchData();
}, []); // Runs only once after the first render

4. Cleanup Example (Event Listener)

useEffect(() => {
  function handleResize() {
    console.log('Window resized!');
  }
  window.addEventListener('resize', handleResize);
  return () => window.removeEventListener('resize', handleResize);
}, []); // Adds and cleans up the event listener

Best Practices

Always specify the dependencies array: This prevents unnecessary or missed effect executions and avoids performance issues[8][16].
Include all dependencies: List every variable from the component scope that your effect uses. Missing dependencies can cause bugs or stale data[8][16].
Use multiple useEffect hooks for separate concerns: This keeps your code organized and easier to debug[2][8].
Always clean up side effects: Return a cleanup function to remove event listeners, timers, or subscriptions to prevent memory leaks[8][15].
Avoid overusing useEffect: Not all logic needs to be inside useEffect. For derived state or simple computations, use regular variables or memoization[2][6][8].

Common Pitfalls and How to Avoid Them

Pitfall	How to Avoid It
Forgetting dependencies	Always include all variables your effect uses in the dependency array[8][16].
Infinite loops from state updates	Don’t update state unconditionally inside useEffect; use guards or conditions if needed[8][16].
Memory leaks from uncleaned side effects	Always return a cleanup function to remove listeners, timers, or subscriptions[8][15].
Overcomplicating effects	Only use useEffect for true side effects, not for simple value calculations or rendering logic[8][2].
Using useEffect for data transformation	Compute derived data directly in render, not in useEffect[2][8].

Summary

The useEffect hook is essential for handling side effects in React functional components. By understanding its syntax, using the dependency array correctly, and following best practices, you can avoid common bugs and write more maintainable code. Remember to clean up after your effects, and don’t use useEffect for tasks that can be handled directly in render.

Let’s Discuss!

Have you run into tricky bugs with useEffect?
Do you have tips or patterns that work well for you?
Any questions about dependencies or cleanup?

Drop your experiences and questions in the comments below!

[1] https://www.geeksforgeeks.org/reactjs-useeffect-hook/
[2] https://www.zipy.ai/blog/useeffect-hook-guide
[3] https://namastedev.com/blog/react-useeffect-hook-deep-dive-7/
[4] https://www.w3schools.com/react/react_useeffect.asp
[5] https://deadsimplechat.com/blog/react-useeffect-a-complete-guide-with-examples/
[6] https://www.developerupdates.com/blog/avoid-these-7-react-useeffect-mistakes
[7] https://www.linkedin.com/pulse/useeffect-mastery-tips-tricks-avoiding-common-mistakes-novin-noori
[8] https://dev.to/hkp22/reacts-useeffect-best-practices-pitfalls-and-modern-javascript-insights-g2f
[9] https://legacy.reactjs.org/docs/hooks-effect.html
[10] https://blog.logrocket.com/useeffect-react-hook-complete-guide/
[11] https://daveceddia.com/useeffect-hook-examples/
[12] https://www.telerik.com/blogs/7-common-mistakes-using-react-hooks
[13] https://dmitripavlutin.com/react-useeffect-explanation/
[14] https://www.geeksforgeeks.org/what-are-the-pitfalls-of-using-hooks-and-how-can-you-avoid-them/
[15] https://hygraph.com/blog/react-useeffect-a-complete-guide
[16] https://blog.bitsrc.io/5-common-mistakes-when-using-useeffect-in-react-84c973060440
[17] https://www.freecodecamp.org/news/react-hooks-useeffect-usestate-and-usecontext/
[18] https://akoskm.com/common-useeffect-mistakes/
[19] https://react.dev/reference/react/useEffect
[20] https://overreacted.io/a-complete-guide-to-useeffect/
[21] https://dev.to/colocodes/6-use-cases-of-the-useeffect-reactjs-hook-282o
[22] https://www.youtube.com/watch?v=2l23TWMZFYk
[23] https://brightmarbles.io/blog/useeffect-pitfalls/
[24] https://www.epicreact.dev/myths-about-useeffect

USE STATE HOOK

Srashti Gupta — Wed, 04 Jun 2025 07:19:35 +0000

Here’s your improved blog post with a clear explanation and practical example of useState, making it even more helpful and approachable for readers:

Mastering State and Immutability in React Functional Components

Why I Wrote This Post

As I dove deeper into React development, I often found myself puzzled by how state management works in functional components—especially when dealing with complex data types like arrays and objects. I wrote this post to share what I’ve learned about using the useState hook effectively, and to help you avoid common pitfalls that can trip up even experienced developers. If you’re looking to write cleaner, more efficient React code, this guide is for you!

Setting a cover image helps your post stand out on the home feed and social media!

Understanding State in React Functional Components

React’s state is a powerful way to store and manage data within your components. In class components, you might use this.state, but in functional components, React gives us hooks—especially the useState hook.

What is `useState`?

The useState hook lets you add state to your functional components. It can hold any type of data: strings, numbers, booleans, arrays, objects, or even more complex structures[1][5][7]. Here’s how you can use it with different data types:

import { useState } from "react";

const [value, setValue] = useState('');    // String
const [list, setList] = useState([]);      // Array
const [obj, setObj] = useState({});        // Object
const [count, setCount] = useState(0);     // Number

value: The current state value.
setValue: The function to update that state.

Example: A Simple Counter

Here’s a classic example to show how useState works in practice—a button that counts how many times it’s clicked:

import React, { useState } from 'react';

function Counter() {
  // Declare a state variable named 'count', initialized to 0
  const [count, setCount] = useState(0);

  return (

      You clicked {count} times
       setCount(count + 1)}>
        Click me


  );
}

useState(0) creates a state variable count with an initial value of 0.
setCount updates the value of count.
Every button click increases the count by 1, and the UI updates automatically[3][4][5][6].

Updating State

Depending on your data type, you’ll update state like this:

setCount(prev => prev + 1);                // Number
setValue('newValue');                      // String
setIsTrue(true);                           // Boolean
setList(prev => [...prev, newItem]);       // Array
setObj(prev => ({ ...prev, name: 'Writer' })); // Object

Key Principles

Immutability: Never mutate the original object or array. Always create a new copy with the necessary changes.
Spread Operator (...): Use it to copy arrays and objects efficiently.
Functional Updates: When the new state depends on the previous state, use the functional form (e.g., setState(prev => ...)) for accuracy, especially with async updates.

Why Immutability Matters for Performance

Creating new references with useState directly supports React’s shallow comparison strategy:

Efficient Change Detection: React can quickly tell if something changed by comparing references, not deep values.
Minimized Re-renders: If the reference hasn’t changed, React skips unnecessary re-renders, improving performance.
Optimized Virtual DOM Diffing: Only the parts of the UI that need to change are updated.

Common Pitfalls with the Spread Operator

Shallow Copy Only: The spread operator only copies the top level. Nested objects or arrays are still referenced, which can lead to bugs if mutated.
Direct Mutation Before Copy: Accidentally mutating the original before copying (e.g., arr.push(x) then [...arr]) still mutates the original data.
Overusing Spread: Excessive use can make code harder to read and, in rare cases, affect performance.
Order of Properties: When merging objects, later properties override earlier ones—be mindful of the order.

Summary

React’s useState hook is a cornerstone for managing state in functional components. By following the principles of immutability and using the spread operator wisely, you can build robust, efficient, and bug-free applications.

Let’s Discuss!

I’d love to hear from you:

What challenges have you faced with state management in React?
Do you have tips or best practices to share?
Any questions about immutability or the spread operator?

Drop your thoughts in the comments below—let’s spark a great discussion!

[1] https://www.w3schools.com/react/react_usestate.asp
[2] https://daveceddia.com/usestate-hook-examples/
[3] https://legacy.reactjs.org/docs/hooks-state.html
[4] https://react.dev/reference/react/useState
[5] https://blog.logrocket.com/guide-usestate-react/
[6] https://www.freecodecamp.org/news/usestate-hook-3-different-examples/
[7] https://hygraph.com/blog/usestate-react
[8] https://www.youtube.com/watch?v=O6P86uwfdR0

DEV Community: Srashti Gupta

DPoP Explained: Making Stolen Access Tokens Useless

The core idea in one sentence

How it works: the moving parts

What a DPoP proof actually looks like

The token binding (cnf.jkt)

One more change: the scheme is DPoP, not Bearer

The full flow, end to end

The "how": code

Client — create and reuse a key pair

Client — build a proof for each request

Client — call the API

Resource server — verify the proof

The "all the cases" part: what production actually throws at you

Case 1 — Binding at the token endpoint (issuance)

Case 2 — Calling a protected resource

Case 3 — Refresh tokens must be bound too

Case 4 — Server-supplied nonce (the strongest replay defense)

Case 5 — Replay protection at scale (jti store)

Case 6 — Clock skew and the iat window

Case 7 — Key rotation mid-session

Case 8 — Multiple resource servers

Case 9 — Opaque tokens

Case 10 — Proxies, TLS termination, and htu mismatches

Case 11 — Error responses your client must understand

The "when": should you actually use DPoP?

What DPoP does not solve (set expectations honestly)

A pragmatic rollout checklist

Wrapping up

How CNNs Learn to See: A Beginner-Friendly Guide

What is a CNN?

Why not use a normal neural network?

Why CNNs are better for images

1) Local pattern detection

2) Position robustness

3) Efficient learning

CNN architecture (simple flow)

Cat example, step by step

Step 1: Convolution

Step 2: ReLU

Step 3: Pooling

Step 4: Deeper layers

Step 5: Fully connected + Softmax

Tips to improve CNN performance

Common applications

Conclusion

Observability vs Monitoring: What Every Developer Must Know

Observability Explained for Backend Engineers

What is Observability?

🏗 The Three Pillars of Observability

Metrics

Logs

Traces

🖼 Observability Architecture

⚖ Observability vs Monitoring

Why Observability Matters in High-Traffic Systems

Advanced Concepts

Conclusion

WHY we use Mapped Types &Conditional Types in TS?

We Use Mapped & Conditional Types in TypeScript (Real-World Examples)

1. Why Mapped Types?

Problem (Real Life)

Solution: Mapped Types ✅

Example 1: Form State (All Optional)

Example 2: Read-Only API Response

Example 3: Editable Fields Only

2. Why Conditional Types?

Problem (Real Life)

Solution: Conditional Types ✅

Example 1: Role-Based Data

Example 2: API Response Type

3. Why infer? (Very Practical Example)

Problem

Solution: infer ✅

4. Why Distributive Conditional Types?

Problem

Solution

5. Real Use of Utility Types (Behind the Scenes)

6. Real-World Summary (Why We Actually Use Them)

Final Thought

The token binding (`cnf.jkt`)

One more change: the scheme is `DPoP`, not `Bearer`

Case 5 — Replay protection at scale (`jti` store)

Case 6 — Clock skew and the `iat` window

Case 10 — Proxies, TLS termination, and `htu` mismatches

3. Why `infer`? (Very Practical Example)

Solution: `infer` ✅

✅ Bonus: Use a `.dockerignore` File