It was a Tuesday morning when our on-call alert fired. P95 latency on /api/dashboard had crossed 4 seconds. Nothing had been deployed. No traffic spike. The database CPU was sitting at 78% on a db.r6g.2xlarge we'd just scaled up to "fix" the same problem two weeks earlier.

We opened DataDog, found the trace, and stared at it for a moment.

1,847 database queries. For a single request.

The offending code had been in production for four months. It passed code review. It passed QA. It looked completely normal:

const tenants = await prisma.tenant.findMany({
  where: { status: 'active' }
});

const enriched = await Promise.all(
  tenants.map(t =>
    prisma.subscription.findFirst({
      where: { tenantId: t.id }
    })
  )
);

At 12 tenants in staging, this ran in 40ms. At 1,847 active tenants in production, Prisma fired 1,848 queries — one to fetch the tenants, then one per tenant to fetch its subscription. The ORM hid every single one behind a clean await. No warnings. No errors. Just a silent, compounding tax that scaled linearly with your growth.

This is the N+1 problem. It doesn't crash your app. It just makes it slower every time you succeed.

The fix took 11 minutes. The diagnosis took three hours. This post is about closing that gap.

Section 01 — Detecting it

Step 1: enable Prisma query logging

const prisma = new PrismaClient({
  log: [
    { emit: 'event', level: 'query' },
    { emit: 'stdout', level: 'error' },
  ],
});

prisma.$on('query', (e) => {
  console.log(`[QUERY] \({e.query} | \){e.duration}ms`);
});

A route that emits 200+ log lines for a single request is your N+1. But logging alone doesn't tell you why it's slow at the database level.

Step 2: read the query plan

// Raw output from EXPLAIN ANALYZE on the child query:
// Seq Scan on "Subscription"
//   actual time=4.831..4.831 rows=1 loops=1847
//   Filter: tenantId = $1
//   Rows Removed by Filter: 49999
// Execution Time: 8,921.4 ms

// What this means:
// loops=1847   → this query plan ran 1,847 times
// Seq Scan     → full table read every loop (50k rows × 1,847 = 92M row reads)
// No index     → tenantId column is unindexed, every loop scans the whole table

Step 3: find repeat queries in production

const hotQueries = await prisma.$queryRaw<HotQuery[]>`
  SELECT query, calls, mean_exec_time, total_exec_time
  FROM pg_stat_statements
  ORDER BY total_exec_time DESC
  LIMIT 10
`;

Section 02 — Fix #1: include and select

// Before: 1 + N queries (1,848 total at 1,847 tenants)
const tenants = await prisma.tenant.findMany({
  where: { status: 'active' }
});
const enriched = await Promise.all(
  tenants.map(t => prisma.subscription.findFirst({
    where: { tenantId: t.id }
  }))
);

// After: 2 queries flat — regardless of tenant count
const tenants = await prisma.tenant.findMany({
  where: { status: 'active' },
  include: {
    subscription: {
      select: { id: true, plan: true, status: true }
    }
  }
});

// Results:
// Queries  → 1,848  down to 2
// Latency  → 8.9s   down to 38ms
// DB CPU   → 78%    down to 4%

Gotcha: Deep include chains (3+ levels) can produce enormous JOINs that are slower than the N+1 they replace. Benchmark anything beyond 2 levels.

Section 03 — Fix #2: the dataloader pattern

// lib/dataloader.ts — no external library needed
type BatchFn<T> = (ids: string[]) => Promise<(T | null)[]>;

function createLoader<T>(batchFn: BatchFn<T>) {
  const queue: { id: string; resolve: (v: T | null) => void }[] = [];
  let scheduled = false;

  return async function load(id: string): Promise<T | null> {
    return new Promise((resolve) => {
      queue.push({ id, resolve });
      if (!scheduled) {
        scheduled = true;
        process.nextTick(async () => {
          const ids = queue.map(q => q.id);
          const results = await batchFn([...new Set(ids)]);
          const map = new Map(ids.map((id, i) => [id, results[i]]));
          queue.forEach(q => q.resolve(map.get(q.id) ?? null));
          queue.length = 0;
          scheduled = false;
        });
      }
    });
  };
}

const userLoader = createLoader<User>(async (ids) => {
  const users = await prisma.user.findMany({
    where: { id: { in: ids } },
    select: { id: true, name: true, email: true }
  });
  return ids.map(id => users.find(u => u.id === id) ?? null);
});

const user = await userLoader.load(post.authorId);

Section 04 — Fix #3: $queryRaw for complex cases

const result = await prisma.$queryRaw<Post[]>`
  SELECT p.*
  FROM "User" u
  CROSS JOIN LATERAL (
    SELECT *
    FROM "Post"
    WHERE "authorId" = u.id
    ORDER BY "createdAt" DESC
    LIMIT 5
  ) p
  WHERE u."tenantId" = ${tenantId}
`;

