DEV Community: Alifa Ara Heya

Understanding Default Operator (`||`) vs Nullish Coalescing Operator (`??`) in JavaScript

Alifa Ara Heya — Thu, 02 Oct 2025 21:55:45 +0000

When working with JavaScript, it’s common to provide default values in case a variable is missing or undefined. Two popular ways are:

Using the logical OR operator (||)
Using the nullish coalescing operator (??)

While they may look similar, they behave differently — and knowing the difference will save you from subtle bugs.

🔹 The Default Operator (`||`)

The || operator returns the right-hand side value if the left-hand side is falsy.
In JavaScript, the following are considered falsy:

0
"" (empty string)
false
null
undefined
NaN

Example:

let userName = "";
let displayName = userName || "Guest";

console.log(displayName); // "Guest"

Here, even though userName is an empty string (which might be valid input), it is treated as falsy. So "Guest" is used instead.

Another case:

let count = 0;
let items = count || 10;

console.log(items); // 10 (oops, we actually wanted 0)

🔹 The Nullish Coalescing Operator (`??`)

The ?? operator only considers null or undefined as missing values.
Other falsy values like 0, false, or "" are preserved.

Example:

let userName = "";
let displayName = userName ?? "Guest";

console.log(displayName); // "" (empty string is valid, not replaced)

Another case:

let count = 0;
let items = count ?? 10;

console.log(items); // 0 ✅ (correct, because 0 is a valid number)

✅ Advantage of `??` over `||`

The key benefit of ?? is that it does not mistakenly override valid falsy values.

With ||, values like 0, "", or false are treated as missing.
With ??, only null and undefined are treated as missing.

This makes ?? especially useful when:

0 is a valid count (e.g., items in a cart)
"" is a valid string (e.g., optional text fields)
false is a valid boolean flag (e.g., user preferences)

🔹 Quick Comparison Table

