Forem: Muhammad Arslan

React Server Components Explained: The Complete 2026 Guide

Muhammad Arslan — Wed, 08 Apr 2026 14:11:41 +0000

React Server Components aren't just a new feature — they're a fundamental rethinking of where your code runs. After years of client-side React, the pendulum is swinging back toward the server, and understanding why is the most important thing a React developer can do in 2026.

1. What Are React Server Components?

React Server Components (RSC) are components that render exclusively on the server and send only HTML to the browser — zero JavaScript shipped for those components. This is fundamentally different from SSR (Server-Side Rendering), which renders on the server but still hydrates the full component tree on the client.

	SSR	RSC
Renders on server	✓	✓
Ships JS to client	✓ (full bundle)	✗ (zero JS)
Needs hydration	✓	✗
Direct DB access	✗	✓

The result? Dramatically smaller JavaScript bundles, faster Time to Interactive (TTI), and the ability to directly access databases, file systems, and secrets — without any API layer.

// app/users/page.tsx — Server Component by default (no 'use client')
import { db } from '@/lib/db';

export default async function UsersPage() {
  // Direct DB access — no useEffect, no fetch, no loading state
  const users = await db.user.findMany();

  return (
    <ul>
      {users.map(user => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

2. Server Components vs Client Components

In the Next.js App Router, every component is a Server Component by default. You opt into client-side behavior by adding 'use client' at the top of the file.

Use Server Components when:

Fetching data or querying a database
Accessing secrets or environment variables safely
Rendering static or non-interactive UI
Working with the filesystem

Use Client Components ('use client') when:

Using useState, useEffect, or other hooks
Attaching event handlers (onClick, onChange)
Using browser APIs (localStorage, window, navigator)
Using third-party libraries that depend on the DOM

The golden rule: push 'use client' as far down the component tree as possible — ideally to small leaf components like buttons, modals, and forms.

3. The Composition Pattern

The most important RSC pattern is passing Client Components as children to Server Components. This lets you keep data fetching on the server while still having interactive UI.

// app/dashboard/page.tsx (Server Component)
import { UserCard } from './UserCard'; // Client Component
import { db } from '@/lib/db';

export default async function Dashboard() {
  const user = await db.user.findFirst(); // runs on server

  return (
    <main>
      <h1>Dashboard</h1>
      {/* Pass server data as props to client component */}
      <UserCard user={user} />
    </main>
  );
}

// components/UserCard.tsx (Client Component)
'use client';
import { useState } from 'react';

export function UserCard({ user }) {
  const [expanded, setExpanded] = useState(false);

  return (
    <div onClick={() => setExpanded(!expanded)}>
      <p>{user.name}</p>
      {expanded && <p>{user.email}</p>}
    </div>
  );
}

⚠️ Common Mistake: You cannot import a Server Component inside a Client Component — the boundary only flows one way. If you need a Server Component's output inside a Client Component, pass it as children props instead.

4. Data Fetching Without useEffect

One of the biggest wins with RSC is eliminating the useEffect + useState data fetching pattern entirely for most cases.

// ❌ OLD WAY — Client Component with useEffect
'use client';
function ProductList() {
  const [products, setProducts] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch('/api/products')
      .then(r => r.json())
      .then(data => { setProducts(data); setLoading(false); });
  }, []);

  if (loading) return <Spinner />;
  return <ul>{products.map(p => <li>{p.name}</li>)}</ul>;
}

// ✅ NEW WAY — Server Component
async function ProductList() {
  const products = await fetch('https://api.example.com/products', {
    next: { revalidate: 60 } // ISR: revalidate every 60 seconds
  }).then(r => r.json());

  return <ul>{products.map(p => <li key={p.id}>{p.name}</li>)}</ul>;
}

Notice the next: { revalidate: 60 } option — this is Next.js's Incremental Static Regeneration (ISR) baked directly into fetch. No extra config needed.

5. Streaming with Suspense

RSC pairs perfectly with React's Suspense for streaming. Instead of waiting for all data before sending any HTML, Next.js streams the page in chunks — the shell renders immediately, and slow data sections stream in as they resolve.

import { Suspense } from 'react';
import { ProductList } from './ProductList';   // slow — hits DB
import { HeroSection } from './HeroSection';   // fast — static

export default function Page() {
  return (
    <main>
      {/* Renders immediately */}
      <HeroSection />

      {/* Streams in when data is ready, shows skeleton meanwhile */}
      <Suspense fallback={<ProductListSkeleton />}>
        <ProductList />
      </Suspense>
    </main>
  );
}

This gives users a fast First Contentful Paint (FCP) even when some parts of the page are slow — a massive Core Web Vitals win.

6. Server Actions: Mutations Without APIs

Server Actions let you run server-side code directly from a form or event handler — no API route needed.

// app/actions.ts
'use server';

import { db } from '@/lib/db';
import { revalidatePath } from 'next/cache';

export async function createPost(formData: FormData) {
  const title = formData.get('title') as string;

  await db.post.create({ data: { title } });

  revalidatePath('/posts'); // invalidate cache after mutation
}

// app/new-post/page.tsx (Server Component)
import { createPost } from '../actions';

export default function NewPostPage() {
  return (
    <form action={createPost}>
      <input name="title" placeholder="Post title" />
      <button type="submit">Create Post</button>
    </form>
  );
}

RSC Decision Checklist

Question	Answer
Does it fetch data or access a DB?	Server Component
Does it use useState / useEffect?	Client Component
Does it use browser APIs?	Client Component
Is it a layout, page, or static UI?	Server Component
Does it handle form submissions?	Server Action

Final Thoughts

React Server Components represent the most significant architectural shift in React since hooks. The mental model is simple: keep as much as possible on the server, push interactivity to the client only where needed.

The payoff is real — smaller bundles, faster load times, simpler data fetching, and the ability to use your backend directly from your components. If you're building with Next.js App Router in 2026, RSC isn't optional knowledge — it's the foundation everything else is built on.

Mastering TypeScript 5.x: Advanced Patterns for Full-Stack Developers

Muhammad Arslan — Thu, 05 Mar 2026 06:38:05 +0000

Mastering TypeScript 5.x: Advanced Patterns for Full-Stack Developers

TypeScript has evolved from being "JavaScript with types" to a powerful, Turing-complete type system that can catch complex architectural bugs before they even hit your IDE. For full-stack developers, mastering advanced TypeScript isn't just about avoiding any—it's about building resilient, self-documenting codebases that scale.

In this guide, we'll explore the patterns I use daily in production-grade React and Node.js applications.

1. The Power of Generics with Constraints

Generics allow us to create reusable components that work with a variety of types while maintaining type safety. But the real magic happens when you add constraints.

interface HasId {
  id: string | number;
}

function getRecordById<T extends HasId>(records: T[], id: string | number): T | undefined {
  return records.find(record => record.id === id);
}

By extending HasId, we ensure that any type passed to getRecordById must have an id property, letting us write safer data-fetching logic.

2. Mapped Types and Key Remapping

Mapped types allow you to create new types based on existing ones. TypeScript 4.1+ introduced Key Remapping, which is incredibly useful for creating API wrappers or state managers.

type FormState = {
  userName: string;
  email: string;
};

type FormValidation = {
  [K in keyof FormState as `validate${Capitalize<K>}`]: (value: FormState[K]) => boolean;
};

// Result:
// {
//   validateUserName: (value: string) => boolean;
//   validateEmail: (value: string) => boolean;
// }

3. Template Literal Types

Template literal types bring the power of string interpolation to the type system. They are perfect for enforcing naming conventions or routing patterns.

type Color = 'primary' | 'secondary';
type Intensity = 'low' | 'high';

type ThemeClass = `bg-${Color}-${Intensity}`;

const myButton: ThemeClass = 'bg-primary-high'; // Valid
const brokenButton: ThemeClass = 'bg-red-low';   // Error!

4. Conditional Types and `infer`

Conditional types act like ternary operators for your types. Combined with the infer keyword, they allow you to "extract" types from complex structures (like the return type of a function or a Promise).

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

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

type User = GetReturnType<typeof fetchUser>; // { id: number, name: string }

Conclusion: Type Safety as a Feature

Advanced TypeScript isn't about making your code more complex—it's about moving the burden of validation from the runtime to the compiler. By implementing these patterns, you reduce unit tests, improve developer experience, and build more predictable systems.

What's your favorite TypeScript pattern? Let me know on Dev.to!

Building Scalable Microservices with Node.js: A Practical Guide

Muhammad Arslan — Tue, 03 Mar 2026 06:49:19 +0000

Building Scalable Microservices with Node.js: A Practical Guide

In today's fast-paced digital landscape, monolithic architectures often struggle to keep up with the demands of scaling, rapid deployment, and technology diversity. Microservices have emerged as the standard for building complex, resilient, and scalable applications. Node.js, with its non-blocking I/O and lightweight nature, is an ideal candidate for building these distributed systems.

What are Microservices?

Microservices architecture is an approach where a single application is built as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery.

Core Principles

Decoupling: Services are independent and can be updated without affecting others.
Single Responsibility: Each service does one thing and does it well.
Autonomy: Teams can choose the best tech stack for each specific service.

Communication Patterns

One of the biggest challenges in microservices is how they talk to each other.

1. Synchronous Communication (REST/gRPC)

Direct request-response pattern. Useful when an immediate response is required.

REST: Simple, ubiquitous, and web-friendly.
gRPC: High-performance, binary protocol using Protocol Buffers.

2. Asynchronous Communication (Message Queues)

Services communicate by sending messages to a broker (like RabbitMQ or Redis). This decouples services and improves reliability.

// Example: Publishing a message to RabbitMQ
const amqp = require('amqplib');

async function publishMessage(queue, message) {
  const connection = await amqp.connect('amqp://localhost');
  const channel = await connection.createChannel();
  await channel.assertQueue(queue, { durable: false });
  channel.sendToQueue(queue, Buffer.from(message));
  console.log(" [x] Sent %s", message);
}

Service Discovery and API Gateways

As your system grows from 5 to 50 services, keeping track of their addresses becomes impossible.

Service Discovery: A mechanism like Consul or Etcd that tracks the health and location of every service instance.
API Gateway: A single entry point for all clients. It handles authentication, routing, rate limiting, and request aggregation.

Managing Data in Microservices

The "Database per Service" pattern is essential. Each microservice owns its data, ensuring that database schema changes in one service don't break others. For cross-service data consistency, consider the Saga Pattern.

Scaling and Resilience

Horizontal Scaling

Instead of a bigger server, use more of them. Node.js services are easy to containerize with Docker and orchestrate with Kubernetes.

Circuit Breakers

Prevent a failure in one service from cascading through the entire system. Use libraries like opossum to stop calling a failing service and give it time to recover.

const CircuitBreaker = require('opossum');

const breaker = new CircuitBreaker(asyncFunctionThatMightFail, options);
breaker.fire()
  .then(console.log)
  .catch(console.error);

Conclusion

Building microservices with Node.js requires a shift in mindset from traditional monolithic development. By embracing decoupling, choosing the right communication patterns, and implementing robust service discovery and scaling strategies, you can build systems that are truly resilient and ready for global scale.

[!TIP]
Start Small: Don't build microservices on day one unless you have a clear reason. Start with a "modular monolith" and split services as they grow.

Mastering React Hooks: From Basics to Custom Hooks (2026 Guide)

Muhammad Arslan — Tue, 03 Mar 2026 04:48:45 +0000

React Hooks transformed how we write React applications. Before hooks, sharing stateful logic between components required complex patterns like Higher-Order Components (HOCs) and render props — patterns that created deeply nested "wrapper hell" and made code difficult to reason about.

With hooks, the same logic is encapsulated in a simple function you can drop into any component. After building dozens of production React applications, I've developed a set of patterns for React hooks that I apply consistently. This guide walks you through all of them — from the fundamentals to advanced custom hook patterns you can use immediately.

Why Hooks Changed Everything
useState — More Than You Think
useEffect — The Right Way
useRef — Beyond DOM References
useContext — Shared State Without Redux
useReducer — Complex State Logic
useMemo & useCallback — When to Actually Use Them
Custom Hooks — The Real Power
React Hooks Best Practices Checklist

1. Why Hooks Changed Everything

Before hooks (React < 16.8), if you needed state or lifecycle methods, you had to write a class component:

// ❌ OLD WAY — Class component with lifecycle methods
class UserProfile extends React.Component {
  state = { user: null, loading: true };

  componentDidMount() {
    fetchUser(this.props.userId).then(user => {
      this.setState({ user, loading: false });
    });
  }

  componentDidUpdate(prevProps) {
    if (prevProps.userId !== this.props.userId) {
      this.setState({ loading: true });
      fetchUser(this.props.userId).then(user => {
        this.setState({ user, loading: false });
      });
    }
  }

  render() {
    if (this.state.loading) return <Spinner />;
    return <div>{this.state.user.name}</div>;
  }
}

The same logic with hooks:

// ✅ NEW WAY — Function component with hooks
const UserProfile = ({ userId }) => {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    setLoading(true);
    fetchUser(userId).then(user => {
      setUser(user);
      setLoading(false);
    });
  }, [userId]);

  if (loading) return <Spinner />;
  return <div>{user.name}</div>;
};

