DEV Community: Saiful Islam

Setting Up PostgreSQL with Docker Compose for Development and Production

Saiful Islam — Sat, 29 Nov 2025 15:05:26 +0000

Working with PostgreSQL becomes much easier when you run it inside Docker. It gives you a clean environment, consistent versions, and a quick setup for both development and production. In this guide, we will walk step by step through a practical setup using Docker Compose.

This setup includes:

A custom PostgreSQL configuration
Automatic initialisation scripts
Separate Docker Compose files for development and production
A clear folder structure
Easy commands for starting and stopping the containers

Let us begin by reviewing the folder layout.

1. Folder Structure

Here is the structure used in this guide:

infra/
├─ docker/
│  ├─ docker-compose-dev.yml
│  └─ docker-compose.yml
├─ postgres/
│  ├─ init-scripts/
│  │  └─ init.sql
│  └─ postgres.conf
├─ package.json

Each file has its own purpose:

**postgres.conf* → Custom PostgreSQL configuration
init.sql → Creates roles, permissions, and databases
docker-compose-dev.yml → Development compose file
docker-compose.yml → Production compose file
package.json scripts → Simple commands for starting and stopping services

2. Custom PostgreSQL Configuration

The file postgres.conf defines PostgreSQL tuning parameters.
Some of the key settings include:

Connection limits
Memory tuning
WAL optimisation
Logging options
Security settings

An example:

# Connection settings
listen_addresses = '*'
port = 5432
max_connections = 200

# Memory settings
shared_buffers = 512MB
effective_cache_size = 1GB
work_mem = 4MB
maintenance_work_mem = 128MB

# WAL settings
wal_buffers = 16MB
checkpoint_completion_target = 0.9
wal_compression = on
min_wal_size = 512MB
max_wal_size = 2GB

# Logging
log_destination = 'stderr'
logging_collector = off
log_min_messages = warning
log_min_error_statement = error
log_min_duration_statement = 1000

# Security
ssl = off
password_encryption = scram-sha-256

# Performance
random_page_cost = 1.1
effective_io_concurrency = 200

Keeping this file external makes it easy to adjust performance for development and production without modifying container images.

3. Database Initialisation with init.sql

The init.sql script runs automatically the first time the container starts.
It performs tasks such as:

Creating roles (db_migrator, db_rw, db_ro)
Creating the test database
Setting permissions for each role
Configuring default privileges
Enforcing secure database access

An example:

-- ---------- 1. Create roles ----------
DO $$
BEGIN
    IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = 'db_migrator') THEN
        CREATE ROLE db_migrator LOGIN PASSWORD '12345678';
    END IF;

    IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = 'db_rw') THEN
        CREATE ROLE db_rw LOGIN PASSWORD '12345678';
    END IF;

    IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = 'db_ro') THEN
        CREATE ROLE db_ro LOGIN PASSWORD '12345678';
    END IF;
END
$$;

-- ---------- 2. Create databases ----------
CREATE DATABASE test;

-- ============================================================
-- Apply permissions for each database
-- ============================================================

------------------------------------------------------------
-- Setup for project_db
------------------------------------------------------------
\connect project_db

-- Remove unsafe default privileges
REVOKE ALL ON DATABASE project_db FROM PUBLIC;
REVOKE CREATE ON SCHEMA public FROM PUBLIC;

-- Prisma requires the db_migrator to own the schema
ALTER SCHEMA public OWNER TO db_migrator;

-- db_Migrator full control
GRANT USAGE, CREATE ON SCHEMA public TO db_migrator;

-- Read/Write application user
GRANT USAGE ON SCHEMA public TO db_rw;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO db_rw;
GRANT USAGE, SELECT, UPDATE ON ALL SEQUENCES IN SCHEMA public TO db_rw;

-- Readonly user
GRANT USAGE ON SCHEMA public TO db_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO db_ro;
GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO db_ro;

-- Default privileges for FUTURE objects created by db_migrator
ALTER DEFAULT PRIVILEGES FOR ROLE db_migrator IN SCHEMA public
    GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO db_rw;

ALTER DEFAULT PRIVILEGES FOR ROLE db_migrator IN SCHEMA public
    GRANT SELECT ON TABLES TO db_ro;

ALTER DEFAULT PRIVILEGES FOR ROLE db_migrator IN SCHEMA public
    GRANT USAGE, SELECT, UPDATE ON SEQUENCES TO db_rw;

ALTER DEFAULT PRIVILEGES FOR ROLE db_migrator IN SCHEMA public
    GRANT USAGE, SELECT ON SEQUENCES TO db_ro;

-- Allow connections
GRANT CONNECT ON DATABASE project_db TO db_migrator, db_rw, db_ro;

-------------------------------
-- Setup for test database
-------------------------------
\connect test

REVOKE ALL ON DATABASE test FROM PUBLIC;
REVOKE CREATE ON SCHEMA public FROM PUBLIC;

ALTER SCHEMA public OWNER TO db_migrator;
GRANT USAGE, CREATE ON SCHEMA public TO db_migrator;

GRANT USAGE ON SCHEMA public TO db_rw, db_ro;

GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO db_rw;
GRANT USAGE, SELECT, UPDATE ON ALL SEQUENCES IN SCHEMA public TO db_rw;

GRANT SELECT ON ALL TABLES IN SCHEMA public TO db_ro;
GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO db_ro;

ALTER DEFAULT PRIVILEGES FOR ROLE db_migrator IN SCHEMA public
    GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO db_rw;

ALTER DEFAULT PRIVILEGES FOR ROLE db_migrator IN SCHEMA public
    GRANT SELECT ON TABLES TO db_ro;

ALTER DEFAULT PRIVILEGES FOR ROLE db_migrator IN SCHEMA public
    GRANT USAGE, SELECT, UPDATE ON SEQUENCES TO db_rw;

ALTER DEFAULT PRIVILEGES FOR ROLE db_migrator IN SCHEMA public
    GRANT USAGE, SELECT ON SEQUENCES TO db_ro;

GRANT CONNECT ON DATABASE test TO db_migrator, db_rw, db_ro;

This ensures a predictable PostgreSQL environment and follows best practices for separating permissions.

Docker automatically executes any .sql file placed inside:

/docker-entrypoint-initdb.d

This is why we mount that directory inside the container.

4. Development Compose File

The development file is simple and focuses on flexibility.
Key features include:

PGAdmin for database management
Exposed ports for local access
Mounted configuration and initialisation scripts
Health checks
Volumes for persistent storage

Example:

services:
  postgres:
    image: postgres:16.11-alpine3.22
    container_name: postgres
    restart: unless-stopped
    ports:
      - "5432:5432"
    env_file:
      - ../../.env
      - ../../.env.development.local
    volumes:
      - pg_volume:/var/lib/postgresql/data:rw
      - ../postgres/postgres.conf:/etc/postgresql/postgresql.conf:ro
      - ../postgres/init-scripts:/docker-entrypoint-initdb.d:ro
    command: [ "postgres", "-c", "config_file=/etc/postgresql/postgresql.conf", "-c", "log_statement=none", "-c", "log_min_duration_statement=1000", "-c", "log_connections=on", "-c", "log_disconnections=on" ]
    user: "70:70" # Postgres user
    healthcheck:
      test: [ "CMD-SHELL", 'pg_isready -U "$${POSTGRES_USER:-postgres}" -d "$${POSTGRES_DB:-postgres}" -h localhost || exit 1' ]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 60s
    stop_grace_period: 120s
    networks:
      - project_network

  pgadmin:
    image: elestio/pgadmin:latest
    container_name: pgadmin
    restart: unless-stopped
    ports:
      - "5050:8080"
    env_file:
      - ../../.env
      - ../../.env.development.local
    volumes:
      - pgadmin_volume:/var/lib/pgadmin:rw
    depends_on:
      - postgres
    networks:
      - project_network

