DEV Community: Blogs World

Laravel Sanctum 419 Error: A 5-Step Debugging Guide

Blogs World — Tue, 08 Sep 2026 12:49:05 +0000

Your Laravel API works.

Your credentials are correct.

/sanctum/csrf-cookie might even return 204.

Then you send the login request:

POST /login

and Laravel responds with:

419 Page Expired

If you've been changing random CORS settings hoping the error disappears, stop there.

A Laravel Sanctum 419 error is usually a CSRF/session authentication problem, and the fastest way to fix it is to identify exactly where the Sanctum authentication flow breaks.

Here's the debugging order I use.

TL;DR

For Laravel Sanctum SPA authentication, verify these five things:

1. Stateful middleware
2. SANCTUM_STATEFUL_DOMAINS
3. CORS credentials
4. Session cookies
5. Axios CSRF handling

And always request:

GET /sanctum/csrf-cookie

before:

POST /login

If one piece of that chain is wrong, Laravel can respond with 419 CSRF token mismatch / Page Expired.

1. Understand What 419 Actually Means

When using Laravel Sanctum's SPA authentication, Laravel relies on normal session cookies and CSRF protection.

The browser flow looks roughly like this:

Frontend
   |
   | GET /sanctum/csrf-cookie
   v
Laravel
   |
   | Sets XSRF-TOKEN
   | Sets session cookie
   v
Browser
   |
   | POST /login
   | Cookie + X-XSRF-TOKEN
   v
Laravel validates request

When Laravel cannot validate that CSRF/session relationship, you can end up with:

419 Page Expired

So the question isn't simply:

"Is my CORS config correct?"

The better question is:

"At which point does the authentication chain break?"

2. Start With the Browser Network Panel

Before touching .env, Axios, or Laravel configuration, open:

Chrome DevTools → Network

Then perform the login again.

Find the first request that doesn't behave as expected.

Case A: OPTIONS fails

If the browser blocks an OPTIONS request, investigate CORS first.

Case B: `/sanctum/csrf-cookie` fails

Your browser isn't successfully initializing Sanctum's CSRF protection.

Case C: CSRF request succeeds but `/login` returns 419

This is where I'd inspect:

XSRF-TOKEN
Laravel session cookie
X-XSRF-TOKEN
cookie domain
Axios credentials
Sanctum stateful domains

Case D: Login succeeds but `/api/user` returns 401

Now the problem is more likely related to the authenticated session or Sanctum recognizing the request as stateful.

This simple classification eliminates a lot of unnecessary debugging.

3. Make Sure Sanctum Treats the SPA as Stateful

Modern Laravel applications can enable Sanctum's stateful API middleware in bootstrap/app.php.

For example:

use Illuminate\Foundation\Configuration\Middleware;

->withMiddleware(function (Middleware $middleware): void {
    $middleware->statefulApi();
})

This matters because Sanctum needs to understand that requests coming from your first-party SPA should use session authentication.

If you're following an older Laravel tutorial, you may see instructions involving:

app/Http/Kernel.php

Be careful.

Laravel's application structure has evolved, so old Sanctum tutorials can send you to configuration locations that aren't appropriate for newer Laravel applications.

4. Check `SANCTUM_STATEFUL_DOMAINS`

Assume your setup looks like this:

Frontend:
https://app.example.com

API:
https://api.example.com

Your SPA host needs to be recognized as stateful.

For example:

SANCTUM_STATEFUL_DOMAINS=app.example.com

One common mistake is adding the protocol:

SANCTUM_STATEFUL_DOMAINS=https://app.example.com

That's not what you normally want here.

Think host, not frontend URL.

localhost can be even trickier

Suppose Vite runs on:

http://localhost:5173

Then you may need:

SANCTUM_STATEFUL_DOMAINS=localhost:5173

Don't casually mix:

localhost
127.0.0.1
localhost:5173
127.0.0.1:5173

Use one consistent development setup.

A surprising number of Sanctum bugs come from tiny hostname differences.

5. CORS Must Allow Credentials

If your SPA authentication uses cookies, your CORS configuration must allow credentialed requests.

A typical setup could include:

return [

    'paths' => [
        'api/*',
        'sanctum/csrf-cookie',
        'login',
        'logout',
    ],

    'allowed_methods' => ['*'],

    'allowed_origins' => [
        'https://app.example.com',
    ],

    'allowed_headers' => ['*'],

    'supports_credentials' => true,

];

