DEV Community: Blogs World

React App Works Locally but Not on Vercel? A Production Checklist

Blogs World — Fri, 21 Aug 2026 12:50:23 +0000

npm run dev works. The production build finishes. Vercel shows a reassuring green Ready label.

Then somebody refreshes /dashboard and gets a 404.

Or the page opens, but login does nothing. The API request is still going to localhost. An image that looked fine on your laptop has disappeared. None of these failures feels related to deployment because, technically, the deployment succeeded.

That green label proves Vercel built and published something. It does not prove that every route, environment variable, browser request, and authentication assumption survived the move to production.

The short answer

If a React app works locally but fails on Vercel, check these in this order:

Run the production build locally.
Confirm the project root, build command, and output directory.
Test a direct visit and refresh on every client-side route.
Check environment-variable names, values, and deployment scope.
Inspect the real API URL, HTTPS, CORS, and cookie settings.
Look for filename-case and asset-path differences.
Read the browser's first Console or Network error before changing configuration.

The order matters. Changing the framework preset will not repair a CORS policy, and adding a rewrite will not install a missing package.

First, separate “deployed” from “working”

A deployment pipeline can answer a few useful questions:

Could it install the dependencies?
Did the build command exit successfully?
Was there an output directory to publish?

It cannot automatically confirm that a user can sign in, that the API accepts the production origin, or that React Router can recover after a hard refresh.

Before debugging in the dashboard, I would reproduce the production build locally:

npm ci
npm run build

For a Vite project, inspect that build with:

npm run preview

For an older Create React App project, you can serve the generated folder locally:

npx serve -s build

This is a better test than npm run dev. Development servers are forgiving. Production builds are much less interested in forgiving a missing dependency, a bad import, or a filename whose capitalization is wrong.

If you are still at the initial setup stage, this step-by-step guide to deploying a React app on Vercel covers the complete GitHub import flow, framework settings, environment variables, SPA routing, and common deployment errors. Here, I want to stay with the awkward part that begins after Vercel says the app is ready.

Three settings quietly control the whole build

Most React deployment problems are not mysterious. Vercel is simply looking in one place while the app is building in another.

Project setup	Build command	Normal output directory
Vite + React	`npm run build`	`dist`
Create React App	`npm run build`	`build`
React app inside a monorepo	Usually `npm run build`	Depends on the selected app and its configuration

The monorepo case is where this becomes easy to miss. If the repository looks like this:

company-project/
├── api/
├── docs/
└── apps/
    └── web/
        ├── package.json
        ├── src/
        └── vite.config.js

then apps/web is the project root. Pointing Vercel at company-project may leave it searching for the wrong package.json or running the correct command from the wrong directory.

There is one more wrinkle: dist is only Vite's default. If vite.config.js contains a custom build.outDir, the Vercel output directory has to match it.

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [react()],
  build: {
    outDir: 'public-app'
  }
})

That app produces public-app, not dist. The setting is not wrong; the two sides just need to agree.

The home page works, but `/account` does not

This failure is almost a rite of passage with a client-side React app.

Clicking from / to /account works because React Router is already running in the browser. Refreshing /account is different. The browser asks the server for /account, and a static host may look for a real file at that path. There is no such file, so the server returns 404 before React gets a chance to render anything.

For a frontend-only Vite single-page application using browser history, add a vercel.json file at the project root:

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "rewrites": [
    {
      "source": "/(.*)",
      "destination": "/index.html"
    }
  ]
}

Commit the file and deploy again. The browser keeps the requested URL, Vercel serves index.html, and the client-side router decides which screen belongs there.

Do not paste a catch-all rewrite into every repository without looking at its architecture. A project that also contains API routes, server-rendered pages, or other separately served paths may need a more specific routing rule. Vercel's Vite deployment documentation is the right reference for the current SPA behavior.

My route test is deliberately boring: paste a nested production URL into a new private window, open it directly, and refresh it twice. Navigation from the home page is not the same test.

An environment variable can be present and still be wrong

There are four separate ways an environment variable can fail:

The name does not match the build tool.
The value belongs to local development.
It was added to Preview but not Production, or the reverse.
It was changed after the current deployment was built.

Vite exposes browser variables through import.meta.env, normally with a VITE_ prefix:

VITE_API_BASE_URL=https://api.example.com

const apiBaseUrl = import.meta.env.VITE_API_BASE_URL

An existing Create React App project uses the older convention:

REACT_APP_API_BASE_URL=https://api.example.com

const apiBaseUrl = process.env.REACT_APP_API_BASE_URL

Those conventions are not interchangeable.

There is also a security trap hidden in the friendly phrase “environment variable.” A VITE_* value used by client-side code is bundled into JavaScript and can be inspected by anyone using the site. Vite's environment-variable guide is explicit about this. Public API base URLs and browser-safe identifiers are fine; database passwords, service-role keys, private payment credentials, and similar secrets are not.

Keep privileged values on a backend or server-side function.

Finally, changing a variable in the Vercel dashboard does not rewrite a bundle that has already been deployed. Build a new deployment after the change, and check whether you edited the Production, Preview, or Development value.

Sometimes the React app is innocent

Open the deployed site, launch DevTools, and look at the failed request in the Network panel. The actual URL usually tells a better story than the UI.

The request still points to localhost

This will never reach the backend on your laptop:

http://localhost:3000/api/products

For every visitor, localhost means that visitor's own device. Replace it with the deployed HTTPS API URL through the correct environment variable.

The page is HTTPS but the API is HTTP

Browsers can block active mixed content. If the frontend is served over HTTPS, the production API should be available over HTTPS too.

The API rejects the Vercel origin

That is a backend CORS decision, not a React build failure. Add the exact production frontend origin to the API's allowed origins. If preview deployments also need API access, decide how those changing preview origins will be handled rather than opening the API to every origin by reflex.

Using cookies? Check Secure, SameSite, the cookie domain, credentialed CORS headers, and whether the browser actually stored the cookie. A response can return 200 while the next authenticated request still fails because the browser rejected the session cookie.

This is why “the API works in Postman” is useful but incomplete. Postman is not enforcing the browser's CORS and cookie rules.

The capitalization bug that waits for production

Some local filesystems treat Header.jsx and header.jsx as though they are the same filename. A Linux build environment does not have to be so generous.

import Header from './components/header'

If the real file is Header.jsx, make the import match exactly:

import Header from './components/Header'

The same issue appears with public assets. /Logo.png and /logo.png are different paths on a case-sensitive system. When only one image or module fails, compare the requested path with the repository filename character by character.

Also confirm that the missing file was committed. Git cannot deploy an image that only exists in your local working directory.

Preview deployments are more than disposable links

Once Git is connected, a branch push can create a Preview deployment while the production branch continues serving the current release. That is useful only if the preview is tested as a real environment.

A sensible flow is:

Push the change to a feature branch.
Let Vercel create the Preview deployment.
Test direct routes, authentication, API calls, and browser errors there.
Merge only after those checks pass.
Verify the new Production deployment once more.

Vercel documents the branch behavior in its Git deployment guide. For applications that can charge cards, send messages, modify customer data, or perform admin actions, point Preview at a staging backend or test account. A hard-to-guess preview URL is not a security boundary.

A five-minute production check

After every meaningful deployment, I would test these before sharing the link:

Open the home page in a private window.
Paste a nested route directly into the address bar and refresh it.
Complete one real sign-in and sign-out cycle.
Trigger one representative API read and, where safe, one write.
Look for the first red Console error.
Inspect failed Network requests and their full URLs.
Check one narrow mobile viewport.
Confirm that Production is using the intended environment values.

It is a small checklist, but it catches more than staring at a green deployment card ever will.

Diagnose by symptom, not by guesswork

What you see	Likely area	First place to look
Build fails	Dependency, import, Node version, or build script	Earliest relevant build-log error and local `npm run build`
Deployment is ready but the page is blank	Runtime JavaScript or missing configuration	Browser Console
`/` works but refreshing `/dashboard` returns 404	SPA fallback routing	`vercel.json` and direct-route test
Requests go to `localhost`	Production API variable	Network request URL
Browser reports a CORS error	Backend origin policy	API CORS configuration
Images fail only in production	Case mismatch or asset path	Requested URL and repository filename
Preview works but Production fails	Environment scope or branch configuration	Production variables and production branch

The first error is normally more valuable than the tenth. Later errors are often just consequences of the first failed import, request, or initialization step.

Frequently asked questions

Do I need to upload the `dist` folder to Vercel?

Not for a normal Git-based deployment. Commit the source code, package.json, and the correct lock file. Vercel installs dependencies, runs the build command, and publishes the generated output. Generated folders such as dist, build, and node_modules are normally ignored.

Why did changing a Vercel environment variable do nothing?

Client-side Vite variables are inserted when the app is built. Redeploy after changing the value, and make sure the variable was added to the environment—Preview or Production—used by that deployment.

Why does React Router work when I click a link but fail after refresh?

Client-side navigation happens after React has loaded. A refresh sends the nested path to the server first. A static SPA needs a fallback rewrite so the server returns index.html and React Router can handle the URL.

Can the React frontend and API use different hosting providers?

Yes. Use the API's deployed HTTPS address and configure the backend to accept the frontend's production origin. Cross-site authentication may also require deliberate cookie and CORS settings.

Is Vercel a good host for every React project?

It is a strong fit for many Vite SPAs, frontend dashboards, prototypes, and applications built for supported serverless or framework patterns. A traditional long-running Express server, background worker, persistent WebSocket process, or content-heavy site needing server rendering has different requirements and should be evaluated separately.

“Ready” is the start of verification

A reliable React deployment is a small contract: the repository supplies a repeatable build, Vercel publishes the correct output, the router can recover on direct requests, the frontend receives the right public configuration, and the backend accepts requests from the deployed origin.

When one part of that contract breaks, start with evidence. Build locally. Open the first browser error. Read the failed request URL. Change one verified cause at a time.

That approach is slower than random dashboard edits for about thirty seconds. After that, it is much faster.

_Disclosure: This article was prepared with AI assistance. Its technical examples were checked against the linked Vercel and Vite documentation.

Java’s `this` keyword helps distinguish fields from parameters, chain constructors, and reference the current object. Practical examples: https://www.blogs-world.in/blog/understanding-the-this-keyword-in-java-a-comprehensive-guide/

Blogs World — Tue, 18 Aug 2026 08:08:08 +0000

Mastering this in Modern Java — 2026 Developer Playbook

