Forem: Pramod Boda

Recommended Folder Structure for Node(TS) 2025

Pramod Boda — Fri, 19 Sep 2025 16:14:12 +0000

If you want ReactJS Folder Structure, You can get from here: Recommended Folder Structure for React 2025

A common and effective folder structure for a Node.js web application with Express in 2025 is based on the service-layered architecture or feature-based organization, which promotes separation of concerns, scalability, and maintainability.

In this article, I have explained both feature-based organization and service-layered architecture, Now by end of this article, You will choose one. I personally follow feature-based architecture. Tell me in comments which one you liked?

Now, lets see how to structure our node projects, Lets go...

Key Principles of a Modern Node.js Structure 🏗️

The goal is to move beyond a simple, monolithic app.js file and organize code into logical, reusable components. This helps with:

Scalability: The application can grow without becoming a tangled mess.
Maintainability: It's easier to find, debug, and update specific parts of the code.
Testing: Individual units of code can be tested in isolation.
Team Collaboration: Multiple developers can work on different parts of the application without conflicts.

Recommended Feature-Based Structure (I personally follow this)

Using feature-based organization is an excellent and modern approach to structuring a Node.js Express application, especially for larger projects. This method groups related files (controllers, services, models) by domain or feature rather than by type. This makes the codebase more scalable, easier to navigate, and better for team collaboration.

This structure is a direct evolution of the layered approach, organizing the same components but in a more modular way.

pramodboda-app/
├── src/
│   ├── features/
│   │   ├── auth/            # All files related to user authentication
│   │   │   ├── auth.controller.ts   # Request handlers: process input and call 'auth' services
│   │   │   ├── auth.model.ts        # Database schemas and data models of 'auth' related
│   │   │   ├── auth.route.ts        # Define API endpoints of 'auth' and map them to controllers
│   │   │   └── auth.service.ts      # Core business logic; the "brain" of the 'auth' features
│   │   │
│   │   ├── users/           # All files related to user management
│   │   │   ├── user.controller.ts   # Request handlers: process input and call 'users' services
│   │   │   ├── user.model.ts        # Database schemas and data models of 'users' related
│   │   │   ├── user.route.ts        # Define API endpoints of 'users' and map them to controllers
│   │   │   └── user.service.ts      # Core business logic; the "brain" of the 'users features
│   │   │
│   │   └── products/        # All files related to products
│   │       ├── product.controller.ts  # Request handlers: process input and call 'product' services
│   │       ├── product.model.ts       # Database schemas and data models of 'products' related
│   │       ├── product.route.ts       # Define API endpoints of 'products' and map them to controllers
│   │       └── product.service.ts     # Core business logic; the "brain" of the 'products' features
│   │
|   ├── api/                # API entry points (e.g., v1/)
│   ├── config/             # Centralized configuration files (DB, auth, etc.)
│   ├── middleware/         # Custom Express middleware (auth, logging, etc.)
│   ├── utils/              # Shared helper functions and reusable code
│   │
│   └── index.ts            # The main entry point for the application logic
|
├── tests/                  # All unit and integration tests
├── .env                    # All variable environments for App
├── .gitignore              # This file includes what are all file/ folders should not to move to your Git repo
├── package.json
├── server.ts               # Sets up and starts the server
└── tsconfig.json

Why is this a good idea?

Cohesion: All code for a specific feature (e.g., users) is located in one place, making it easy to understand and work on that feature in isolation.
Scalability: As your application grows, you simply add new folders for new features without cluttering a central controllers/ or services/ folder.
Maintainability: You can delete an entire feature folder when it's no longer needed without affecting the rest of the application.

Breakdown of Key Folders

This folder structure uses a feature-based organization, which groups all related code for a specific domain together. This approach is highly scalable and maintains a clear separation of concerns. Here's a breakdown of the key folders and files in your provided structure:

`src/` Folder

This is the main directory for your application's source code. Keeping all source files here helps keep the project root clean.

features/: This is the core of your application's modular design. Each subfolder here represents a distinct domain or "feature" of your application, like auth or users. This approach, known as Domain-Driven Design (DDD), ensures that all components related to a specific business function are co-located.
- auth/, users/, products/: These folders are your features. Each one contains the controller, model, route, and service files specific to that feature. This prevents your codebase from becoming a monolithic mess as it grows. For example, all code for managing users lives in features/users/.
  - auth.controller.ts: Handles requests related to authentication. It takes the request, validates the input, and calls the auth.service.ts to execute the business logic, then sends the response back to the client.
  - auth.model.ts: Defines the structure of your data in the database for the authentication feature (e.g., the User schema in Mongoose).
  - auth.route.ts: Defines the API endpoints for authentication (e.g., /api/auth/login, /api/auth/register) and maps them to the appropriate controller functions.
  - auth.service.ts: Contains the business logic for the feature. This is the "brain" of your feature, where complex operations like password hashing, JWT token creation, and database interactions happen. The controller simply orchestrates the service calls.