Cleaner, shorter, and — crucially — the data-fetching logic can now be extracted into a reusable custom hook. That's the real win.

2. useState — More Than You Think

useState looks simple but has subtleties that trip up even experienced developers.

Functional Updates

When new state depends on previous state, always use the functional form:

// ❌ BAD — can have stale state in closures
const increment = () => setCount(count + 1);

// ✅ GOOD — always works, even inside async callbacks or event batching
const increment = () => setCount(prev => prev + 1);

This matters especially when called multiple times in rapid succession:

// ❌ This will only increment by 1, not 3
const handleTripleClick = () => {
  setCount(count + 1);
  setCount(count + 1);
  setCount(count + 1);
};

// ✅ This correctly increments by 3
const handleTripleClick = () => {
  setCount(prev => prev + 1);
  setCount(prev => prev + 1);
  setCount(prev => prev + 1);
};

Lazy Initial State

If your initial state requires an expensive computation, pass a function to avoid re-running it on every render:

// ❌ BAD — parseFilters runs on EVERY render
const [filters, setFilters] = useState(parseFilters(window.location.search));

// ✅ GOOD — parseFilters runs only once
const [filters, setFilters] = useState(() => parseFilters(window.location.search));

State Batching

In React 18+, state updates are automatically batched — even inside setTimeout, Promise, and native event handlers. This means fewer re-renders out of the box:

// In React 18, this causes ONE re-render (not two)
const handleSubmit = async () => {
  const result = await submitForm(formData);
  setLoading(false);    // ─┐ Batched together
  setSuccess(true);     // ─┘ → single re-render
};

3. useEffect — The Right Way

useEffect is powerful but commonly misused. Let's break down the rules.

The Dependency Array — No Lies

Every value from the component scope that is used inside useEffect must be in the dependency array. Omitting dependencies leads to stale closure bugs:

// ❌ BAD — stale closure: `userId` is captured from the first render only
useEffect(() => {
  fetchUser(userId).then(setUser);
}, []); // Missing userId

// ✅ GOOD — re-runs correctly whenever userId changes
useEffect(() => {
  fetchUser(userId).then(setUser);
}, [userId]);

Use the eslint-plugin-react-hooks ESLint plugin to catch these automatically.

Cleanup Functions

Always return a cleanup function when your effect sets up a subscription, timer, or async operation:

useEffect(() => {
  const controller = new AbortController();

  fetch(`/api/users/${userId}`, { signal: controller.signal })
    .then(res => res.json())
    .then(setUser)
    .catch(err => {
      if (err.name !== 'AbortError') throw err;
    });

  // Cleanup: cancel the in-flight request when component unmounts or userId changes
  return () => controller.abort();
}, [userId]);

// Cleanup for event listeners
useEffect(() => {
  const handleResize = () => setWindowWidth(window.innerWidth);
  window.addEventListener('resize', handleResize);

  return () => window.removeEventListener('resize', handleResize);
}, []);

Separating Concerns

Each useEffect should do one thing. Split unrelated logic into separate effects:

// ❌ BAD — two unrelated concerns in one effect
useEffect(() => {
  fetchUser(userId).then(setUser);
  document.title = `Profile - ${username}`;
}, [userId, username]);

// ✅ GOOD — separated, easier to reason about and debug
useEffect(() => {
  fetchUser(userId).then(setUser);
}, [userId]);

useEffect(() => {
  document.title = `Profile - ${username}`;
}, [username]);

4. useRef — Beyond DOM References

useRef is commonly used to access DOM nodes, but it has a second powerful use case: storing mutable values that persist across renders without triggering a re-render.

Tracking Previous Values

const usePrevious = (value) => {
  const ref = useRef(undefined);

  useEffect(() => {
    ref.current = value;
  });

  return ref.current; // Returns the value from the previous render
};

// Usage
const MyComponent = ({ count }) => {
  const prevCount = usePrevious(count);

  return (
    <p>
      Current: {count} | Previous: {prevCount}
    </p>
  );
};

Storing Stable Callbacks

useRef can be used to create a "stable" callback reference — useful when you need a callback inside useEffect but don't want to re-run the effect when it changes:

const useEventCallback = (fn) => {
  const ref = useRef(fn);

  useEffect(() => {
    ref.current = fn;
  });

  return useCallback((...args) => ref.current(...args), []);
};

// Usage — the effect doesn't re-run when `onSuccess` changes
const MyForm = ({ onSuccess }) => {
  const stableOnSuccess = useEventCallback(onSuccess);

  useEffect(() => {
    subscribeToForm(stableOnSuccess);
    return () => unsubscribeFromForm(stableOnSuccess);
  }, [stableOnSuccess]); // ← stable reference, never changes
};

Tracking Whether a Component Is Mounted

Prevent the "Can't perform a React state update on an unmounted component" warning:

const useIsMounted = () => {
  const isMounted = useRef(false);

  useEffect(() => {
    isMounted.current = true;
    return () => {
      isMounted.current = false;
    };
  }, []);

  return isMounted;
};

// Usage
const DataFetcher = ({ url }) => {
  const [data, setData] = useState(null);
  const isMounted = useIsMounted();

  useEffect(() => {
    fetch(url)
      .then(res => res.json())
      .then(result => {
        if (isMounted.current) {  // ← Check before updating state
          setData(result);
        }
      });
  }, [url]);
};

5. useContext — Shared State Without Redux

useContext combined with useReducer often eliminates the need for Redux in medium-complexity apps.

Theme / Auth Context Pattern

// context/AuthContext.js
const AuthContext = createContext(null);

export const AuthProvider = ({ children }) => {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    // Check if user is already logged in (e.g., from localStorage/session)
    const storedUser = JSON.parse(localStorage.getItem('user'));
    if (storedUser) setUser(storedUser);
    setLoading(false);
  }, []);

  const login = async (credentials) => {
    const user = await authService.login(credentials);
    localStorage.setItem('user', JSON.stringify(user));
    setUser(user);
  };

  const logout = () => {
    localStorage.removeItem('user');
    setUser(null);
  };

  return (
    <AuthContext.Provider value={{ user, loading, login, logout }}>
      {children}
    </AuthContext.Provider>
  );
};

// Custom hook to consume the context — always export this, not the context itself
export const useAuth = () => {
  const context = useContext(AuthContext);
  if (!context) {
    throw new Error('useAuth must be used within an AuthProvider');
  }
  return context;
};

// Usage inside any component, anywhere in the tree
const Navbar = () => {
  const { user, logout } = useAuth();

  return (
    <nav>
      {user ? (
        <>
          <span>Welcome, {user.name}</span>
          <button onClick={logout}>Sign Out</button>
        </>
      ) : (
        <Link to="/login">Sign In</Link>
      )}
    </nav>
  );
};