Master the this keyword in Java with clear examples, best practices, and advanced tips for cleaner, bug-free code. Boost your Java skills today!

blogs-world.in

I Kept Reaching for Redux by Default. One Question Fixed That

Blogs World — Tue, 18 Aug 2026 07:50:31 +0000

There's a specific kind of shame that comes from opening a pull request review and seeing npm install @reduxjs/toolkit react-redux as the first line of the diff, for a feature that turned out to be a dropdown and a boolean.

I did that more than once. Not because I didn't understand Redux. Because I didn't have a real test for when not to reach for it, so I defaulted to the tool that felt "serious."

The habit nobody tells you to unlearn

Early in my React years, the advice I absorbed from tutorials was basically: small app, use useState. Big app, use Redux. That's a size-based rule, and size is a terrible proxy for what actually matters, which is how the state behaves, not how many files your project has.

A five-screen internal tool with a workflow editor, undo history, and three roles fighting over permissions? That probably wants Redux. A forty-page marketing site with a theme toggle and a mobile nav state? That's Context, maybe not even that.

I learned this the slow way, on a dashboard project where I'd wired notification counts, a selected-workspace value, and a live job feed all into one AppContext. It worked fine in the demo. Then someone added a fourth thing to that context, a component three levels down started re-rendering on every WebSocket tick, and I spent an afternoon staring at React DevTools trying to figure out why a settings icon was blinking every two seconds like it had a heartbeat.

What actually separates the two tools

Here's the reframe that fixed it for me, and it's less "which library" and more "what job is this state doing."

Context is a plumbing solution. It moves a value down the tree without prop drilling. That's it. It doesn't care where the value came from or how it changes — you could feed it a useState, a useReducer, or a hardcoded object, and Context wouldn't know the difference.

Redux is an architecture. Actions, reducers, a single store, a predictable flow of "this happened → here's the new state." You get that structure whether you need it or not, and for small, cohesive values, that structure is overhead, not help.

So the actual decision isn't Context vs Redux. It's closer to:

useState / useReducer + Context
        vs.
Redux Toolkit + selectors

Once I started asking "does this state need an architecture, or does it just need to reach three components without fifteen props," most of my choices got obvious fast.

A quick gut-check I actually use now

Three questions, roughly in this order:

Who owns this? One feature tree, or does it get read/written across totally unrelated routes?
How does it change? A handful of clean transitions, or a tangle of business rules that touch five other pieces of state?
Who's subscribing? Do consumers basically all need "the same thing," or does one tiny badge need to react to a firehose of updates without the rest of the screen re-rendering?

If the answers land on "one feature, simple transitions, everyone wants the same value" — Context, and honestly probably just useReducer + Context, no extra library required.

If it's "read everywhere, complicated rules, and only slivers of it change independently" — that's where Redux Toolkit's selector model starts paying for its setup cost.

The mistake I don't make anymore

I used to think memoizing everything in a context provider was the fix for re-render pain. useMemo on the value, useCallback on every handler, wrap, wrap, wrap. It helps with accidental identity changes — a new object reference on every render for no reason — but it can't give you the thing Redux's useSelector gives you for free: a component subscribing to one slice of a much bigger state tree.

Memoization fixes noise. It doesn't fix architecture. If you're three layers of useMemo deep just to stop unrelated components from updating, that's usually a sign the state itself is trying to tell you something — probably that it's outgrown Context, or that it was never one cohesive value in the first place and needs splitting into separate providers.

That second one, by the way, is underrated as a fix. Before reaching for Redux, try just... splitting the context. A ThemeContext and a NotificationsContext and a WorkspaceContext instead of one AppContext solves a surprising number of "why is everything re-rendering" problems on its own.

Where I landed

These days my default order looks something like: local state first, always — don't be the person adding global anything for two props. Context next, for stuff that's genuinely shared but genuinely simple. Redux Toolkit only once I can point at real coordination complexity — multiple features reacting to the same event, selectors doing real work, or a debugging need that "just add a console.log" won't satisfy anymore.

And API data doesn't go in either bucket, honestly. That's a separate problem — caching, refetching, staleness — that neither Context nor a hand-rolled Redux slice handles well without a lot of extra plumbing you're better off not building yourself.

I went looking for a writeup that laid out the decision framework more rigorously than my "vibes and a bad afternoon" version, and found a genuinely thorough one — includes a full decision framework, side-by-side code for both approaches, and a section specifically on the failure modes (the universal-context trap, memoizing a design problem instead of fixing it, stuffing every form input into Redux) that I definitely lived through firsthand. Worth the read if you're mid-decision on a real feature right now: React Context API vs Redux: When to Use Each.

If you've got your own "I reached for the wrong tool and paid for it" story, I'd genuinely like to hear it in the comments. Misery loves company, and also I collect these for the next time I'm tempted to npm install my way out of a design decision.

Build a Maintainable Node.js CRUD API with Express and MySQL

Blogs World — Fri, 07 Aug 2026 07:34:52 +0000

Writing SELECT, INSERT, UPDATE, and DELETE queries is not the difficult part of a CRUD API. The difficulty begins when every route starts handling SQL, input validation, HTTP status codes, and error formatting at the same time.

That version may work for five endpoints. It becomes unpleasant when you add authentication, pagination, related tables, or a second developer.