networks:
  project_network:
    driver: bridge

volumes:
  pg_volume:
    driver: local
  pgadmin_volume:
    driver: local

Development environments usually need visibility, so logging and access remain more open.

5. Production Compose File

Production requires a stricter setup.
This file includes:

Resource limits
Security enhancements
Custom network settings
Logging configuration
No PGAdmin
No unnecessary services

Example:

services:
  postgres:
    image: postgres:16.11-alpine3.22
    container_name: postgres
    restart: unless-stopped
    ports:
      - "5432:5432"
    env_file:
      - ../../.env
      - ../../.env.production.local
    volumes:
      - pg_volume:/var/lib/postgresql/data:rw
      - ../postgres/postgres.conf:/etc/postgresql/postgresql.conf:ro
      - ../postgres/init-scripts:/docker-entrypoint-initdb.d:ro
    command: [ "postgres", "-c", "config_file=/etc/postgresql/postgresql.conf", "-c", "log_statement=none", "-c", "log_min_duration_statement=1000", "-c", "log_connections=on", "-c", "log_disconnections=on" ]
    user: "70:70" # Postgres user
    healthcheck:
      test: [ "CMD-SHELL", 'pg_isready -U "$${POSTGRES_USER:-postgres}" -d "$${POSTGRES_DB:-postgres}" -h localhost || exit 1' ]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 60s
    stop_grace_period: 120s
    networks:
      - project_network
    security_opt:
      - no-new-privileges:true
    shm_size: "512mb"
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "5"
    deploy:
      resources:
        limits:
          cpus: "1.5"
          memory: 1G
        reservations:
          cpus: "0.5"
          memory: 512M
    labels:
      - "com.docker.compose.service=postgres"
      - "maintainer=your.dev.mail@mail.com"

networks:
  project_network:
    driver: bridge
    driver_opts:
      com.docker.network.bridge.name: ma_bridge
    ipam:
      config:
        - subnet: 172.20.0.0/16
    labels:
      - "com.docker.compose.network=project_name"

volumes:
  pg_volume:
    driver: local
    labels:
      - "com.docker.compose.volume=pg_volume"

Production setups focus on stability, performance, and security.

6. Running PostgreSQL with NPM Scripts

To simplify the workflow, the package.json includes convenient commands:

"scripts": {
  "docker-dev:up": "docker compose -f ./infra/docker/docker-compose-dev.yml -p project_name up -d",
  "docker-dev:down": "docker compose -f ./infra/docker/docker-compose-dev.yml -p project_name down",
  "docker:up": "docker compose -f ./infra/docker/docker-compose.yml -p project_name up -d",
  "docker:down": "docker compose -f ./infra/docker/docker-compose.yml -p project_name down"
}

Now starting PostgreSQL is as simple as:

npm run docker-dev:up

And stopping:

npm run docker-dev:down

The same applies to production.

7. Conclusion

Using separate Docker Compose files for development and production provides a cleaner and safer workflow. Your development environment becomes flexible, while the production environment stays stable and optimised.

This approach also ensures:

Reproducible environments
Clear separation of roles and permissions
Easier onboarding for other developers
Stronger security controls
Scalable and maintainable infrastructure

You can now use PostgreSQL with confidence in any setup.

useSyncExternalStore in React — The Right Way to Subscribe to External Data

Saiful Islam — Sun, 12 Oct 2025 16:26:31 +0000

Starting with React 18, a new hook called useSyncExternalStore was introduced.
At first glance, it might look confusing — why do we need it when we already have useState, useEffect, or useRef?

The answer lies in React’s new concurrent rendering model.

When your component depends on data from an external source (like browser events, a global store, or even a WebSocket connection), React needs a way to read that data consistently — even during complex renders or Suspense transitions.

That’s where useSyncExternalStore comes in.

⚙️ What is `useSyncExternalStore`?

useSyncExternalStore is a low-level React hook designed to let components safely subscribe to external data sources.

It ensures:

React always reads a consistent snapshot of the external state.
Avoids tearing — a bug where different components read inconsistent versions of external state.
Works correctly with Concurrent Mode and Server Components.

🧩 The Hook Signature

const snapshot = useSyncExternalStore(
  subscribe,
  getSnapshot,
  getServerSnapshot?
);

Here’s what each argument means:

subscribe(callback)
A function that registers a listener. React will call this callback whenever the external data changes.
getSnapshot()
Returns the current value of the external data.
getServerSnapshot()
(Optional) Returns a fallback snapshot during server-side rendering (SSR).

React uses getSnapshot() during render, and re-renders the component if subscribe() notifies it that something changed.

🧠 Why Not Just Use `useEffect`?

Before React 18, we used something like this:

const [isOnline, setIsOnline] = useState(navigator.onLine);

useEffect(() => {
  function updateStatus() {
    setIsOnline(navigator.onLine);
  }

  window.addEventListener("online", updateStatus);
  window.addEventListener("offline", updateStatus);

  return () => {
    window.removeEventListener("online", updateStatus);
    window.removeEventListener("offline", updateStatus);
  };
}, []);

This works fine in normal rendering, but can fail in concurrent scenarios (e.g., during Suspense, streaming SSR, or concurrent updates).
React might read outdated data or re-render unnecessarily.
useSyncExternalStore fixes this problem by providing synchronised reads of external state.

💻 Example: Tracking Online/Offline Status

Let’s create a reusable hook using useSyncExternalStore:

import { useSyncExternalStore } from "react";

// 1️⃣ Subscribe to browser online/offline events
function subscribe(callback: () => void) {
  window.addEventListener("online", callback);
  window.addEventListener("offline", callback);

  return () => {
    window.removeEventListener("online", callback);
    window.removeEventListener("offline", callback);
  };
}

// 2️⃣ Snapshot getter
function getSnapshot() {
  return navigator.onLine;
}

// 3️⃣ Optional SSR fallback
function getServerSnapshot() {
  return true; // assume online on the server
}

// 4️⃣ Our custom hook
export function useOnlineStatus() {
  return useSyncExternalStore(subscribe, getSnapshot, getServerSnapshot);
}

Now we can use this hook anywhere:

import React from "react";
import { useOnlineStatus } from "./useOnlineStatus";

export default function NetworkStatus() {
  const isOnline = useOnlineStatus();

  return (
    <div
      style={{
        padding: "2rem",
        textAlign: "center",
        fontFamily: "sans-serif",
      }}
    >
      <h1>
        You are currently:{" "}
        <span style={{ color: isOnline ? "green" : "red" }}>
          {isOnline ? "Online" : "Offline"}
        </span>
      </h1>
    </div>
  );
}

🧩 How It Works

subscribe() tells React how to listen for external changes. When an event happens, React calls the stored callback.
getSnapshot() reads the current external value. React calls it whenever it needs the latest state.
When the external source changes, React re-renders the component with the latest snapshot.
No risk of race conditions or stale state, even in concurrent rendering.

⚡ Other Use Cases

useSyncExternalStore can be used for:

Subscribing to a custom store (like Zustand or Redux)
Watching WebSocketupdates
Reacting to localStorage/sessionStorage changes
Integrating with browser APIs (media queries, geolocation, etc.)

Example with localStorage:

function subscribe(callback: () => void) {
  window.addEventListener("storage", callback);
  return () => window.removeEventListener("storage", callback);
}

function getSnapshot() {
  return localStorage.getItem("theme") || "light";
}

export const useThemeStore = () =>
  useSyncExternalStore(subscribe, getSnapshot, () => "light");

🧭 Key Takeaways

✅ useSyncExternalStore lets React safely read external data.
✅ Prevents stale state issues in concurrent rendering.
✅ Perfect for browser APIs, custom stores, and global events.
✅ Always use it when your component reads state outside React.