Performance Note: Context re-renders all consumers when its value changes. Split your context into multiple providers (e.g., AuthContext and ThemeContext) so a theme change doesn't re-render every component that consumes auth.

6. useReducer — Complex State Logic

When state updates are complex or interdependent, useReducer is far cleaner than multiple useState calls.

// ❌ Messy — 5 related useState calls, hard to manage atomically
const [items, setItems] = useState([]);
const [loading, setLoading] = useState(false);
const [error, setError] = useState(null);
const [page, setPage] = useState(1);
const [hasMore, setHasMore] = useState(true);

// ✅ Clean — useReducer manages all related state as a unit
const initialState = {
  items: [],
  loading: false,
  error: null,
  page: 1,
  hasMore: true,
};

const feedReducer = (state, action) => {
  switch (action.type) {
    case 'FETCH_START':
      return { ...state, loading: true, error: null };
    case 'FETCH_SUCCESS':
      return {
        ...state,
        loading: false,
        items: [...state.items, ...action.payload.items],
        page: state.page + 1,
        hasMore: action.payload.items.length === action.payload.limit,
      };
    case 'FETCH_ERROR':
      return { ...state, loading: false, error: action.payload };
    case 'RESET':
      return initialState;
    default:
      return state;
  }
};

const InfiniteList = () => {
  const [state, dispatch] = useReducer(feedReducer, initialState);

  const loadMore = async () => {
    dispatch({ type: 'FETCH_START' });
    try {
      const data = await fetchItems({ page: state.page, limit: 20 });
      dispatch({ type: 'FETCH_SUCCESS', payload: data });
    } catch (err) {
      dispatch({ type: 'FETCH_ERROR', payload: err.message });
    }
  };

  // ...
};

7. useMemo & useCallback — When to Actually Use Them

These hooks are frequently overused. Here's a precise decision framework:

Use `useMemo` when:

Computing a filtered/sorted array from a large dataset
Creating an object or array passed as a prop to a React.memo component
Performing genuinely expensive calculations (parsing, complex math)

Use `useCallback` when:

Passing a callback to a memoized child (React.memo)
Passing a callback into a useEffect dependency array
The function is a dependency of another hook

// ✅ Correct use of useMemo
const expensiveReport = useMemo(() => {
  return rawData
    .filter(row => row.status === activeFilter)
    .map(row => ({ ...row, profit: row.revenue - row.cost }))
    .sort((a, b) => b.profit - a.profit);
}, [rawData, activeFilter]);

// ✅ Correct use of useCallback
const handleDelete = useCallback((id) => {
  setItems(prev => prev.filter(item => item.id !== id));
}, []); // No dependencies → stable reference forever

// ❌ Useless memoization — wrapping a primitive computation
const double = useMemo(() => count * 2, [count]); // Just write: count * 2

8. Custom Hooks — The Real Power

Custom hooks are where hooks truly shine. They let you extract, reuse, and test stateful logic independently of any UI.

`useFetch` — Data Fetching with Loading & Error States

const useFetch = (url, options = {}) => {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const controller = new AbortController();

    const fetchData = async () => {
      setLoading(true);
      setError(null);
      try {
        const res = await fetch(url, { ...options, signal: controller.signal });
        if (!res.ok) throw new Error(`HTTP error: ${res.status}`);
        const json = await res.json();
        setData(json);
      } catch (err) {
        if (err.name !== 'AbortError') {
          setError(err.message);
        }
      } finally {
        setLoading(false);
      }
    };

    fetchData();

    return () => controller.abort();
  }, [url]);

  return { data, loading, error };
};

// Usage
const ProductList = () => {
  const { data, loading, error } = useFetch('/api/products');

  if (loading) return <Spinner />;
  if (error) return <ErrorBanner message={error} />;
  return <ul>{data.map(p => <li key={p.id}>{p.name}</li>)}</ul>;
};

`useLocalStorage` — Persistent State

const useLocalStorage = (key, initialValue) => {
  const [storedValue, setStoredValue] = useState(() => {
    try {
      const item = window.localStorage.getItem(key);
      return item ? JSON.parse(item) : initialValue;
    } catch {
      return initialValue;
    }
  });

  const setValue = (value) => {
    try {
      const valueToStore = value instanceof Function ? value(storedValue) : value;
      setStoredValue(valueToStore);
      window.localStorage.setItem(key, JSON.stringify(valueToStore));
    } catch (error) {
      console.error(error);
    }
  };

  return [storedValue, setValue];
};

// Usage — works exactly like useState but persists to localStorage
const Settings = () => {
  const [theme, setTheme] = useLocalStorage('theme', 'light');
  const [language, setLanguage] = useLocalStorage('language', 'en');

  return (
    <div>
      <select value={theme} onChange={e => setTheme(e.target.value)}>
        <option value="light">Light</option>
        <option value="dark">Dark</option>
      </select>
    </div>
  );
};

`useDebounce` — Throttle Expensive Operations

const useDebounce = (value, delay = 300) => {
  const [debouncedValue, setDebouncedValue] = useState(value);

  useEffect(() => {
    const timer = setTimeout(() => setDebouncedValue(value), delay);
    return () => clearTimeout(timer);
  }, [value, delay]);

  return debouncedValue;
};

// Usage — perfect for search inputs
const SearchBar = () => {
  const [query, setQuery] = useState('');
  const debouncedQuery = useDebounce(query, 400);

  const { data: results } = useFetch(
    debouncedQuery ? `/api/search?q=${debouncedQuery}` : null
  );

  return (
    <div>
      <input
        value={query}
        onChange={e => setQuery(e.target.value)}
        placeholder="Search products..."
      />
      <ResultsList results={results} />
    </div>
  );
};

`useForm` — Reusable Form Logic

const useForm = (initialValues, validate) => {
  const [values, setValues] = useState(initialValues);
  const [errors, setErrors] = useState({});
  const [touched, setTouched] = useState({});
  const [isSubmitting, setIsSubmitting] = useState(false);

  const handleChange = (e) => {
    const { name, value } = e.target;
    setValues(prev => ({ ...prev, [name]: value }));
  };

  const handleBlur = (e) => {
    const { name } = e.target;
    setTouched(prev => ({ ...prev, [name]: true }));
    if (validate) {
      setErrors(validate(values));
    }
  };

  const handleSubmit = (onSubmit) => async (e) => {
    e.preventDefault();
    const validationErrors = validate ? validate(values) : {};
    setErrors(validationErrors);
    setTouched(Object.keys(values).reduce((acc, key) => ({ ...acc, [key]: true }), {}));

    if (Object.keys(validationErrors).length === 0) {
      setIsSubmitting(true);
      await onSubmit(values);
      setIsSubmitting(false);
    }
  };

  const reset = () => {
    setValues(initialValues);
    setErrors({});
    setTouched({});
  };

  return { values, errors, touched, isSubmitting, handleChange, handleBlur, handleSubmit, reset };
};

// Usage
const ContactForm = () => {
  const { values, errors, touched, isSubmitting, handleChange, handleBlur, handleSubmit } = useForm(
    { name: '', email: '', message: '' },
    (vals) => {
      const errs = {};
      if (!vals.name) errs.name = 'Name is required';
      if (!vals.email.includes('@')) errs.email = 'Valid email required';
      if (vals.message.length < 10) errs.message = 'Message too short';
      return errs;
    }
  );

  const onSubmit = handleSubmit(async (data) => {
    await submitContactForm(data);
  });

  return (
    <form onSubmit={onSubmit}>
      <input
        name="name"
        value={values.name}
        onChange={handleChange}
        onBlur={handleBlur}
      />
      {touched.name && errors.name && <span className="error">{errors.name}</span>}

      <button type="submit" disabled={isSubmitting}>
        {isSubmitting ? 'Sending...' : 'Send Message'}
      </button>
    </form>
  );
};

9. React Hooks Best Practices Checklist

Apply this every time you write a hook or component:

Rules of Hooks (Non-Negotiable):

[ ] Only call hooks at the top level — never inside loops, conditions, or nested functions
[ ] Only call hooks from React function components or other custom hooks

useState:

[ ] Use functional updates (prev => ...) when new state depends on old state
[ ] Use lazy initialization (() => ...) for expensive initial state computations
[ ] Group related state into objects or switch to useReducer if state has 4+ fields

useEffect:

[ ] Every value used inside the effect is listed in the dependency array
[ ] Every effect with subscriptions, timers, or async operations has a cleanup function
[ ] Each effect handles a single responsibility (split unrelated effects)
[ ] Install and configure eslint-plugin-react-hooks

Custom Hooks:

[ ] Named with the use prefix
[ ] Each hook has a single, clear responsibility
[ ] Logic is generic enough to be reused across 2+ components
[ ] Side effects inside the hook have proper cleanup

Performance:

[ ] useCallback is only used when passing callbacks to memoized children or hooks
[ ] useMemo is only used for genuinely expensive computations
[ ] Don't premature optimize — profile first

Conclusion

Hooks represent the most significant shift in React's history. But mastering them isn't about memorizing their API — it's about understanding when and why to use each one.

The real lever is custom hooks. Once you start extracting business logic into useFetch, useForm, useDebounce, and domain-specific hooks, you'll find your components become dramatically simpler — pure expressions of what to render, with all the complex logic neatly tucked away in composable, testable functions.

The patterns in this guide are production-tested across dozens of React applications. Start with the custom hooks above, wire them into your own projects, and adapt them to your specific needs.

What's your favourite custom hook pattern? Drop it in the comments below 👇

For more React deep dives, architectural guides, and full-stack content, visit muhammadarslan.codes or connect with me on LinkedIn and GitHub.

Building Scalable Real-Time Applications with Node.js, Socket.io, and React

Muhammad Arslan — Fri, 27 Feb 2026 06:27:11 +0000