In this tutorial, we will build a Node.js REST API with Express and MySQL while keeping each responsibility in a predictable place. The result uses plain JavaScript, a small dependency set, prepared queries, a shared connection pool, request validation, and centralized error responses.

For a more detailed file-by-file walkthrough, including additional explanations and production considerations, see the original Node.js Express REST API CRUD tutorial with MySQL.

The API Contract Comes First

Our resource is a product with a name, optional description, price, and stock count. Before creating files, define how clients will interact with it.

Method	Path	Result
`GET`	`/api/products`	Return all products
`GET`	`/api/products/:id`	Return one product
`POST`	`/api/products`	Create a product
`PATCH`	`/api/products/:id`	Change selected fields
`DELETE`	`/api/products/:id`	Delete a product

The update route uses PATCH because it accepts partial input. A client can send only { "stock": 18 } without resubmitting the name, description, and price.

Successful responses use a data property:

{
  "data": {
    "id": 1,
    "name": "Mechanical Keyboard"
  }
}

Errors have a stable shape:

{
  "error": {
    "code": "PRODUCT_NOT_FOUND",
    "message": "Product not found"
  }
}

That consistency is part of the API contract. Frontend code should not need to guess whether a failure will be JSON, HTML, a stack trace, or a raw database message.

Create the Project

Initialize the project and install the dependencies:

mkdir express-mysql-products-api
cd express-mysql-products-api

npm init -y
npm install express mysql2 dotenv

npm pkg set scripts.start="node src/server.js"
npm pkg set scripts.dev="node --watch src/server.js"

Use this structure:

express-mysql-products-api/
├── src/
│   ├── config/
│   │   └── database.js
│   ├── controllers/
│   │   └── product.controller.js
│   ├── errors/
│   │   └── AppError.js
│   ├── middleware/
│   │   ├── errorHandler.js
│   │   └── productValidation.js
│   ├── models/
│   │   └── product.model.js
│   ├── routes/
│   │   └── product.routes.js
│   ├── app.js
│   └── server.js
├── .env
├── .env.example
├── .gitignore
└── schema.sql

The structure is intentionally small. It separates HTTP routing, request handling, validation, and SQL without adding an ORM or a large framework.

Let MySQL Enforce Basic Data Rules

Create schema.sql:

CREATE DATABASE IF NOT EXISTS node_crud
  CHARACTER SET utf8mb4
  COLLATE utf8mb4_unicode_ci;

CREATE USER IF NOT EXISTS 'node_api'@'localhost'
  IDENTIFIED BY 'local_development_password';

GRANT SELECT, INSERT, UPDATE, DELETE
  ON node_crud.*
  TO 'node_api'@'localhost';

USE node_crud;

CREATE TABLE IF NOT EXISTS products (
  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  name VARCHAR(120) NOT NULL,
  description TEXT NULL,
  price DECIMAL(10, 2) NOT NULL,
  stock INT NOT NULL DEFAULT 0,
  created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  updated_at TIMESTAMP NOT NULL
    DEFAULT CURRENT_TIMESTAMP
    ON UPDATE CURRENT_TIMESTAMP,

  PRIMARY KEY (id),
  CONSTRAINT chk_product_price CHECK (price >= 0),
  CONSTRAINT chk_product_stock CHECK (stock >= 0)
);

Run the schema using an account with permission to create databases and tables:

mysql -u root -p < schema.sql

The database constraints are the final protection against invalid data. They do not replace API validation, because a MySQL constraint error is not a useful response for an API consumer.

The price column uses DECIMAL, not FLOAT. MySQL stores decimal values exactly, while JavaScript numbers use floating-point representation. The mysql2 driver returns DECIMAL values as strings by default to avoid silently changing their precision.

Keep Secrets Out of the Source Code

Create .env:

PORT=3000
NODE_ENV=development

DB_HOST=localhost
DB_PORT=3306
DB_USER=node_api
DB_PASSWORD=local_development_password
DB_NAME=node_crud

Your application account must exist and have SELECT, INSERT, UPDATE, and DELETE permission on node_crud. Use a separate administrative account for schema changes.

Add this .gitignore:

node_modules/
.env
npm-debug.log*

Commit .env.example with the same variable names, but do not commit real production credentials.

Share a MySQL Connection Pool

Create src/config/database.js:

const mysql = require('mysql2/promise');

const pool = mysql.createPool({
  host: process.env.DB_HOST,
  port: Number(process.env.DB_PORT) || 3306,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  database: process.env.DB_NAME,
  waitForConnections: true,
  connectionLimit: 10,
  queueLimit: 0
});

async function verifyDatabase() {
  await pool.query('SELECT 1');
}

module.exports = {
  pool,
  verifyDatabase
};

Create one pool for the process and share it across models. Opening a fresh database connection inside every route adds latency and can exhaust the server's connection limit under load.

Pool sizing is a deployment decision. Ten connections may be reasonable locally, but five application instances could open up to fifty connections. Compare the total with the database server's limit instead of increasing the number by instinct.

Make the Model the Only Layer That Knows SQL

Create src/models/product.model.js:

const { pool } = require('../config/database');

const selectedColumns = `
  id,
  name,
  description,
  price,
  stock,
  created_at AS createdAt,
  updated_at AS updatedAt
`;