api/: A common practice for versioning your API (e.g., v1/). You could move your route files into src/api/v1/ to support multiple API versions in the future.
config/: Contains all configuration files for your application, such as database connection settings, API keys, or environment-specific variables.
middleware/: Houses all your custom Express middleware functions, which can be shared across multiple features. Examples include authentication checks, error handlers, and request loggers.
utils/: A repository for reusable helper functions that don't belong to any specific feature or layer. Examples include validation helpers, email sending functions, or general utility functions.
index.ts: The central file that sets up your Express application. It imports and applies all global middleware (like express.json() and cors) and registers all your feature routes. This file acts as a central hub for your application's logic, but it doesn't start the server itself.

Root Level Files & Folders

tests/: A dedicated folder for all your unit and integration tests. Organizing them here keeps them separate from your production code.
.env: Stores environment-specific variables. This file should never be committed to version control.
.gitignore: Specifies files and folders that Git should ignore, such as node_modules and .env.
server.ts: The entry point for your application. Its sole responsibility is to import the Express app from index.ts and start the server, listening on a specific port. This separation makes your index.ts file highly testable, as you can import the app instance without starting the server.
tsconfig.json: The configuration file for the TypeScript compiler, which defines how your TypeScript code should be compiled into JavaScript.
package.json: Manages your project's metadata and dependencies.

`server.ts` and `app.ts` (or `index.ts`)

It's a common and good practice to separate the Express application setup from the server listening part. This makes your application more testable, as you can import the Express app instance directly into your test files without needing to start a server.

`src/server.ts`

This file is the entry point for starting the server. It's minimal and only concerns itself with initializing the Express application and listening for incoming requests.

// src/server.ts
import { app } from './index'; // or './app' if you use app.ts
import { connectDB } from './config/database'; // Assuming you have a DB config

const PORT = process.env.PORT || 5000;

// Connect to the database before starting the server
connectDB();

app.listen(PORT, () => {
    console.log(`Server is running on port ${PORT}`);
});

`src/index.ts` (or `app.ts`)

This file is the core of your application. It's where you configure all your middleware, define global settings, and import and register all your feature routes.

// src/index.ts
import express from 'express';
import cors from 'cors';
import helmet from 'helmet';
import compression from 'compression';

import authRoutes from './features/auth/auth.route';
import userRoutes from './features/users/user.route';
// Import other feature routes here

export const app = express();

// Global Middleware
app.use(express.json());       // Parse JSON body
app.use(express.urlencoded({ extended: true })); // Parse URL-encoded bodies
app.use(cors());               // Enable Cross-Origin Resource Sharing
app.use(helmet());             // Secure HTTP headers
app.use(compression());        // Compress response bodies

// API Routes
app.use('/api/auth', authRoutes);
app.use('/api/users', userRoutes);
// Use other feature routes here

This separation makes the application's core logic (index.ts) highly modular and testable, while server.ts remains a simple, clean entry point for deployment.

This structure allows for a clear separation of concerns, making your application more modular, robust, and easier to maintain as it grows.

Now, the below Service-layered Folder Structure is bit common and confusion for me. If you like the Service-layered Folder Structure then use the below one:

Service-layered Folder Structure

This structure separates code by its purpose and domain, often combining elements of the Model-View-Controller (MVC) pattern with a service-layer approach.

my-web-app/
├── src/
│   ├── api/             # API entry points (e.g., v1/)
│   ├── config/          # Centralized configuration files (DB, auth, etc.)
│   ├── controllers/     # Request handlers: process input and call services
│   ├── middleware/      # Custom Express middleware (auth, logging, etc.)
│   ├── models/          # Database schemas and data models
│   ├── routes/          # Define API endpoints and map them to controllers
│   ├── services/        # Core business logic; the "brain" of the app
│   └── utils/           # Shared helper functions and reusable code
│
├── public/              # Static files (CSS, JS, images)
├── tests/               # All unit and integration tests
├── .env                 # Environment variables for local development
├── .gitignore
├── package.json
├── server.js            # Main application entry point
└── README.md

Breakdown of Key Folders

src/: This is the heart of your application. All your source code lives here, keeping the project root clean.
config/: This folder centralizes all your application configurations. Never hardcode sensitive information like API keys or database credentials. Use a .env file and a library like dotenv to manage them.
controllers/: These files are responsible for handling incoming HTTP requests. A controller's job is simple: take the request, validate the data, call the appropriate service to perform the business logic, and send a response. They should contain minimal logic.
middleware/: Store custom Express middleware here. This is where you'll put functions for things like authentication, error handling, request logging, or rate limiting.
models/: In a database-driven application, this is where you'd define your database schemas (e.g., with Mongoose for MongoDB or Sequelize for a SQL database). These models provide a structured way to interact with your data.
routes/: This folder contains the definitions of all your API endpoints. Each file should group related routes together (e.g., user.routes.js, product.routes.js). The routes file's sole purpose is to map an HTTP method and path to a controller function.
services/: This is a crucial folder that contains all your core business logic. This layer is responsible for complex operations, interacting with models, and orchestrating tasks. By separating this logic from the controllers, you make your code reusable and much easier to test.
utils/: This is a catch-all for small, reusable helper functions that don't fit into any other category. Examples include functions for password hashing, token generation, or data formatting.
public/: If your web app serves static assets, like CSS, JavaScript files, or images, put them here. This folder is typically exposed directly to the browser.
tests/: A dedicated folder for all your unit and integration tests. Organize them to mirror your src directory to make it easy to find tests for specific components.