From collaborative whiteboards and live trading dashboards to chat applications and multiplayer games, real-time functionality is no longer a luxury—it's an expectation.

Building a real-time application that works for 10 users on a local machine is relatively straightforward. Scaling that same application to handle 10,000 concurrent users across distributed servers is a completely different architectural challenge.

After architecting real-time systems for enterprise clients, I've distilled the patterns that matter. In this guide, we'll traverse the entire stack: from setting up a reliable Socket.io server with Node.js, seamlessly integrating it with React, to ultimately structuring the system to scale horizontally.

1. Understanding the Transport Layer

Before writing code, it's crucial to understand why we use the tools we do.

HTTP is stateless and unidirectional. The client requests, the server responds. If the server has new data, it cannot initiate a push to the client unless the client asks for it (using techniques like Long Polling).

WebSockets provide a persistent, bi-directional, full-duplex communication channel over a single TCP connection. Once the handshake is complete, both the server and the client can send data at any time with minimal overhead.

Socket.io is not a WebSocket library. It is a library that uses WebSockets as its primary transport protocol but provides crucial abstractions:

Fallback mechanisms: If WebSockets aren't supported (or blocked by a corporate proxy), it seamlessly downgrades to HTTP Long Polling.
Automatic reconnections: If a user drops connection, Socket.io handles the complex logic of reconnecting with exponential backoff.
Broadcasting & Rooms: Built-in APIs to send messages to everyone, specific groups, or individual users.
Acknowledgements: You know exactly when the client received an event.

2. Architecting the Node.js Server

A flat file structure might work for a quick tutorial, but a production application needs a modular architecture to manage event handlers cleanly.

The Foundation

Let's construct the basic Express + Socket.io scaffolding:

// server.js
const express = require('express');
const http = require('http');
const { Server } = require('socket.io');
const setupSocketHandlers = require('./sockets');
const cors = require('cors');

const app = express();
app.use(cors());

// Required: Socket.io attaches to the raw HTTP server, not the Express app
const server = http.createServer(app);

const io = new Server(server, {
  cors: {
    origin: process.env.CLIENT_URL || 'http://localhost:3000',
    methods: ['GET', 'POST'],
    credentials: true,
  },
  // Recommended: ping times to detect dead connections faster
  pingTimeout: 60000,
  pingInterval: 25000,
});

// Pass the io instance to our handler setup
setupSocketHandlers(io);

const PORT = process.env.PORT || 8080;
server.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

Structuring Event Handlers

Instead of dumping everything inside io.on('connection'), we split handlers by domain logic, passing the io instance and the specific socket.

// sockets/index.js
const chatHandler = require('./chatHandler');
const notificationHandler = require('./notificationHandler');
const { authenticateSocket } = require('../middlewares/auth');

module.exports = (io) => {
  // 1. Authentication Middleware
  io.use(authenticateSocket);

  // 2. Connection Logic
  io.on('connection', (socket) => {
    console.log(`User connected: ${socket.user.id} (Socket: ${socket.id})`);

    // Add user to their personal room for direct private messages
    socket.join(`user:${socket.user.id}`);

    // Register domain-specific handlers
    chatHandler(io, socket);
    notificationHandler(io, socket);

    socket.on('disconnect', (reason) => {
      console.log(`User disconnected: ${socket.id} - Reason: ${reason}`);
      // Cleanup offline presence status here
    });
  });
};

The Domain Handler

A typical domain handler encapsulates related events:

// sockets/chatHandler.js
module.exports = (io, socket) => {
  // Join a specific chat room
  socket.on('chat:join', (roomId) => {
    socket.join(`room:${roomId}`);

    // Notify others in the room
    socket.to(`room:${roomId}`).emit('chat:user_joined', {
      userId: socket.user.id,
      name: socket.user.name,
    });
  });

  // Handle incoming messages
  socket.on('chat:message', async (data, callback) => {
    try {
      const { roomId, content } = data;

      // 1. Save to database completely decoupled from transport (MongoDB, PostgreSQL)
      const message = await MessageService.save({
        senderId: socket.user.id,
        roomId,
        content,
      });

      // 2. Broadcast to everyone in the room (except sender)
      socket.to(`room:${roomId}`).emit('chat:new_message', message);

      // 3. Acknowledge success to the sender
      callback({ status: 'ok', data: message });

    } catch (error) {
      // Return error to client without crashing server
      callback({ status: 'error', message: 'Failed to send message' });
    }
  });
};

Key Takeaway: Notice the callback pattern. By acknowledging the event, the client knows definitively whether the server processed the database write successfully, removing the need to emit a separate "success" event back to the sender.

3. Integrating React Robustly

Integrating Socket.io on the frontend isn't just about calling io(). Managing the lifecycle of the socket connection in a React component tree requires care to avoid memory leaks, duplicate event listeners, and stale state closures.

The Socket Context Provider

The most scalable pattern is to isolate the socket connection in a React Context. This ensures only one connection exists for the entire application, accessible by any component.

// context/SocketContext.tsx
import React, { createContext, useContext, useEffect, useState } from 'react';
import { io, Socket } from 'socket.io-client';
import { useAuth } from './AuthContext'; // Assume you have an auth context

interface SocketContextData {
  socket: Socket | null;
  isConnected: boolean;
}

const SocketContext = createContext<SocketContextData>({ 
  socket: null, 
  isConnected: false 
});

export const SocketProvider: React.FC<{ children: React.ReactNode }> = ({ children }) => {
  const { token, isAuthenticated } = useAuth();
  const [socket, setSocket] = useState<Socket | null>(null);
  const [isConnected, setIsConnected] = useState(false);

  useEffect(() => {
    // Only connect if the user is authenticated
    if (!isAuthenticated || !token) return;

    // Initialize connection
    const socketInstance = io(process.env.NEXT_PUBLIC_API_URL, {
      auth: { token },     // Pass auth token during handshake
      transports: ['websocket'], // Prefer native websockets
      autoConnect: true,
    });

    setSocket(socketInstance);

    // Track connection state
    socketInstance.on('connect', () => setIsConnected(true));
    socketInstance.on('disconnect', () => setIsConnected(false));

    // Connection error handling
    socketInstance.on('connect_error', (err) => {
      console.error('Socket connection error:', err.message);
    });

    // CRITICAL: Cleanup connection when provider unmounts or auth changes
    return () => {
      socketInstance.disconnect();
    };
  }, [token, isAuthenticated]);

  return (
    <SocketContext.Provider value={{ socket, isConnected }}>
      {children}
    </SocketContext.Provider>
  );
};

export const useSocket = () => useContext(SocketContext);

Implementing Listeners in Components

When components mount, they listen to events. When they unmount, they must remove their listeners. If you don't remove listeners, every time a component re-renders, a new listener is attached, causing an event to trigger multiple times (the classic duplicate message bug).

// components/ChatRoom.tsx
import React, { useEffect, useState, useRef } from 'react';
import { useSocket } from '../context/SocketContext';

export const ChatRoom = ({ roomId }) => {
  const { socket, isConnected } = useSocket();
  const [messages, setMessages] = useState([]);
  const [inputValue, setInputValue] = useState('');

  // Use a ref to always access the latest messages in the callback
  // without adding `messages` into the useEffect dependency array
  const messagesRef = useRef(messages);
  useEffect(() => {
    messagesRef.current = messages;
  }, [messages]);

  useEffect(() => {
    if (!socket || !isConnected) return;

    // 1. Join room
    socket.emit('chat:join', roomId);

    // 2. Define listener
    const handleNewMessage = (newMessage) => {
      // Functional state update or ref to avoid stale closures
      setMessages((prev) => [...prev, newMessage]);
    };

    // 3. Attach listener
    socket.on('chat:new_message', handleNewMessage);

    // 4. Cleanup on unmount or when dependencies change
    return () => {
      socket.off('chat:new_message', handleNewMessage);
      socket.emit('chat:leave', roomId);
    };
  }, [socket, isConnected, roomId]);

  const sendMessage = (e) => {
    e.preventDefault();
    if (!inputValue.trim() || !socket) return;

    // Utilizing the acknowledgement callback pattern
    socket.emit('chat:message', { roomId, content: inputValue }, (response) => {
      if (response.status === 'ok') {
        // Add our own message immediately (Optimistic UI) 
        // or wait for the server confirmation (Pessimistic UI)
        setMessages((prev) => [...prev, response.data]);
        setInputValue('');
      } else {
        alert('Failed to send message');
      }
    });
  };

  // Render UI...
};

4. Scaling Horizontally (The Multi-Server Challenge)

Here is where the architecture changes drastically.

Imagine your traffic grows and you put a Load Balancer (like Nginx or AWS ALB) in front of three Node.js server instances: Server A, Server B, and Server C.

User 1 connects to Server A.
User 2 connects to Server B.
User 1 sends a message to a room. Server A receives it and tells all connected clients in that room about the message.
The Problem: Server A knows nothing about User 2 connected to Server B. User 2 never gets the message.

The Redis Adapter Solution

To solve this, servers need a way to communicate with each other. The industry standard is utilizing Redis Pub/Sub via the @socket.io/redis-adapter.

When Server A wants to broadcast a message, it doesn't just broadcast to its own local clients. It publishes the message to Redis. Redis immediately pushes that message to Server B and Server C, instructing them to broadcast the message to their respective connected clients.

npm install redis @socket.io/redis-adapter

// server.js (scaled version)
const { createClient } = require('redis');
const { createAdapter } = require('@socket.io/redis-adapter');

const io = new Server(server, { /* options */ });

const setupRedis = async () => {
  const pubClient = createClient({ url: process.env.REDIS_URL });
  const subClient = pubClient.duplicate();

  await Promise.all([pubClient.connect(), subClient.connect()]);

  // Connect Socket.io to Redis
  io.adapter(createAdapter(pubClient, subClient));
  console.log('Redis adapter attached to Socket.io');
};