async function findAll() {
  const [rows] = await pool.execute(`
    SELECT ${selectedColumns}
    FROM products
    ORDER BY id DESC
  `);

  return rows;
}

async function findById(id) {
  const [rows] = await pool.execute(
    `SELECT ${selectedColumns}
     FROM products
     WHERE id = ?`,
    [id]
  );

  return rows[0] || null;
}

async function create(product) {
  const [result] = await pool.execute(
    `INSERT INTO products (name, description, price, stock)
     VALUES (?, ?, ?, ?)`,
    [
      product.name,
      product.description,
      product.price,
      product.stock
    ]
  );

  return findById(result.insertId);
}

async function update(id, changes) {
  const columns = {
    name: 'name',
    description: 'description',
    price: 'price',
    stock: 'stock'
  };

  const entries = Object.entries(changes).filter(
    ([field]) => columns[field]
  );

  if (entries.length === 0) {
    return findById(id);
  }

  const assignments = entries.map(
    ([field]) => `${columns[field]} = ?`
  );

  const values = entries.map(([, value]) => value);
  values.push(id);

  const [result] = await pool.execute(
    `UPDATE products
     SET ${assignments.join(', ')}
     WHERE id = ?`,
    values
  );

  if (result.affectedRows === 0) {
    return null;
  }

  return findById(id);
}

async function remove(id) {
  const [result] = await pool.execute(
    'DELETE FROM products WHERE id = ?',
    [id]
  );

  return result.affectedRows > 0;
}

module.exports = {
  findAll,
  findById,
  create,
  update,
  remove
};

All request values are bound through ? placeholders. The update column names cannot use placeholders, so they come from the fixed columns map. Never insert an arbitrary request key directly into an SQL string.

The model does not know anything about response status codes. It returns a product, a list, null, or a boolean. The controller will translate those outcomes into HTTP responses.

Validate IDs and Request Bodies at the Boundary

Create src/middleware/productValidation.js:

const allowedFields = ['name', 'description', 'price', 'stock'];

function validateId(req, res, next) {
  const { id } = req.params;

  if (!/^[1-9]\d*$/.test(id) || !Number.isSafeInteger(Number(id))) {
    return res.status(400).json({
      error: {
        code: 'INVALID_PRODUCT_ID',
        message: 'Product ID must be a positive integer'
      }
    });
  }

  req.productId = Number(id);
  next();
}

function validateProduct({ partial = false } = {}) {
  return function validate(req, res, next) {
    const body = req.body || {};
    const errors = {};
    const values = {};
    const fields = Object.keys(body);
    const has = (field) =>
      Object.prototype.hasOwnProperty.call(body, field);

    const unknown = fields.filter(
      (field) => !allowedFields.includes(field)
    );

    if (unknown.length > 0) {
      errors.body = `Unknown fields: ${unknown.join(', ')}`;
    }

    if (partial && fields.length === 0) {
      errors.body = 'Provide at least one field to update';
    }

    if (!partial || has('name')) {
      if (typeof body.name !== 'string' || body.name.trim() === '') {
        errors.name = 'Name is required';
      } else if (body.name.trim().length > 120) {
        errors.name = 'Name cannot exceed 120 characters';
      } else {
        values.name = body.name.trim();
      }
    }

    if (has('description')) {
      if (
        body.description !== null &&
        typeof body.description !== 'string'
      ) {
        errors.description = 'Description must be text or null';
      } else {
        values.description =
          body.description === null ? null : body.description.trim();
      }
    } else if (!partial) {
      values.description = null;
    }

    if (!partial || has('price')) {
      const price = String(body.price ?? '').trim();

      if (!/^\d{1,8}(\.\d{1,2})?$/.test(price)) {
        errors.price = 'Price must be a non-negative decimal';
      } else {
        values.price = Number(price).toFixed(2);
      }
    }

    if (has('stock')) {
      const stock = Number(body.stock);

      if (
        body.stock === '' ||
        body.stock === null ||
        !Number.isInteger(stock) ||
        stock < 0
      ) {
        errors.stock = 'Stock must be a non-negative integer';
      } else {
        values.stock = stock;
      }
    } else if (!partial) {
      values.stock = 0;
    }

    if (Object.keys(errors).length > 0) {
      return res.status(422).json({
        error: {
          code: 'VALIDATION_ERROR',
          message: 'The request data is invalid',
          details: errors
        }
      });
    }

    req.validatedBody = values;
    next();
  };
}

module.exports = {
  validateId,
  validateProduct
};

This validator rejects unknown fields, normalizes accepted values, and gives the controller a trusted req.validatedBody object.

Manual validation is useful while the request shape is small. Once the API has nested objects, conditional rules, or repeated schemas, a validation library will usually reduce maintenance work.

Translate Model Results in the Controller

Create src/errors/AppError.js:

class AppError extends Error {
  constructor(status, code, message) {
    super(message);
    this.status = status;
    this.code = code;
  }
}

module.exports = AppError;

Now create src/controllers/product.controller.js:

const Product = require('../models/product.model');
const AppError = require('../errors/AppError');

async function listProducts(req, res) {
  const products = await Product.findAll();

  res.status(200).json({
    data: products,
    meta: { count: products.length }
  });
}

async function getProduct(req, res) {
  const product = await Product.findById(req.productId);

  if (!product) {
    throw new AppError(404, 'PRODUCT_NOT_FOUND', 'Product not found');
  }

  res.status(200).json({ data: product });
}