🧩 Conclusion

useSyncExternalStore might seem complex at first, but it’s the correct way to subscribe to data outside React’s control — whether that’s browser state, global stores, or server signals.

By using it, your components stay predictable, synchronised, and ready for React’s future.

How to Create an ESLint Config Package in Turborepo

Saiful Islam — Thu, 08 May 2025 13:06:14 +0000

In a growing monorepo, maintaining consistent code quality across multiple apps and packages is crucial. One powerful way to do this is by creating a shared ESLint config package. In this post, I’ll walk you through how I set up a reusable ESLint config inside a Turborepo-based monorepo — perfect for full-stack projects using TypeScript, React, and Node.js.

✅ Related: How to Create a TypeScript Config Package in Turborepo

🧩 Step-by-Step: Creating the `@dtr-cli/eslint-config` Package

1. Create a Package Folder

Inside your packages folder, create a new directory for the ESLint config package:

mkdir -p packages/eslint-config
cd packages/eslint-config
npm init -y

2. Update the `package.json` with a proper name and export map:

{
  "name": "@dtr-cli/eslint-config",
  "version": "0.0.1",
  "description": "Shared Eslint configuration for @dtr-cli",
  "license": "ISC",
  "author": "Saiful Islam <saiful.islam.rafi.88@gmail.com>",
  "exports": {
    "./base-eslint-config": "./base-eslint-config.js",
    "./backend-eslint-config": "./backend-eslint-config.js",
    "./react-eslint-config": "./react-eslint-config.js",
    "./frontend-eslint-config": "./frontend-eslint-config.js",
    "./extension-eslint-config": "./extension-eslint-config.js",
    "./ui-eslint-config": "./ui-eslint-config.js"
  },
  "files": [
    "base-eslint-config.js",
    "backend-eslint-config.js",
    "react-eslint-config.js",
    "frontend-eslint-config.js",
    "extension-eslint-config.js",
    "ui-eslint-config.js"
  ],
  "devDependencies": {
    "@eslint/js": "^9.26.0",
    "@tanstack/eslint-plugin-query": "^5.74.7",
    "eslint-config-prettier": "^10.1.3",
    "eslint-plugin-react": "^7.37.5",
    "eslint-plugin-react-hooks": "^5.2.0",
    "eslint-plugin-react-refresh": "^0.4.20",
    "eslint-plugin-turbo": "^2.5.3",
    "globals": "^16.1.0",
    "typescript-eslint": "^8.32.0"
  }
}

3. Create Base ESLint Config

`base-eslint-config.js`

This config includes basic settings for TypeScript, TurboRepo, and Prettier:

import eslintJs from "@eslint/js";
import eslintConfigPrettier from "eslint-config-prettier";
import turboPlugin from "eslint-plugin-turbo";
import tseslint from "typescript-eslint";

export const baseEslintConfig = [
  eslintConfigPrettier,
  eslintJs.configs.recommended,
  turboPlugin.configs["flat/recommended"],
  ...tseslint.configs.recommended,
  {
    languageOptions: {
      ecmaVersion: 2020,
    },
    rules: {
      "turbo/no-undeclared-env-vars": "warn",
    },
  },
];

4. Create targeted ESLint config

🔧 `backend-eslint-config.js`

import globals from "globals";
import { baseEslintConfig } from "./base-eslint-config";

export const backendEslintConfig = [
  ...baseEslintConfig,
  {
    languageOptions: {
      globals: globals.node,
    },
  },
];

⚛️ `react-eslint-config.js`

import reactEslint from "eslint-plugin-react";
import reactHooks from "eslint-plugin-react-hooks";
import reactRefresh from "eslint-plugin-react-refresh";
import globals from "globals";
import { baseEslintConfig } from "./base-eslint-config";

export const reactEslintConfig = [
  ...baseEslintConfig,
  reactEslint.configs.flat.recommended,
  reactHooks.configs["recommended-latest"],
  reactRefresh.configs.recommended,
  {
    settings: {
      react: { version: "19.1.0" },
    },
    languageOptions: {
      ecmaVersion: 2020,
      globals: globals.browser,
    },
    rules: {
      "react/react-in-jsx-scope": "off",
      "react/prop-types": "off",
      "react-refresh/only-export-components": [
        "warn",
        { allowConstantExport: true },
      ],
    },
  },
];

🧩 `frontend-eslint-config.js`

import { reactEslintConfig } from "./react-eslint-config";

export const frontendEslintConfig = [...reactEslintConfig];

🧪 `extension-eslint-config.js`

import { reactEslintConfig } from "./react-eslint-config.js";
import pluginQuery from "@tanstack/eslint-plugin-query";

export const extensionEslintConfig = [
  ...reactEslintConfig,
  ...pluginQuery.configs["flat/recommended"],
];

🎨 `ui-eslint-config.js`

import { reactEslintConfig } from "./react-eslint-config.js";

export const uiEslintConfig = [...reactEslintConfig];

Use the ESLint Config Package

In any project inside your monorepo, like apps/backend, create an eslint.config.mjs:

import { backendEslintConfig } from "@dtr-cli/eslint-config/backend-eslint-config";

/** @type {import("eslint").Linter.Config} */
export default [
  ...backendEslintConfig,
  {
    ignores: ["dist/**"],
  },
];

apps/frontend create an eslint-config.js

import { frontendEslintConfig } from "@dtr-cli/eslint-config/frontend-eslint-config";

/** @type {import("eslint").Linter.Config} */
export default [...frontendEslintConfig];

Final Thoughts

Having a centralized ESLint config package in your Turborepo setup is a massive productivity and consistency boost. Instead of rewriting and maintaining config files in every app, you can rely on one source of truth that scales with your repo.

This setup supports various contexts like backend, React apps, extensions, and UI libraries — making your developer experience smoother and your codebase cleaner.

🧩 How to Create a Reusable TypeScript Config Package in Turborepo

Saiful Islam — Thu, 08 May 2025 00:09:20 +0000

When working in a monorepo with multiple applications and packages, it's easy for your TypeScript config files to become redundant, inconsistent, or just plain messy. Fortunately, if you're using Turborepo, you can clean that up with a single, shareable TypeScript config package.

In this blog post, I’ll walk you through how to create a reusable @dtr-cli/typescript-config -- @dtr-cli is my project package, structure it for multiple project types (backend, frontend, Vite, Next.js etc.), and integrate it across your monorepo like a pro.

✅ This approach is especially helpful for developers maintaining multiple apps in a monorepo using tools like Turborepo, pnpm workspaces, or Yarn workspaces.

🧩 Step-by-Step: Creating the `@dtr-cli/typescript-config` Package

1. Create a Package Folder

Inside your packages/ folder, create a new directory called typescript-config.

mkdir -p packages/typescript-config && cd packages/typescript-config
npm init -y

2. Update the `package.json` with a proper name and export map:

{
  "name": "@dtr-cli/typescript-config",
  "version": "0.0.1",
  "description": "Shared Typescript configuration for @dtr-cli",
  "license": "ISC",
  "author": "Saiful Islam <saiful.islam.rafi.88@gmail.com>",
  "exports": {
    "./base-tsconfig.json": "./base-tsconfig.json",
    "./backend-tsconfig.json": "./backend-tsconfig.json",
    "./react-tsconfig.json": "./react-tsconfig.json",
    "./vite-node-tsconfig.json": "./vite-node-tsconfig.json"
  },
  "files": [
    "base-tsconfig.json",
    "backend-tsconfig.json",
    "react-tsconfig.json",
    "vite-node-tsconfig.json"
  ],
  "devDependencies": {
    "@types/node": "^22.15.15"
  }
}

3. Create Base and Extended Configs

Create these four config files inside your package:

`base-tsconfig.json`

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "display": "Base",
  "compilerOptions": {
    "strict": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noFallthroughCasesInSwitch": true,
    "noUncheckedSideEffectImports": true,
    "esModuleInterop": true,
    "incremental": false,
    "sourceMap": false,
    "typeRoots": ["./node_modules/@types"]
  }
}

`react-tsconfig.json`

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "extends": "./base-tsconfig.json",
  "display": "React Library",
  "compilerOptions": {
    "target": "ES2020",
    "useDefineForClassFields": true,
    "lib": ["ES2020", "DOM", "DOM.Iterable"],
    "module": "ESNext",
    "moduleResolution": "bundler",
    "allowImportingTsExtensions": true,
    "isolatedModules": true,
    "moduleDetection": "force",
    "noEmit": true,
    "jsx": "react-jsx"
  }
}

`vite-node-tsconfig.json`

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "extends": "./base-tsconfig.json",
  "display": "Vite Node",
  "compilerOptions": {
    "target": "ES2022",
    "lib": ["ES2023"],
    "module": "ESNext",
    "moduleResolution": "bundler",
    "allowImportingTsExtensions": true,
    "isolatedModules": true,
    "moduleDetection": "force",
    "noEmit": true
  }
}

🔌 Installing the Config Package

To use your shared config package in any app inside your monorepo, add it to the app's package.json:

"devDependencies": {
  "@dtr-cli/typescript-config": "workspace:*"
}

🛠️ How to Use the Configs

Backend App (`apps/backend/tsconfig.json`)

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "extends": "@dtr-cli/typescript-config/backend-tsconfig.json",
  "compilerOptions": {
    "rootDir": "./src",
    "outDir": "./dist",
    "typeRoots": ["./node_modules/@types", "./src/types"]
  },
  "include": ["./src/**/*.ts"],
  "exclude": ["node_modules", "dist"]
}

Vite app (`tsconfig.app.json`)

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "extends": "@dtr-cli/tsconfig-config/react-tsconfig.json",
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"]
    },
    "tsBuildInfoFile": "./node_modules/.tmp/tsconfig.app.tsbuildinfo"
  },
  "include": ["src"],
  "exclude": ["node_modules", "dist", "test"]
}

Vite app (`tsconfig.node.json`)

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "extends": "@dtr-cli/tsconfig-config/vite-node.json",
  "compilerOptions": {
    "tsBuildInfoFile": "./node_modules/.tmp/tsconfig.node.tsbuildinfo"
  },
  "include": ["vite.config.ts"]
}

Vite app (`tsconfig.json`)

{
  "files": [],
  "references": [
    { "path": "./tsconfig.app.json" },
    { "path": "./tsconfig.node.json" }
  ],
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}

✅ Conclusion

By creating a reusable TypeScript config package in Turborepo, you:

Maintain consistency across all your apps.
DRY up repeated tsconfig.json logic.
Make onboarding and scaling much easier.

If you're managing a modern monorepo setup, especially using TypeScript, Turborepo, and pnpm, this strategy will pay off quickly. It’s a small step that brings a lot of organization and clarity to your developer experience.

✨ Improve Your Developer Lifecycle with Husky, lint-staged, and commitlint

Saiful Islam — Wed, 30 Apr 2025 10:16:06 +0000

As a developer, especially when managing code standards, your workflow matters.

You can write great code, but if you:

forget to format it before committing,
skip linting,
or leave vague commit messages like update or fix bug

It all snowballs into a messy codebase that's hard to maintain and collaborate on.

Let me introduce you to three tools that can drastically improve your developer lifecycle:
✅ Husky
✅ lint-staged
✅ commitlint

These tools help enforce discipline and automation without slowing you down, and I've integrated them into my last project.

🔧 What is Husky?

Husky is a tool for managing Git hooks — scripts that run automatically during Git events like pre-commit, commit-msg, pre-push, etc.

Think of it as your personal assistant that runs checks or commands every time you or your teammates interact with Git.

✅ Why Use Husky?

Prevent bad code from being committed.
Run tests, lint, or format files before commits.
Block invalid commits before they reach your repo.

🎯 What is lint-staged?

lint-staged runs linters (or any command) on only the staged files (files that you’re about to commit), not your entire codebase.

✅ Why Use lint-staged?

It's super fast.
You don’t accidentally commit unformatted or buggy code.
It keeps your commits clean and atomic.

📌 Example Use Cases:

Run Prettier and ESLint only on changed files.
Validate Markdown or config files before committing.

📝 What is commitlint?

commitlint checks if your commit messages meet a defined convention, like Conventional Commits.

✅ Why Use commitlint?

Keeps commit messages consistent and meaningful.
Useful for changelogs, release automation, and team collaboration.
Helps new developers follow the project's commit rules.

🚀 Real-World Setup in My Turborepo Project

I’ve used these tools in my own Turborepo-based MERN monorepo containing:

apps/frontend (Next.js)
apps/backend (Express.js)
apps/extension
packages/ui

Let’s walk through how to configure each tool with code examples:

📁 `.lintstagedrc` Configuration

{
  "apps/backend/**/*.{js,ts}": [
    "prettier --write --config ./apps/backend/.prettierrc.mjs",
    "eslint --max-warnings 0 --config ./apps/backend/eslint.config.mjs"
  ],
  "apps/extension/**/*.{js,jsx,ts,tsx}": [
    "prettier --write --config ./apps/extension/.prettierrc.mjs",
    "eslint --max-warnings 0 --config ./apps/extension/eslint.config.js"
  ],
  "apps/frontend/**/*.{js,jsx,ts,tsx}": [
    "prettier --write --config ./apps/frontend/.prettierrc.mjs",
    "eslint --max-warnings 0 --config ./apps/frontend/eslint.config.js"
  ],
  "packages/ui/**/*.{js,jsx,ts,tsx}": [
    "prettier --write --config ./apps/frontend/.prettierrc.mjs",
    "eslint --max-warnings 0 --config ./apps/frontend/eslint.config.js"
  ],
  "*.md": ["prettier --write"]
}

📁 `.commitlintrc.json` Configuration

{
  "extends": ["@commitlint/config-conventional"],
  "rules": {
    "type-enum": [
      2,
      "always",
      [
        "ci",
        "chore",
        "docs",
        "feat",
        "fix",
        "perf",
        "refactor",
        "revert",
        "style",
        "assets",
        "test"
      ]
    ]
  }
}

✅ This enforces commit types like feat, fix, docs, chore, etc.

🔴 Invalid: updated code
✅ Valid: feat: add login screen

📁 Husky Git Hooks

You can install and enable Husky with:

pnpm dlx husky install
pnpm pkg set scripts.prepare="husky install"
git add . && git commit -m "chore: setup husky"

husky/pre-commit

npx lint-staged --allow-empty

→ Runs prettier and eslint only on staged files.

husky/commit-msg

npx --no-install commitlint --edit

npx --no-install commitlint --edit

husky/pre-push

npm run test && npm run build

→ Prevents pushing broken builds.

🧠 Summary: Why You Should Use These Tools

Husky

What it Does: Hooks into Git to run scripts
Why it Matters: Enforces quality and automation at each Git stage

Lint-staged

What it Does: Lints only changed files
Why it Matters: Keeps commits clean without slowing you down

Commitlint

What it Does: Validates commit messages
Why it Matters: Ensures consistent commit history for teams & tooling

Monorepo vs Polyrepo: Choosing the Right Structure for Your MERN Stack Project

Saiful Islam — Sun, 27 Apr 2025 22:56:23 +0000

In modern software development, project structure matters a lot. Whether you are a solo full-stack developer or working in a large team, choosing between Monorepo and Polyrepo can significantly impact your productivity and codebase management.

Today, let's dive into:

What is Monorepo and Polyrepo?
How Turborepo and pnpm workspaces help manage Monorepo?
Why solo/fullstack developers should choose Monorepo?
Why large teams often prefer Polyrepo?

🚀 What is Monorepo?

A Monorepo is a single repository that stores the code for multiple apps or packages.

Example:

apps/client (React frontend)
apps/server (Express backend)
packages/*-config (shared config. Example: typescript config, prettier config, eslint config)

✅ Advantages:

Shared code easily
Single place for versioning and dependency management
Unified CI/CD pipeline
Easy refactoring across apps

🏢 What is Polyrepo?

A Polyrepo is multiple repositories, each responsible for a separate app or service.

Example:

frontend-repo
backend-repo

✅ Advantages:

Clear separation of teams
Independent release cycles
Specific access control

⚙️ How Turborepo + pnpm Workspace Helps Monorepo

Turborepo: Smart task running, build caching, and pipeline orchestration.
pnpm Workspace: Handles dependencies between apps efficiently without duplication.
With Turborepo, you can run and build only the parts of the project that changed.
With pnpm Workspace, all dependencies are installed once, and shared efficiently.

Result: Fast, lightweight, developer-friendly Monorepo management.

👨‍💻 Which One Should You Choose?

Solo fullstack developer use monorepo
Small team of fullstack developers use monorepo
Separate frontend and backend teams use polyrepo
Independent services use polyrepo

💬 Real Talk for Fullstack Developers:

If you are building a MERN Stack project (MongoDB, Express, React, Node.js) and you are working alone as like me or with a small fullstack team — use Monorepo.

Why?

Faster local development.
Easier dependency sharing (e.g., types, API schemas).
Single PR for changes affecting frontend + backend.

"As a fullstack developer, Monorepo feels like home. Everything in one place. Easy to manage. Easy to scale."

🧱 How to Structure MERN Monorepo (Quick Example)

my-monorepo/
│
├── apps/
│   ├── client/       # React app
│   └── server/       # Express API
│
├── packages/
│   └── *-configs/       # all config packages
│
├── turbo.json
├── pnpm-workspace.yaml
└── README.md

🧠 Conclusion

Choosing between Monorepo and Polyrepo depends on your team structure and workflow.

🔵 Solo fullstack or small fullstack team → Monorepo (with Turborepo + pnpm).
🔴 Separate frontend/backend teams → Polyrepo.

Use the right structure and tools to maximize your efficiency 🚀!

Setting Up Redux in Next.js 15 with Typescript

Saiful Islam — Tue, 25 Feb 2025 13:34:42 +0000

When working with global state management in Next.js 15, integrating Redux efficiently is crucial. Instead of directly wrapping the entire app inside Provider, it's best to create a dedicated provider component that manages Redux (and other global providers). This ensures better modularity, scalability, and cleaner architecture.

In this blog, we’ll set up Redux in Next.js 15 with a structured provider approach.

1️⃣ Creating the Root Layout (`RootLayout.tsx`)

The RootLayout.tsx file is the entry point for our Next.js application. Here, we wrap the app inside a custom MainProvider, which will hold all global providers (Redux, Auth, Theme, etc.).

export default function RootLayout({
  children,
}: Readonly<{ children: React.ReactNode }>) {
  return (
    <html lang="en" className="dark" style={{ colorScheme: "dark" }}>
      <body className="antialiased w-full min-h-screen overflow-x-hidden">
        <MainProvider>{children}</MainProvider>
      </body>
    </html>
  );
}

💡 Why use MainProvider?

This approach ensures that all global providers are separated from the layout, making it easier to manage and extend.

2️⃣ Creating `MainProvider.tsx`

The MainProvider component serves as the central place to wrap all providers. Currently, it only includes ReduxProvider, but you can add Auth, Theme, or other providers later.

"use client";
import ReduxProvider from "./ReduxProvider";

const MainProvider: React.FC<{ children: React.ReactNode }> = ({ children }) => {
  return <ReduxProvider>{children}</ReduxProvider>;
};

export default MainProvider;

🚀 Modular Architecture

This approach ensures we can extend providers easily in the future without modifying RootLayout.tsx.

3️⃣ Setting Up `ReduxProvider.tsx`

Next, we create ReduxProvider.tsx, which initializes Redux and ensures the store remains persistent.

"use client";
import { useRef } from "react";
import { Provider } from "react-redux";
import { store, AppStore } from "@/lib/redux/store";

const ReduxProvider: React.FC<{ children: React.ReactNode }> = ({ children }) => {
  const storeRef = useRef<AppStore | null>(null);

  if (!storeRef.current) {
    storeRef.current = store();
  }

  return <Provider store={storeRef.current}>{children}</Provider>;
};

export default ReduxProvider;

✅ Why useRef?

We use useRef to prevent reinitializing the Redux store on every render, ensuring better performance.

4️⃣ Setting Up Redux Store (`store.ts`)

Now, let’s configure our Redux store inside lib/redux/store.ts.

import { configureStore } from "@reduxjs/toolkit";
import favoriteReducer from "./features/favorite/favoriteSlice";

export const store = () => {
  return configureStore({
    reducer: {
      favorite: favoriteReducer,
    },
  });
};

export type AppStore = ReturnType<typeof store>;
export type RootState = ReturnType<AppStore["getState"]>;
export type AppDispatch = AppStore["dispatch"];

🔥 Dynamic Store Initialization

Instead of exporting a singleton store, we use a factory function (store()), which allows Next.js server actions and middleware integration.

5️⃣ Creating Hooks for Redux (`redux.hooks.ts`)

Instead of importing useDispatch and useSelector directly, let’s create typed Redux hooks.

import { useDispatch, useSelector, useStore } from "react-redux";
import type { RootState, AppDispatch, AppStore } from "@/lib/redux/store";

export const useAppDispatch = useDispatch.withTypes<AppDispatch>();
export const useAppSelector = useSelector.withTypes<RootState>();
export const useAppStore = useStore.withTypes<AppStore>();

🛠 Typed Redux Hooks

This ensures better TypeScript support and avoids repetitive type definitions.

6️⃣ Creating a Redux Slice (`favoriteSlice.ts`)

Let’s create a Redux slice for handling favorite items inside features/favorite/favoriteSlice.ts.

import { createSlice, nanoid, type PayloadAction } from "@reduxjs/toolkit";
import { useAppSelector } from "@/hooks/redux.hooks";

interface FavoriteProductType {}

interface InitialStateType = {
  favoriteProduct: FavoriteProductType[]
};

const initialState: InitialStateType = {};

const favoriteSlice = createSlice({
  name: "favorites",
  initialState,
  reducers: {
    addFavorite: (state, action: PayloadAction<FavoriteProductType>) => {}
  },
});

export const useFavoriteProduct = () =>
  useAppSelector((state) => state.favorite);

export const { addFavorite } = favoriteSlice.actions;
export default favoriteSlice.reducer;

🛒 Scalable State Management

Using Redux slices ensures better modularity when adding new features.

Conclusion

By following this structured approach, we’ve successfully integrated Redux into Next.js 15 while keeping the architecture clean and scalable.

🔹 Key Takeaways:
✅ Use a dedicated MainProvider to wrap all global providers.
✅ Use a factory function for Redux store to allow future scalability.
✅ Create typed Redux hooks for better TypeScript support.
✅ Use useRef in ReduxProvider to prevent unnecessary reinitialization.

Now, Redux is seamlessly integrated into Next.js 15! 🚀

Previous Blogs You Might Find Useful

📌 Next.js 15 API Error Handling
📌 Zod Validation in Next.js 15

Using React Context API in Next.js 15 for Global State Management

Saiful Islam — Sun, 23 Feb 2025 14:21:02 +0000

In modern Next.js applications, state management is essential for maintaining global UI states like modals, sidebars, and theme toggles. While Redux and Zustand are powerful options, React Context API is a lightweight and built-in solution for simpler global states.

In this guide, we’ll build a global state manager in Next.js 15 using Context API and TypeScript, with a custom hook for seamless usage.

Step 1: Create a Context for Global State

We start by creating a StateContext to manage a simple open state (e.g., for a modal or sidebar):

📌 `StateContext.tsx`

"use client";
import { createContext, useCallback, useMemo, useState } from "react";

interface StateContextProps {
  open: boolean;
  handleSetOpen: VoidFunction;
}

const StateContext = createContext<StateContextProps | null>(null);

const StateContextProvider: React.FC<{ children: React.ReactNode }> = ({
  children,
}) => {
  const [open, setOpen] = useState<boolean>(false);

  const handleSetOpen = useCallback(() => setOpen((prev) => !prev), []);

  const contextValue = useMemo<StateContextProps>(
    () => ({ open, handleSetOpen }),
    [open, handleSetOpen]
  );

  return (
    <StateContext.Provider value={contextValue}>
      {children}
    </StateContext.Provider>
  );
};

export { StateContextProvider, StateContext };

🔹 Why This Works:
✅ Uses useCallback to optimize state updates.
✅ Uses useMemo to prevent unnecessary re-renders.
✅ Provides open and handleSetOpen globally.

Step 2: Create a Custom Hook for Accessing Context

Instead of using useContext(StateContext) every time, we create a custom hook to simplify access.

📌 `useStateData.tsx`

"use client";
import { StateContext } from "@/contexts/StateContext";
import { useContext } from "react";

export default function useStateData() {
  const context = useContext(StateContext);
  if (!context) {
    throw new Error("useStateData must be used within a StateContextProvider");
  }
  return context;
}

🔹 Why This is Useful:
✅ Encapsulates useContext to avoid repetitive code.
✅ Throws an error if used outside StateContextProvider.

Step 3: Implement Context in a Next.js 15 Application

Now, let’s use the context in a Next.js 15 component.

📌 `layout.tsx`

import { StateContextProvider } from "@/contexts/StateContext";

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body>
        <StateContextProvider>{children}</StateContextProvider>
      </body>
    </html>
  );
}

✅ Ensures the context is available throughout the app.

Use the Context in a Component

📌 `ToggleButton.tsx`

"use client";
import useStateData from "@/hooks/useStateData";

export default function ToggleButton() {
  const { open, handleSetOpen } = useStateData();

  return (
    <button
      onClick={handleSetOpen}
      className="px-4 py-2 bg-blue-600 text-white rounded-md"
    >
      {open ? "Close Sidebar" : "Open Sidebar"}
    </button>
  );
}

📌 `Sidebar.tsx`

"use client";
import useStateData from "@/hooks/useStateData";

export default function Sidebar() {
  const { open } = useStateData();

  return (
    <aside
      className={`fixed top-0 left-0 h-full w-64 bg-gray-900 text-white transform ${
        open ? "translate-x-0" : "-translate-x-full"
      } transition-transform`}
    >
      <p className="p-4">Sidebar Content</p>
    </aside>
  );
}

Final Integration in a Page

📌 `page.tsx`

import ToggleButton from "@/components/ToggleButton";
import Sidebar from "@/components/Sidebar";

export default function HomePage() {
  return (
    <main className="flex flex-col items-center justify-center min-h-screen">
      <ToggleButton />
      <Sidebar />
    </main>
  );
}

✅ Now, clicking the button toggles the sidebar state globally!

Final Thoughts

🚀 Why Use Context API for Global UI State?
✅ Built into React – No need for external state libraries.
✅ Works perfectly in Next.js 15.
✅ Great for UI state like modals, sidebars, and themes.

API Validation in Next.js 15 with Zod and TypeScript

Saiful Islam — Wed, 19 Feb 2025 02:45:12 +0000

In our previous blogs, we built:

A structured API response helper → serverResponse Read here
An async error-handling wrapper → serverAsyncResolve Read here

Now, let’s enhance API validation in Next.js 15 using Zod and TypeScript.

Why Use Zod for API Validation?

🚀 Zod is a TypeScript-first schema validation library that helps ensure API inputs are correctly formatted before processing.

✅ Eliminates manual validation – No need for if-else checks.
✅ Type-safe validation – Prevents unexpected runtime errors.
✅ Structured error messages – Helps frontend developers display form errors correctly.

Step 1: Define the Validation Schema

Let’s create a validation schema for a password reset request using Zod:

import { z } from "zod";

const emailValidation = z
  .string({ required_error: "Email address is required" })
  .email({ message: "Email address is required" })
  .max(80, "Email address is too long");

export const forgetPasswordSchema = z.object({
  email: emailValidation,
});

Explanation:

✔️ Requires an email → Users must enter a valid email address.
✔️ Ensures correct format → Rejects malformed email addresses.
✔️ Limits length → Prevents excessively long input.

Step 2: Handle API Requests with Validation

Now, let’s create a POST API route for password reset that:

Validates the input with Zod
Uses our serverAsyncResolve wrapper for error handling
Sends structured responses with serverResponse

import { forgetPasswordSchema } from "@/schemas/forget-password";
import { serverAsyncResolve } from "@/helpers/server-helper/serverAsyncResolve";
import { serverResponse } from "@/helpers/server-helper/serverResponse";
import { getJsonBodyData } from "@/helpers/server-helper/getJsonBodyData";

export async function POST(req: Request) {
  return serverAsyncResolve(async () => {
    const body = await getJsonBodyData<ForgetPasswordType>(req);

    const { email } = forgetPasswordSchema.parse(body);

    return serverResponse({
      success: true,
      message: "Reset password email sent",
    });
  });
}

Uses getJsonBodyData Read previous blog to extract JSON input.

🔹 Validates input using forgetPasswordSchema.parse(body).
🔹 If validation fails, it throws a ZodError, which is handled globally.

Step 3: Handling Validation Errors Globally

Instead of handling validation errors inside each API, let’s centralize error handling in serverAsyncResolve:

import type { NextResponse } from "next/server";
import type { ServerResponseType } from "@/types";
import type { ZodError } from "zod";
import validationErrors from "@/helpers/server-helper/validationErrors";
import serverResponse from "@/helpers/server-helper/serverResponse";

export default async function serverAsyncResolve<T>(
  asyncCallback: () => Promise<NextResponse<ServerResponseType<T>>>,
): Promise<NextResponse<ServerResponseType<T>>> {
  try {
    return await asyncCallback();
  } catch (err) {
    if (err instanceof ZodError) {
      return serverResponse({
        success: false,
        error: validationErrors(err),
        status: 422,
      });
    }
    if (err instanceof Error) {
      return serverResponse({
        success: false,
        error: err.message,
        status: 500,
      });
    }
    return serverResponse({
      success: false,
      error: "Something went wrong",
      status: 500,
    });
  }
}

📌 This ensures all Zod validation errors return a structured response.

Step 4: Convert Zod Errors into Readable Messages

To make Zod errors more user-friendly, we transform them into an array of ValidationError objects:

import type { ValidationError } from "@/types";
import type { ZodError } from "zod";

export default function validationErrors(error: ZodError): ValidationError[] {
  return error.errors.map((err) => ({
    field: err.path.join("."),
    message: err.message,
  }));
}

✔️ Now, frontend applications receive structured errors like:

{
  "success": false,
  "error": [
    { "field": "email", "message": "Email address is required" }
  ],
  "status": 422
}

Final Thoughts

🎯 By combining Next.js 15, Zod, and TypeScript, we achieve:

✅ Automatic request validation with Zod.
✅ Centralized error handling with serverAsyncResolve.
✅ Consistent API responses with serverResponse.

💡 Ready to implement validation in your Next.js APIs? Drop a comment and let me know how you handle validation!

Simplifying API Promise Handling in Next.js 15

Saiful Islam — Mon, 17 Feb 2025 06:57:38 +0000

In modern Next.js 15 applications, API routes often deal with asynchronous operations like database queries, authentication, and data fetching. Handling these properly requires structured error management to avoid unexpected crashes.

In our previous blogs, we built:

A structured API response helper → serverResponse Read here
A request body parser → getJsonBodyData Read here

Now, we’ll take it one step further by creating a universal API promise resolver to eliminate try-catch repetition across all API routes.

Why Use a Promise Resolver for API Routes?

❌ Without it, every API function needs a try-catch block, leading to redundant code.
❌ Error handling becomes inconsistent, making debugging harder.
❌ Missed edge cases might cause APIs to crash unexpectedly.

✅ With a reusable promise resolver, we centralize error handling, reduce boilerplate, and ensure clean API code.

Building the `serverAsyncResolve` Helper in Next.js 15

Step 1: Creating the Promise Resolver Function

Let’s build a universal try-catch wrapper for Next.js 15 API routes:

import type { NextResponse } from "next/server";
import serverResponse from "@/helpers/server-helper/serverResponse";
import type { ServerResponseType } from "@/types";

export default async function serverAsyncResolve<T>(
  asyncCallback: () => Promise<NextResponse<ServerResponseType<T>>>,
): Promise<NextResponse<ServerResponseType<T>>> {
  try {
    return await asyncCallback();
  } catch (err) {
    if (err instanceof Error) {
      switch (err.name) {
        default:
          return serverResponse({
            success: false,
            error: err.message,
            status: 500,
          });
      }
    }
    return serverResponse({
      success: false,
      error: "Something went wrong",
      status: 500,
    });
  }
}

🔹 This function wraps API logic inside a single async callback.
🔹 All errors are handled centrally, avoiding redundant try-catch blocks in multiple APIs.

Step 2: Using `serverAsyncResolve` in an API Route

Here’s an example of how to use it in a PUT request handler:

export async function PUT(req: Request) {
  return serverAsyncResolve(async () => {
    const body = await getJsonBodyData<LoginSchemaType>(req);

    return serverResponse({
      success: true,
      message: "Login successful",
      status: 200,
    });
  });
}

📌 Key Takeaways:
✔️ The API handler only focuses on business logic.
✔️ The async callback handles errors automatically.
✔️ The serverResponse function Read previous blog ensures consistent responses.

Benefits of This Approach

✅ Reduces boilerplate – No need to write try-catch in every API route.
✅ Improves error management – Centralized error handling ensures API stability.
✅ Enhances readability – API functions focus only on business logic.

By combining serverResponse, getJsonBodyData, and serverAsyncResolve, we ensure that API routes in Next.js 15 are structured, readable, and maintainable.

💡 Have you used a similar pattern in your API routes? Let me know in the comments!

Simplifying Request Body Handling in Next.js 15

Saiful Islam — Mon, 17 Feb 2025 06:25:58 +0000

When working with API routes in Next.js 15, handling different types of request payloads (JSON, FormData, and Raw text) can be frustrating. Developers often write repetitive code to extract data from req.json(), req.formData(), or req.text().

To simplify this process, we’ll create a set of utility functions that make request body handling more structured and error-proof. These functions will also integrate with the serverResponse function we built in our previous blog to maintain consistent API responses.

Why Use a Request Body Helper?

❌ Manually parsing request bodies in every API route leads to redundant code.
❌ Missing or invalid payloads can cause unexpected runtime errors.
❌ Inconsistent error messages make debugging difficult.

✅ With reusable helpers, we ensure cleaner code, standardized error handling, and better DX (Developer Experience).

Building the Request Body Helper in Next.js 15

Step 1: Creating the `ServerError` Class

First, let’s define a custom error class to handle different request body errors:

export class ServerError extends Error {
  constructor(message: string, name: string) {
    super(message);
    this.name = name;
  }
}

📌 This allows us to throw custom errors when request bodies are missing or invalid.

Step 2: Creating Utility Functions for Parsing Request Bodies

Now, we’ll write functions to handle different request body types.

import { ServerError } from "@/helpers/server-helper/ServerError";

export async function getJsonBodyData<T>(req: Request): Promise<T | null> {
  try {
    return req.json() as T | null;
  } catch {
    throw new ServerError("JSON Payload is required", "BodyError");
  }
}

export async function getFormData<T>(req: Request): Promise<T | null> {
  try {
    return req.formData() as T | null;
  } catch {
    throw new ServerError("FORM Payload is required", "BodyError");
  }
}

export async function getRawBody(req: Request): Promise<string> {
  try {
    return req.text();
  } catch {
    throw new ServerError("TEXT Payload is required", "BodyError");
  }
}

✅ Each function automatically throws an error if the required payload is missing or invalid.
✅ Works with TypeScript for better type safety.

Step 3: Integrating with the `serverResponse` Function

In our previous blog, we built a reusable serverResponse function to ensure consistent API responses. Now, let’s use it in an API route.

import serverResponse from "@/helpers/serverResponse";
import { getJsonBodyData } from "@/helpers/request-helper";

export async function POST(req: Request) {
  try {
    const body = await getJsonBodyData<{ email: string; password: string }>(req);

    if (!body || !body.email || !body.password) {
      return serverResponse({
        success: false,
        message: "Missing required fields",
        status: 400,
      });
    }

    // Simulated user creation
    const user = { id: 1, email: body.email };

    return serverResponse({
      success: true,
      message: "User created successfully",
      data: user,
      status: 201,
    });
  } catch (error) {
    return serverResponse({
      success: false,
      message: error instanceof ServerError ? error.message : "Internal Server Error",
      error: error.name || "UnknownError",
      status: 500,
    });
  }
}

📌 Now, all API routes will follow a structured error-handling pattern!

Conclusion

With this helper function setup:

✔️ Less boilerplate when handling request payloads.
✔️ Standardized error handling using ServerError.
✔️ Consistent API responses with serverResponse.

If you haven’t read the previous blog, I recommend checking it out first to see how serverResponse works!

💡 What’s your approach to handling API request payloads? Let me know in the comments!

🚀 Building a Robust API Response Helper in Next.js 15

Saiful Islam — Mon, 17 Feb 2025 05:56:37 +0000

When developing APIs in Next.js 15, structuring responses properly is crucial for consistency, debugging, and maintainability. Instead of manually crafting responses in every route, we can create a universal response helper that ensures uniformity across all API responses.

In this guide, we'll build a reusable API response helper using TypeScript, Next.js 15, and Zod for validation handling.

🔍 Why Use a Response Helper?

✅ Ensures consistency – Every API response follows the same structure
✅ Improves readability – Cleaner, more structured API responses
✅ Simplifies error handling – Centralized handling of validation and server errors
✅ Reduces redundancy – Write less repetitive response code

🛠 Creating the Response Helper

We'll create a utility function that:
✔ Returns a consistent response format
✔ Supports Zod validation errors
✔ Handles success, errors, and status codes dynamically

📌 Step 1: Define TypeScript Types

We need to define strongly typed response structures using TypeScript.

import type { ZodIssue } from "zod";

export type ValidationError = {
  field: string;
  message: string;
};

export interface ServerResponseType<T> {
  success: boolean;
  message?: string | undefined;
  error?: string | undefined | ZodIssue[] | ValidationError[];
  data?: T | undefined;
  status?: number | undefined;
}

🔹 Key Features:

✔ success: Indicates whether the request was successful
✔ message: A human-readable response message
✔ error: Supports custom validation errors or Zod validation issues
✔ data: Stores the actual response data
✔ status: Allows custom HTTP status codes

📌 Step 2: Implement the Helper Function

Now, let's create the API response helper:

import type { ServerResponseType } from "@/types";
import { NextResponse } from "next/server";

/**
 * A universal API response helper function for Next.js 15.
 * @param {ServerResponseType<T>} options - API response parameters.
 * @returns {NextResponse<ServerResponseType<T>>}
 */