Operator	Treats as “missing”	Preserves 0 / "" / false?	Example Result
`		`	All falsy values (`0`, `""`, `false`, `null`, `undefined`, `NaN`)	❌ No	`0 \
{% raw %}`??`	Only `null` and `undefined`	✅ Yes	`0 ?? 5 → 0`

🌍 Real-World Use Cases

1. API Response Defaults

When working with APIs, some fields may be missing (null/undefined) but others might be valid even if falsy.

let response = { items: 0 };

let itemCount = response.items ?? 10;
console.log(itemCount); // 0 (valid number, not replaced!)

If you used ||, this would incorrectly give 10 instead of 0.

2. Config Settings with Boolean Flags

Sometimes false is a deliberate setting, not a missing value.

let config = { darkMode: false };

let theme = config.darkMode ?? true;
console.log(theme); // false (respects the user setting)

Using || here would incorrectly turn it into true.

3. User Input Handling

A user might leave a text field empty intentionally. With ??, you can respect that choice.

let userInput = "";
let value = userInput ?? "Default text";

console.log(value); // "" (user chose empty string, not replaced)

With ||, this would turn into "Default text" unexpectedly.

🎯 Final Thoughts

Use || when you want to fall back on any falsy value.
Use ?? when you want to preserve valid falsy values and only handle null/undefined.

In modern JavaScript, ?? is often the safer choice for handling defaults, especially with APIs, configs, and user input.

👉 Next time you’re about to write || for defaults, ask yourself: Do I really want to override 0, "", or false?
If not — reach for ??.

HTTP Requests in React(fetch vs Axios and Tanstack Query)

Alifa Ara Heya — Sun, 17 Aug 2025 16:45:24 +0000

As a web developer, understanding how to communicate with a server is fundamental. In React, you'll frequently use HTTP requests to Create, Read, Update, and Delete (CRUD) data. This note will walk you through three common approaches: the built-in fetch API, the popular library Axios, and the powerful state management tool TanStack Query. We'll start with the foundational fetch API, explore the improvements offered by Axios, and then see how a library like TanStack Query can manage the entire data-fetching lifecycle for you.

1. The Native fetch API

The fetch API is a built-in browser function that provides a clean, promise-based interface for making network requests. While it's the native solution and requires no external dependencies, its raw nature means you're responsible for handling a lot of the boilerplate yourself.

Boilerplate for a GET Request with fetch

The standard approach involves using the useEffect and useState hooks to manage the request lifecycle. To properly handle asynchronous data, we need state variables to track the data itself, the loading status of the request, and any potential errors.

import React, { useState, useEffect } from 'react';

function FetchExample() {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchData = async () => {
      try {
        const response = await fetch('https://api.example.com/items');
        if (!response.ok) {
          throw new Error(`HTTP error! status: ${response.status}`);
        }
        let result = await response.json();
        setData(result);
      } catch (e) {
        setError(e);
      } finally {
        setLoading(false);
      }
    };

    fetchData();
  }, []); // The empty dependency array ensures this runs once on mount

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error: {error.message}</div>;

  return (
    <div>
      {data && data.map(item => <p key={item.id}>{item.name}</p>)}
    </div>
  );
}

export default FetchExample;

A Deeper Look at fetch's Promise Chain and Error Handling

One of the most important distinctions of the fetch API is how it handles errors. A fetch promise will only reject if a network error occurs (e.g., no internet connection). It will not reject for common HTTP errors like 404 Not Found or 500 Server Error. Instead, the promise will resolve successfully, and you must manually check the response.ok property or the response.status code to handle these cases. This is why the if (!response.ok) check is a crucial part of the boilerplate.

Full CRUD Operations with fetch

POST (Create):

fetch('https://api.example.com/items', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ name: 'New Item' }),
}).then(response => response.json())
  .then(data => console.log('Item created:', data))
  .catch(error => console.error('Error creating item:', error));

PUT (Update):

fetch('https://api.example.com/items/123', {
  method: 'PUT',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ name: 'Updated Item' }),
}).then(response => response.json())
  .then(data => console.log('Item updated:', data))
  .catch(error => console.error('Error updating item:', error));

DELETE (Delete):

fetch('https://api.example.com/items/123', {
  method: 'DELETE',
}).then(response => {
    if (!response.ok) throw new Error('Deletion failed');
    console.log('Item deleted successfully');
  })
  .catch(error => console.error('Error deleting item:', error));

As you can see, the manual handling of success and error cases for each request can lead to repetitive code, especially in a large application.

2. Axios: The Easier Alternative

Axios is a popular, promise-based HTTP client for both the browser and Node.js. It's often favored for its simplicity and built-in features that the native fetch API lacks. It provides a cleaner, more intuitive API, reducing the amount of boilerplate needed for common tasks.

fetch vs. Axios

Feature	fetch (Native)	Axios (Library)
Parsing	Manual `response.json()` call	Automatic JSON data parsing
Error Handling	Doesn't reject on HTTP errors (e.g., 404, 500)	Rejects promises on HTTP errors, simplifying try/catch
Configuration	Headers, body, etc. are configured manually	Instance-level configuration (base URL, headers)
Interceptors	No built-in interceptors	Interceptors to handle requests/responses globally
Request & Response Data	Response object and request body handling can be cumbersome	Data is available directly in the `response.data` property

Boilerplate for a GET Request with Axios

import React, { useState, useEffect } from 'react';
import axios from 'axios';

function AxiosExample() {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchData = async () => {
      try {
        const response = await axios.get('https://api.example.com/items');
        setData(response.data);
      } catch (e) {
        setError(e);
      } finally {
        setLoading(false);
      }
    };

    fetchData();
  }, []);

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error: {error.message}</div>;

  return (
    <div>
      {data && data.map(item => <p key={item.id}>{item.name}</p>)}
    </div>
  );
}

export default AxiosExample;

Going Deeper with Axios: Interceptors and Configuration

One of Axios's most powerful features is its use of interceptors. These are functions that let you inspect and modify every HTTP request and response before they are handled by then() or catch(). They are perfect for common tasks like adding an authentication token to every request or logging errors globally.

Example: A Request Interceptor for Authentication

// services/api.js
import axios from 'axios';

const api = axios.create({
  baseURL: 'https://api.example.com',
  timeout: 5000,
});

// Add a request interceptor
api.interceptors.request.use(
  (config) => {
    const token = localStorage.getItem('authToken');
    if (token) {
      config.headers['Authorization'] = `Bearer ${token}`;
    }
    return config;
  },
  (error) => {
    return Promise.reject(error);
  }
);

export default api;

Now, every time you use this api instance, it will automatically check for an authToken in local storage and add it to the headers. This centralizes your logic and prevents you from having to manually add the token to every single request.

3. TanStack Query: A Data Fetching Superpower

While useEffect and useState work for simple requests, they quickly become complex for managing a real-world application. You have to handle:

Loading and error states for each component.
Caching data to avoid redundant requests.
Background refetching to keep data fresh.
Invalidating and updating the cache after a POST, PUT, or DELETE.
Handling multiple requests with race conditions.

This leads to a lot of boilerplate and potential bugs. This is where TanStack Query (formerly React Query) shines. It's a library that handles all these complexities for you declaratively. It's not a state management library for all your application's state, but rather for your server state.

The Problem: Native State Management for Caching & Refetching

// This is an example of the kind of boilerplate TanStack Query solves.
import React, { useState, useEffect } from 'react';

function NativeStateManagementExample() {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);
  const [shouldRefetch, setShouldRefetch] = useState(false);

  useEffect(() => {
    setLoading(true);
    fetch('https://api.example.com/items')
      .then(res => {
        if (!res.ok) throw new Error('Network response was not ok');
        return res.json();
      })
      .then(json => setData(json))
      .catch(err => setError(err))
      .finally(() => setLoading(false));
  }, [shouldRefetch]);

  return (
    <div>
      <button onClick={() => setShouldRefetch(!shouldRefetch)}>Refresh Data</button>
      {loading && <div>Loading...</div>}
      {error && <div>Error: {error.message}</div>}
      {data && data.map(item => <p key={item.id}>{item.name}</p>)}
    </div>
  );
}

The Solution: TanStack Query's `useQuery` Hook

// You'll need to set up a QueryClientProvider at the root of your app
import { useQuery } from '@tanstack/react-query';

const fetchItems = async () => {
  const res = await fetch('https://api.example.com/items');
  if (!res.ok) {
    throw new Error('Network response was not ok');
  }
  return res.json();
};

function TanStackQueryExample() {
  const { data, isLoading, isError, error, refetch } = useQuery({
    queryKey: ['items'],
    queryFn: fetchItems,
  });

  if (isLoading) return <div>Loading...</div>;
  if (isError) return <div>Error: {error.message}</div>;

  return (
    <div>
      <button onClick={() => refetch()}>Refresh Data</button>
      {data.map(item => <p key={item.id}>{item.name}</p>)}
    </div>
  );
}

The Power of Caching and Stale-while-revalidate

At its core, TanStack Query is about caching. When a query is first performed, the data is cached under its unique queryKey. Subsequent requests for the same queryKey will instantly return the cached data while a new, "stale" request is performed in the background to ensure the data is up to date. This pattern is known as stale-while-revalidate and provides an excellent user experience by making the UI feel instantly responsive.

Handling Mutations with `useMutation`

For POST, PUT, and DELETE operations, TanStack Query provides the useMutation hook. Mutations are treated differently because they modify server-side data. useMutation gives you a function to trigger the request (mutate) and provides state variables like isPending and isSuccess to manage the UI. Most importantly, it has powerful callback functions like onSuccess and onError that allow you to invalidate and refetch related queries, ensuring your UI always reflects the latest server state.

4. Combining Axios and TanStack Query

This is a powerful combination for building robust and developer-friendly applications. Think of it this way:

Axios handles the "how" of data fetching: a clean, configurable, and robust way to make the actual HTTP call. You define a single Axios instance, which centralizes your base URL, timeouts, and most importantly, request and response interceptors.
TanStack Query handles the "what" and "when" of data fetching: a declarative way to manage the entire data fetching and synchronization lifecycle. It manages loading states, caching, background refetching, and automatically updates the UI after mutations.

Example of an Integrated Solution

Axios Instance

// services/api.js
import axios from 'axios';

const api = axios.create({
  baseURL: 'https://api.example.com',
  timeout: 5000,
  headers: {
    'Content-Type': 'application/json',
    // 'Authorization': `Bearer ${token}` // You could add an auth header here
  },
});

export default api;

React Component using TanStack Query + Axios

// components/CombinedExample.jsx
import { useQuery, useMutation, useQueryClient } from '@tanstack/react-query';
import api from '../services/api'; // Our configured Axios instance
import React from 'react';

// A reusable function for fetching all items
const fetchItems = async () => {
  const { data } = await api.get('/items');
  return data;
};

// A reusable function for creating an item
const createItem = async (newItem) => {
  const { data } = await api.post('/items', newItem);
  return data;
};

// A reusable function for deleting an item
const deleteItem = async (itemId) => {
  await api.delete(`/items/${itemId}`);
  return itemId;
};

function CombinedExample() {
  const queryClient = useQueryClient();

  // Use TanStack Query to manage the 'GET' request for all items
  const { data, isLoading, isError, error } = useQuery({
    queryKey: ['items'],
    queryFn: fetchItems,
  });

  // Use a mutation to handle the 'POST' request
  const createMutation = useMutation({
    mutationFn: createItem,
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: ['items'] });
    },
  });

  // Use a mutation to handle the 'DELETE' request
  const deleteMutation = useMutation({
    mutationFn: deleteItem,
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: ['items'] });
    },
  });

  const handleCreate = () => {
    createMutation.mutate({ name: 'New Item From Mutation' });
  };

  const handleDelete = (id) => {
    deleteMutation.mutate(id);
  };

  if (isLoading) return <div>Loading...</div>;
  if (isError) return <div>Error: {error.message}</div>;

  return (
    <div className="p-4">
      <h2 className="text-2xl font-bold mb-4">Item List</h2>
      <button
        onClick={handleCreate}
        className="px-4 py-2 bg-blue-500 text-white rounded-md hover:bg-blue-600 transition-colors"
      >
        Add New Item
      </button>
      {createMutation.isPending && <p className="text-blue-500 mt-2">Adding item...</p>}
      {deleteMutation.isPending && <p className="text-red-500 mt-2">Deleting item...</p>}
      <ul className="mt-4 space-y-2">
        {data.map(item => (
          <li key={item.id} className="flex justify-between items-center bg-gray-100 p-3 rounded-md shadow-sm">
            <span className="text-lg">{item.name}</span>
            <button
              onClick={() => handleDelete(item.id)}
              className="px-3 py-1 bg-red-500 text-white rounded-md text-sm hover:bg-red-600 transition-colors"
            >
              Delete
            </button>
          </li>
        ))}
      </ul>
    </div>
  );
}

export default CombinedExample;

Final Thoughts

This final, comprehensive example shows the best of both worlds:

Axios provides a clean, configurable, and robust way to make the actual HTTP call. The separate api.js file is a best practice for managing this.
TanStack Query takes care of all the complex data-fetching state management, caching, and automatic UI updates.

This makes your code more readable, efficient, and less prone to bugs. You just tell it what to do (useQuery, useMutation), and it handles the rest.

✅ Summary

Use fetch for basics.
Use Axios for cleaner syntax & interceptors.
Use TanStack Query for caching, refetching & lifecycle management.
Combine Axios + TanStack Query for production-ready apps.

💬 From Rejection to Revolution: The Engineering Brilliance Behind WhatsApp

Alifa Ara Heya — Sun, 10 Aug 2025 22:45:07 +0000

📱 The Incredible Engineering Story Behind WhatsApp

Today I stumbled upon the incredible story behind WhatsApp—one of the most successful instant messaging platforms in history—and found it absolutely captivating.

Jan Koum, a former Yahoo engineer, was once rejected by Facebook. Ironically, just a few years later, Facebook acquired WhatsApp for a staggering $19 billion. Alongside co-founder Brian Acton, Koum built a product that transformed global communication—and did so with remarkable engineering discipline.

Here are some key takeaways from WhatsApp’s technical journey that every developer and architect can learn from:

🧭 1. Single Responsibility Principle

WhatsApp was laser-focused on one goal: replacing expensive SMS.

No ads, no social feed, no distractions. This clarity of purpose helped it scale rapidly without compromising user experience.

⚙️ 2. Smart Technology Choices

WhatsApp’s backend was built using Erlang, a language designed for massive concurrency.

Unlike Java or C++, Erlang’s lightweight processes are managed by its own virtual machine (BEAM), allowing millions of simultaneous connections with minimal overhead.

This made context switching extremely efficient, enabling WhatsApp to handle real-time messaging at scale.

🧱 3. Building on Open Source

Rather than reinventing the wheel, WhatsApp was built on Ejabberd, an open-source XMPP server written in Erlang.

This decision accelerated development and allowed the team to focus on performance and reliability.

📈 4. Scaling with Simplicity

WhatsApp initially leaned into vertical scaling—maximizing the power of individual servers—before layering in horizontal scaling as needed.

This hybrid approach kept infrastructure costs and complexity low while supporting exponential growth.

🔁 5. Seamless Deployment

Running on FreeBSD, WhatsApp leveraged Erlang’s hot code swapping to deploy updates with zero downtime.

While their CI/CD pipeline wasn’t publicly detailed, their ability to push changes without interrupting service was a testament to thoughtful engineering.

👥 6. Small Team, Big Impact

At the time of acquisition, WhatsApp had just 32 engineers supporting over 450 million users.

This wasn’t just lean—it was legendary. A small, focused team with clear goals outperformed giants.

🚀 Final Thought

WhatsApp’s story is more than a tale of startup success—it’s a masterclass in engineering focus, smart choices, and purposeful simplicity.

Whether you're building your own product or scaling an existing one, there’s a lot to learn from how WhatsApp did it.

🔗 Read more: WhatsApp Engineering Journey

Monorepo vs Polyrepo

Alifa Ara Heya — Thu, 07 Aug 2025 14:13:54 +0000

Monorepo vs Polyrepo - Strategies for Organizing Codebases

Monorepo and polyrepo are two different strategies for organizing a codebase within version control systems like Git. The core difference lies in the number of repositories used: one for all projects (monorepo) or one for each project (polyrepo).

📊 Feature Comparison

Feature	Monorepo	Polyrepo
Structure	A single repository contains all projects, libraries, and applications.	Each project, service, or library has its own independent repository.
Code Sharing	Easy and immediate. Dependencies can be referenced directly within the repo.	Difficult. Requires setting up dependency managers and version coordination.
Atomic Commits	Possible. A single commit can span multiple projects.	Not possible. Requires separate commits/PRs per repo.
Team Autonomy	Lower. Changes affect all teams, requiring more coordination.	Higher. Teams control their own dependencies, cycles, and tooling.
Tooling	Standardized across all projects.	Fragmented; each team may use different tools.
Scalability	Can become challenging without tooling (e.g., Bazel, Nx, Turborepo).	More scalable for individual projects.
Deployment	More complex; changes may trigger builds/tests across the repo.	Simpler. Each project has its own CI/CD and schedule.

✅ Monorepo: Pros & Cons

Pros:

Simplified dependency management and versioning.
Easier refactoring and consistent changes across projects.
Improved visibility and collaboration.
Centralized tooling and CI/CD pipelines.

Cons:

Performance issues in large repositories (e.g., slow git pull/clone).
Harder access control (typically at the repo level).
Requires specialized tooling to manage builds efficiently.
A single bug in shared code can affect multiple projects.

✅ Polyrepo: Pros & Cons

Pros:

High team autonomy and independent release cycles.
Granular access control and simpler project management.
Faster builds and git operations.
Bugs are isolated to individual projects.

Cons:

Code duplication and inconsistency.
Complex dependency management and coordination.
Overhead in managing multiple CI/CD pipelines and tooling.
Can lead to team silos and hinder collaboration.

Monolith vs. Microservices: Choosing a Software Architecture

Alifa Ara Heya — Thu, 07 Aug 2025 14:08:36 +0000

Choosing between a monolithic and microservices architecture is a fundamental decision in software development. Each approach has distinct advantages and disadvantages that impact development, scalability, and maintenance.

Monolithic Architecture

A monolithic architecture is a traditional, unified approach where all components of an application are bundled into a single unit. It's a single, self-contained entity.

Key Characteristics

Single Codebase: All code resides in one large project.
Tightly Coupled: Components are closely intertwined and share a single process.
Single Deployment: The entire application is built and deployed as a single artifact.

Pros

Simplicity: Easier to develop, test, and deploy initially.
Performance: Communication between components is faster as it happens within the same process.
Centralized Management: Easier to manage a single codebase and deployment.

Cons

Scalability: The entire application must be scaled, even if only one part requires more resources.
Maintenance: A small change in one module can require a full re-deployment of the entire application.
Technology Lock-in: Difficult to use different technologies for different parts of the application.

Microservices Architecture

A microservices architecture is a modern, distributed approach where an application is composed of many small, independent services. Each service performs a specific business function.

Key Characteristics

Multiple Codebases: Each service has its own codebase.
Loosely Coupled: Services communicate with each other through APIs (e.g., REST, gRPC).
Independent Deployment: Each service can be built, deployed, and scaled independently.

Pros

Scalability: Individual services can be scaled independently, optimizing resource usage.
Resilience: The failure of one service does not necessarily bring down the entire application.
Technology Diversity: Different services can be built using different technologies.
Easier Maintenance: Smaller, focused codebases are easier to understand and maintain.

Cons

Complexity: Managing a distributed system with multiple services is more complex.
Communication Overhead: Network latency and API calls introduce overhead.
Debugging: Tracing issues across multiple services can be challenging.

Comparison at a Glance

Feature	Monolithic	Microservices
Structure	Single, unified application	Collection of small, independent services
Scalability	Scale the entire application	Scale individual services
Deployment	Single deployment	Independent deployments for each service
Coupling	Tightly coupled	Loosely coupled
Complexity	Lower (initial)	Higher (initial and ongoing)
Best For	Small to medium-sized projects, startups	Large, complex applications; teams with specialized roles

Conclusion

The choice between monolith and microservices depends on the project's scale, team size, and long-term goals. While a monolith offers simplicity and is often a great starting point for new projects, a microservices architecture provides the flexibility and scalability needed for large, evolving applications. Many companies start with a monolith and transition to microservices as their application grows, a strategy often called "monolith-to-microservices."

How I Implemented Google Authentication: A Step-by-Step Guide

Alifa Ara Heya — Mon, 21 Jul 2025 15:55:15 +0000

Google Authentication Setup: A Step-by-Step Guide

This guide outlines the process of implementing a "Login with Google" feature in a Node.js/Express application using Passport.js.

Step 1: Setting Up the Foundation with Middleware

The foundation is established in the main app.ts file by configuring the necessary middleware for Passport to function correctly.

// d:\L2-programming-hero\backend-tour-management-system\src\app.ts

import express from "express";
import cors from "cors";
import { router } from "./app/routes";
import { globalErrorHandler } from "./app/middlewares/globalErrorHandler";
import notFound from "./app/middlewares/notfound";
import cookieParser from "cookie-parser";
import passport from "passport";
import expressSession from "express-session";
// import passport config
import "./app/config/passport";
import { envVars } from "./app/config/env";

const app = express();

// Configure express-session for Passport
app.use(
  expressSession({
    secret: envVars.EXPRESS_SESSION_SECRET,
    resave: false,
    saveUninitialized: false,
  })
);

// Initialize Passport and its session handling
app.use(passport.initialize());
app.use(passport.session());

app.use(cookieParser());
// ... other middleware and routes

Express Session: The express-session middleware is added. Passport uses this to maintain a login session for the user during the OAuth handshake with Google. It is secured with a secret sourced from environment variables.
Passport Initialization: Passport is initialized with passport.initialize() and its session handling is enabled with passport.session(). This hooks Passport into the Express request-response cycle.
Passport Configuration: The line import "./app/config/passport" is a crucial step. This imported file contains the core Passport strategy configuration. Within this configuration, the GoogleStrategy is defined, the Google Client ID and Secret are provided, and the verify callback function is implemented. This function is responsible for finding or creating a user in the database based on the profile information returned by Google.
Cookie Parser: cookie-parser is included to facilitate setting custom JSON Web Tokens (JWTs) in browser cookies after a successful login.

Step 2: Creating the "Login with Google" Route

In auth.route.ts, an endpoint is defined for initiating the Google login process from the frontend.

// d:\L2-programming-hero\backend-tour-management-system\src\app\modules\auth\auth.route.ts

router.get(
  "/google",
  async (req: Request, res: Response, next: NextFunction) => {
    const redirect = req.query.redirect || "/";
    passport.authenticate("google", {
      scope: ["profile", "email"],
      state: redirect as string,
    })(req, res, next);
  }
);

When a request is made to /api/v1/auth/google, the passport.authenticate('google', ...) middleware is triggered.
scope: The scope is set to ["profile", "email"]. This informs Google that the application is requesting permission to access the user's basic profile information (like name and picture) and their email address.
state: This option provides an enhanced user experience. A redirect query parameter from the frontend can be captured and passed as the state. This allows the frontend to specify where the user should be redirected after a successful login (e.g., /my-tours). Google includes this state value in the callback request.

This route redirects the user from the application to Google's standard login page.

Step 3: Handling the Callback from Google

After the user authenticates with Google and grants permission, Google redirects them back to a predefined callback URL. A route is defined to handle this callback.

// d:\L2-programming-hero\backend-tour-management-system\src\app\modules\auth\auth.route.ts

router.get(
  "/google/callback",
  passport.authenticate("google", { failureRedirect: "/login" }), // Handle failed authentication
  AuthControllers.googleCallbackController // Handle successful authentication
);

This route, /api/v1/auth/google/callback, is protected by the same passport.authenticate('google', ...) middleware. In this context, Passport's role is to:

Take the authorization code from Google's response.
Exchange it for an access token and user profile information behind the scenes.
Invoke the verify function defined in the passport.ts configuration.

If the authentication fails (e.g., the user denies access), the failureRedirect: "/login" option sends the user back to a login page on the frontend.
Upon success, Passport attaches the user object (retrieved from the database) to req.user and passes control to the googleCallbackController.

Step 4: Finalizing Login and Redirecting the User

The final step occurs in auth.controller.ts, where the authenticated user from Passport is processed, an application-specific session is created, and the user is redirected back to the frontend.

// d:\L2-programming-hero\backend-tour-management-system\src\app\modules\auth\auth.controller.ts

const googleCallbackController = catchAsync(
  async (req: Request, res: Response, next: NextFunction) => {
    // Retrieve the original redirect path from the state query parameter
    let redirectTo = req.query.state ? (req.query.state as string) : "";

    if (redirectTo.startsWith("/")) {
      redirectTo = redirectTo.slice(1);
    }

    // Get the user object attached by Passport
    const user = req.user;

    if (!user) {
      throw new AppError(httpStatus.NOT_FOUND, "User Not Found");
    }

    // Create application-specific JWTs
    const tokenInfo = createUserTokens(user);

    // Set JWTs as secure, httpOnly cookies
    setAuthCookie(res, tokenInfo);

    // Redirect the user back to the frontend
    res.redirect(`${envVars.FRONTEND_URL}/${redirectTo}`);
  }
);

Get User and Redirect Path: The user object is retrieved from req.user, and the original redirect path is extracted from req.query.state.
Create JWTs: The createUserTokens(user) utility is called. This represents a key transition from Google's OAuth flow to the application's own JWT-based authentication system. This function generates a custom accessToken and refreshToken.
Set Secure Cookies: The setAuthCookie(res, tokenInfo) utility is used to securely set the accessToken and refreshToken as httpOnly cookies in the user's browser.
Redirect to Frontend: Finally, the user is redirected back to the frontend application, completing the login flow. For example, if the original path was /my-tours, the user would be sent to https://my-frontend-app.com/my-tours.

At this point, the user is successfully logged in, and the frontend can use the tokens (stored in cookies) to make authenticated API requests.

How I implemented Access Token and Refresh Token in my Tour Management System Application

Alifa Ara Heya — Fri, 18 Jul 2025 23:53:36 +0000

Authentication Flow: Two-Token Strategy

Github Code Link

In this application, we employ a two-token strategy for authentication to enhance security and user experience. This involves an Access Token and a Refresh Token.

📜 Token Overview

🔑 Access Token

A short-lived JSON Web Token (JWT) that the client sends with every request to access protected resources.
Its short lifespan (defined by JWT_ACCESS_EXPIRES in env.ts) minimizes the risk if it's ever compromised.

🔄 Refresh Token

A long-lived JWT used solely to obtain a new access token when the old one expires.
It is stored securely in an httpOnly cookie, making it inaccessible to client-side JavaScript.
Its longer lifespan is defined by JWT_REFRESH_EXPIRES.

🔥 The Complete Authentication and Refresh Flow

Here is the step-by-step process from initial login to session renewal.

1️⃣ User Login

A user submits their credentials (e.g., email/password or through Google OAuth) to a login endpoint like:

  /api/v1/auth/login

The server validates these credentials against the database.
Upon successful validation, the server generates two tokens:
- A new Access Token, signed with JWT_ACCESS_SECRET.
- A new Refresh Token, signed with JWT_REFRESH_SECRET.
The server sends its response:
- Access Token is sent in the JSON body of the response. The frontend stores it (e.g., in memory).
- Refresh Token is sent back in an httpOnly cookie. The cookieParser middleware in app.ts is essential for the server to read this cookie in subsequent requests.

2️⃣ Accessing Protected Routes

To make a request to a protected API endpoint (e.g., /api/v1/bookings), the frontend client attaches the Access Token to the Authorization header:

  Authorization: Bearer <access_token>

Backend middleware:
- Intercepts the request.
- Verifies the Bearer token's signature and expiration date.
- If valid, allows the request to proceed to the controller.

3️⃣ Handling an Expired Access Token

Eventually, the short-lived Access Token will expire.
When the client sends a request with the expired token, the backend responds with:

  HTTP/1.1 401 Unauthorized

4️⃣ The Refresh Token Flow (The Core Logic)

When the frontend receives a 401 response, it knows to request a new access token.
It sends a POST request to:

  /api/v1/auth/refresh-token

This request does not require an Authorization header. The browser automatically includes the httpOnly cookie containing the Refresh Token.

Backend process:

Uses cookieParser to extract the refresh token from cookies.
Verifies the refresh token:
- Checks signature with JWT_REFRESH_SECRET.
- Checks expiration.
- Optionally confirms the user still exists and is active in the database.
If valid:
- Generates a new Access Token (signed with JWT_ACCESS_SECRET).
- Sends it back in the JSON response body.

5️⃣ Resuming the Session

The frontend receives the new Access Token.
It updates its stored Access Token.
Automatically retries the original failed API request, now with a valid token.
The user’s session continues seamlessly.

6️⃣ When the Refresh Token Expires

If the Refresh Token is expired or invalid, the backend responds with:

  HTTP/1.1 403 Forbidden

The client knows the session is over.
Clears user state and redirects to the login page for re-authentication.

⚙️ Configuration References

Access Token Expiration: JWT_ACCESS_EXPIRES in env.ts
Refresh Token Expiration: JWT_REFRESH_EXPIRES in env.ts
Secrets: JWT_ACCESS_SECRET, JWT_REFRESH_SECRET
Middleware: cookieParser in app.ts

This entire process provides a secure and smooth authentication experience for the end-user.

JWT Implementation Walkthrough

Alifa Ara Heya — Wed, 16 Jul 2025 06:06:27 +0000

Let’s walk through the JWT process I’ve implemented in my application, how the flow works.
My Backend API GitHub link.

📝 A Quick Refresher on JWTs

A JSON Web Token (JWT) is a standard I’m using to securely transmit information between my client and server. It’s essentially a signed, self-contained JSON object.

Because it’s signed with a secret key that only my server knows, I can trust the information within it.

📦 JWT Structure

It has three parts:

Header Metadata about the token (e.g., algorithm HS256).
Payload The data I want to send (claims), like userId, email, and role, plus standard claims like exp (expiration time).
Signature Ensures the token’s integrity. Created using the header, payload, and my secret key.

🚀 The JWT Flow I’ve Built

Here is the step-by-step flow of how I am using JWTs in my code.

✅ Step 1: Generate Token on Login

This is where my user gets their credentials for accessing protected parts of the API.

Login Request
A user submits their email and password to my /api/v1/auth/login endpoint.
Service Logic (auth.service.ts)

credentialsLogin service finds the user in the database.
Securely compares the submitted password with the stored hash using bcryptjs.compare.
Creates a jwtPayload object with only necessary, non-sensitive data.

const jwtPayload = {
  userId: isUserExist._id,
  email: isUserExist.email,
  role: isUserExist.role,
};

Signing the Token (utils/jwt.ts)

I call my generateToken utility. It's great that I've abstracted this into a separate utility file to keep my code clean.
Uses jsonwebtoken to sign the payload with JWT_ACCESS_SECRET and sets an expiration time from my .env variables..

Sending the Token

Sends the newly created accessToken back to the client. The client stores it for future requests.

🔐 Step 2: Client Accesses a Protected Route

Now, the user wants to do something that requires authentication, like updating their profile.

The client sends a PATCH request to /api/v1/user/:id with the accessToken in the Authorization header, typically as Bearer <token>.:
Middleware Intercepts (user.route.ts)

The request passes through the checkAuth middleware before hitting the controller.

🛡 Step 3: Verify the Token and Authorize the User (`checkAuth.ts`)

This middleware is the heart of the API’s security.

A Flexible Higher-Order Function
I designed checkAuth as a higher-order function. It accepts a list of roles (...authRoles) and returns an Express middleware function. This makes it incredibly powerful and reusable. For instance, to protect an admin-only route, I simply use checkAuth(Role.ADMIN, Role.SUPER_ADMIN).
Token Extraction
My middleware first looks for the Authorization header and extracts the token.
Token Verification
It then calls my verifyToken utility function.
This function uses jwt.verify() with the same JWT_ACCESS_SECRET. This single call verifies both the signature (ensuring it’s not tampered with) and the expiration date.
If the token is invalid for any reason, jwt.verify() throws an error, which my catch block sends to my globalErrorHandler.
Role-Based Authorization
If the token is valid, I then check if the user’s role (from the decoded token) is included in the authRoles I passed to the middleware. If not, I throw a "Forbidden" error.
Attaching the User to the Request
This is a key pattern I’ve implemented. After successful verification and authorization, I attach the entire decoded payload to the Express Request object.

req.user = verifiedToken; // declared globally in src/app/interfaces/index.d.ts

🏗 Step 4: Controller and Service Use Authenticated User

Because of the work I did in the middleware, my controller logic is now much cleaner.

Accessing the User in the Controller (user.controller.ts) In my updateUser controller, I can now trust that req.user exists and contains the authenticated user's data. I don't need to re-verify the token here.

const verifiedToken = req.user;

This is fully type-safe because I cleverly extended the global Express Request type in backend-tour-managemnet-system\src\app\interfaces\index.d.ts.

Service-Layer Logic (user.service.ts) I pass this trusted verifiedToken to my service layer, where I can implement fine-grained business logic, such as checking if an ADMIN is trying to modify a SUPER_ADMIN.

This entire flow is robust and secure.

JWT Token vs. Session token vs. Refresh Token

Alifa Ara Heya — Wed, 16 Jul 2025 05:56:34 +0000

⚖️ Session Tokens vs. JWT Implementation vs. Refresh Tokens

Feature	Session Tokens (Traditional)	JWT (Stateless)	JWT + Refresh Token
State	Stateful (Server stores session data)	Stateless (No server storage needed)	Stateless for access, stateful for refresh
Data Storage	Server stores session info securely	User’s claims in token payload	Short-lived access token + long-lived refresh
Scalability	Needs sticky sessions or shared store	Highly scalable; any server can validate token	Refresh tokens allow scaling with security
Security	Session ID reveals nothing (random pointer)	Payload visible (Base64), no sensitive data	Refresh token stored securely (httpOnly cookie)
Expiration	Controlled by server session timeout	Fixed expiration in JWT	Access token expires quickly; refresh token rotates
Vulnerable To	CSRF (if not using same-site cookies)	XSS (if token in localStorage)	XSS for access tokens, mitigated by refresh flow
When to Use	Monolithic apps, simple setups	APIs, microservices, mobile apps	When you want both scalability and strong security

🔄 When and Why Use Refresh Tokens?

Why?
Since access tokens in JWT are short-lived (for security), refresh tokens allow the client to silently obtain new access tokens without forcing the user to log in again.
When?
Use refresh tokens:
- For long-lived sessions without sacrificing statelessness.
- In mobile and SPAs (Single Page Applications) where users expect to stay logged in.
- When access tokens are stored in memory or localStorage and refresh tokens in secure httpOnly cookies.

✅ When and Why Use Session Tokens

📌 When to Use

For monolithic web apps (server-rendered pages).
When you control both frontend and backend tightly.
If you can use httpOnly cookies for extra security.
Apps where cross-site requests (forms, etc.) are common and CSRF protections are needed.

💡 Why

Simple to implement with browser’s built-in cookie handling.
Session data stays server-side, reducing exposure of user data.
Works well for small-scale apps or systems without horizontal scaling needs.

🔑 When and Why Use JWT (Access Token Only)

📌 When to Use

For RESTful APIs and microservices architectures.
In mobile apps or SPAs (Single Page Applications).
When clients don’t need long-lived sessions.
If you need a stateless backend (no session store).

💡 Why

Highly scalable since no state is stored on the server.
Any server instance can validate the token with the secret key.
Ideal for distributed systems and modern API-first designs.

🔄 When and Why Use JWT + Refresh Token

📌 When to Use

When you want short-lived access tokens but also long-lived sessions.
For mobile apps, SPAs, or systems where users expect to stay logged in.
To mitigate risks of storing tokens in memory or localStorage.
When rotating tokens improves security.

💡 Why

Balances security (short access token lifetime) and user convenience.
Refresh token stays securely in httpOnly cookies, reducing XSS risks.
Allows silent re-authentication without frequent logins.

Dream Tour Management Backend Development – Part 1: Foundational Setup

Alifa Ara Heya — Sun, 13 Jul 2025 02:34:35 +0000

This is a progress recap of Part 1 of the backend development for the DreamTourManagement system. The goal was to set up a clean, scalable, and production-ready Express.js architecture using TypeScript, Zod, and modular patterns.

🚀 Step-by-Step Implementation Journey

Here’s the logical order in which the backend was built.

✅ Step 1: Core Application Setup

This step established the basic server infrastructure.

Express Server (app.ts)

The Express app was initialized with essential middleware:
- express.json() for parsing JSON request bodies
- cors() for enabling cross-origin requests
Database Connection (server.ts)

Mongoose was configured to connect to MongoDB. The server only starts if the database connection succeeds.
Environment Configuration (app/config/env.ts)

A type-safe system was created to manage environment variables like PORT, DB_URL, etc., ensuring better security and easier environment switching (dev, prod).

👤 Step 2: Building the First Feature Module – User

The user module was used as a pattern for all future modules. This modular architecture helps in scaling and maintaining the app.

Interface (user.interface.ts)

Defined the IUser interface with proper typing for consistent and type-safe data across the app.
Model (user.model.ts)

Created a Mongoose userSchema with field rules like required and unique constraints.
Service (user.service.ts)

Contains business logic like User.create() and User.find(). It acts as the “brain” behind each module.
Controller (user.controller.ts)

Acts as the middle layer between HTTP requests and services. Handles incoming data and formats outgoing responses.
Route (user.route.ts)

Sets up REST endpoints such as POST /register and GET /all-users and connects them to controller functions.

🧱 Step 3: Architecting for Scalability

With the base module built, scalable patterns were introduced.

Centralized Routing (routes/index.ts)

All module routes are registered in one place. New routes can be added simply by adding them to a moduleRoutes array.
Standardized Response Utility (utils/sendResponse.ts)

A utility to send all success responses in a uniform structure:

  {
    success,
    statusCode,
    message,
    data,
    meta
  }

⚠️ Step 4: Robust Error Handling System

Handling errors effectively is key to building a stable application.

Async Wrapper (utils/catchAsync.ts)
A higher-order function that wraps async controllers and automatically forwards errors to next(). This eliminates repetitive try...catch blocks.
Custom Error Class (errorHelpers/appError.ts)
Extends the built-in Error class to support custom status codes. Helpful for throwing HTTP-aware errors like new AppError(404, "User not found").
Global Error Handler (middlewares/globalErrorHandler.ts)
Catches and formats all errors into a consistent JSON response.
Not Found Handler (middlewares/notfound.ts)
Captures all undefined routes and sends a clean 404 Not Found response.

🔁 Step 5: Server Stability & Graceful Shutdown

In server.ts, listeners were added for:

unhandledRejection
uncaughtException
SIGTERM

These allow the server to exit cleanly in case of unexpected errors or shutdown signals — crucial for production readiness.

🔄 The Complete Request Flow (Example: `POST /api/v1/user/register`)

Let’s break down what happens from request to response.

📥 Request Flow:

A client sends a POST request with user data to /api/v1/user/register.
app.ts:

express.json() parses the JSON body.
The route /api/v1/user is forwarded to the router from routes/index.ts.

routes/index.ts:

The router matches /user and forwards to userRoutes.

user.route.ts:

The POST /register route is matched.
Input validation happens here using validateRequest middleware with a Zod schema.

   router.post(
     "/register",
     validateRequest(UserValidations.createUserValidationSchema),
     UserControllers.createUser
   );

user.controller.ts:

The createUser controller is wrapped in catchAsync.
It receives the validated req.body, calls UserServices.createUser(), and sends a formatted success response via sendResponse.

user.service.ts:

Handles the actual database logic with User.create() and returns the new user.

user.model.ts:

Mongoose validates the data and saves it to the MongoDB users collection.

⚠️ Error Flow:

If Zod validation fails → validateRequest calls next(error).
If Mongoose fails (e.g., duplicate email) → the promise rejects.
catchAsync catches and forwards the error to Express.
globalErrorHandler.ts receives the error and responds with:

{
  success: false,
  message: "Detailed error message",
  stack: "only in development"
}

🧠 Summary

In Part 1, the focus was on building a professional-grade foundation that supports:

🧩 Modular design
✅ Consistent responses
🧪 Centralized validation and error handling
🧱 Scalable route management
🧯 Stable production-ready behavior

With this groundwork in place, the application is ready to move on to authentication, authorization, OTP, and role-based access in the next part.

Coming up in Part 2:
🔐 Authentication with JWT
📨 OTP system
🛂 Role-based Access Control (Admin, Guide, User)
🧾 Guide approval workflows

Stay tuned!

#nodejs #typescript #expressjs #zod #backend #webdev #cleancode #dreamtourmanagement #programminghero

Stop Writing try-catch in Every Express Controller — Use This Pattern Instead!

Alifa Ara Heya — Sat, 12 Jul 2025 17:10:24 +0000

In Express.js apps, especially when dealing with async operations (like database queries), you've likely repeated the same code structure over and over:

const getAllUsers = async (req, res, next) => {
  try {
    const users = await UserServices.getAllUsers();
    res.status(200).json({ users });
  } catch (error) {
    next(error);
  }
};

✅ This works — but do you really want to write that try...catch block every single time?

Let’s clean it up using a Higher-Order Function.

🚫 The Problem

Every controller duplicates the same try-catch-next() logic.
It violates the DRY principle (Don't Repeat Yourself).
It clutters your code and distracts from the actual business logic.

✅ The Solution: `catchAsync`

Let’s abstract the error-catching logic into a reusable utility function.

📁 src/utils/catchAsync.ts

import { NextFunction, Request, RequestHandler, Response } from 'express';

export const catchAsync = (fn: RequestHandler) => {
  return (req: Request, res: Response, next: NextFunction) => {
    Promise.resolve(fn(req, res, next)).catch((err) => next(err));
  };
};

🧠 What's Going On Here? What Is a Higher-Order Function (HOF)?

The catchAsync function is a Higher-Order Function (HOF).

A Higher-Order Function is simply a function that:

Takes another function as an argument, or
Returns a new function, or
Does both (like catchAsync!)

🔁 Why are HOFs powerful?

They allow you to wrap and enhance behavior without repeating code.
You can build reusable utilities like authentication guards, validators, logging, and — in our case — async error handlers.

🔍 Deep Dive: How `catchAsync` Works

const catchAsync = (fn: RequestHandler) => {
  return (req, res, next) => {
    Promise.resolve(fn(req, res, next)).catch((err) => next(err));
  };
};

Let’s break this down:

Line	Explanation
`catchAsync(fn)`	Takes your controller as an argument
`return (req, res, next)`	Returns a new function with the same signature Express expects
`Promise.resolve(...)`	Ensures even non-async handlers are wrapped in a Promise
`.catch((err) => next(err))`	Automatically catches any error and forwards it to Express’s global error handler

🧠 So instead of you writing try...catch, catchAsync does it for you!

🎯 Cleaner Controller Code

Now your controller becomes:

import { catchAsync } from '../../../utils/catchAsync';

export const getAllUsers = catchAsync(async (req, res, next) => {
  const users = await UserServices.getAllUsers();
  res.status(200).json({
    success: true,
    message: 'Users retrieved successfully',
    data: users
  });
});

✅ No more try...catch clutter
✅ Just focus on the actual logic

💬 Bonus: Want to Handle Validation or Custom Errors?

You can combine catchAsync with a custom error class like AppError. You can read more about it here (https://dev.to/alifa_ara_heya/building-a-better-apperror-class-in-nodejs-for-robust-api-error-handling-25o)

if (!user) {
  throw new AppError(404, 'User not found');
}

Now your global error handler can cleanly handle all cases.

🧪 TL;DR

Problem	Solution
Repeating try/catch in every controller	Use `catchAsync()` to wrap async functions
Messy controllers	Cleaner, focused logic
Manual error handling	Automatic forwarding to global error middleware

🧠 Final Thoughts

Using Higher-Order Functions like catchAsync makes your codebase:

More readable
Less error-prone
Easier to maintain

It’s a small trick, but it will make your Express codebase much more professional and clean.

🔁 Try it out in your next Express project and say goodbye to repetitive try...catch blocks forever!

#expressjs #javascript #nodejs #backend #cleancode #webdev #devtips

Building a Better `AppError` Class in Node.js for Robust API Error Handling

Alifa Ara Heya — Fri, 11 Jul 2025 23:12:45 +0000

When you're building a Node.js API with Express, error handling is critical. You want responses to be:

✅ Consistent
✅ Predictable
✅ Meaningful for the client

But JavaScript’s built-in Error class falls short for APIs — it doesn’t carry the HTTP status code.

The AppError class extends the built-in Error to add a statusCode property. This allows you to create errors that carry their own status code, making your error handling much cleaner and more predictable.

Let’s build a powerful AppError class and integrate it cleanly into your Express API.

🚫 The Problem with the Default Error Class

Consider this typical controller logic:

// user.controller.ts
try {
  const user = await UserServices.findUserById(req.params.id);
  if (!user) {
    throw new Error('User not found');
  }
  res.json(user);
} catch (err) {
  res.status(500).json({ success: false, message: err.message });
}

The issue?
Even though User not found is a 404, we send a 500 Internal Server Error — because there's no way to attach the right status code to the error itself.

✅ A First Draft: Creating `AppError`

Let’s define a simple custom error class:

// src/errorHelpers/appError.ts
class AppError extends Error {
  public statusCode: number;

  constructor(statusCode: number, message: string, stack = '') {
    super(message);
    this.statusCode = statusCode;

    if (stack) {
      this.stack = stack;
    } else {
      Error.captureStackTrace(this, this.constructor);
    }
  }
}

🔍 Explanation: What’s Happening Behind the Scenes

`AppError` Breakdown:

The first line

class AppError extends Error {...

declares a new class named AppError that inherits from the standard JavaScript Error class. This means an AppError instance will have all the properties and methods of a regular Error (like .message and .stack), plus any new ones we define.

The second line

    public statusCode: number;

This declares a new public property on the class called statusCode. This is the key addition that will hold the HTTP status code (e.g., 400, 404, 500).

The third line

  constructor(statusCode: number, message: string, stack = '') {

This is the constructor for the class. It's called whenever you create a new instance with new AppError(...). It takes three arguments:

statusCode: The HTTP status code for this error.
message: The human-readable error message.
stack = '': An optional stack trace. If you don't provide one, it will be generated automatically.

        super(message)

This is crucial. It calls the constructor of the parent Error class and passes the message to it. This is what sets the error.message property correctly.

    this.statusCode = statusCode

This line assigns the statusCode passed into the constructor to the statusCode property of the new AppError instance.

        if (stack) {
            this.stack = stack
        } else {
            Error.captureStackTrace(this, this. Constructor)
        }

This block handles the stack trace.

If a stack string is provided to the constructor, it uses that.
Otherwise, it calls Error.captureStackTrace(this, this. Constructor). This is a standard Node.js V8 feature that generates a stack trace for the error. The second argument (this. Constructor) tells it to exclude the AppError constructor function from the stack trace, which makes your error logs cleaner and points directly to where the error was created.

Why this works:

this.statusCode = statusCode: We now attach the right HTTP status code.
Error.captureStackTrace(...): This is a standard Node.js practice. It captures the stack trace, excluding the constructor function itself, which makes for cleaner error logs.

💡 How to Use `AppError`

1️⃣ Throwing it in services or controllers:

// user.service.ts
import { AppError } from '../errorHelpers/appError';
import httpStatus from 'http-status-codes';

const findUserById = async (id: string) => {
  const user = await User.findById(id);
  if (!user) {
    throw new AppError(httpStatus.NOT_FOUND, 'User not found!');
  }
  return user;
};

2️⃣ Handling it globally:

This custom error becomes powerful when used with globalErrorHandler.

// middlewares/globalErrorHandler.ts

export const globalErrorHandler = (err, req, res, next) => {
  const statusCode = err.statusCode || 500;
  const message = err.message || 'Something went wrong!';

  res.status(statusCode).json({
    success: false,
    message,
    stack: process.env.NODE_ENV === 'development' ? err.stack : undefined,
  });
};

✅ Now the response reflects the real nature of the error — 404 for missing user, 403 for unauthorized, etc.

🧪 Bonus: Cleaner Code, Better API

With AppError, your services are responsible for context, and your global error handler is consistent.

Your API becomes:

✅ Easier to maintain
✅ More readable
✅ Scalable with different error types (ValidationError, DatabaseError, etc.)

🎉 Conclusion

By creating an AppError class:

You decouple status code logic from the global handler
You make services more expressive and controllers leaner
You set the foundation for robust, predictable error handling

Pro tip: You can even extend AppError into specific subclasses like ValidationError, AuthError, etc.

📌 TL;DR

Problem	Solution
No HTTP status in `Error`	Add `statusCode` in `AppError`
Messy stack traces	Use `Error.captureStackTrace`
Guessing error codes	Define them at the throw site

By implementing this pattern, you've made your error handling more structured, expressive, and easier to manage.

Happy coding! 🚀

DEV Community: Alifa Ara Heya

Understanding Default Operator (`||`) vs Nullish Coalescing Operator (`??`) in JavaScript

🔹 The Default Operator (||)

🔹 The Nullish Coalescing Operator (??)

✅ Advantage of ?? over ||

🔹 Quick Comparison Table

🌍 Real-World Use Cases

1. API Response Defaults

2. Config Settings with Boolean Flags

3. User Input Handling

🎯 Final Thoughts

HTTP Requests in React(fetch vs Axios and Tanstack Query)

1. The Native fetch API

Boilerplate for a GET Request with fetch

A Deeper Look at fetch's Promise Chain and Error Handling

Full CRUD Operations with fetch

2. Axios: The Easier Alternative

fetch vs. Axios

Boilerplate for a GET Request with Axios

Going Deeper with Axios: Interceptors and Configuration

3. TanStack Query: A Data Fetching Superpower

The Problem: Native State Management for Caching & Refetching

The Solution: TanStack Query's useQuery Hook

The Power of Caching and Stale-while-revalidate

Handling Mutations with useMutation

4. Combining Axios and TanStack Query

Example of an Integrated Solution

Final Thoughts

✅ Summary

💬 From Rejection to Revolution: The Engineering Brilliance Behind WhatsApp

📱 The Incredible Engineering Story Behind WhatsApp

🧭 1. Single Responsibility Principle

⚙️ 2. Smart Technology Choices

🧱 3. Building on Open Source

📈 4. Scaling with Simplicity

🔁 5. Seamless Deployment

👥 6. Small Team, Big Impact

🚀 Final Thought

Monorepo vs Polyrepo

Monorepo vs Polyrepo - Strategies for Organizing Codebases

📊 Feature Comparison

✅ Monorepo: Pros & Cons

✅ Polyrepo: Pros & Cons

Monolith vs. Microservices: Choosing a Software Architecture

Monolithic Architecture

Key Characteristics

Pros

Cons

Microservices Architecture

Key Characteristics

Pros

Cons

Comparison at a Glance

Conclusion

How I Implemented Google Authentication: A Step-by-Step Guide

Google Authentication Setup: A Step-by-Step Guide

Step 1: Setting Up the Foundation with Middleware

Step 2: Creating the "Login with Google" Route

Step 3: Handling the Callback from Google

Step 4: Finalizing Login and Redirecting the User

How I implemented Access Token and Refresh Token in my Tour Management System Application

Authentication Flow: Two-Token Strategy

📜 Token Overview

🔑 Access Token

🔄 Refresh Token

🔥 The Complete Authentication and Refresh Flow

1️⃣ User Login

2️⃣ Accessing Protected Routes

3️⃣ Handling an Expired Access Token

4️⃣ The Refresh Token Flow (The Core Logic)

5️⃣ Resuming the Session

6️⃣ When the Refresh Token Expires

⚙️ Configuration References

JWT Implementation Walkthrough

📝 A Quick Refresher on JWTs

📦 JWT Structure

🚀 The JWT Flow I’ve Built

✅ Step 1: Generate Token on Login

🔐 Step 2: Client Accesses a Protected Route

🛡 Step 3: Verify the Token and Authorize the User (checkAuth.ts)

🔹 The Default Operator (`||`)

🔹 The Nullish Coalescing Operator (`??`)

✅ Advantage of `??` over `||`

The Solution: TanStack Query's `useQuery` Hook

Handling Mutations with `useMutation`

🛡 Step 3: Verify the Token and Authorize the User (`checkAuth.ts`)

🔄 The Complete Request Flow (Example: `POST /api/v1/user/register`)

✅ The Solution: `catchAsync`

🔍 Deep Dive: How `catchAsync` Works

✅ A First Draft: Creating `AppError`

`AppError` Breakdown:

💡 How to Use `AppError`