// Benchmark vs include chain:
// 10 authors  →  11 queries / 42ms   vs  1 query / 6ms
// 100 authors → 101 queries / 390ms  vs  1 query / 11ms
// 1k authors  → 1,001 queries / 4.1s vs  1 query / 68ms

Section 05 — The part everyone skips: indexes

// schema.prisma

model Subscription {
  id       String @id @default(cuid())
  tenantId String
  plan     String
  status   String

  @@index([tenantId])
  @@index([tenantId, status])
}

model Post {
  id       String @id @default(cuid())
  authorId String
  tenantId String

  @@index([authorId])
  @@index([tenantId, authorId])
}

// Rule: every FK column in a Prisma include, where, or orderBy needs an index.
// Confirm with EXPLAIN ANALYZE: "Index Scan" not "Seq Scan"

Section 06 — Preventing regression with CI query budgets

// lib/queryCounter.ts
export function createQueryCounter(prisma: PrismaClient) {
  let count = 0;
  prisma.$on('query', () => { count++; });
  return {
    reset: () => { count = 0; },
    get: () => count,
    assertMax: (max: number, label?: string) => {
      if (count > max) {
        throw new Error(
          `Query budget exceeded on \({label ?? 'unknown'}: expected ≤\){max}, got ${count}`
        );
      }
    }
  };
}

// __tests__/dashboard.test.ts
describe('GET /api/dashboard', () => {
  it('stays within query budget', async () => {
    const counter = createQueryCounter(prisma);
    await request(app)
      .get('/api/dashboard')
      .set('Authorization', `Bearer ${token}`);
    counter.assertMax(3, 'GET /api/dashboard');
  });
});

// Express middleware — emit query count to APM
app.use(async (req, res, next) => {
  const counter = createQueryCounter(prisma);
  res.on('finish', () => {
    datadog.gauge('prisma.query_count', counter.get(), {
      route: req.route?.path ?? req.path,
      status: res.statusCode,
    });
  });
  next();
});

Results

No infra changes. No cache layer. No schema redesign.

Our Node.js backend powers critical features, so even a broken build or 2–3 minutes of downtime wasn’t acceptable. As our team grew, deployment became risky:

• Manual SSH deployments were slow

• Missed steps caused crashes

• Different machines had different Node versions

• Rollbacks were painful

• Hotfixes slowed down because the pipeline wasn’t automated

We needed a bulletproof CI/CD pipeline.

Below is the journey of how we moved from a patchy deployment process to a fully automated CI/CD setup using GitHub Actions + AWS EC2 + PM2.

The Problem

1 — Manual Deployments Became a Bottleneck

Every update required logging into EC2, pulling code, installing dependencies, restarting PM2, and praying we didn’t break something.

During busy days, this became tedious — and errors slipped in.

2 — No Consistency Across Deployments

One laptop used Node 16, another had Node 18.
Some deployments skipped tests.
Some forgot npm install.
Some overwrote .env accidentally.

We were relying on luck, not process.

3 — Zero Rollback Support

If something broke:

• We scrambled to revert to the previous commit

• Re-deployed manually

• Restarted PM2 again

Not fast, not reliable.

We needed automation.

Step 1 — Setting Up GitHub Actions for CI

We began by automating the basics:

• Install Node

• Install dependencies

• Run tests

• Prepare build artifacts

GitHub Actions became our “CI engine”.

Why GitHub Actions?

• Close to the repository

• Easy secrets management

• Parallel jobs

• Free for most usage

• Very simple YAML-based workflows

This ensured every push was validated before deployment.

Step 2 — Automating Deployment to AWS EC2

Next, we automated deployment.

Instead of SSH-ing manually to EC2, GitHub Actions now:

1. Builds the backend

2. Uploads the updated code to EC2

3. Restarts PM2 automatically

4. Verifies that the server comes back online

We securely stored:

• EC2 host

• SSH user

• Private key

• Environment variables

in GitHub Secrets, eliminating credential sharing.

This alone removed 90% of deployment friction.

Step 3 — Introducing PM2 for Zero-Downtime Restarts

PM2 became our process manager.

It allowed:

• App restarts without downtime

• Crash auto-recovery

• CPU utilization monitoring

• Log management

• Easy rollbacks using saved snapshots

Whenever a deployment happened:

pm2 restart node-app

The app restarted instantly while keeping old connections alive.

Downtime: 0 seconds.

Step 4 — Handling Secure Environment Management

We moved all sensitive configuration from code into:

• .env file on EC2

• GitHub Secrets for CI

• PM2 ecosystem config for runtime variables

This ensured:

• No secrets in Git

• Easy environment change without redeploy

• Safer rollbacks

Step 5 — Improving Deployment Reliability

We refined the pipeline further:

Added health checks after deploy

To ensure the API booted correctly.

Added rollback capability

By keeping previous build folders.

Cleaned old build artifacts

To reduce EC2 disk usage over time.

Added monitoring

Using PM2 logs + CloudWatch.