The important setting is:

'supports_credentials' => true,

And don't casually do this:

'allowed_origins' => ['*']

when you're relying on cookie credentials.

Specify the frontend origin explicitly:

https://app.example.com

Origin and domain are not the same thing

For CORS:

https://app.example.com

is an origin.

The scheme matters.

These are different origins:

http://app.example.com
https://app.example.com

Meanwhile, Sanctum's stateful domain configuration is concerned with the appropriate host/domain.

Mixing these concepts is one reason Sanctum configuration feels confusing at first.

6. Inspect Your Session Cookie Configuration

Now suppose your architecture is:

app.example.com
api.example.com

Both are under:

example.com

A typical production session configuration might include:

SESSION_DOMAIN=.example.com
SESSION_SECURE_COOKIE=true
SESSION_SAME_SITE=lax

The parent-domain cookie configuration allows the session to work across the relevant subdomains.

After changing environment settings, also remember that cached configuration can make you think your changes aren't working.

Depending on your deployment workflow, refresh Laravel's configuration cache appropriately.

For example:

php artisan config:clear

and rebuild/cache configuration according to your production deployment process.

7. Configure Axios Correctly

Your Laravel setup can be perfect and still fail if the frontend never sends the cookies back.

For Axios:

import axios from 'axios';

const api = axios.create({
  baseURL: import.meta.env.VITE_API_URL,
  withCredentials: true,
  withXSRFToken: true,
  headers: {
    Accept: 'application/json',
  },
});

Before login:

await api.get('/sanctum/csrf-cookie');

await api.post('/login', {
  email,
  password,
});

The two important Axios options are:

withCredentials: true

and:

withXSRFToken: true

Now look in the browser.

After:

GET /sanctum/csrf-cookie

you should normally be able to see the relevant CSRF/session cookies.

Then inspect:

POST /login

and confirm the authentication data is actually being sent back to Laravel.

A Better Way to Debug 419

Instead of changing Laravel, CORS, Axios, cookies, and middleware simultaneously, use this sequence.

Test 1 — CSRF endpoint

Request:

GET /sanctum/csrf-cookie

Expected:

Successful response
+
XSRF/session cookies created

If no cookies appear, don't debug your login controller yet.

Test 2 — Login request

Request:

POST /login

Check:

Are cookies attached?
Is X-XSRF-TOKEN present?
Is the request being blocked by CORS?

If the answer is no, you've narrowed the problem substantially.

Test 3 — Authenticated endpoint

After successful login:

GET /api/user

If login succeeds but this gives:

401 Unauthenticated

focus on:

Sanctum stateful configuration
Session cookie
Cookie domain
withCredentials
Middleware

instead of CSRF.

419 vs 401 vs 422

These errors frequently get mixed together.

419

Usually investigate:

CSRF
XSRF token
Cookies
Session

401

Usually investigate:

Authentication
Session recognition
Sanctum stateful requests
Missing credentials

422

Usually investigate:

Validation errors
Missing fields
Invalid input

Knowing the difference can save a surprising amount of time.

Why Does Sanctum Work in Postman but Fail in Chrome?

This is an extremely common situation:

Postman ✅
Browser ❌

And it's an important clue.

Browsers enforce:

CORS
cookie policies
origins
credentials
SameSite behavior
CSRF flows

API clients such as Postman don't behave exactly like a browser page.

So if the API works from Postman but fails from React/Vue/Vite, start investigating the browser authentication flow, not your database credentials.

Don't "Fix" 419 by Disabling CSRF

You might find solutions online suggesting that you exclude your login endpoint from CSRF protection.

That can make the error disappear.

It doesn't necessarily mean you've fixed Sanctum.

For first-party SPA session authentication, the better solution is to correctly configure:

CSRF
Session cookies
Stateful domains
CORS
Frontend credentials

rather than removing the protection that exposed the configuration problem.

One Production Architecture Detail People Miss

This setup:

app.example.com
api.example.com

is very different from:

my-app.vercel.app
api.example.com

In the first example, the frontend and backend share the same top-level site.

In the second, they're on unrelated domains.

CORS cannot magically turn unrelated domains into the same first-party cookie environment.

So if you're struggling with Sanctum cookie authentication across completely different production domains, revisit the architecture itself.

A custom frontend domain such as:

app.example.com