Enjoyed this post?

Stay updated with the latest tech trends! Follow me on Instagram: @pramodboda.art and @pramodboda.codevik.
let me know your thoughts! 👇

Mastering HTTP Methods in Node.js (Express): Quick Reference Guide

Pramod Boda — Fri, 18 Jul 2025 15:20:58 +0000

HTTP Methods: Definitions & Descriptions

HTTP Method	Definition / Description
GET	Retrieve data from a server at the specified resource. It is read-only and should have no side effects (i.e., not modify data). Commonly used for fetching lists, details, or static content.
POST	Submit data to the server to create a new resource. The server processes the request and returns the new resource or a success status. Used in forms, sign-ups, data submissions.
PUT	Replace an existing resource entirely with the provided data. If the resource does not exist, some APIs may create it (though this is debated). Used for complete updates.
PATCH	Partially update an existing resource. Only the fields sent in the request are modified; others remain unchanged. More efficient than PUT for small changes.
DELETE	Remove a resource from the server. It targets a specific resource or dataset. Often used for deleting users, posts, files, etc.
HEAD	Same as `GET`, but only returns headers, not the response body. Useful for checking if a resource exists or retrieving metadata.
OPTIONS	Returns allowed HTTP methods and CORS policies for a resource. Often used in preflight requests in cross-origin setups.
TRACE	Echoes back the received request. Mostly used for debugging and testing, but generally disabled for security reasons.
CONNECT	Establishes a tunnel, typically for HTTPS connections through proxies. Rarely used in app-level programming.

Mastering HTTP Methods in Node.js (Express.js)

HTTP Method	Node.js Method (Express.js)	Usage Description	Typical Responses
GET	`app.get('/route')`	Fetch data without causing side effects.	`200 OK`, `204 No Content`, `404 Not Found`
POST	`app.post('/route')`	Submit data to create a resource.	`201 Created`, `400 Bad Request`, `409 Conflict`, `422 Unprocessable Entity`, `500 Internal Server Error`
PUT	`app.put('/route/:id')`	Update/replace a full resource.	`200 OK`, `204 No Content`, `400 Bad Request`, `404 Not Found`
PATCH	`app.patch('/route/:id')`	Partially update a resource.	`200 OK`, `204 No Content`, `400 Bad Request`, `404 Not Found`
DELETE	`app.delete('/route/:id')`	Remove a resource by ID or criteria.	`200 OK`, `204 No Content`, `404 Not Found`, `400 Bad Request`

Typical HTTP Response Codes

Code	Meaning	When to Use
`200`	OK	Request succeeded (GET, PUT, PATCH, DELETE).
`201`	Created	Resource created successfully (POST).
`204`	No Content	Success with no body returned.
`400`	Bad Request	Invalid input or request syntax.
`401`	Unauthorized	Authentication is required or failed.
`403`	Forbidden	Authenticated but not authorized.
`404`	Not Found	Resource doesn’t exist.
`409`	Conflict	Resource already exists or version conflict.
`422`	Unprocessable Entity	Validation passed structurally but failed semantically.
`500`	Internal Server Error	Unexpected error on server side.

Mastering HTTP Methods in Spring Boot: Quick Reference Guide

Pramod Boda — Mon, 09 Jun 2025 14:35:42 +0000

HTTP Methods: Definitions & Descriptions

HTTP Method	Definition / Description
GET	Retrieve data from a server at the specified resource. It is read-only and should have no side effects (i.e., not modify data). Commonly used for fetching lists, details, or static content.
POST	Submit data to the server to create a new resource. The server processes the request and returns the new resource or a success status. Used in forms, sign-ups, data submissions.
PUT	Replace an existing resource entirely with the provided data. If the resource does not exist, some APIs may create it (though this is debated). Used for complete updates.
PATCH	Partially update an existing resource. Only the fields sent in the request are modified; others remain unchanged. More efficient than PUT for small changes.
DELETE	Remove a resource from the server. It targets a specific resource or dataset. Often used for deleting users, posts, files, etc.
HEAD	Same as `GET`, but only returns headers, not the response body. Useful for checking if a resource exists or retrieving metadata.
OPTIONS	Returns allowed HTTP methods and CORS policies for a resource. Often used in preflight requests in cross-origin setups.
TRACE	Echoes back the received request. Mostly used for debugging and testing, but generally disabled for security reasons.
CONNECT	Establishes a tunnel, typically for HTTPS connections through proxies. Rarely used in app-level programming.

Mastering HTTP Methods in Spring Boot