setupRedis().then(() => {
  setupSocketHandlers(io);
  server.listen(PORT);
});

With literally 10 lines of code, your real-time application can now be deployed across an infinite number of servers.

Important Load Balancing Note: If you are using HTTP Long Polling as a fallback, your Load Balancer must be configured to use Sticky Sessions (IP hash routing). This ensures that a client's transport requests always go to the same server where their initial handshake occurred. If you force native WebSockets only (transports: ['websocket']), sticky sessions are not required.

5. Security & Production Checklist

Before shipping a real-time app to production, check these off:

Authentication: Never trust the client. Always authenticate users during the handshake using middleware (io.use()) utilizing JWTs or Session IDs.
Authorization: Just because a user is authenticated doesn't mean they can join any room. Verify permission inside the chat:join event before calling socket.join().
Rate Limiting: WebSockets bypass typical HTTP API rate limiters. Implement a custom rate limiting middleware using Redis or memory to prevent a malicious client from emitting 1,000 events per second.
Payload Validation: Validate every incoming WebSocket event payload (e.g., using Joi or Zod) just as strictly as you would an HTTP POST request.
Connection Limits: Set limits on the maximum number of concurrent connections per IP address to mitigate basic DoS attacks.

Final Thoughts

Building real-time systems is one of the most rewarding challenges in web development. By organizing your Node.js handlers logically, strictly managing your React context lifecycles, and utilizing Redis for horizontal scaling, you shift your architecture from a localized prototype to an enterprise-grade system.

The patterns described here are battle-tested in systems handling tens of thousands of concurrent users. Implement them rigorously, and your application will stay stable, fast, and remarkably scalable.

What's the hardest part of building real-time apps in your experience? State management? Scaling? Let me know in the comments 👇

For more insights into Node.js architecture and React front-end scalability, visit my blog at muhammadarslan.codes/blog or connect with me on LinkedIn and GitHub.

Mastering Next.js 16 SEO: A Practical Guide to Ranking Higher

Muhammad Arslan — Mon, 23 Feb 2026 04:28:52 +0000

Next.js has become the gold standard for building React applications that perform exceptionally well and rank highly on search engines. But out of the box, Next.js isn't magically optimized for SEO—it just provides the tools you need to get there.

After auditing and deploying numerous Next.js projects for production, I've compiled the essential checklist for technical SEO in Next.js 16 (App Router). If you want your site to be easily discoverable by Google and other crawlers, you need to implement these patterns.

1. Dynamic Metadata API

The new App Router in Next.js 16 features a powerful Metadata API that makes managing your <head> tags much simpler and more robust than the old next/head component.

Instead of defining SEO tags inside components, you export a metadata object or generateMetadata function from your layout.tsx or page.tsx.

// app/blog/[slug]/page.tsx
import { Metadata } from 'next';

type Props = {
  params: { slug: string };
};

export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const post = await fetchBlogPost(params.slug);

  return {
    title: `${post.title} | My Tech Blog`,
    description: post.excerpt,
    openGraph: {
      title: post.title,
      description: post.excerpt,
      url: `https://muhammadarslan.codes/blog/${params.slug}`,
      siteName: 'Muhammad Arslan Tech Blog',
      images: [
        {
          url: post.coverImage,
          width: 1200,
          height: 630,
          alt: post.title,
        },
      ],
      type: 'article',
    },
    twitter: {
      card: 'summary_large_image',
      title: post.title,
      description: post.excerpt,
      images: [post.coverImage],
    },
  };
}

Why This Matters

Google's crawlers no longer have to wait for client-side JavaScript to execute to discover your page's title and description. This ensures your social sharing cards (Open Graph and Twitter Cards) look perfect when shared on LinkedIn, X, or Slack.

2. Server-Side Rendering (SSR) and Static Site Generation (SSG)

Search engines process static HTML much faster and more reliably than dynamic client-side applications. Next.js excels here by pre-rendering pages.

For marketing pages, portfolios, or directories, Static Site Generation (SSG) is your best friend. In the App Router, Next.js does this automatically unless you use dynamic functions (like cookies() or headers()).

// app/portfolio/page.tsx
// This page is automatically statically optimized
export default async function Portfolio() {
  const projects = await fetchProjects(); // Data fetched at build time (if cached)

  return (
    <main>
      <h1>My Portfolio</h1>
      <ul>
        {projects.map((project) => (
          <li key={project.id}>{project.title}</li>
        ))}
      </ul>
    </main>
  );
}

For content that updates constantly, use Incremental Static Regeneration (ISR) to update static pages in the background without rebuilding the entire site:

// Revalidates this page every 1 hour (3600 seconds)
export const revalidate = 3600;

3. Dynamic XML Sitemaps

A sitemap tells search engines exactly what pages exist on your site. For small sites, a static sitemap.xml in the public/ folder is fine. For content-heavy sites (like blogs or e-commerce), you must generate it dynamically.

Next.js 16 makes this incredibly easy with a sitemap.ts file in your app/ directory:

// app/sitemap.ts
import { MetadataRoute } from 'next';

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const baseUrl = 'https://muhammadarslan.codes';

  // Fetch dynamic routes (e.g., blog posts)
  const posts = await fetchAllBlogPosts();

  const postUrls = posts.map((post) => ({
    url: `${baseUrl}/blog/${post.slug}`,
    lastModified: new Date(post.updatedAt),
    changeFrequency: 'weekly' as const,
    priority: 0.8,
  }));

  // Add static routes
  const staticUrls = [
    {
      url: baseUrl,
      lastModified: new Date(),
      changeFrequency: 'monthly' as const,
      priority: 1.0,
    },
    {
      url: `${baseUrl}/about`,
      lastModified: new Date(),
      changeFrequency: 'yearly' as const,
      priority: 0.5,
    },
  ];

  return [...staticUrls, ...postUrls];
}

4. `robots.txt` Automation

Alongside your sitemap, you need a robots.txt file to instruct crawlers on what they are allowed to index.

You can configure this programmatically in Next.js:

// app/robots.ts
import { MetadataRoute } from 'next';

export default function robots(): MetadataRoute.Robots {
  return {
    rules: {
      userAgent: '*',
      allow: '/',
      disallow: ['/api/', '/admin/', '/private/'], // Hide private routes
    },
    sitemap: 'https://muhammadarslan.codes/sitemap.xml',
  };
}

5. Canonical URLs to Prevent Duplicate Content Bugs

If your site is accessible via www.yoursite.com and yoursite.com, Google might see this as duplicate content and penalize your ranking. Canonical URLs explicitly tell search engines which URL is the "master" version.

Define your canonical URL globally in your root layout, or individually per page:

// app/layout.tsx
export const metadata: Metadata = {
  metadataBase: new URL('https://muhammadarslan.codes'),
  alternates: {
    canonical: '/',
  },
};

When building dynamic routes, always generate the exact canonical path to avoid query parameter duplication (e.g., /blog/post?ref=twitter).

6. Image Optimization with `next/image`

Large, unoptimized images destroy your Core Web Vitals, specifically LCP (Largest Contentful Paint). Poor Core Web Vitals directly harm your Google ranking.

Always use the built-in <Image> component instead of standard <img> tags.

import Image from 'next/image';

export default function HeroSection() {
  return (
    <Image
      src="/hero-banner.jpg"
      alt="Developer building a scalable application"
      width={1200}
      height={800}
      priority // Add priority for LCP images above the fold
      placeholder="blur" // Gives users a smooth loading experience
    />
  );
}

The next/image component automatically converts images to modern formats like WebP or AVIF, serves responsive sizes based on the user's device, and prevents layout shift (CLS).

Final Thoughts

SEO in 2026 isn't about keyword stuffing; it's about delivering a fast, accessible, and structured experience for both users and crawlers. By leveraging Next.js 16 features—dynamic metadata, SSR/SSG, automated sitemaps, and optimized media—you lay down a technical foundation that search engines love.

Build fast. Render smartly. Rank highly.

What SEO strategies are you leaning heavily into this year? Drop your thoughts in the comments below 👇

If you want to see more of my work or discuss a project, feel free to visit my portfolio at muhammadarslan.codes or connect with me on LinkedIn and GitHub.

React Performance Optimization: Advanced Techniques That Actually Work

Muhammad Arslan — Mon, 16 Feb 2026 12:50:29 +0000

Your React app works. But is it fast?

In my experience building React applications for enterprise clients, I've seen apps that feel snappy with 100 users suddenly crawl to a halt with 10,000. The difference isn't the server — it's how the frontend handles rendering.

Here's the comprehensive guide to making your React apps blazingly fast, using techniques I apply on every production project.

Understanding the Cost of Rendering

Before optimizing, you need to understand why React re-renders.

React re-renders a component when:

Its state changes
Its props change
Its parent re-renders (even if props didn't change!)

That third point is the silent killer. A single state change at the top of your component tree can cascade into hundreds of unnecessary re-renders.

How to Measure

Before optimizing blindly, profile first:

# Install React DevTools browser extension
# Then in your app:
# 1. Open DevTools → Profiler tab
# 2. Click Record
# 3. Interact with your app
# 4. Stop Recording
# 5. Look for components with high "render time"

You can also add this to spot unnecessary re-renders during development:

// hooks/useWhyDidYouRender.ts
import { useRef, useEffect } from 'react';

export function useWhyDidYouRender(name: string, props: Record<string, any>) {
  const prev = useRef(props);

  useEffect(() => {
    const changes: Record<string, { from: any; to: any }> = {};

    Object.entries(props).forEach(([key, value]) => {
      if (prev.current[key] !== value) {
        changes[key] = { from: prev.current[key], to: value };
      }
    });

    if (Object.keys(changes).length > 0) {
      console.log(`[WhyRender] ${name}:`, changes);
    }

    prev.current = props;
  });
}

1. Memoization — `useMemo` and `useCallback`

These hooks prevent expensive calculations or function recreations on every render.

`useMemo` — Memoize Computed Values

// ❌ BAD — recalculates on every render
const FilteredProducts = ({ products, filter }) => {
  const filtered = products.filter(p => p.category === filter);
  const sorted = filtered.sort((a, b) => b.price - a.price);

  return <ProductList items={sorted} />;
};

// ✅ GOOD — only recalculates when dependencies change
const FilteredProducts = ({ products, filter }) => {
  const sorted = useMemo(() => {
    const filtered = products.filter(p => p.category === filter);
    return filtered.sort((a, b) => b.price - a.price);
  }, [products, filter]);

  return <ProductList items={sorted} />;
};

`useCallback` — Memoize Functions

// ❌ BAD — new function reference every render → child always re-renders
const Parent = () => {
  const [count, setCount] = useState(0);

  const handleClick = () => {
    console.log('clicked');
  };

  return <ExpensiveChild onClick={handleClick} />;
};

// ✅ GOOD — stable function reference
const Parent = () => {
  const [count, setCount] = useState(0);

  const handleClick = useCallback(() => {
    console.log('clicked');
  }, []);

  return <ExpensiveChild onClick={handleClick} />;
};

When NOT to Use Them

Don't wrap everything in useMemo/useCallback. Memoization itself has a cost (memory + comparison). Only use them when:

The computation is genuinely expensive (filtering/sorting large arrays)
The result is passed to a memoized child (React.memo)
You're preventing expensive child re-renders

2. `React.memo` — Prevent Unnecessary Re-renders

Wrap components that receive stable props but re-render because their parent did:

// This component only re-renders when `items` or `onSelect` actually change
const ProductList = React.memo(({ items, onSelect }) => {
  return (
    <ul>
      {items.map(item => (
        <li key={item.id} onClick={() => onSelect(item.id)}>
          {item.name} — ${item.price}
        </li>
      ))}
    </ul>
  );
});

Custom Comparison

For complex props, provide a custom comparator:

const Chart = React.memo(({ data, config }) => {
  // Expensive chart rendering
  return <canvas ref={chartRef} />;
}, (prevProps, nextProps) => {
  // Only re-render if data length changes or config updates
  return (
    prevProps.data.length === nextProps.data.length &&
    prevProps.config.type === nextProps.config.type
  );
});

3. Virtualization — Render Only What's Visible

If you're rendering a list of 1,000+ items, the browser is creating 1,000+ DOM nodes. Virtualization renders only the ~20 visible items and recycles DOM nodes as the user scrolls.

Using `react-window`

npm install react-window

import { FixedSizeList } from 'react-window';

const BigList = ({ items }) => {
  const Row = ({ index, style }) => (
    <div style={style} className="flex items-center p-4 border-b">
      <span>{items[index].name}</span>
      <span className="ml-auto">${items[index].price}</span>
    </div>
  );

  return (
    <FixedSizeList
      height={600}        // Container height
      itemCount={items.length}
      itemSize={60}        // Row height
      width="100%"
    >
      {Row}
    </FixedSizeList>
  );
};

Result: Instead of 10,000 DOM nodes, you have ~15. Scroll performance goes from choppy to silky smooth.

For variable-height rows, use VariableSizeList. For grids, use FixedSizeGrid.

4. Code Splitting — Load Only What's Needed

Don't make users download your entire app upfront. Split your bundle by routes and heavy components:

import { lazy, Suspense } from 'react';

// These components are loaded only when the route is visited
const Dashboard = lazy(() => import('./pages/Dashboard'));
const Analytics = lazy(() => import('./pages/Analytics'));
const Settings = lazy(() => import('./pages/Settings'));

const App = () => (
  <Suspense fallback={<LoadingSpinner />}>
    <Routes>
      <Route path="/dashboard" element={<Dashboard />} />
      <Route path="/analytics" element={<Analytics />} />
      <Route path="/settings" element={<Settings />} />
    </Routes>
  </Suspense>
);

Lazy Load Heavy Libraries

// Don't import chart libraries at the top level
const ChartComponent = lazy(() => import('./components/Chart'));

// The chart library JS only loads when <ChartComponent> is rendered
const Dashboard = () => (
  <div>
    <h1>Dashboard</h1>
    <Suspense fallback={<div>Loading chart...</div>}>
      <ChartComponent data={chartData} />
    </Suspense>
  </div>
);

5. State Management — Keep State Close

One of the biggest performance mistakes is putting everything in global state (Redux/Context). When global state updates, every connected component re-renders.

Rules of Thumb

State Type	Where to Put It
Form input values	Local `useState`
UI toggles (modals, dropdowns)	Local `useState`
Server data (API responses)	React Query / SWR
Auth / Theme	Context (rarely changes)
Complex cross-component state	Zustand / Jotai

// ❌ BAD — every modal open triggers global re-render
const globalState = {
  user: { ... },
  products: [...],
  isModalOpen: false,  // This doesn't belong here
  modalContent: null,  // Neither does this
};

// ✅ GOOD — modal state lives locally
const ProductPage = () => {
  const [isModalOpen, setIsModalOpen] = useState(false);
  const { data: products } = useQuery(['products'], fetchProducts);

  return (
    <>
      <ProductList products={products} onEdit={() => setIsModalOpen(true)} />
      {isModalOpen && <EditModal onClose={() => setIsModalOpen(false)} />}
    </>
  );
};

6. Image Optimization

Images are often the heaviest assets on a page:

// Lazy load images that are below the fold
<img 
  src={product.image} 
  alt={product.name}
  loading="lazy"
  decoding="async"
  width={400}
  height={300}
/>

// Use modern formats with fallbacks
<picture>
  <source srcSet="/hero.avif" type="image/avif" />
  <source srcSet="/hero.webp" type="image/webp" />
  <img src="/hero.jpg" alt="Hero" />
</picture>

7. Debounce Expensive Operations

Search inputs, resize handlers, and scroll listeners should be debounced:

import { useState, useMemo } from 'react';
import debounce from 'lodash.debounce';

const SearchBar = ({ onSearch }) => {
  const [query, setQuery] = useState('');

  const debouncedSearch = useMemo(
    () => debounce((q: string) => onSearch(q), 300),
    [onSearch]
  );

  const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    setQuery(e.target.value);
    debouncedSearch(e.target.value);
  };

  return <input value={query} onChange={handleChange} placeholder="Search..." />;
};

Quick Performance Checklist

Before shipping to production, run through this:

[ ] Profile with React DevTools — identify slow components
[ ] Bundle analyze with webpack-bundle-analyzer or vite-plugin-visualizer
[ ] Lighthouse audit — target 90+ performance score
[ ] Virtualize lists with 50+ items
[ ] Lazy load routes and heavy components
[ ] Memoize expensive computations and stable callbacks
[ ] Optimize images — WebP/AVIF, lazy loading, proper sizing
[ ] Debounce user input that triggers expensive operations

Conclusion

Performance is a feature, not an afterthought. By applying these techniques systematically — profiling first, then optimizing where it matters — you ensure your React applications remain snappy and responsive as they grow.

The key insight? Don't optimize everything. Measure first, then optimize the bottlenecks.

What performance wins have you had in your React apps? Share in the comments! 👇

For more technical deep dives, check out my blog at muhammadarslan.codes/blog or connect with me on LinkedIn and GitHub.

Scaling MERN Stack Applications to 100K+ Users: A Real-World Guide

Muhammad Arslan — Mon, 16 Feb 2026 12:48:00 +0000

Your MERN stack app works beautifully with 100 concurrent users. Then one day, traffic spikes to 10,000 — and everything falls apart. Database queries timeout, the Node.js process maxes out its memory, and your React frontend takes 8 seconds to load.

I've been through this scenario multiple times across enterprise projects. Scaling isn't about rewriting your entire stack — it's about systematically identifying and eliminating bottlenecks at every layer.

Here's the playbook I use.

Architecture Overview

Before diving in, here's the high-level architecture of a scaled MERN application:

                    ┌──────────────┐
                    │   CDN        │  ← Static assets (React build, images)
                    │  CloudFront  │
                    └──────┬───────┘
                           │
                    ┌──────▼───────┐
                    │ Load Balancer│  ← Distributes traffic
                    │   (Nginx)    │
                    └──────┬───────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
        ┌─────▼────┐ ┌────▼─────┐ ┌────▼─────┐
        │ Node.js  │ │ Node.js  │ │ Node.js  │  ← Multiple instances
        │ Instance │ │ Instance │ │ Instance │
        └─────┬────┘ └────┬─────┘ └────┬─────┘
              │            │            │
              └────────────┼────────────┘
                           │
              ┌────────────┼────────────┐
              │                         │
        ┌─────▼────┐           ┌───────▼──────┐
        │  Redis   │           │   MongoDB    │
        │  Cache   │           │  Replica Set │
        └──────────┘           └──────────────┘

Now let's break down each layer.

1. Database Optimization (MongoDB)

The database is almost always the first bottleneck. Here's how to fix it.

Indexing — The Single Biggest Win

Unindexed queries on large collections can take seconds. With proper indexes, they take milliseconds.

// Check which queries are slow
db.setProfilingLevel(1, { slowms: 100 });

// View slow queries
db.system.profile.find().sort({ ts: -1 }).limit(10);

// Create indexes for your most common queries
// Schema definition with Mongoose
const orderSchema = new Schema({
  userId: { type: Schema.Types.ObjectId, index: true },
  status: { type: String, index: true },
  createdAt: { type: Date, index: true },
  total: Number,
  items: [orderItemSchema],
});

// Compound index for queries that filter on multiple fields
orderSchema.index({ userId: 1, status: 1, createdAt: -1 });

// Text index for search functionality
orderSchema.index({ 'items.name': 'text', 'items.description': 'text' });

Use the Aggregation Pipeline

For complex data processing, the aggregation pipeline runs everything inside MongoDB — far faster than pulling data into Node.js and processing it there:

// ❌ BAD — Pull all orders into Node.js memory
const orders = await Order.find({ status: 'completed' });
const totalByUser = {};
orders.forEach(order => {
  totalByUser[order.userId] = (totalByUser[order.userId] || 0) + order.total;
});

// ✅ GOOD — Let MongoDB do the heavy lifting
const totalByUser = await Order.aggregate([
  { $match: { status: 'completed' } },
  { $group: {
    _id: '$userId',
    totalSpent: { $sum: '$total' },
    orderCount: { $sum: 1 },
    avgOrderValue: { $avg: '$total' },
  }},
  { $sort: { totalSpent: -1 } },
  { $limit: 100 },
]);

Connection Pooling

Don't create a new connection per request. Configure your pool:

// mongoose connection with proper pooling
mongoose.connect(process.env.DATABASE_URL, {
  maxPoolSize: 50,           // Max connections in the pool
  minPoolSize: 10,           // Keep at least 10 connections ready
  serverSelectionTimeoutMS: 5000,
  socketTimeoutMS: 45000,
  bufferCommands: false,     // Fail fast if not connected
});

Pagination — Never Load Everything

// Cursor-based pagination (better than skip/limit for large datasets)
const getProducts = async (lastId, limit = 20) => {
  const query = lastId 
    ? { _id: { $gt: new ObjectId(lastId) } } 
    : {};

  return Product.find(query)
    .sort({ _id: 1 })
    .limit(limit)
    .lean(); // .lean() returns plain objects — 5x faster than Mongoose documents
};

2. API Performance (Node.js & Express)

Redis Caching

Cache expensive or frequently-accessed data:

const Redis = require('ioredis');
const redis = new Redis(process.env.REDIS_URL);

// Cache middleware
const cache = (keyPrefix, ttlSeconds = 300) => {
  return async (req, res, next) => {
    const key = `${keyPrefix}:${req.originalUrl}`;

    try {
      const cached = await redis.get(key);
      if (cached) {
        return res.json(JSON.parse(cached));
      }

      // Override res.json to cache the response
      const originalJson = res.json.bind(res);
      res.json = (data) => {
        redis.setex(key, ttlSeconds, JSON.stringify(data));
        return originalJson(data);
      };

      next();
    } catch (err) {
      next(); // If Redis fails, just skip caching
    }
  };
};

// Usage
app.get('/api/products', cache('products', 600), productController.getAll);
app.get('/api/products/:id', cache('product', 300), productController.getById);

Cache Invalidation

The hardest problem in computer science. Keep it simple:

// When a product is updated, clear related cache keys
const updateProduct = async (id, data) => {
  const product = await Product.findByIdAndUpdate(id, data, { new: true });

  // Clear specific cache
  await redis.del(`product:/api/products/${id}`);

  // Clear list caches (use pattern matching)
  const keys = await redis.keys('products:*');
  if (keys.length) await redis.del(...keys);

  return product;
};

Compression

Reduce payload sizes by 60-80%:

const compression = require('compression');

app.use(compression({
  level: 6,                    // Balance between speed and compression ratio
  threshold: 1024,             // Only compress responses > 1KB
  filter: (req, res) => {
    if (req.headers['x-no-compression']) return false;
    return compression.filter(req, res);
  },
}));

Node.js Clustering

Use all CPU cores:

// cluster.js
const cluster = require('cluster');
const os = require('os');

if (cluster.isPrimary) {
  const numCPUs = os.cpus().length;
  console.log(`Primary process ${process.pid} starting ${numCPUs} workers`);

  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker) => {
    console.log(`Worker ${worker.process.pid} died, spawning replacement`);
    cluster.fork();
  });
} else {
  require('./app'); // Each worker runs the Express app
}

Or better yet, use PM2 in production:

# pm2 ecosystem file
pm2 start app.js -i max --name "api" --max-memory-restart "500M"

3. Frontend Efficiency (React)

Optimistic UI Updates

Don't wait for the server to confirm — update the UI immediately and roll back on failure:

const useOptimisticUpdate = () => {
  const queryClient = useQueryClient();

  const toggleLike = useMutation({
    mutationFn: (postId: string) => api.post(`/posts/${postId}/like`),

    // Optimistically update the cache
    onMutate: async (postId) => {
      await queryClient.cancelQueries(['posts']);
      const previousPosts = queryClient.getQueryData(['posts']);

      queryClient.setQueryData(['posts'], (old: Post[]) =>
        old.map(post =>
          post.id === postId
            ? { ...post, liked: !post.liked, likes: post.liked ? post.likes - 1 : post.likes + 1 }
            : post
        )
      );

      return { previousPosts };
    },

    // Roll back on error
    onError: (err, postId, context) => {
      queryClient.setQueryData(['posts'], context.previousPosts);
    },
  });

  return toggleLike;
};

React Query for Server State

Stop using useEffect + useState for API calls:

// ❌ BAD — manual state management
const [products, setProducts] = useState([]);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);

useEffect(() => {
  fetch('/api/products')
    .then(res => res.json())
    .then(setProducts)
    .catch(setError)
    .finally(() => setLoading(false));
}, []);

// ✅ GOOD — React Query handles caching, refetching, error states
const { data: products, isLoading, error } = useQuery({
  queryKey: ['products'],
  queryFn: () => fetch('/api/products').then(r => r.json()),
  staleTime: 5 * 60 * 1000,  // Cache for 5 minutes
  retry: 3,
});

Bundle Size Optimization

Analyze and shrink your bundle:

# For Vite projects
npx vite-bundle-visualizer