can make a first-party Sanctum setup considerably cleaner.

My 60-Second Sanctum 419 Checklist

Before searching Stack Overflow again, check this:

[ ] statefulApi() enabled

[ ] SPA exists in SANCTUM_STATEFUL_DOMAINS

[ ] Exact frontend origin allowed by CORS

[ ] supports_credentials = true

[ ] Correct SESSION_DOMAIN

[ ] Secure cookie configuration matches HTTPS setup

[ ] Axios withCredentials = true

[ ] Axios withXSRFToken = true

[ ] /sanctum/csrf-cookie called before login

[ ] XSRF-TOKEN appears in browser

[ ] Session cookie appears in browser

[ ] Login request sends cookies

[ ] X-XSRF-TOKEN is sent correctly

If all twelve are correct, you've eliminated most of the common causes of a Laravel Sanctum 419 error.

The Debugging Order Matters More Than the Fix

The biggest lesson isn't a specific .env setting.

It's this:

Debug the first broken request instead of randomly changing authentication configuration.

Use this order:

OPTIONS
   ↓
/sanctum/csrf-cookie
   ↓
Cookies
   ↓
POST /login
   ↓
/api/user

Find where the expected behavior stops.

That's usually where your real problem begins.

Need the Full Laravel Sanctum 419 Reference?

I wrote a more detailed guide covering Laravel Sanctum CORS, CSRF cookies, Axios configuration, production domains, localhost issues, session configuration, 401 vs 419 vs 422 errors, and deployment troubleshooting.

👉 Read the complete Laravel Sanctum CORS 419 Error Fix guide

Use the full guide when the quick checklist above doesn't expose the problem immediately.

If you're debugging Sanctum today, remember:

419 is the symptom. The browser's request flow tells you the cause.

AI Coding Tools Are Fast. That Doesn't Mean They Make You Faster

Blogs World — Wed, 02 Sep 2026 12:20:43 +0000

AI coding assistants can generate a surprising amount of code in a fo a terrible way to measure whether the tool is actually making a developer more productive.

A 200-line implementation generated in thirty seconds sounds great until you spend the next hour understanding the diff, correcting assumptions, repairing tests, and discovering that the assistant quietly changed something outside the requested scope.

The more useful question is not:

"How much code did the AI generate?"

It is:

"How quickly did I get from a clearly defined problem to a change I would actually be comfortable merging?"

That difference changes how you evaluate tools such as GitHub Copilot, Cursor, Claude Code, Codex, JetBrains AI Assistant, and other coding agents.

Generated Code Is Not Finished Work

Consider two coding assistants.

Tool A generates a complete implementation in five minutes.

Tool B takes twelve minutes.

Tool A looks much faster.

But then you review the results.

With Tool A:

two unrelated files were modified
one existing test was changed to match the new implementation
an edge case was missed
you spend thirty minutes debugging the result

With Tool B:

only the relevant files were changed
existing tests were preserved
a new regression test was added
the implementation passes the project's checks

Tool B was technically slower at generating code.

It was faster at producing usable code.

That is the metric developers should care about.

Measure Time to a Verified Change

A better productivity metric for AI-assisted development is what I think of as verified-change latency.

Start the timer when the task is clearly defined.

Stop it when the change has:

passed the relevant tests
passed linting and type checks
survived code review
avoided unnecessary modifications
preserved existing behavior
satisfied security checks where required

This gives you a much more realistic picture of productivity.

Lines generated per minute tells you almost nothing.

Minutes required per trustworthy change tells you a lot.

Different AI Coding Tools Solve Different Problems

Another mistake is expecting one AI tool to be the best at everything.

Coding assistance now covers several very different workflows.

1. Autocomplete

Autocomplete should feel almost invisible.

You type part of a function and the assistant predicts what comes next.

The important factors here are:

suggestion latency
acceptance rate
understanding of nearby code
consistency with existing naming patterns

For this type of work, a fast editor-integrated assistant can be more useful than an autonomous agent.

You probably don't need an agent planning an entire implementation when all you wanted was to finish a mapping function.

2. Repository Exploration

The problem changes when you inherit an unfamiliar project.

Now you might ask:

Where is authentication actually enforced?

or:

Which services eventually call this database method?

Answering that requires understanding relationships across several files.

This is where repository-aware assistants become much more useful than ordinary autocomplete.

A good assistant should be able to trace the path through the codebase rather than simply explain the file currently open in the editor.