Small improvements → Big stability gains.

Final Architecture Diagram

                 ┌─────────────────────────┐
                 │     GitHub Actions      │
                 │ (CI: Build & Test Code) │
                 └───────────┬─────────────┘
                             │
                             ▼
     ┌────────────────────────────────────────────────┐
     │        GitHub Actions Deployment Job           │
     │  1️⃣ SCP/SSH to EC2                             │
     │  2️⃣ Upload Build Files                         │
     │  3️⃣ Restart PM2                                │
     └───────────┬───────────────────────────┬────────┘
                 │                           │
     ┌───────────▼────────────┐   ┌──────────▼─────────────┐
     │      AWS EC2 Ubuntu    │   │   GitHub Secrets        │
     │  Node.js + PM2 Runtime │   │  (SSH, Host, Env Keys)  │
     └───────────┬────────────┘   └─────────────────────────┘
                 │
     ┌───────────▼────────────┐
     │   Node.js Application  │
     │ (Zero Downtime via PM2)│
     └────────────────────────┘

Conclusion

Migrating to a CI/CD pipeline wasn’t just a tooling upgrade — it was an operational transformation.

With GitHub Actions + EC2 + PM2, we achieved:

• Fully automated deployments

• Zero downtime during restarts

• Safe and secure environment handling

• Consistent, reliable build process

• Faster development cycles

• No more late-night "quick fixes" breaking production

Today, pushing to main is all it takes for a clean, fast, safe deployment — every single time.

Shallow Copy

A shallow copy creates a new object but only copies the top-level properties.

• If the property is a primitive value like string, number, boolean, null, undefined, symbol, or bigint, it gets copied directly.

• If the property is an object, array, or function (reference type), then only the reference is copied. This means both the original and the copied object will point to the same nested structure.

Example:

const original = {
  name: "Pratik",
  skills: ["JavaScript", "React"]
};

const shallowCopy = { ...original };

shallowCopy.name = "Alex";
shallowCopy.skills.push("Node.js");

console.log(original.name);   // "Pratik" → unchanged
console.log(original.skills); // ["JavaScript", "React", "Node.js"] → changed

Here, the primitive property name is copied safely, but the skills array is shared. Updating shallowCopy.skills also updates original.skills.

Common Ways to Create Shallow Copies:

• Object spread: { ...obj }

• Object.assign({}, obj)

• Array methods like:

  • arr.slice()

  • [...arr]

Deep Copy

A deep copy goes one step further. It copies not only the top-level properties but also all nested objects and arrays. This makes the copied object completely independent of the original.

Example:

const original = {
  name: "Pratik",
  skills: ["JavaScript", "React"]
};

// Deep copy using structuredClone
const deepCopy = structuredClone(original);

deepCopy.name = "Alex";
deepCopy.skills.push("Node.js");

console.log(original.name);   // "Pratik" → safe
console.log(original.skills); // ["JavaScript", "React"] → safe

Here, the deepCopy object is fully independent. Any change in deepCopy does not affect original.

Common Ways to Create Deep Copies:

1. structuredClone() (works in modern browsers and Node.js 17+)

    const clone = structuredClone(obj);
   

2. JSON method (works but has limitations)

    const clone = JSON.parse(JSON.stringify(obj));
   

   Note: This method removes functions, symbols, undefined values, and fails with circular references.

3. Libraries like Lodash (_.cloneDeep(obj)) or Immer.

When Should You Use Each?

• Shallow Copy is enough when:

  • You only need to copy simple, top-level data.

  • You are sure that nested objects or arrays will not be modified.

• Deep Copy is necessary when:

  • You want complete independence between the copy and the original.

  • You are working with frameworks like React/Redux, where immutability is important.

  • You are dealing with nested or complex data structures.

Quick Comparison

Conclusion

Understanding the difference between shallow copy and deep copy is very important for every JavaScript developer. It helps avoid unexpected bugs, especially when handling state management in frameworks like React.

• Use shallow copy when you only need a quick top-level copy.

• Use deep copy when you want complete isolation between the original and the copied data.

This clarity will save you from a lot of hidden issues in real-world applications.

But here’s the challenge:
These resources can’t directly access the internet.
And yet, they often need outbound connectivity (e.g., downloading packages, calling third-party APIs).

This blog explains how we solved that problem at scale using NAT Gateway.

The Problem

1. Private Subnet Isolation

   • By design, private subnets cannot route traffic to the Internet Gateway.

   • EC2 or Lambda inside them had no internet access.

2. Broken External Calls

   • Our workloads needed outbound internet:

     • EC2 instances → install security patches.

     • Lambdas → call Firebase/FCM APIs.

   • Without internet, everything failed.

3. Direct IGW Not an Option

   • Attaching Internet Gateway directly to private subnet would expose resources.

   • Security rules prevented that.

Step 1 — Introducing NAT Gateway

We deployed a NAT Gateway in the public subnet of our VPC.