export default function serverResponse<T>({
  success,
  message = undefined,
  error = undefined,
  data = undefined,
  status = 200,
}: ServerResponseType<T>): NextResponse<ServerResponseType<T>> {
  const response: ServerResponseType<T> = { success, status };

  if (message) response.message = message;
  if (error) response.error = error;
  if (data) response.data = data;

  return NextResponse.json(response, { status: response.status });
}

🔹 How It Works:

✅ Accepts a generic type <T> for flexible data handling
✅ Automatically formats the response into JSON
✅ Supports custom status codes and error messages
✅ Returns a structured API response

📌 Step 3: Using the Helper in Next.js 15 API Routes

Let's integrate this helper into an API route in Next.js 15.

✅ Example: User Registration API

Here's how we use serverResponse in a Next.js API route:

import { NextRequest } from "next/server";
import serverResponse from "@/utils/serverResponse";
import db from "@/lib/db";
import { z } from "zod";

const userSchema = z.object({
  name: z.string().min(2, "Name must be at least 2 characters"),
  email: z.string().email("Invalid email"),
  password: z.string().min(6, "Password must be at least 6 characters"),
});

export async function POST(req: NextRequest) {
  try {
    const body = await req.json();

    // Validate input data
    const validation = userSchema.safeParse(body);
    if (!validation.success) {
      return serverResponse({
        success: false,
        error: validation.error.issues,
        status: 400,
      });
    }

    // Check if user already exists
    const existingUser = await db.user.findUnique({
      where: { email: body.email },
    });

    if (existingUser) {
      return serverResponse({
        success: false,
        message: "User already exists",
        status: 409,
      });
    }

    // Create new user
    const user = await db.user.create({
      data: {
        name: body.name,
        email: body.email,
        password: body.password, // In real apps, always hash passwords!
      },
    });

    return serverResponse({
      success: true,
      data: user,
      message: "User registered successfully",
      status: 201,
    });
  } catch (error) {
    return serverResponse({
      success: false,
      message: "Internal Server Error",
      error: error instanceof Error ? error.message : undefined,
      status: 500,
    });
  }
}