3. Multi-File Implementation

Then there are tasks where the assistant needs to:

inspect the repository
understand the requirement
modify several files
run commands
observe failures
adjust the implementation
report what changed

This is where agent-style tools become interesting.

But autonomy creates another problem:

the bigger the task, the bigger the possible wrong diff.

Giving an agent a prompt such as:

Improve this project.

is asking for trouble.

A much better task looks like:

Fix the failed login attempt counter. Preserve the current API response structure, add a regression test, run the authentication test suite, and do not modify unrelated files.

The completion condition is observable.

Either the relevant tests pass or they do not.

Give the Tool Evidence, Not Just a Problem Description

When debugging with an AI assistant, avoid starting with:

My application isn't working. Fix it.

Provide evidence.

For example:

Command:
npm test -- auth

Expected:
All authentication tests pass.

Actual:
2 tests fail.

Error:
Expected status 401 but received 500.

Relevant behavior:
This started after the refresh-token validation change.

Now the assistant has something concrete to investigate.

For debugging work, I prefer asking the tool to identify the likely root cause before changing anything.

That small instruction makes a big difference.

Otherwise, coding agents often jump straight into editing the first suspicious file they encounter.

Protect Your Tests

One of the easiest ways for generated code to appear correct is to change the test.

Imagine the requirement says:

A user without permission must receive HTTP 403.

The implementation accidentally returns 200.

A bad AI-assisted workflow might change the test expectation from:

expect(response.status).toBe(403);

to:

expect(response.status).toBe(200);

Congratulations. Everything is green.

The bug is still there.

This is why existing tests should be treated as part of the specification unless the requirement itself has intentionally changed.

When using an AI coding agent, explicitly state:

Do not weaken or remove existing assertions simply to make the test suite pass.

That sentence can prevent a surprising amount of nonsense.

AI Review Should Focus on Consequences

AI-assisted code review has another common failure mode: noise.

A review containing twenty comments about variable names is not necessarily useful.

A review identifying one broken authorization path can be extremely useful.

For AI review, prioritize questions such as:

Can this change expose data to the wrong user?
Is error handling missing?
Did the change introduce an extra database query?
Is a null or empty state unhandled?
Can two concurrent requests create inconsistent state?
Did the implementation alter an existing API contract?
Are tests missing for the failure path?

Formatters already know how to complain about spaces.

Use AI review for things that require context.

Security Still Needs Deterministic Tools

An AI assistant can notice insecure code.

That does not make it a security scanner.

If you ask:

Is this application secure?

you will probably receive a confident answer containing several reasonable observations.

You will not receive proof that every relevant vulnerability has been found.

Use dedicated static-analysis, dependency-scanning, and secret-detection tools for concrete findings.

Then use AI to:

explain the finding
trace the affected path
suggest remediation
generate a regression test
help interpret scanner output

The order matters.

Detection first. AI-assisted remediation second. Verification last.

Don't Give an Agent Unlimited Scope

AI agents are particularly effective when the task has boundaries.

Good:

Update the user endpoint to validate email addresses.

Requirements:
- preserve the existing response schema
- return 422 for invalid emails
- add tests for empty and malformed addresses
- run the API test suite
- list the files changed

Not so good:

Improve user management.

The first prompt defines success.

The second defines an adventure.

And adventures create large pull requests.

Repository Instructions Are Underrated

Developers often spend a lot of time improving prompts when the real problem is missing project context.

Your repository should tell an assistant things such as:

Package manager: pnpm

Run tests:
pnpm test

Run type checking:
pnpm typecheck

Architecture:
API handlers live in /src/api
Database access belongs in /src/repositories

Rules:
Do not edit generated files.
Do not modify migrations that have already shipped.
Do not add dependencies without explaining why.

Those instructions are much more useful than trying to invent a magical universal prompt.

AI coding tools are extremely sensitive to context.

Better context usually beats clever wording.

Compare Tools Using the Same Task

If you are deciding between coding assistants, don't compare them using random daily interactions.

Create one small but representative task.

For example, prepare a repository containing:

one failing unit test
one bug spanning multiple files
one simple security problem
one documented completion command

Then give every tool the same task.

Record:

first-pass test result
time to completion
number of correction prompts
files modified
unrelated modifications
whether existing tests were changed
accuracy of the final explanation
time required for human review

Run the test more than once.