async function createProduct(req, res) {
  const product = await Product.create(req.validatedBody);

  res
    .location(`/api/products/${product.id}`)
    .status(201)
    .json({ data: product });
}

async function updateProduct(req, res) {
  const product = await Product.update(
    req.productId,
    req.validatedBody
  );

  if (!product) {
    throw new AppError(404, 'PRODUCT_NOT_FOUND', 'Product not found');
  }

  res.status(200).json({ data: product });
}

async function deleteProduct(req, res) {
  const deleted = await Product.remove(req.productId);

  if (!deleted) {
    throw new AppError(404, 'PRODUCT_NOT_FOUND', 'Product not found');
  }

  res.status(204).send();
}

module.exports = {
  listProducts,
  getProduct,
  createProduct,
  updateProduct,
  deleteProduct
};

The controller owns HTTP behavior. It returns 201 Created and a Location header after an insert, 404 Not Found for a missing resource, and 204 No Content after a successful deletion.

Make the Routes Read Like Documentation

Create src/routes/product.routes.js:

const express = require('express');
const controller = require('../controllers/product.controller');
const {
  validateId,
  validateProduct
} = require('../middleware/productValidation');

const router = express.Router();

router.get('/', controller.listProducts);
router.get('/:id', validateId, controller.getProduct);
router.post('/', validateProduct(), controller.createProduct);
router.patch(
  '/:id',
  validateId,
  validateProduct({ partial: true }),
  controller.updateProduct
);
router.delete('/:id', validateId, controller.deleteProduct);

module.exports = router;

At this point the route file describes the public interface without containing business rules or SQL.

Handle Errors in One Place

Create src/middleware/errorHandler.js:

function errorHandler(err, req, res, next) {
  if (res.headersSent) {
    return next(err);
  }

  if (
    err instanceof SyntaxError &&
    err.status === 400 &&
    Object.prototype.hasOwnProperty.call(err, 'body')
  ) {
    return res.status(400).json({
      error: {
        code: 'INVALID_JSON',
        message: 'The request body contains invalid JSON'
      }
    });
  }

  const status = err.status || 500;

  if (status >= 500) {
    console.error(err);
  }

  res.status(status).json({
    error: {
      code:
        status >= 500
          ? 'INTERNAL_SERVER_ERROR'
          : err.code || 'REQUEST_FAILED',
      message:
        status >= 500
          ? 'An unexpected server error occurred'
          : err.message
    }
  });
}

module.exports = errorHandler;

Do not expose raw SQL errors or stack traces in public responses. Log unexpected failures on the server and return a generic message to the client.

This tutorial assumes Express 5, which forwards rejected promises from async route handlers to error middleware. Express 4 applications need an async wrapper or an explicit .catch(next) pattern.

Assemble the Express Application

Create src/app.js:

const express = require('express');
const productRoutes = require('./routes/product.routes');
const AppError = require('./errors/AppError');
const errorHandler = require('./middleware/errorHandler');

const app = express();

app.disable('x-powered-by');
app.use(express.json({ limit: '10kb' }));

app.get('/health', (req, res) => {
  res.status(200).json({ data: { status: 'ok' } });
});

app.use('/api/products', productRoutes);

app.use((req, res, next) => {
  next(
    new AppError(
      404,
      'ROUTE_NOT_FOUND',
      `No route exists for ${req.method} ${req.path}`
    )
  );
});

app.use(errorHandler);

module.exports = app;

Create src/server.js:

require('dotenv').config();

const app = require('./app');
const { verifyDatabase } = require('./config/database');

async function start() {
  await verifyDatabase();

  const port = Number(process.env.PORT) || 3000;

  app.listen(port, () => {
    console.log(`API listening on http://localhost:${port}`);
  });
}

start().catch((error) => {
  console.error('Unable to start the API:', error);
  process.exit(1);
});

dotenv loads before app.js imports the database module. The startup query also prevents the process from accepting HTTP requests when its database configuration is broken.

Exercise More Than the Happy Path

Start the development server:

npm run dev

Create a product:

curl -i \
  -X POST http://localhost:3000/api/products \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Mechanical Keyboard",
    "description": "Hot-swappable 75% keyboard",
    "price": "89.90",
    "stock": 25
  }'

Update only its stock:

curl -i \
  -X PATCH http://localhost:3000/api/products/1 \
  -H "Content-Type: application/json" \
  -d '{"stock": 18}'

Then test the failures that reveal weak API boundaries: malformed JSON, an empty name, a negative stock value, an unknown field, a non-numeric ID, and an ID that is valid but does not exist.

Postman is useful for manual exploration. Automated integration tests should eventually import app.js, send requests without starting server.js, and use a separate test database with predictable fixtures.

Where This Structure Stops Being Enough

This layout is appropriate for a small or medium CRUD API, but it is not the final architecture for every application.

Add a service layer when one operation coordinates several models, calls an external service, enforces complex permissions, or needs a transaction. For example, creating an order, adding its line items, and reducing product stock must either complete together or roll back together.

Add pagination before GET /api/products can return an unbounded table. Add optimistic concurrency control when multiple users may edit the same product. Consider soft deletion when products must remain connected to historical orders.