• NAT Gateway gets an Elastic IP.

• It can reach the internet via the Internet Gateway.

Private subnet instances send traffic → NAT Gateway → Internet.
Inbound traffic from the internet is blocked.

Step 2 — Updating Private Subnet Route Tables

For each private subnet, we updated the route table:

• Default route 0.0.0.0/0 → NAT Gateway.

• Internal traffic (10.0.0.0/16) still routes locally within the VPC.

This gave private resources outbound internet access while keeping them hidden.

Step 3 — Testing with EC2 in Private Subnet

We launched an EC2 in the private subnet and verified connectivity:

ping google.com
sudo yum update -y
curl https://api.github.com

Outbound requests succeeded.
Inbound requests from internet were blocked — exactly what we wanted.

Final Architecture Diagram

                   +-----------------------+
                   |       Internet        |
                   +-----------+-----------+
                               |
                        (Internet Gateway)
                               |
                   +-----------+-----------+
                   |       Public Subnet   |
                   |  NAT Gateway + EIP    |
                   +-----------+-----------+
                               |
                    Route to NAT Gateway
                               |
                   +-----------+-----------+
                   |      Private Subnet   |
                   |  EC2 / Lambda / RDS   |
                   +-----------------------+

Conclusion

By introducing a NAT Gateway, we achieved:

• Secure isolation: Private subnets remain unreachable from the internet.

• Controlled outbound: Instances can fetch updates, call APIs, or access S3.

• Scalability: Fully managed by AWS (no manual patching or scaling).

Today, our workloads run inside private subnets with:

• Private, low-latency access to databases inside the VPC.

• Outbound internet connectivity for external APIs via NAT Gateway.

This simple design pattern is a must-know for any AWS-based architecture where you want security + flexibility.

Why is React so popular, and what makes it better than traditional approaches?

The short answer is Virtual DOM. But if you’ve only read the high-level explanations (“React keeps a copy of the DOM in memory”), you’re missing the real picture. The Virtual DOM isn’t just a performance hack — it’s an architectural innovation that reshaped how developers think about UIs, manage state, and scale applications.

In this article, we’ll take a deep dive into:

• Why direct DOM manipulation became a bottleneck

• What Virtual DOM actually is (beyond buzzwords)

• How React uses Virtual DOM (render, diff, commit phases)

• The Fiber engine and how it enables concurrency

• Real-world cases where Virtual DOM made React superior

• Comparisons with Angular, Vue, Svelte, SolidJS

• Best practices to maximize performance with Virtual DOM

• The future of React in the age of Server Components and concurrent rendering

By the end, you’ll have an interview-ready, production-grade understanding of Virtual DOM — not just the textbook definition.

1. The DOM Problem: Why React Needed a New Model

Before React, developers mainly used:

• jQuery → powerful DOM utilities but fully imperative.

• AngularJS → two-way binding with dirty-checking.

• Backbone/Knockout → some structure, but still DOM-heavy.

1.1 Why the DOM is Slow

The DOM is a tree of nodes. Manipulating it directly is costly because:

1. Reflows → recalculating element positions.

2. Repaints → redrawing pixels on screen.

3. Layout Thrashing → repeated reads/writes block the main thread.

4. Event Listeners → attaching them to many nodes consumes memory.

Updating just one property may force recalculations across thousands of nodes.

1.2 State–UI Mismatch

With jQuery, state lives in JavaScript variables and UI lives in the DOM tree.
Keeping them in sync is error-prone. Example:

let count = 0;
function increment() {
  count++;
  $('#counter').text(count);
}

If some developer forgets to update #counter, the UI no longer matches state. This gets worse with nested components.

1.3 AngularJS Dirty Checking

AngularJS improved things with two-way binding. But dirty-checking loops checked every binding repeatedly → O(n²) complexity on large UIs.

👉 The ecosystem needed a predictable, scalable model.

2. Enter React: A Declarative Mindset

React introduced a new formula:

UI = f(state)

Instead of manually updating the DOM step-by-step, developers just describe the UI for the current state.

• If state changes → React re-renders → UI syncs automatically.

• No more manual patching.

• No more spaghetti jQuery logic.

But rendering the full DOM tree on each state change would be wasteful. That’s where the Virtual DOM comes in.

3. What is the Virtual DOM?

The Virtual DOM (VDOM) is one of React’s core innovations. At a basic level, it is:

• A lightweight, in-memory representation of the actual DOM.

• Made of simple JavaScript objects that describe UI elements and their structure.

• A kind of staging area where React prepares and calculates changes before applying them to the browser’s DOM.

Think of it as a blueprint of a building:

• You first modify the blueprint (cheap, quick, no real-world cost).

• Only after the design is finalized do you renovate the actual building (time-consuming, costly).

React follows the same idea. It updates the Virtual DOM first, figures out what actually changed, and then makes the minimal possible updates to the real DOM.

3.1 Why Do We Need a Virtual DOM?