Agent output is not perfectly deterministic, so a single successful attempt can be misleading.

I put together a more detailed comparison of current assistants, including GitHub Copilot, Cursor, Codex, Claude Code, JetBrains AI Assistant and specialist review/security workflows, in this AI coding tools comparison for developers.

The useful part isn't picking a universal winner. It is matching the tool to the type of development work you actually do.

The Best AI Workflow Still Has a Human Owner

The most important rule is simple:

Someone must still own the final diff.

Before merging an AI-assisted change, a developer should understand:

what changed
why it changed
what could break
how the change was tested
whether security or data handling is affected
how the change would be rolled back

AI can generate the implementation.

It can run commands.

It can explain the diff.

It can even review parts of its own work.

But the person merging the change still owns the result when production behaves differently at 2 AM.

That responsibility hasn't been automated.

A Simple Rule for Using Coding Assistants

Before accepting an AI-generated change, try to explain it in one or two sentences without looking at the assistant's explanation.

If you cannot explain what the code does, you probably should not merge it yet.

AI coding tools are becoming incredibly capable.

The winning workflow, however, isn't the one that generates the most code.

It's the one that gets you to a small, understandable, tested and reviewable change with the least unnecessary work.

That's a much less exciting benchmark than "10x developer."

It is also much closer to how good software actually gets shipped.

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

DEV Community: Blogs World

Laravel Sanctum 419 Error: A 5-Step Debugging Guide

TL;DR

1. Understand What 419 Actually Means

2. Start With the Browser Network Panel

Case A: OPTIONS fails

Case B: /sanctum/csrf-cookie fails

Case C: CSRF request succeeds but /login returns 419

Case D: Login succeeds but /api/user returns 401

3. Make Sure Sanctum Treats the SPA as Stateful

4. Check SANCTUM_STATEFUL_DOMAINS

localhost can be even trickier

5. CORS Must Allow Credentials

Origin and domain are not the same thing

6. Inspect Your Session Cookie Configuration

7. Configure Axios Correctly

A Better Way to Debug 419

Test 1 — CSRF endpoint

Test 2 — Login request

Test 3 — Authenticated endpoint

419 vs 401 vs 422

419

401

422

Why Does Sanctum Work in Postman but Fail in Chrome?

Don't "Fix" 419 by Disabling CSRF

One Production Architecture Detail People Miss

My 60-Second Sanctum 419 Checklist

The Debugging Order Matters More Than the Fix

Need the Full Laravel Sanctum 419 Reference?

AI Coding Tools Are Fast. That Doesn't Mean They Make You Faster

Generated Code Is Not Finished Work

Measure Time to a Verified Change

Different AI Coding Tools Solve Different Problems

1. Autocomplete

2. Repository Exploration

3. Multi-File Implementation

Give the Tool Evidence, Not Just a Problem Description

Protect Your Tests

AI Review Should Focus on Consequences

Security Still Needs Deterministic Tools

Don't Give an Agent Unlimited Scope

Repository Instructions Are Underrated

Compare Tools Using the Same Task

The Best AI Workflow Still Has a Human Owner

A Simple Rule for Using Coding Assistants

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

The short answer

First, separate “deployed” from “working”

Three settings quietly control the whole build

The home page works, but /account does not

An environment variable can be present and still be wrong

Sometimes the React app is innocent

The request still points to localhost

The page is HTTPS but the API is HTTP

The API rejects the Vercel origin

The capitalization bug that waits for production

Preview deployments are more than disposable links

A five-minute production check

Diagnose by symptom, not by guesswork

Frequently asked questions

Do I need to upload the dist folder to Vercel?

Why did changing a Vercel environment variable do nothing?

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

Can the React frontend and API use different hosting providers?

Is Vercel a good host for every React project?

“Ready” is the start of verification

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/

Mastering this in Modern Java — 2026 Developer Playbook

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

The habit nobody tells you to unlearn

What actually separates the two tools

A quick gut-check I actually use now

The mistake I don't make anymore

Where I landed

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

The API Contract Comes First

Create the Project

Let MySQL Enforce Basic Data Rules

Keep Secrets Out of the Source Code

Case B: `/sanctum/csrf-cookie` fails

Case C: CSRF request succeeds but `/login` returns 419

Case D: Login succeeds but `/api/user` returns 401

4. Check `SANCTUM_STATEFUL_DOMAINS`

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

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