Before public deployment, the API also needs authentication, authorization, restricted CORS rules, rate limiting, database migrations, structured logging, backups, HTTPS, monitoring, and secret management.

The practical goal is not to create the maximum number of folders. It is to keep changes local. A validation rule should not require editing SQL. A database query should not decide an HTTP status. An authentication check should not be duplicated inside every controller.

Once those boundaries are clear, authentication, pagination, search, and deployment can be added without turning each route into a different style of application.

I Was Tired of Fixing the Same Bugs Twice, So I Built Blogs World

Blogs World — Thu, 06 Aug 2026 13:20:35 +0000

Most developers have a private collection of things they don’t want to forget.

Mine started with scattered code snippets, bookmarked Stack Overflow answers, half-finished drafts, screenshots of terminal errors, and a notebook that had survived more coffee spills than it should have.

Whenever I solved a difficult problem, I told myself:

“I’ll document this properly later.”

Later rarely arrived.

A few months would pass, the same problem would appear in another project, and I would find myself repeating the entire debugging process. Sometimes I remembered the solution but not why it worked. Other times, the saved snippet no longer worked because a package, framework, or API had changed.

That frustration eventually became the reason I started Blogs World.

It wasn’t created as a content business or a perfectly planned publication. It began as a public place for the technical notes I wished I had written earlier.

A working solution needs more than code

There’s a particular kind of disappointment every developer knows.

You search for an error, find an article with exactly the right title, copy the suggested code, and run it.

Nothing happens.

Or worse, you get a completely different error.

The article may not mention the framework version. It may skip an environment variable, assume a package has already been installed, or leave out the one configuration change that makes the whole solution work.

Technically, the code in the tutorial might be correct. Practically, it isn’t useful.

That changed the way I wanted to write.

A useful technical article should explain more than the successful result. It should include the conditions around it:

What caused the problem?
Which version was being used?
What had already been tried?
Why did the first approach fail?
Are there any limitations?
How can someone verify that the solution actually worked?

The missing details are often more valuable than the final snippet.

The site grew before I noticed it becoming a brand

At first, I published whatever problem I had recently solved.

One week it might be a Laravel issue. The next could be React cleanup, a CORS error, an API integration, or a deployment configuration that behaved differently in production.

There wasn’t a grand editorial calendar sitting beside my keyboard. The direction came from the work itself.

Over time, those individual notes became an archive of more than 136 articles covering over 96 development topics. They now include Laravel and PHP, Next.js, React, TypeScript, APIs, databases, DevOps, deployment, and the practical use of AI in development.

That was when I started thinking about Blogs World as more than a collection of posts.

A logo can make a website recognizable, but it doesn’t make people trust it.

Trust comes from smaller things repeated over time:

Publishing code that has been tested
Explaining trade-offs instead of pretending there is one perfect solution
Updating an article when the underlying technology changes
Correcting mistakes openly
Giving readers a real way to ask questions
Keeping sponsored content clearly labelled
Putting an identifiable person behind the writing

None of these actions creates instant authority. Together, however, they give readers a reason to return.

That is the kind of brand I want Blogs World to become.

What writing technical articles has taught me

Writing for developers has made me more careful as a developer.

When I know I’ll have to explain a solution, I pay closer attention to the decisions behind it. “It works” is no longer enough. I need to understand why it works, what could break it, and whether there is a simpler approach.

It has also taught me that beginners frequently ask the best questions.

An experienced developer may automatically fill in a missing step. Someone newer to the stack won’t, and that exposes gaps in the explanation. If a reader has to guess what happens between step three and step four, the article probably isn’t finished.

Comments have become part of that process. If someone tells me a command no longer works or a step behaves differently on their setup, that isn’t an inconvenience. It is useful information that can make the article better for the next reader.

Technical writing shouldn’t be treated like a file that becomes untouchable after publication. It is closer to maintaining code: review it, update it, and fix what no longer works.

Performance is part of the reading experience

I also wanted the website itself to respect the person reading it.

Developers often open technical articles while they are already dealing with a problem. They don’t need a page covered by pop-ups, heavy animations, autoplay videos, and scripts competing for their laptop’s memory.

They need the explanation.

That’s why Blogs World has been rebuilt around a fairly simple idea: anything loaded on the page should earn its place.

The site should remain readable on a laptop, a mid-range phone, or an unreliable connection. Search should be easy to find. Topics should be organized clearly. Code should be readable without fighting the layout.

These details may not be as exciting as launching a new feature, but they determine whether people enjoy using the site.

Where I want to take Blogs World next

My goal isn’t to publish hundreds of shallow articles just to cover more keywords.

I would rather build a dependable library of explanations that solve real development problems. Some posts will be beginner-friendly. Others will go deeper into architecture, debugging, deployment, and the decisions that only become visible when an application reaches production.

I also want the site to remain personal.

Every article has one accountable author. Questions are read by the same person who wrote the post. If a tutorial is outdated, readers can point it out, and it can be corrected.

The internet already has an enormous amount of technical content. It doesn’t necessarily need more of it.

It needs more content that someone is willing to stand behind.

That is what I’m trying to build with Blogs World: a developer’s working notebook, maintained in public and improved through real feedback.

If you explore it and find something that helps you, I’d genuinely like to hear about it. And if you find something that doesn’t work, tell me that too.

Both responses help build a better resource.

What makes you trust a technical blog enough to return to it?