HTTP Method	Spring Boot Annotation	Usage Description	Typical Responses
GET	`@GetMapping`	Retrieve resource(s) without modifying anything.	`200 OK`, `204 No Content`, `404 Not Found`
POST	`@PostMapping`	Create a new resource.	`201 Created`, `400 Bad Request`, `409 Conflict`, `422 Unprocessable Entity`, `500 Internal Server Error`
PUT	`@PutMapping`	Replace an existing resource entirely.	`200 OK`, `204 No Content`, `400 Bad Request`, `404 Not Found`
PATCH	`@PatchMapping`	Update a part of the existing resource.	`200 OK`, `204 No Content`, `400 Bad Request`, `404 Not Found`
DELETE	`@DeleteMapping`	Delete a resource.	`200 OK`, `204 No Content`, `404 Not Found`, `400 Bad Request`

Typical HTTP Response Codes

Code	Meaning	When to Use
`200`	OK	Request succeeded (GET, PUT, PATCH, DELETE).
`201`	Created	Resource created successfully (POST).
`204`	No Content	Success with no body returned.
`400`	Bad Request	Invalid input or request syntax.
`401`	Unauthorized	Authentication is required or failed.
`403`	Forbidden	Authenticated but not authorized.
`404`	Not Found	Resource doesn’t exist.
`409`	Conflict	Resource already exists or version conflict.
`422`	Unprocessable Entity	Validation passed structurally but failed semantically.
`500`	Internal Server Error	Unexpected error on server side.

Part 2: Building Advanced useDateFormatter Hook with dayjs, UTC & Timezone Support

Pramod Boda — Tue, 29 Apr 2025 12:06:05 +0000

Subject: Handle any date from any timezone, precisely and predictably — with the help of dayjs.

📦 Why Move Beyond Native Date Formatting?

In Part 1, we built a clean useDateFormatter hook using JavaScript’s built-in Intl.DateTimeFormat.

That works great for simple needs — but what if you need to:

Show dates in a specific timezone (e.g. always show in "Asia/Kolkata")
Format dates like YYYY-MM-DD HH:mm A
Do math like "3 days from now" or "subtract 2 hours"?

💥 That’s where dayjs shines.

🧰 Step 1: Install dayjs with Plugins

npm install dayjs
npm install dayjs-plugin-utc dayjs-plugin-timezone

Now lets build a superior useDateFormatter custom React hook to auto-detect timezone and format dates cleanly.

🧠 Step 2: Create useDateFormatter with dayjs

// hooks/useDateFormatter.ts
import { useCallback } from "react";
import dayjs from 'dayjs';
import utc from 'dayjs/plugin/utc';
import timezone from 'dayjs/plugin/timezone';

dayjs.extend(utc);
dayjs.extend(timezone);

type FormatOptions = {
  format?: string;         // e.g. 'YYYY-MM-DD HH:mm'
  timezone?: string;       // e.g. 'Asia/Kolkata'
};

export const useDateFormatter = () => {
  const formatDate = useCallback(
    (
      input: string | Date | number | null | undefined,
      options: FormatOptions = {}
    ): string => {
      if (!input) return "N/A";

      try {
        const { format = "MMM D, YYYY h:mm A", timezone = dayjs.tz.guess() } = options;

        return dayjs.utc(input).tz(timezone).format(format);
      } catch (error) {
        return "Invalid Date";
      }
    },
    []
  );

  return { formatDate };
};

🧪 Example Usage in a Component

// components/EventCard.tsx
import React from "react";
import { useDateFormatter } from "../hooks/useDateFormatter";

const EventCard: React.FC<{ startDate: string }> = ({ startDate }) => {
  const { formatDate } = useDateFormatter();

  return (
    <div>
      <h3>Event Starts</h3>
      <p>{formatDate(startDate, { timezone: "Asia/Kolkata", format: "dddd, MMM D [at] h:mm A" })}</p>
    </div>
  );
};

export default EventCard;

Even if it's just 1 line inside the helper — it's worth it.

🌏 Bonus Example – Showing in User’s Local Time

formatDate("2025-04-29T12:00:00Z", {
  format: "DD-MM-YYYY hh:mm A",
  timezone: dayjs.tz.guess(), // User's current zone
});

🧪 Output Examples

Input UTC Date	Format	Timezone	Output
2025-04-29T12:00:00Z	`"MMM D, YYYY h:mm A"`	Asia/Kolkata	`Apr 29, 2025 5:30 PM`
2025-04-29T12:00:00Z	`"YYYY-MM-DD HH:mm"`	America/New_York	`2025-04-29 08:00`

🆚 Native vs Day.js Summary

Feature	Native `Intl`	`dayjs`
Localized output	✅	✅
Timezone support	⚠️ Limited	✅ Full
Custom format strings	❌	✅
Add/subtract time	❌	✅
Parsing & validation	Basic	Strong
Lightweight	✅	✅ (~5KB with plugins)

🧼 Final Thoughts

Use native if your needs are simple and performance is key.
Use dayjs if you:

Need timezone handling
Want full control over format
Are working with global users or scheduling

✅ This is exactly how big production dashboards (admin panels, SaaS apps) build it professionally.

🧩 Missed Part 1?
👉 Go back to the Native useDateFormatter without libraries

Part 1: Stop Formatting Dates in Database!, lets Create a Reusable useDateFormatter Hook in React (with TypeScript)