The real DOM is slow to manipulate because it is directly tied to the rendering engine of the browser. When you change one element:

• The browser often needs to recalculate CSS styles.

• It may have to reflow layouts, repositioning elements on the page.

• Finally, it must repaint pixels on the screen.

Even small updates can cascade into expensive operations. In apps with hundreds or thousands of elements, this becomes a serious performance bottleneck.

By introducing a Virtual DOM layer, React ensures:

• Updates happen in memory first (fast, cheap).

• Only the necessary changes are applied to the actual DOM (optimized).

3.2 How the Virtual DOM is Structured

The Virtual DOM is essentially a tree of JavaScript objects that mirrors the real DOM tree.

Example real DOM:

<div id="app">
  <h1>Hello World</h1>
  <button>Click Me</button>
</div>

Virtual DOM equivalent:

{
  type: "div",
  props: { id: "app" },
  children: [
    { type: "h1", props: {}, children: ["Hello World"] },
    { type: "button", props: {}, children: ["Click Me"] }
  ]
}

Instead of manipulating real nodes directly, React manipulates this lightweight JavaScript object tree.

3.3 Analogy: Draft vs. Final Version

Think of writing a 50-page report:

• If you edit directly on the printed copy, every small change forces you to reprint all 50 pages — slow and wasteful.

• Instead, you edit in a draft document (Word, Google Docs). Once finalized, you only print the few pages that changed.

The Virtual DOM is that draft workspace for React.

3.4 Why This Makes React Efficient

By working with a Virtual DOM, React:

1. Reduces direct DOM operations — since most changes happen in memory.

2. Batches updates — React groups multiple state changes and processes them efficiently.

3. Performs diffing — React compares the new Virtual DOM with the previous one and updates only what’s necessary.

This is the reason React can handle highly interactive UIs (dashboards, live feeds, chat apps) without becoming sluggish.

4. How Virtual DOM Works

4.1 Initial Render

1. React components produce elements (via JSX).

2. React builds a Virtual DOM tree.

3. React converts it into real DOM nodes and mounts them.

4.2 On State Update

1. Component re-runs → produces a new Virtual DOM.

2. React compares old VDOM vs new VDOM (diffing).

3. React computes the minimal DOM mutations.

4. React updates the DOM in a batch.

4.3 Diffing Rules

• Different types → replace node.

• Same type, different props → update props only.

• Lists → use keys to track items across renders.

Example:

<ul>
  {items.map(item => <li key={item.id}>{item.text}</li>)}
</ul>

If you change only one item.text, React updates just that <li>, not the entire <ul>.

5. The Render and Commit Phases

React splits updates into:

1. Render Phase (diffing)

   • Create new VDOM.

   • Compare with previous VDOM.

   • Collect changes.

2. Commit Phase

   • Apply minimal mutations to real DOM.

   • Run effects, refs, lifecycle hooks.

This batching avoids intermediate, wasteful DOM reflows.

6. React Fiber: Beyond Virtual DOM

The Virtual DOM solved correctness and performance. But React 15 and earlier had a problem: updates were synchronous.

A large render could freeze the UI until finished.

6.1 Fiber Architecture

React 16 introduced Fiber, a new reconciliation engine:

• Breaks rendering into units of work.

• Allows React to pause, resume, abort, or prioritize work.

• Each VDOM element is linked to a Fiber node (a data structure with pointers to parent/child/sibling).

6.2 Work Loop & Priorities

• Updates are scheduled with lanes (priorities).

• Urgent updates (typing, animations) interrupt less important ones (background data fetching).

• The browser remains responsive.

6.3 Concurrent Rendering (React 18)

• With startTransition, developers can mark expensive updates as low priority.

• Example: Typing in a search bar stays smooth while React filters a huge list in the background.

7. Why Virtual DOM Makes React Better

7.1 Declarative Programming

• No need to write manual DOM manipulation code.

• React ensures UI always reflects state.

7.2 Predictable Updates

• Virtual DOM diffing ensures consistency.

• Fiber scheduling ensures responsiveness.

7.3 Cross-Platform

• React DOM → web.

• React Native → maps VDOM to native views.

• React Three Fiber → maps VDOM to WebGL.

All possible because UI description is abstracted in the Virtual DOM.

7.4 Maintainability at Scale

• Components are isolated and predictable.

• Even massive teams (Facebook, Airbnb) can scale apps with fewer bugs.

8. Real-World Case Studies

8.1 Facebook

• News Feed updates frequently (likes, comments, live updates).

• Virtual DOM ensures minimal re-renders → smooth scrolling.

8.2 Instagram

• Complex media grids, stories, infinite scrolling.

• React’s VDOM + Fiber enable background rendering for feed updates without freezing.

8.3 Netflix

• Migrated UI to React in 2015.

• Result: 50% faster startup, smoother TV UIs.

8.4 Airbnb

• Thousands of reusable components.