Is it the depth of the explanation, tested code, regular updates, the author’s experience, or something else?

I’d love to hear how other developers decide which resources are worth keeping.

How to Fix CORS Errors in React: The Practical Guide (With Real Solutions)

Blogs World — Tue, 04 Aug 2026 07:05:34 +0000

The Error Everyone Hits

You're building a React app. API works in Postman. Works in curl. Works everywhere.

Then you put it in your React component:

useEffect(() => {
  fetch('https://api.example.com/data')
    .then(res => res.json())
    .then(data => console.log(data))
    .catch(err => console.log(err))
}, [])

Browser console:

Access to XMLHttpRequest at 'https://api.example.com/data' 
from origin 'http://localhost:3000' has been blocked by CORS policy: 
No 'Access-Control-Allow-Origin' header is present on the requested resource.

Why? Browser security. Not your fault. But also... frustrating.

Here's what actually works:

Solution 1: Backend Fix (The Right Way)

The correct fix is on the backend, not frontend.

Your backend needs to send:

Access-Control-Allow-Origin: http://localhost:3000

If you control the backend:

Node.js/Express:

const cors = require('cors');

app.use(cors({
  origin: 'http://localhost:3000', // Your frontend URL
  credentials: true
}));

app.get('/api/data', (req, res) => {
  res.json({ message: 'success' });
});

Laravel/PHP:

header('Access-Control-Allow-Origin: http://localhost:3000');
header('Access-Control-Allow-Methods: GET, POST, PUT, DELETE');
header('Access-Control-Allow-Credentials: true');
header('Content-Type: application/json');

Python/Flask:

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app, origins=['http://localhost:3000'])

@app.route('/api/data')
def data():
    return {'message': 'success'}

That's it. Your React code now works.

Solution 2: Proxy During Development

If you DON'T control the backend, or you're developing locally:

Create a proxy in package.json:

{
  "proxy": "https://api.example.com"
}

Then in React, remove the domain:

// ❌ Before (gets CORS error)
fetch('https://api.example.com/data')

// ✅ After (goes through proxy)
fetch('/data')

Why this works: React's dev server acts as a middleman. Browsers don't block same-origin requests.

⚠️ Important: This only works in development (npm start). Production builds need the backend fix.

Solution 3: CORS Proxy (Temporary, Not Recommended)

If you're stuck and can't change the backend:

const corsProxy = 'https://cors-anywhere.herokuapp.com/';
const apiUrl = 'https://api.example.com/data';

fetch(corsProxy + apiUrl)
  .then(res => res.json())
  .then(data => console.log(data))

Why this sucks:

Extra latency (request goes through a third server)
Free CORS proxies get rate-limited
Security risk (your data goes through someone else's server)
Will break in production

Use this only for testing. Don't ship it.

Solution 4: Credentials & Cookies

If your API requires authentication (cookies, JWT):

// ❌ Doesn't send cookies
fetch('https://api.example.com/data')

// ✅ Sends cookies
fetch('https://api.example.com/data', {
  credentials: 'include'
})

Backend also needs to allow credentials:

Express:

cors({
  origin: 'http://localhost:3000',
  credentials: true  // ← This line
})

The Checklist (Before Asking for Help)

✅ Does your backend have CORS headers set?
- Check: curl -I https://api.example.com/data | grep Access-Control
- If nothing appears → backend needs fixing
✅ Is it a preflight request being blocked?
- Look for OPTIONS request in Network tab
- If it fails → backend doesn't handle preflight
✅ Are you sending credentials?
- If yes → both frontend needs credentials: 'include' AND backend needs credentials: true
✅ Is this production or development?
- Dev: use proxy
- Production: backend must have CORS headers

Real Example: Fetch with All Options

Here's a complete, production-ready example:

async function fetchUserData(userId) {
  try {
    const response = await fetch(`https://api.example.com/users/${userId}`, {
      method: 'GET',
      headers: {
        'Content-Type': 'application/json',
        'Authorization': `Bearer ${token}`
      },
      credentials: 'include'  // Include cookies if backend requires auth
    });

    if (!response.ok) {
      throw new Error(`API error: ${response.status}`);
    }

    const data = await response.json();
    return data;
  } catch (error) {
    console.error('CORS or network error:', error);
  }
}

What I've Learned (After Fixing This 100+ Times)

99% of CORS errors are a backend configuration issue, not a React problem
The proxy solution feels like magic locally, but it's a trap for production — always fix the backend
Credentials require matching configurations on both sides — one side correct isn't enough
Preflight requests (OPTIONS) are the actual blocker — if those fail, everything fails

The Fastest Debug Path

Open DevTools → Network tab
Try your API call
Look for the failed request
Click it → Response headers → search for Access-Control-Allow-Origin
If it's missing → backend problem
If it's there but says a different origin → update backend to allow your URL

Still Stuck?

Drop the actual error message in the comments. Knowing:

What frontend (React, Vue, etc.) you're using
What backend (Express, Laravel, etc.) you're using
Whether this is local dev or production

...helps me (and others) give you the exact fix.

Cheers ☕

Want more React debugging tips? I write practical solutions to the problems that actually kill deployments. Check out my full blog for deep dives on error handling, performance, and production gotchas.

Author: Ankit Khoiwal | Full-stack developer | Every post is from real production experience