🚀 Final Thoughts

With this reusable response helper, Next.js 15 API routes become cleaner, more structured, and easier to manage. It simplifies error handling, ensures consistency, and helps in debugging.

Would you use this approach in your Next.js APIs? Let me know your thoughts! 🚀

DEV Community: Saiful Islam

Setting Up PostgreSQL with Docker Compose for Development and Production

1. Folder Structure

2. Custom PostgreSQL Configuration

3. Database Initialisation with init.sql

4. Development Compose File

5. Production Compose File

6. Running PostgreSQL with NPM Scripts

7. Conclusion

useSyncExternalStore in React — The Right Way to Subscribe to External Data

⚙️ What is useSyncExternalStore?

🧩 The Hook Signature

🧠 Why Not Just Use useEffect?

💻 Example: Tracking Online/Offline Status

🧩 How It Works

⚡ Other Use Cases

🧭 Key Takeaways

🧩 Conclusion

How to Create an ESLint Config Package in Turborepo

🧩 Step-by-Step: Creating the @dtr-cli/eslint-config Package

1. Create a Package Folder

2. Update the package.json with a proper name and export map:

3. Create Base ESLint Config

base-eslint-config.js

4. Create targeted ESLint config

🔧 backend-eslint-config.js

⚛️ react-eslint-config.js