• Virtual DOM abstraction allowed consistent rendering across web and mobile.

9. Comparisons with Other Frameworks

While React’s Virtual DOM approach is innovative, it’s important to understand how it compares to other major frontend frameworks. Each framework takes a slightly different route to solve the same fundamental problem: how to efficiently update the UI when state changes.

9.1 Angular (Legacy and Modern)

AngularJS (the original Angular 1.x) used a dirty-checking mechanism.

• Every time a change happened, Angular ran a digest cycle that checked all the variables in scope and compared them with previous values.

• This worked fine for small apps, but as the app size and number of bindings grew, the digest cycles became expensive.

• For large, dynamic UIs, performance dropped significantly because Angular had to keep checking every variable, even if most didn’t change.

React’s Virtual DOM solved this by:

• Representing the UI as a tree.

• Running diffing only where state/props actually changed.

• Avoiding a global check on all variables.

With Angular 2+ (modern Angular), the framework moved closer to React’s model:

• It introduced zone.js for change detection.

• It compiles templates into optimized JavaScript instructions.

• Performance improved drastically, but React’s Virtual DOM still offered more predictability and fine-grained rendering control (especially with concurrent rendering and Fiber).

9.2 Vue.js

Vue also uses a Virtual DOM, but pairs it with a reactivity system.

• Vue tracks dependencies at the component level.

• When a reactive property changes, Vue knows exactly which components depend on it and updates only those.

• This can be more efficient in many cases because Vue avoids unnecessary diffing work.

Example:
If you have a large form with 50 fields, but only one changes, Vue updates just that field’s component. React will still diff the entire subtree but optimize rendering through reconciliation.

• Vue’s computed properties and watchers make it easy to optimize performance.

• React focuses more on state as a function of props (unidirectional data flow) and scheduling updates with Fiber.

The difference:

• Vue = reactivity-driven updates + VDOM.

• React = scheduler-driven updates + VDOM.

Both work well, but React’s scheduling system scales better for concurrent rendering and complex UIs.

9.6 Why React’s Virtual DOM Still Wins

When comparing across frameworks:

• Angular (legacy) struggled with dirty-checking.

• Vue combines reactivity + VDOM but doesn’t have React’s scheduling.

• Svelte and SolidJS avoid VDOM but sacrifice flexibility for performance.

• Preact is fast but limited.

React’s Virtual DOM + Fiber strikes a balance:

• Performance (with concurrent rendering).

• Flexibility (custom renderers, React Native).

• Ecosystem (tools, libraries, hiring pool).

• Predictable mental model (UI = f(state)).

That’s why, despite new challengers, React’s Virtual DOM continues to be the dominant abstraction in frontend development.

10. Best Practices for Developers

1. Always use keys for list items

    {todos.map(todo => <li key={todo.id}>{todo.text}</li>)}
   

2. Minimize state

   • Store only what you must.

   • Derive values when possible.

3. Use memoization

   • React.memo, useMemo, useCallback.

   • Prevents re-renders of unchanged components.

4. Split components

   • Smaller components = less diffing work.

5. Batch updates

   • React already batches in event handlers.

   • Don’t force synchronous DOM reads/writes.

6. Concurrent rendering features

   • Use startTransition for heavy updates.

11. The Future of Virtual DOM

• Server Components → render parts of UI on server.

• Streaming SSR → faster hydration.

• Selective Hydration → hydrate only parts visible to user.

• Virtual DOM remains the foundation for these innovations.

Conclusion

The Virtual DOM is more than a clever optimization. It’s the architectural backbone that:

• Enables declarative programming.

• Ensures scalable, maintainable UIs.

• Powers concurrency and cross-platform rendering.

React is “better” not because Virtual DOM is the fastest approach in micro-benchmarks — but because it offers the best trade-offs for real-world apps: performance, predictability, scalability, and developer experience.

As frontend continues to evolve, React’s Virtual DOM will keep adapting — not as a buzzword, but as a proven foundation for building UIs at scale.

In this blog, we’ll explore 5 AWS services every developer should master, with examples and use cases tailored for SaaS and MERN stack projects.

1. Amazon EC2 (Elastic Compute Cloud) – Your Virtual Server

What it is: EC2 provides resizable virtual machines in the cloud.

When to use:

• Running Node.js backend APIs.

• Hosting services that require full server control.

• Running cron jobs or background workers.

Example: Deploying an Express.js backend on an EC2 instance with NGINX + PM2 for process management.

2. Amazon S3 (Simple Storage Service) – Scalable Object Storage

What it is: Secure and highly scalable object storage service.

When to use:

• Store user-uploaded files (profile pictures, reports, invoices).

• Host static websites (React SPA).

• Store backups and logs.

Code Example (Node.js file upload):

import { S3Client } from '@aws-sdk/client-s3';
import multerS3 from 'multer-s3';
import { configData } from '../config/config';
import path from 'path';