# For Webpack (CRA) projects
npx source-map-explorer build/static/js/*.js

Common wins:

Replace moment.js (300KB) with date-fns (tree-shakeable) or dayjs (2KB)
Replace lodash (70KB) with individual imports: import debounce from 'lodash/debounce'
Lazy load routes (we covered this in the React performance article)

4. Infrastructure

Load Balancing with Nginx

upstream node_api {
    least_conn;  # Send to the server with fewest active connections
    server 127.0.0.1:3001;
    server 127.0.0.1:3002;
    server 127.0.0.1:3003;
    server 127.0.0.1:3004;
}

server {
    listen 80;
    server_name api.yourdomain.com;

    # Serve static files directly — don't waste Node.js on this
    location /static/ {
        root /var/www/app/build;
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    location / {
        proxy_pass http://node_api;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_cache_bypass $http_upgrade;
    }
}

CDN for Static Assets

Serve your React build from a CDN (CloudFront, Cloudflare, Fastly). This alone can cut load times by 50-70% for global users because assets are served from the edge location nearest to the user.

MongoDB Replica Set

Never run a single MongoDB instance in production:

Primary  →  handles all writes
Secondary →  handles read queries (read preference: secondaryPreferred)
Secondary →  handles read queries + acts as failover

This gives you:

High availability: If primary goes down, a secondary is automatically promoted
Read scaling: Distribute read queries across secondaries
Data safety: Your data exists on multiple machines

5. Monitoring & Alerts

You can't fix what you can't see. Set up monitoring from day one:

What to Monitor	Tool	Alert When
API response times	Datadog / New Relic	p95 > 500ms
Error rate	Sentry	> 1% of requests
MongoDB slow queries	MongoDB Atlas	> 100ms
Memory usage	PM2 / Docker	> 80%
CPU usage	Cloud provider metrics	Sustained > 70%
Redis hit rate	Redis CLI / Datadog	< 80%

Scaling Checklist

Here's the order I tackle scaling issues:

📊 Measure first — Don't guess. Profile your app, find the actual bottleneck.
🗄️ Database indexes — This alone often fixes 80% of performance issues.
🔴 Redis caching — Cache frequently-read, rarely-changed data.
📦 API compression — Gzip/Brotli middleware for 60-80% smaller payloads.
⚛️ Frontend code splitting — Don't ship 2MB of JS on first load.
🖥️ Node.js clustering — Use all your CPU cores.
⚖️ Load balancing — Scale horizontally with multiple server instances.
🌐 CDN — Serve static assets from the edge.
🔄 Read replicas — Scale database reads independently.

Conclusion

Scaling is an iterative process, not a one-time event. Monitor your application's bottlenecks and address them systematically. The order matters — always start with the database and caching before throwing more hardware at the problem.

The patterns in this guide have helped me scale MERN applications from hundreds to hundreds of thousands of users. They'll work for you too.

Have you scaled a MERN stack application? What was your biggest bottleneck? Share your experience in the comments 👇

For more architecture deep dives and case studies, visit muhammadarslan.codes or connect with me on LinkedIn and GitHub.

Complete Guide to Node.js Best Practices for Production in 2024

Muhammad Arslan — Mon, 16 Feb 2026 12:47:59 +0000

Building a Node.js app that works locally is easy. Building one that survives production — with real traffic, unpredictable errors, and zero-downtime deployments — is an entirely different game.

After 5+ years of shipping Node.js backends to production for enterprise clients globally, I've distilled the patterns that separate hobby projects from battle-tested systems. This is the guide I wish I had when I started.

1. Standardizing Project Architecture

The single biggest mistake I see in Node.js projects? A flat file structure where routes, business logic, and database calls are all tangled together in one file.

A scalable Node.js application should follow a strictly layered architecture:

src/
├── controllers/    # HTTP lifecycle — validate input, send responses
├── services/       # Business logic — the brain of your app
├── repositories/   # Data access — Mongoose, Prisma, Knex abstractions
├── middlewares/     # Auth, rate limiting, logging
├── validators/     # Input validation schemas (Joi, Zod)
├── utils/          # Pure helper functions
├── config/         # Environment-specific configuration
└── app.js          # Express/Fastify app setup

Why This Matters

Controller Layer: Sanitizes input and manages the HTTP lifecycle. It should never contain business logic.
Service Layer: The brain of your app where business logic resides. This is where you enforce rules, orchestrate workflows, and call repositories.
Repository / Data Access Layer: Abstractions for your database (Mongoose, Prisma, Sequelize). If you ever switch databases, only this layer changes.

// ❌ BAD — Everything crammed into a route handler
app.post('/users', async (req, res) => {
  const { email, password } = req.body;
  // validation, hashing, DB call, email sending — all in one place
  const hashedPassword = await bcrypt.hash(password, 10);
  const user = await User.create({ email, password: hashedPassword });
  await sendWelcomeEmail(user.email);
  res.json(user);
});

// ✅ GOOD — Separated concerns
// controller/user.controller.js
const createUser = async (req, res, next) => {
  try {
    const user = await userService.register(req.body);
    res.status(201).json({ success: true, data: user });
  } catch (err) {
    next(err);
  }
};

// service/user.service.js
const register = async (userData) => {
  const existing = await userRepo.findByEmail(userData.email);
  if (existing) throw new ConflictError('Email already registered');

  const hashedPassword = await bcrypt.hash(userData.password, 10);
  const user = await userRepo.create({ ...userData, password: hashedPassword });
  await emailService.sendWelcome(user.email);
  return user;
};

This separation means your services are testable without HTTP, your controllers are thin, and your data layer is swappable.

2. Resilient Error Management

Production apps shouldn't just run; they should fail gracefully. Here's the pattern I use on every project:

Create Custom Error Classes

// errors/AppError.js
class AppError extends Error {
  constructor(message, statusCode, isOperational = true) {
    super(message);
    this.statusCode = statusCode;
    this.isOperational = isOperational;
    Error.captureStackTrace(this, this.constructor);
  }
}

class NotFoundError extends AppError {
  constructor(resource = 'Resource') {
    super(`${resource} not found`, 404);
  }
}

class ValidationError extends AppError {
  constructor(message) {
    super(message, 422);
  }
}

class ConflictError extends AppError {
  constructor(message) {
    super(message, 409);
  }
}

Centralized Error Handler

// middleware/errorHandler.js
const errorHandler = (err, req, res, next) => {
  // Log the full error for debugging
  logger.error({
    message: err.message,
    stack: err.stack,
    path: req.path,
    method: req.method,
    ip: req.ip,
    userId: req.user?.id,
  });

  // Operational errors — safe to show to client
  if (err.isOperational) {
    return res.status(err.statusCode).json({
      status: 'error',
      message: err.message,
    });
  }

  // Programming errors — don't leak details
  res.status(500).json({
    status: 'error',
    message: 'Something went wrong. Please try again later.',
  });
};

Handle Uncaught Exceptions

// Catch unhandled promise rejections
process.on('unhandledRejection', (reason, promise) => {
  logger.fatal('Unhandled Rejection:', reason);
  // Graceful shutdown
  server.close(() => process.exit(1));
});

// Catch uncaught exceptions
process.on('uncaughtException', (error) => {
  logger.fatal('Uncaught Exception:', error);
  // Graceful shutdown
  server.close(() => process.exit(1));
});

Never use console.log for production errors. Use structured logging with Pino or Winston — they output JSON that your log aggregator (Datadog, ELK, CloudWatch) can parse and alert on.

3. Configuration Management

Hardcoded values are a production time bomb. Use environment-based configuration with validation:

// config/index.js
const Joi = require('joi');

const envSchema = Joi.object({
  NODE_ENV: Joi.string().valid('development', 'staging', 'production').required(),
  PORT: Joi.number().default(3000),
  DATABASE_URL: Joi.string().uri().required(),
  REDIS_URL: Joi.string().uri().required(),
  JWT_SECRET: Joi.string().min(32).required(),
  JWT_EXPIRY: Joi.string().default('7d'),
}).unknown(true);

const { error, value: env } = envSchema.validate(process.env);

if (error) {
  throw new Error(`Config validation error: ${error.message}`);
}

module.exports = {
  env: env.NODE_ENV,
  port: env.PORT,
  db: { url: env.DATABASE_URL },
  redis: { url: env.REDIS_URL },
  jwt: { secret: env.JWT_SECRET, expiry: env.JWT_EXPIRY },
};

Your app crashes immediately on startup if config is invalid — much better than discovering a missing env var at 3 AM in production.

4. Performance & Monitoring

Monitor the Event Loop

If your Event Loop lag exceeds 50ms, you're likely performing blocking synchronous operations that starve throughput:

const { monitorEventLoopDelay } = require('perf_hooks');

const h = monitorEventLoopDelay({ resolution: 50 });
h.enable();

setInterval(() => {
  const p99 = h.percentile(99) / 1e6; // Convert to ms
  if (p99 > 50) {
    logger.warn(`Event loop lag (p99): ${p99.toFixed(2)}ms`);
  }
  h.reset();
}, 10000);

Health Check Endpoint

Every production Node.js app needs a health check:

app.get('/health', async (req, res) => {
  const healthcheck = {
    uptime: process.uptime(),
    status: 'OK',
    timestamp: Date.now(),
    checks: {
      database: await checkDB(),
      redis: await checkRedis(),
      memory: process.memoryUsage(),
    },
  };
  res.json(healthcheck);
});

Use APM Tools

Combine Application Performance Monitoring (Datadog, New Relic, or Elastic APM) with structured logging to catch bottlenecks before they impact users. These tools give you:

Request tracing across services
Database query performance
Memory leak detection
Error rate dashboards

5. Security Essentials

Production security in 60 seconds:

const helmet = require('helmet');
const rateLimit = require('express-rate-limit');
const cors = require('cors');

// Security headers
app.use(helmet());

// CORS — be explicit, never use '*' in production
app.use(cors({
  origin: ['https://yourdomain.com'],
  credentials: true,
}));

// Rate limiting
app.use('/api/', rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100,
  message: { error: 'Too many requests, slow down.' },
}));

// Prevent parameter pollution
app.use(hpp());

// Sanitize input against NoSQL injection
app.use(mongoSanitize());

Final Thoughts

Building for production is a marathon of consistency. By following these pillars — layered architecture, resilient error handling, validated configuration, proactive monitoring, and security defaults — you ensure your Node.js applications are ready to scale globally.

These aren't theoretical patterns. I've used every single one across enterprise projects handling millions of requests. They work.

What production patterns have saved you? Drop them in the comments below 👇

If you want to see more of my work or discuss a project, feel free to visit my portfolio at muhammadarslan.codes or connect with me on LinkedIn and GitHub.

👋 Hey Dev!

Muhammad Arslan — Wed, 28 Jan 2026 10:36:10 +0000

I'm Muhammad Arslan

Senior Full Stack Developer specializing in Node.js, React.js, Next.js, Laravel & AWS

5+ years building scalable web apps. Here to share what I'm learning, building, and breaking 😅

Let's connect! 🚀

Forem: Muhammad Arslan

React Server Components Explained: The Complete 2026 Guide

1. What Are React Server Components?

2. Server Components vs Client Components

3. The Composition Pattern

4. Data Fetching Without useEffect

5. Streaming with Suspense

6. Server Actions: Mutations Without APIs

RSC Decision Checklist

Final Thoughts

Mastering TypeScript 5.x: Advanced Patterns for Full-Stack Developers

Mastering TypeScript 5.x: Advanced Patterns for Full-Stack Developers

1. The Power of Generics with Constraints

2. Mapped Types and Key Remapping

3. Template Literal Types

4. Conditional Types and infer

Conclusion: Type Safety as a Feature

Building Scalable Microservices with Node.js: A Practical Guide

Building Scalable Microservices with Node.js: A Practical Guide

What are Microservices?

Core Principles

Communication Patterns

1. Synchronous Communication (REST/gRPC)

2. Asynchronous Communication (Message Queues)

Service Discovery and API Gateways

Managing Data in Microservices

Scaling and Resilience

Horizontal Scaling

Circuit Breakers

Conclusion

Mastering React Hooks: From Basics to Custom Hooks (2026 Guide)

Table of Contents

1. Why Hooks Changed Everything

2. useState — More Than You Think

Functional Updates

Lazy Initial State

State Batching

3. useEffect — The Right Way

The Dependency Array — No Lies

Cleanup Functions

Separating Concerns

4. useRef — Beyond DOM References

Tracking Previous Values

Storing Stable Callbacks

Tracking Whether a Component Is Mounted

5. useContext — Shared State Without Redux

Theme / Auth Context Pattern

6. useReducer — Complex State Logic

7. useMemo & useCallback — When to Actually Use Them

Use useMemo when:

Use useCallback when:

8. Custom Hooks — The Real Power

useFetch — Data Fetching with Loading & Error States

useLocalStorage — Persistent State

useDebounce — Throttle Expensive Operations

useForm — Reusable Form Logic

9. React Hooks Best Practices Checklist

Conclusion

Building Scalable Real-Time Applications with Node.js, Socket.io, and React

1. Understanding the Transport Layer

2. Architecting the Node.js Server

The Foundation

Structuring Event Handlers

The Domain Handler

3. Integrating React Robustly

The Socket Context Provider

Implementing Listeners in Components

4. Scaling Horizontally (The Multi-Server Challenge)

The Redis Adapter Solution

5. Security & Production Checklist

Final Thoughts

Mastering Next.js 16 SEO: A Practical Guide to Ranking Higher

1. Dynamic Metadata API

Why This Matters

2. Server-Side Rendering (SSR) and Static Site Generation (SSG)

3. Dynamic XML Sitemaps

4. robots.txt Automation

5. Canonical URLs to Prevent Duplicate Content Bugs

6. Image Optimization with next/image

Final Thoughts

4. Conditional Types and `infer`

Use `useMemo` when:

Use `useCallback` when:

`useFetch` — Data Fetching with Loading & Error States

`useLocalStorage` — Persistent State

`useDebounce` — Throttle Expensive Operations

`useForm` — Reusable Form Logic

4. `robots.txt` Automation

6. Image Optimization with `next/image`

1. Memoization — `useMemo` and `useCallback`

`useMemo` — Memoize Computed Values

`useCallback` — Memoize Functions

2. `React.memo` — Prevent Unnecessary Re-renders

Using `react-window`