Pramod Boda — Tue, 29 Apr 2025 12:05:54 +0000

Subject: Let build useDateFormatter react custom hook without any libraries only with Native JavaScript.

Have you ever seen a date like this in your app that comes from the backend?

"2024-04-29T07:30:00.000Z"

And wondered why it looks weird, or why it's showing the wrong time?
That’s because dates coming from a backend (like Node.js + PostgreSQL) are usually in ISO format, in UTC time, and not user-friendly.

🚫 The Wrong Way: Using TO_CHAR in PostgreSQL

This is what many people do in their SQL:

SELECT TO_CHAR(emp.emp_join_date, 'DD-MM-YYYY') AS emp_join_date FROM employees;

output:

"29-04-2025"

and thought, “Looks fine, right?”

👎 Nope. That format might look nice, but it breaks a lot of things in your app later.

Let’s understand why it's bad to format dates in PostgreSQL, and then fix it using a clean, reusable React useDateFormatter custom hook.

Here's why it causes real problems:

❌ Disadvantages of TO_CHAR(date, 'DD-MM-YYYY')

Problem	Why it’s bad
1. Loses Date Type	`TO_CHAR` turns your date into a plain text string. So the frontend can't sort, compare, or manipulate it like a real `Date`.
2. Not ISO/Standard	`'DD-MM-YYYY'` is not a universal format. JS expects ISO like `'2025-04-29T00:00:00Z'`. Manual parsing is needed.
3. Hard to Re-format Later	If frontend wants to show it as `April 29, 2025` or local time — you can't. It’s just a string!
4. No Time Info	You lose the hours, minutes, seconds — which might matter for logs, tickets, comments, etc.
5. No Timezone Awareness	There's no way to tell if the date was in UTC, IST, PST, etc. You risk showing wrong times to users.

✅ The Right Way: Send Raw Dates (as ISO) from Backend

Instead of this:

SELECT TO_CHAR(emp_join_date, 'DD-MM-YYYY') AS emp_join_date FROM employees;

Do this:

SELECT emp_join_date FROM employees;

Let the date stay as a proper timestamp or ISO string ("2025-04-29T00:00:00.000Z"), and then format it in React using a reusable hook.

💡 Solution 1: A fundamental approach.

🔧 The Reusable useDateFormatter React Hook

Let’s build a simple hook in TypeScript that works in any component.

// hooks/useDateFormatter.ts
import { useCallback } from "react";

type FormatOptions = Intl.DateTimeFormatOptions;

const defaultOptions: FormatOptions = {
  year: "numeric",
  month: "short",
  day: "numeric",
  hour: "2-digit",
  minute: "2-digit",
};

export const useDateFormatter = () => {
  const formatDate = useCallback(
    (
      dateInput: string | number | Date | null | undefined,
      options: FormatOptions = defaultOptions
    ): string => {
      if (!dateInput) return "N/A";

      const date = new Date(dateInput);
      if (isNaN(date.getTime())) return "Invalid Date";

      return new Intl.DateTimeFormat(undefined, options).format(date); // locale-aware
    },
    []
  );

  return { formatDate };
};

🧪 Example Usage in a Component

// components/EmployeeCard.tsx
import React from "react";
import { useDateFormatter } from "../hooks/useDateFormatter";

type Employee = {
  name: string;
  emp_join_date: string;
};

const EmployeeCard: React.FC<{ emp: Employee }> = ({ emp }) => {
  const { formatDate } = useDateFormatter();

  return (
    <div>
      <h4>{emp.name}</h4>
      <p>Joined on: {formatDate(emp.emp_join_date)}</p>
    </div>
  );
};

export default EmployeeCard;

⚡ Real-World Use Case

Imagine you're building an HR dashboard. If the date is a string like "29-04-2025", this fails:

const date = new Date("29-04-2025"); // ❌ Invalid Date in many browsers

But if you get a raw ISO date like "2025-04-29T00:00:00Z", it's perfect:

const date = new Date("2025-04-29T00:00:00Z"); // ✅ Works everywhere

Then useDateFormatter formats it for display.

When to Use Just Native `Intl.DateTimeFormat` (like the above solution1)

✅ Pros:

Zero dependencies — no need to install any libraries.
Lightweight — perfect for small apps or dashboards.
Localized formatting based on user’s browser language.
Handles common formatting needs: short/long date, time, etc. Works great for:
Showing dates like "Apr 29, 2025, 10:00 AM"
Safe fallback behavior for invalid/missing dates

❌ Cons:

Limited support for custom formats like "YYYY-MM-DD HH:mm".
Hard to manipulate dates (e.g. add/subtract days, set timezones).
Browser support for time zones via Intl.DateTimeFormat is decent, but not fully flexible like dayjs.

✅ Now you know how to format dates cleanly using native JavaScript!

But what if you need timezones, custom formats, or date math?

👉 Read Part 2: Building useDateFormatter with dayjs + timezone support

URL vs. URI

Pramod Boda — Fri, 04 Apr 2025 07:17:08 +0000

URL stands for (Uniform Resource Locator)

URI stands for (Uniform Resource Identifier)