export const s3Client = new S3Client({
    region: 'ap-south-1',
    credentials: {
        accessKeyId: configData.s3accessKeyId,
        secretAccessKey: configData.s3secretAccessKey,
    },
});

export const s3Storage = multerS3({
    s3: s3Client,
    bucket: `${process.env.S3_BUCKETNAME}`,
    metadata: (req, file, cb) => {
        cb(null, { fieldname: file.fieldname });
    },
    key: (req, file, cb) => {

        if (!file || !file.originalname) {
            return cb(new Error('No file provided.'));
        }

        const allowedExtensions = ['.jpg', '.jpeg', '.png'];
        const ext = path.extname(file.originalname).toLowerCase();

        if (!allowedExtensions.includes(ext)) {
            return cb(new Error('Only .jpg, .jpeg, and .png formats are allowed.'));
        }

        const fileName = `Profile-Images/${Date.now()}_${file.fieldname}_${file.originalname}`;
        cb(null, fileName);
    }

});

3. AWS Lambda – Serverless Functions

What it is: Run code without managing servers.

When to use:

• Event-driven tasks (file upload triggers, email sending).

• Background processing (image compression, PDF generation).

• Low-traffic APIs to save cost.

Example: Triggering a Lambda when a new file is uploaded to S3 → process → save result in MongoDB.

4. Amazon RDS (Relational Database Service) & DynamoDB

• RDS: Managed SQL databases (MySQL, PostgreSQL).

• DynamoDB: NoSQL key-value store, fully serverless.

When to use:

• Use RDS when you need transactions & complex queries.

• Use DynamoDB for fast lookups, real-time apps, or event-driven workloads.

5. Amazon CloudWatch & IAM – Monitoring & Security

• CloudWatch: Logs, metrics, alarms for apps.

• IAM (Identity & Access Management): Secure access with least-privilege policies.

Why it matters:

• CloudWatch helps debug production issues (API latency, memory leaks).

• IAM ensures your app isn’t overexposed (e.g., public S3 buckets = security nightmare).

Quick Deployment Example: MERN App on AWS

1. React frontend → Deploy on S3 + CloudFront.

2. Node.js backend → Run on EC2 or Elastic Beanstalk.

3. MongoDB → Use MongoDB Atlas on AWS (or DynamoDB if allowed).

4. File uploads → Store on S3.

5. Monitoring → Use CloudWatch for logs + alerts.

In this blog, we’ll explore how to manage Dev and Prod Lambda deployments using the Serverless Framework. We’ll set up environment-specific configurations, IAM permissions, and function names to keep both environments isolated and manageable.

Why Separate Dev and Prod?

• Avoid breaking production: Experiment safely in Dev before pushing to Prod.

• Environment-specific configs: API keys, DB URIs, and secrets differ between Dev and Prod.

• Cost control: Run lightweight configs in Dev, scale Prod as needed.

• Audit & Monitoring: Logs and alerts should be separated per environment.

Serverless Framework Setup

The Serverless Framework simplifies AWS Lambda deployments by allowing us to declare everything (functions, IAM, env variables, resources) in a single YAML file.

Install Serverless

npm install -g serverless

Initialize a new project:

serverless create --template aws-nodejs --path my-service
cd my-service
npm init -y

Example serverless.yml with Dev & Prod Environments

Here’s a clean example:

service: user-api-service
frameworkVersion: '3'

custom:
  currentStage: ${opt:stage, 'dev'}
  functionNameMap:
    dev: userApiFunction
    prod: userApiFunction-prod

provider:
  name: aws
  runtime: nodejs18.x
  region: ap-south-1
  stage: ${self:custom.currentStage}
  memorySize: ${self:custom.currentStage == 'dev' ? 128 : 512}
  timeout: ${self:custom.currentStage == 'dev' ? 10 : 30}

  environment:
    NODE_ENV: ${self:custom.currentStage}
    DB_URI: ${self:custom.currentStage == 'dev' 
      ? 'mongodb+srv://dev-cluster/test' 
      : 'mongodb+srv://prod-cluster/live'}

  iam:
    role:
      statements:
        - Effect: Allow
          Action:
            - logs:CreateLogGroup
            - logs:CreateLogStream
            - logs:PutLogEvents
          Resource: "*"

functions:
  userApi:
    handler: handler.main
    name: ${self:custom.functionNameMap.${self:custom.currentStage}}
    description: "Lambda for ${self:custom.currentStage} environment"

plugins:
  - serverless-dotenv-plugin
  - serverless-plugin-typescript

Breaking It Down

• custom.currentStage: Picks up stage from CLI (sls deploy --stage prod). Defaults to dev.

• functionNameMap: Ensures Lambda functions have unique names across environments.

• environment: Stage-specific environment variables (e.g., DB URIs).

• memorySize & timeout: Different performance settings for Dev vs Prod.

Deploying to Dev vs Prod

To deploy in Dev (default):

sls deploy

To deploy in Prod:

sls deploy --stage prod

Each environment will create a separate Lambda function, logs, and resources, ensuring clean isolation.

Logging & Monitoring per Environment

Every deployment automatically creates CloudWatch log groups:

• /aws/lambda/userApiFunction → Dev logs

• /aws/lambda/userApiFunction-prod → Prod logs

This separation makes debugging easier and prevents noisy logs from mixing.

Best Practices

1. Use Secrets Manager/SSM Parameter Store for sensitive credentials instead of hardcoding in serverless.yml.

2. Enable log retention to avoid bloated CloudWatch bills.

3. Automate deployments with CI/CD pipelines (GitHub Actions, CodePipeline).

4. Test in Dev before promoting to Prod.

Conclusion

Managing AWS Lambda for multiple environments can get messy if not planned well. Using Serverless Framework with stage-aware configs ensures clean isolation between Dev and Prod. You can tune resources, environment variables, and IAM permissions per environment, while still keeping everything in a single configuration file.

Our medicine reminder app depends heavily on precise dose reminders. Even a 1–2 minute delay can cause users to miss their doses, so reliability was critical.

Initially, we used BullMQ + Node.js workers for scheduling and sending notifications. It worked fine for a small number of users, but at scale, the system started to break.

The Problem

1. Too Many Notifications at the Same Time

• Thousands of notifications were scheduled for the same second.

• Workers pulled huge batches from Redis, causing CPU & memory spikes.

• Redis queues became congested and some jobs got delayed.

2. Worker Overload

• Even with multiple worker instances, the Node.js event loop struggled during peaks.

• Delays became more frequent as user count increased.

Step 1 — Moving to AWS Step Functions + Lambda

We redesigned the scheduling process to spread the load more efficiently.

New Flow:

1. Step Function schedules notification batches at exact times.

2. Each execution triggers a Lambda dedicated to a subset of notifications.

3. We keep 2–3 hot Lambdas ready during peak times to avoid cold starts.

Why Step Functions?

• Native CRON/Rate-based scheduling.

• Orchestration of multiple parallel Lambda executions.

• Fully managed — no manual queue management.

Step 2 — Horizontal Scaling in Lambda

AWS Lambda scales automatically, so during high load, we got dozens of Lambdas in parallel.

This solved the compute bottleneck — but introduced a new problem…

Step 3 — The Database Connection Storm

Each Lambda invocation created a new PostgreSQL connection.

At scale:

• RDS hit the max_connections limit.

• Some Lambdas failed instantly due to connection errors.

• This caused missed or late notifications.

Step 4 — Introducing Amazon RDS Proxy

RDS Proxy pools and shares DB connections across Lambdas.

Benefits:

• Reuses existing DB connections.

• Reduces connection churn and overhead.

• Eliminates too many connections errors.

• Lowers latency because connections are pre-warmed.

Step 5 — Putting Lambdas in a VPC

Since RDS Proxy lives inside a VPC:

• All Lambdas were moved into private subnets within the same VPC.

• This allowed private, low-latency connections to RDS Proxy.

Step 6 — Adding Internet Access via NAT Gateway

Once Lambdas were in the VPC, they lost internet access — which broke calls to FCM.

Fix:

• Created a NAT Gateway in the VPC.

• Updated route tables so Lambdas could:

  • Connect to RDS Proxy privately.

  • Still reach the internet for external APIs.

Final Architecture Diagram

          ┌───────────────────┐
          │  Step Function    │
          │  (Scheduled CRON) │
          └─────────┬─────────┘
                    │
                    ▼
           ┌────────────────────────────────────┐
           │            AWS Lambda(s)           │
           │ (Horizontal Scaling, VPC-Enabled)  │
           │  1️⃣ Query DB via RDS Proxy         │
           │  2️⃣ Send Notifications via APIs    │
           └─────────┬────────────────┬─────────┘
                     │                │
        ┌────────────▼─────────┐   ┌──▼───────────────┐
        │   Amazon RDS Proxy   │   │ NAT Gateway      │
        │ (Connection Pooling) │   │ (Internet Access)│
        └───────────┬──────────┘   └──────────┬──────┘
                    │                        │
          ┌─────────▼──────────┐     ┌───────▼─────────────────┐
          │ PostgreSQL (RDS)   │     │ External APIs (FCM, SNS,│
          └────────────────────┘     │ Push Notification, etc.)│
                                     └─────────────────────────┘

Conclusion

Building an on-time notification system at scale required more than just adding more workers — it demanded a complete architectural rethink. By moving from BullMQ workers to AWS Step Functions for scheduling, Lambda for scalable compute, and RDS Proxy for efficient database connectivity, we achieved a fully serverless, reliable, and low-maintenance solution.

Integrating VPC networking with a NAT Gateway ensured secure database access while still allowing internet connectivity for push and Firebase APIs. Today, our system delivers notifications precisely on time, even during heavy load, while remaining cost-efficient and easy to operate.