🧩 frontend-eslint-config.js

🧪 extension-eslint-config.js

🎨 ui-eslint-config.js

Use the ESLint Config Package

Final Thoughts

🧩 How to Create a Reusable TypeScript Config Package in Turborepo

🧩 Step-by-Step: Creating the @dtr-cli/typescript-config Package

1. Create a Package Folder

2. Update the package.json with a proper name and export map:

3. Create Base and Extended Configs

base-tsconfig.json

react-tsconfig.json

vite-node-tsconfig.json

🔌 Installing the Config Package

🛠️ How to Use the Configs

Backend App (apps/backend/tsconfig.json)

Vite app (tsconfig.app.json)

Vite app (tsconfig.node.json)

Vite app (tsconfig.json)

✅ Conclusion

✨ Improve Your Developer Lifecycle with Husky, lint-staged, and commitlint

🔧 What is Husky?

✅ Why Use Husky?

🎯 What is lint-staged?

✅ Why Use lint-staged?

📌 Example Use Cases:

📝 What is commitlint?

✅ Why Use commitlint?

🚀 Real-World Setup in My Turborepo Project

📁 .lintstagedrc Configuration

📁 .commitlintrc.json Configuration

📁 Husky Git Hooks

🧠 Summary: Why You Should Use These Tools

Husky

Lint-staged

Commitlint

Monorepo vs Polyrepo: Choosing the Right Structure for Your MERN Stack Project

🚀 What is Monorepo?

🏢 What is Polyrepo?

⚙️ How Turborepo + pnpm Workspace Helps Monorepo

👨‍💻 Which One Should You Choose?

💬 Real Talk for Fullstack Developers:

🧱 How to Structure MERN Monorepo (Quick Example)

🧠 Conclusion

Setting Up Redux in Next.js 15 with Typescript

1️⃣ Creating the Root Layout (RootLayout.tsx)

💡 Why use MainProvider?

2️⃣ Creating MainProvider.tsx

🚀 Modular Architecture

3️⃣ Setting Up ReduxProvider.tsx

✅ Why useRef?

4️⃣ Setting Up Redux Store (store.ts)

🔥 Dynamic Store Initialization

⚙️ What is `useSyncExternalStore`?

🧠 Why Not Just Use `useEffect`?

🧩 Step-by-Step: Creating the `@dtr-cli/eslint-config` Package

2. Update the `package.json` with a proper name and export map:

`base-eslint-config.js`

🔧 `backend-eslint-config.js`

⚛️ `react-eslint-config.js`

🧩 `frontend-eslint-config.js`

🧪 `extension-eslint-config.js`

🎨 `ui-eslint-config.js`

🧩 Step-by-Step: Creating the `@dtr-cli/typescript-config` Package

2. Update the `package.json` with a proper name and export map:

`base-tsconfig.json`

`react-tsconfig.json`

`vite-node-tsconfig.json`

Backend App (`apps/backend/tsconfig.json`)

Vite app (`tsconfig.app.json`)

Vite app (`tsconfig.node.json`)

Vite app (`tsconfig.json`)

📁 `.lintstagedrc` Configuration

📁 `.commitlintrc.json` Configuration

1️⃣ Creating the Root Layout (`RootLayout.tsx`)

💡 Why use `MainProvider`?

2️⃣ Creating `MainProvider.tsx`

3️⃣ Setting Up `ReduxProvider.tsx`

✅ Why `useRef`?

4️⃣ Setting Up Redux Store (`store.ts`)

5️⃣ Creating Hooks for Redux (`redux.hooks.ts`)

6️⃣ Creating a Redux Slice (`favoriteSlice.ts`)

📌 `StateContext.tsx`

📌 `useStateData.tsx`

📌 `layout.tsx`

📌 `ToggleButton.tsx`

📌 `Sidebar.tsx`

📌 `page.tsx`

Building the `serverAsyncResolve` Helper in Next.js 15

Step 2: Using `serverAsyncResolve` in an API Route

Step 1: Creating the `ServerError` Class

Step 3: Integrating with the `serverResponse` Function