Both URL and URI are used to identify resources on the internet, but they have distinct meanings.

URL - Uniform Resource Locator

A specific type of URI that provides the location (address) of a resource along with the means to access it.

means its a specific type of URI that tells where the resource is located and how to access it (includes a protocol like Protocol (http, https, ftp), domain, path, and sometimes query parameters., etc.).

✅ Example of URLs (all are also URIs):

https://www.google.com → Identifies and locates the Google homepage.
ftp://files.pramodboda.com/myfile.zip → Provides the file location and how to access it via FTP.
https://pramodboda.com/products?id=1234 → Identifies and locates a product page.

URI - Uniform Resource Identifier

A broader term that includes both URLs (which specify location) and URNs (which specify names without location).

means anything that uniquely identifies a resource.

Not all URIs are URLs. It can be a URL, a URN, or both.

✅ Example of a URI:

mailto:user@codevik.com → Identifies an email address but doesn’t tell how to retrieve it.
isbn:0451450523 → Identifies a book by its ISBN number (URN, not a URL).
https://pramodboda.com/portfolio-page.html → Identifies and locates a webpage (Both a URL & URI).

Example in `.env`

✅ Correct (since it's a full web address)
API_URL=http://localhost:5000/api/
DB_USER_URI=postgres
DB_HOST_URI=localhost

❌ Less accurate (but would still work)
API_URI=http://localhost:5000/api/

Simple Analogy

URL is like a full address (house number, street, city, and country).
URI is like a name (it can be an address but may also just be an identifier).

Conclusion:

Every URL is a URI because it identifies a resource.
Not every URI is a URL, as some URIs only name a resource but don’t tell how to access it.

Enjoyed this post?

Stay updated with the latest tech trends! Follow me on Instagram: @pramodboda.codevik and @pramodboda.art.

let me know your thoughts! 👇

React Router vs. React Router DOM: Key Differences Explained

Pramod Boda — Tue, 25 Feb 2025 00:25:14 +0000

react-router and react-router-dom are libraries used for routing in React applications. They allow you to create single-page applications (SPAs) where navigation between different views or pages happens without a full page reload. Here's a detailed explanation of both:

1. What is `react-router`?

react-router is the core routing library for React applications.
It provides the basic fundamental routing functionality, such as matching URLs to components and managing navigation. but it does not include anything specific to web applications.
It contains essential components like Routes, Route, and Outlet.
It is framework-agnostic, meaning it does not just depend on the web. but it can be used with React for web applications, React Native for mobile apps, or even other environments.
You don't typically install or use react-router directly in web projects.
This package is used as a foundation for other libraries like react-router-dom (for web apps) and react-router-native (for React Native apps).
Key Features:
- Declarative routing (defining routes using components).
- Dynamic routing (routes can be added or removed at runtime).
- Nested routes (routes within routes).
- Programmatic navigation (e.g., redirecting users programmatically).
Use Case:
- react-router is typically used as a dependency for other routing libraries like react-router-dom (for web) or react-router-native (for mobile).

2. What is `react-router-dom`?

react-router-dom is the official routing library for React web applications. It is built on top of react-router and provides additional components and hooks specifically designed for web development.
It provides additional web-related components like BrowserRouter, HashRouter, Link, NavLink, and hooks like useNavigate, useParams, and useLocation.
Key Features:
- BrowserRouter: Uses the HTML5 History API (pushState, replaceState, etc.) to keep the UI in sync with the URL.
- HashRouter: Uses the hash portion of the URL (e.g., #/about) for routing, which is useful for older browsers or static deployments.
- Link and NavLink: Components for creating navigation links.
- useHistory (in older versions, replaced with useNavigate in v6)
- useNavigate: A hook for programmatic navigation.
- useParams: A hook for accessing route parameters (e.g., :id in /users/:id).
- useLocation: A hook for accessing the current URL location.
Use Case:
- react-router-dom is used for building web applications with client-side routing. It is the most common choice for React web apps.

3. Key Differences Between `react-router` and `react-router-dom`

Feature	`react-router`	`react-router-dom`
Purpose	Core routing library for React	Web-specific routing library for React apps
Web/ Browser Support	No direct support	Supports web routing (`BrowserRouter`, `HashRouter`)
Components	No UI components. Basic essential routing components like `Routes`, `Route` and `Outlet`.	Web-specific components like `BrowserRouter`, `Link`, `NavLink` etc.
Hooks	Basic routing hooks	Web-specific hooks like `useNavigate`, `useLocation`, etc.
Environment	Works with React, React Native, etc.	Specifically for web applications
Dependency	Independent	Depends on `react-router`

Installation

To use react-router-dom in your project, install it via npm or yarn:

npm:

npm install react-router-dom

or with yarn:

yarn add react-router-dom

Example Usage of `react-router-dom`

Basic Routing Setup:

import React from 'react';
import { BrowserRouter as Router, Routes, Route, Link } from 'react-router-dom';
import Home from './Home';
import About from './About';
import UserProfile from './UserProfile';

function App() {
  return (
    <Router>
      <nav>
        <Link to="/">Home</Link>
        <Link to="/about">About</Link>
        <Link to="/user/123">User Profile</Link>
      </nav>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/about" element={<About />} />
        <Route path="/user/:id" element={<UserProfile />} />
      </Routes>
    </Router>);
}

export default App;

Using useNavigate for Programmatic Navigation:

import React from 'react';
import { useNavigate } from 'react-router-dom';

function LoginButton() {
  const navigate = useNavigate();

  const handleLogin = () => {
    // Perform login logic
    navigate('/dashboard'); // Redirect to the dashboard after login
  };

  return <button onClick={handleLogin}>Login</button>;
}

export default LoginButton;

Using useParams to Access Route Parameters:

import React from 'react';
import { useParams } from 'react-router-dom';

function UserProfile() {
  const { id } = useParams(); // Access the `id` parameter from the URL

  return <div>User ID: {id}</div>;
}

export default UserProfile;

4. How They Work Together?

react-router-dom is built on top of react-router. It extends the core functionality of react-router with web-specific features.
When you install react-router-dom, it automatically includes react-router as a dependency.

5. Which One Should You Use?

If you are building a React web application, use react-router-dom.
If you are creating a library or a React Native app, use react-router (along with react-router-native for mobile apps).
If you're creating a custom routing solution, you might need react-router internally.

6. What Has Changed in 2025?

React Router v6+ is now the standard, focusing on component-based routing.
Hooks like useHistory (deprecated) are fully replaced by useNavigate.
react-router is rarely used directly in web projects, while react-router-dom is the main package for web routing.

Summary

react-router: The core routing library for React.
react-router-dom: The web-specific routing library built on top of react-router.
Use react-router-dom for web applications to take advantage of web-specific features like BrowserRouter, Link, and useNavigate.

If you're building a web application, you only need to install and use react-router-dom. It will automatically include react-router as a dependency.

Recommended Folder Structure for React 2025

Pramod Boda — Fri, 21 Feb 2025 11:38:02 +0000

For a React project in 2025, a well-organized folder structure is essential for maintainability, scalability, and ease of collaboration. The structure should be modular, flexible, and adaptable to different types of projects, whether you're building a small app or a large-scale enterprise application.

Here’s an updated folder structure for modern React projects, keeping in mind best practices, scalability, and performance:

1. Root Directory

At the root of your project, you should have these typical files and directories:

/my-app
  ├── /public/
  ├── /src/
  ├── /assets/
  ├── .gitignore
  ├── package.json
  ├── README.md
  ├── tsconfig.json (for TypeScript projects)
  ├── vite.config.js (for Vite projects)
  └── .eslintrc.json (or .eslint.js)

2. Folder Structure

/public

The public folder contains static files that are served directly to the browser, such as the index.html, images, and other assets.

/public
  ├── index.html
  ├── favicon.ico
  └── /images/

/src

The src folder is where all of your React application code resides. This is where you'll spend most of your time.

/src
  ├── /assets/           # Static assets (images, fonts, etc.)
  ├── /components/       # Reusable components
  ├── /features/         # Feature-specific logic and components (could be feature folders)
  ├── /hooks/            # Custom React hooks
  ├── /layouts/          # Layout components (e.g., Header, Footer, Sidebar)
  ├── /pages/            # Page components (routes)
  ├── /services/         # API requests, utilities, external service integrations
  ├── /store/            # State management (Redux, Zustand, Context API)
  ├── /styles/           # Global styles (CSS, SASS, Styled Components)
  ├── /types/            # TypeScript types (if using TS)
  ├── /utils/            # Utility functions, helpers, and constants
  ├── /app.tsx           # App component (entry point)
  ├── /index.tsx         # Main entry point for React
  ├── /router.tsx        # Routing (React Router setup)
  └── /config/           # Environment variables and configuration files

3. Folder Details

/assets:
- Store images, fonts, and other media assets here.
- It's optional to break this into subfolders (e.g., /images, /fonts).
/components:
- Contains all reusable UI components that can be shared across different parts of your app.
- Example:
```
/components
  ├── Button.tsx
  ├── Modal.tsx
  └── Navbar.tsx
```

/features:

Organize your components, hooks, and logic by features (also called domain-based structure). This helps separate code based on functionality rather than by component type, promoting better scalability and maintainability.

Example:

/features
  ├── /auth/           # Authentication-related components, hooks, reducers
  ├── /dashboard/      # Dashboard components, hooks, etc.
  └── /profile/        # Profile-related components

/hooks:
- Store custom hooks that can be reused across your app, such as data fetching, form handling, etc.
- Example:
```
/hooks
  ├── useAuth.ts
  ├── useFetch.ts
  └── useForm.ts
```
/layouts:
- Layout components like Header, Sidebar, Footer, etc., that are used across multiple pages.
- Example:
```
/layouts
  ├── MainLayout.tsx
  ├── AdminLayout.tsx
  └── DashboardLayout.tsx
```

/pages:

Contains page-level components (typically mapped to routes) that use the components from /features or /components.

Example:

/pages
    ├── Auth/
    │   └── SignInPage.tsx
    │   └── SignUpPage.tsx
  ├── Dashboard.tsx
  ├── Home.tsx
  ├── Users.tsx
  ├── Prodcuts.tsx
  └── ContactUs.tsx

/services:
- Functions for API requests, integrating third-party services, or utilities that handle external communication.
- This could also be the place for service hooks or API-related logic.
- Example:
```
/services
  ├── authService.ts   # Authentication API
  └── apiService.ts    # General API calls
```

/store:

If you’re using a state management solution like Redux, Zustand, or Context API, keep the logic and actions here.

Example (if using Redux):

/store
  ├── /auth/          # Auth-related Redux slices
  ├── /user/          # User-related Redux slices
  └── store.ts        # Global store configuration

/styles:

Store global styles, theme files, or any CSS/SASS or CSS-in-JS styles here.

Example:

/styles
  ├── index.css
  ├── theme.ts        # For theme configuration in styled-components
  └── global.scss     # Global styles for the app

/types:

If using TypeScript, store your custom types or interfaces here for easier management and reusability.

Example:

/types
  ├── auth.d.ts       # Types for authentication-related data
  ├── api.d.ts        # Types for API responses
  └── user.d.ts       # Types for user objects

/utils:
- General utility functions that are used across your app (e.g., date formatting, data validation, etc.).
- Example:
```
/utils
  ├── formatDate.ts
  └── validateEmail.ts
```

/config:

Store environment variables or app configuration settings here, such as the API base URL, feature flags, etc.

Example:

/config
  ├── index.ts        # Export environment variables and configurations
  ├── config.ts       # Configuration file for app set

Conclusion

This folder structure provides a flexible, scalable, and maintainable setup for React applications in 2025. It focuses on:

Modularity: Organizing by features or domains (vs. just by components).
Reusability: Components, hooks, and utilities can be easily shared.
Scalability: As your project grows, the structure allows for easy addition of new features or pages.
Separation of Concerns: Each part of the app (state, services, components) has its own dedicated space.

This structure works for both small projects and large-scale applications. You can always adjust the specifics depending on the complexity and requirements of your app.

Enjoyed this post?

Stay updated with the latest tech trends! Follow me on Instagram: @pramodboda.codevik and @pramodboda.art.
let me know your thoughts! 👇

Forem: Pramod Boda

Recommended Folder Structure for Node(TS) 2025

Key Principles of a Modern Node.js Structure 🏗️

Recommended Feature-Based Structure (I personally follow this)

Breakdown of Key Folders

src/ Folder

Root Level Files & Folders

server.ts and app.ts (or index.ts)

src/server.ts

src/index.ts (or app.ts)

Service-layered Folder Structure

Breakdown of Key Folders

Enjoyed this post?

Mastering HTTP Methods in Node.js (Express): Quick Reference Guide

HTTP Methods: Definitions & Descriptions

Mastering HTTP Methods in Node.js (Express.js)

Typical HTTP Response Codes

Mastering HTTP Methods in Spring Boot: Quick Reference Guide

HTTP Methods: Definitions & Descriptions

Mastering HTTP Methods in Spring Boot

Typical HTTP Response Codes

Part 2: Building Advanced useDateFormatter Hook with dayjs, UTC & Timezone Support

📦 Why Move Beyond Native Date Formatting?

🧰 Step 1: Install dayjs with Plugins

🧠 Step 2: Create useDateFormatter with dayjs

🧪 Example Usage in a Component

🧪 Output Examples

🆚 Native vs Day.js Summary

🧼 Final Thoughts

Part 1: Stop Formatting Dates in Database!, lets Create a Reusable useDateFormatter Hook in React (with TypeScript)

🚫 The Wrong Way: Using TO_CHAR in PostgreSQL

❌ Disadvantages of TO_CHAR(date, 'DD-MM-YYYY')

✅ The Right Way: Send Raw Dates (as ISO) from Backend

💡 Solution 1: A fundamental approach.

🔧 The Reusable useDateFormatter React Hook

🧪 Example Usage in a Component

⚡ Real-World Use Case

When to Use Just Native Intl.DateTimeFormat (like the above solution1)

URL vs. URI

URL - Uniform Resource Locator

URI - Uniform Resource Identifier

Example in .env

Simple Analogy

Conclusion:

Enjoyed this post?

React Router vs. React Router DOM: Key Differences Explained

1. What is react-router?

2. What is react-router-dom?

3. Key Differences Between react-router and react-router-dom

Installation

Example Usage of react-router-dom

4. How They Work Together?

5. Which One Should You Use?

6. What Has Changed in 2025?

Summary

Recommended Folder Structure for React 2025

1. Root Directory

2. Folder Structure

3. Folder Details

Conclusion

Enjoyed this post?

`src/` Folder

`server.ts` and `app.ts` (or `index.ts`)

`src/server.ts`

`src/index.ts` (or `app.ts`)

When to Use Just Native `Intl.DateTimeFormat` (like the above solution1)

Example in `.env`

1. What is `react-router`?

2. What is `react-router-dom`?

3. Key Differences Between `react-router` and `react-router-dom`

Example Usage of `react-router-dom`