DEV Community: AddWeb Solution Pvt Ltd

Managing Environment Variables in React Properly

Lakashya Upadhyay — Wed, 29 Apr 2026 07:36:27 +0000

Environment variables in React often look simple at first, but they can quickly become a source of bugs, leaks, and deployment confusion if handled carelessly. In modern React apps, especially with Vite or CRA, the way you name, store, and access environment variables matters just as much as the values themselves.

This guide walks through the most common mistakes developers make when managing environment variables in React, explains why they happen, and shows how to set up a clean and reliable environment configuration strategy.

Key Takeaways

Use the correct prefix for your build tool: REACT_APP_ for CRA and VITE_ for Vite.youtubevite
Never store secrets in client-side environment variables, because anything shipped to the browser can be inspected.
Keep .env.local for local-only values and add env files to .gitignore when appropriate.
Use import.meta.env in Vite instead of process.env.
Keep environment variables documented, consistent, and validated before the app uses them.

Index

Why This Matters
Mistake 1: Using the Wrong Environment Variable Prefix
Mistake 2: Treating Client-Side Env Vars Like Secrets
Mistake 3: Mixing process.env and import.meta.env
Mistake 4: Hardcoding URLs Instead of Using Config
Mistake 5: Not Using .env.local Properly
Mistake 6: Forgetting to Restart the Dev Server
Mistake 7: Keeping Too Many Environment Files Without a Clear Rule
Mistake 8: Not Validating Required Variables
Mistake 9: Committing Sensitive .env Files to Git
Mistake 10: Poor Naming and Documentation
Frequently Asked Questions (FAQs)
Interesting Facts & Stats
Conclusion

1. Why This Matters

React environment variables are usually used for API URLs, feature flags, analytics IDs, and deployment settings. The problem is that frontend apps are bundled for the browser, so misconfigured variables can lead to broken builds, undefined values, or exposed configuration that should never have been public.

A small mistake like using API_URL instead of VITE_API_URL or REACT_APP_API_URL can make the value unavailable in your app. Another common issue is assuming environment variables are private when they are actually shipped to the client bundle.

A good environment strategy makes your app:

Easier to deploy across dev, staging, and production.
Safer to maintain in a team.
Less likely to break from config mistakes.
Easier to document and onboard new developers.

2. Mistake 1: Using the Wrong Environment Variable Prefix

“Your variable name matters more than you think.”

In React, the framework or build tool only exposes specific environment variables to the client. In Create React App, custom variables must begin with REACT_APP_, while Vite exposes variables prefixed with VITE_ through import.meta.env.youtube
Example of the mistake:

text
API_URL=https://api.example.com
js
console.log(import.meta.env.API_URL);

How to fix it:
Use the correct prefix for your tool.

text
VITE_API_URL=https://api.example.com
js
console.log(import.meta.env.VITE_API_URL);
For CRA:
text
REACT_APP_API_URL=https://api.example.com
js
console.log(process.env.REACT_APP_API_URL);

Benefits:

Variables are actually available in the app.
Builds behave consistently across environments.
Your team knows which config values are intended for frontend use.

3. Mistake 2: Treating Client-Side Env Vars Like Secrets

“Anything in a React bundle is public.”

A very common misunderstanding is storing passwords, private tokens, or database credentials in frontend env files. React environment variables are bundled into client-side code, which means users can inspect them in the browser.

Example of the mistake:

text
VITE_STRIPE_SECRET_KEY=sk_live_12345

This is dangerous because any secret exposed to the front end can be discovered by end users.

How to fix it:
Use frontend env vars only for:

Public API base URLs.
Feature flags.
Analytics public IDs.
Non-sensitive deployment settings. Keep sensitive secrets on the backend, and let your React app communicate with a server API instead.

Benefits:

Better security.
Less risk of accidental leaks.
Cleaner separation between frontend and backend responsibilities.

4. Mistake 3: Mixing process.env and import.meta.env

“Use the syntax your build tool expects.”

One of the most frequent bugs in Vite apps is using process.env, which is a CRA/Node-style pattern. Vite expects values from import.meta.env.

Example of the mistake in Vite:

js
console.log(process.env.VITE_API_URL);

How to fix it:

js
console.log(import.meta.env.VITE_API_URL);
In CRA, the equivalent pattern is usually:
js
console.log(process.env.REACT_APP_API_URL);

Benefits:

Avoids undefined errors.
Keep your code compatible with the correct build environment.
Reduces confusion when switching between CRA and Vite.

5. Mistake 4: Hardcoding URLs Instead of Using Config

“Hardcoding works until deployment changes.”

A lot of React apps start with hardcoded endpoints like http://localhost:3000, then later break when deployed to staging or production. This makes the app harder to move between environments and increases refactoring work later.

Example of the mistake:

js
const baseUrl = 'http://localhost:8000/api';

How to fix it:
Move environment-specific values into env files.

text
VITE_API_URL=https://api.example.com
js
const baseUrl = import.meta.env.VITE_API_URL;

Benefits:

One codebase works across multiple environments.
Easier switching between dev and production.
Cleaner deployment pipeline.

6. Mistake 5: Not Using .env.local Properly

“Local overrides should stay local.”
A common best practice is to place developer-specific values in .env.local, which is intended for local overrides and usually not committed. This is especially useful when each developer has different local endpoints, test credentials, or personal feature flags.

Example structure:

text
.env
.env.development
.env.production
.env.local

How to fix it:

Use .env for shared defaults.
Use .env.local for machine-specific values.
Use .env.development and .env.production for environment-specific behavior.

Benefits:

Cleaner collaboration.
Fewer accidental git commits of personal values.
Easier developer onboarding.

7. Mistake 6: Forgetting to Restart the Dev Server

“Env changes are not always hot-reloaded.”

In many React setups, environment file changes do not always appear immediately in the running dev server. If a variable seems stuck or undefined, the first thing to try is restarting the server.

How to fix it:

Stop the dev server.
Save the .env file.
Start the server again.

Benefits:

Saves debugging time.
Prevents confusion when values appear stale.
Ensures the bundler picks up the latest config.

8. Mistake 7: Keeping Too Many Environment Files Without a Clear Rule

“Too many env files can become configuration chaos.”

It’s easy to end up with .env, .env.local, .env.development, .env.staging, .env.production, and several team-specific variants without a clear structure. That usually makes it hard to know which value is active in which environment.

How to fix it:
Define a simple convention:

.env for shared defaults.
.env.local for developer-specific overrides.
.env.development for local development.
.env.production for production build values.

Benefits:

Easier to understand.
Less confusion during deployment.
More predictable configuration behavior.

9. Mistake 8: Not Validating Required Variables

“Missing config should fail early.”

If your app depends on a value like VITE_API_URL, it should not silently continue with undefined. A missing environment variable often leads to broken API calls, blank screens, or confusing runtime errors.

How to fix it:
Check required values at app startup.

js
const apiUrl = import.meta.env.VITE_API_URL;

if (!apiUrl) {
  throw new Error('VITE_API_URL is missing');
}

Benefits:

Fails fast during development.
Prevents subtle runtime bugs.
Makes deployment issues easier to catch.

10. Mistake 9: Committing Sensitive .env Files to Git

“Git remembers everything.”

Another common mistake is committing real environment files to source control. Even if the repo later becomes private, the secret may already have been exposed in history.

How to fix it:

Add .env, .env.local, and secret files to .gitignore.
Commit only .env.example.
Put placeholder values in examples.

Example:

text
VITE_API_URL=
VITE_APP_NAME=

Benefits:

Protects secrets.
Makes setup easier for teammates.
Keeps the repo safer and cleaner.

11. Mistake 10: Poor Naming and Documentation

“Clear names save time later.”

Vague variable names like URL1, KEY, or TOKEN make maintenance harder. Good naming conventions help your team understand what belongs where and reduce mistakes when moving between projects.

Better names:

VITE_API_URL
VITE_APP_NAME
VITE_GOOGLE_MAPS_KEY
REACT_APP_BACKEND_URL

How to fix it:

Use uppercase letters and underscores.
Prefix only values meant for the frontend.
Document each variable in your README or .env.example.

Benefits:

Easier onboarding.
Better readability.
Less confusion during refactoring or deployment.

12. Frequently Asked Questions (FAQs)

Q. Can I use environment variables to hide secrets in React?
A. No. Anything shipped to the browser is visible to users, so secrets should stay on the backend.

Q. Why is import.meta.env undefined in my Vite app?
A. The variable probably does not use the VITE_ prefix, or the dev server needs a restart.

Q. What prefix should I use in CRA?
A. Use REACT_APP_ for custom variables in Create React App.youtubeconfigu

Q. Should I commit .env files?
A. Usually not for real secrets. Commit .env.example instead.

Q. Do I need separate env files for every environment?
A. Not always, but a clear convention for local, development, and production makes projects easier to manage.

13. Interesting Facts & Stats

Vite exposes custom client-side env variables through import.meta.env, and only variables prefixed with VITE_ are exposed by default. Source: Vite Env Variables and Modes
CRA requires the REACT_APP_ prefix for custom environment variables to be available in React code. Source: React .env File Hierarchy | Master Environment Variables in CRA & Vite
Many environment variable bugs are not code bugs at all, but naming or build-tool configuration issues. Source: React Environment Variables: Basics, Tutorial, and Best Practices
Using .env.local for local-only settings is a widely recommended pattern for safer collaboration. Source: React Environment Variables: Basics, Tutorial, and Best Practices

14. Conclusion

Managing environment variables in React is less about storing values and more about building a predictable configuration system. Once you follow the right prefixing rules, keep secrets off the client, and separate local, development, and production values properly, environment setup becomes much more reliable.

A good React environment strategy is simple:

Use the correct build-tool syntax.
Keep secrets on the server.
Document variables clearly.
Fail fast when config is missing.

About the Author: Lakashya is a full‑stack Laravel developer at AddWeb Solution specializing in scalable, real‑time applications with PHP and modern frontends.

Building Reusable UI Components in React (Clean & Scalable Approach)

Ankit Parmar — Mon, 27 Apr 2026 08:33:36 +0000

“Programs must be written for people to read, and only incidentally for machines to execute.” - Harold Abelson

Modern frontend applications grow fast-and without a solid component strategy, they become hard to maintain, inconsistent, and fragile. Reusable UI components solve this by promoting consistency, reducing duplication, and enabling scalable architecture.

But simply “reusing components” isn’t enough. Poorly designed components can create more problems than they solve.

In this article, we’ll explore how to build clean, reusable, and scalable UI components in React, focusing on architecture, patterns, and real-world practices-not just syntax.

Why Reusable Components Matter

Without reusable components, teams often face:

UI inconsistencies across pages
Duplicate logic and styling
Difficult debugging and updates
Slower development velocity

Reusable components help you:

Standardize design and behavior
Reduce code duplication
Improve maintainability
Speed up development

What Makes a Component Truly Reusable?

A reusable component is:

Generic → Works in multiple contexts
Composable → Can be combined with other components
Configurable → Controlled via props
Decoupled → Not tied to specific business logic Bad example: A UserDashboardCard hardcoded for one screen Good example: A Card component configurable via props

Core Philosophy
“Components should do one thing, and do it well.”
Focus on:
Separation of concerns
Clear interfaces (props)
Minimal assumptions

Key Takeaways

Reusable components reduce duplication and improve maintainability
Keep components small, focused, and composable
Use props for flexibility, not hardcoded values
Separate UI from business logic
Follow consistent folder and naming conventions
Avoid premature abstraction-refactor when patterns emerge
Design systems and shared libraries scale teams effectively

Index

Introduction
What Are Reusable Components?
Component Design Principles
Types of Reusable Components
Structuring Your Component Folder
Props and Configuration
Composition vs Inheritance
Styling Strategies
Handling State and Logic
Building a Design System
Common Mistakes to Avoid
Why This Approach Works
Watch Out For
Next Steps You Can Take
Interesting Facts
FAQ
Conclusion

1. Introduction

As React applications grow, managing UI becomes increasingly complex. Without a reusable component strategy, developers often duplicate UI patterns, leading to inconsistent designs and bloated codebases.
Reusable components solve this by encapsulating UI and behavior into modular building blocks. When done correctly, they create a system where features can be built faster and maintained more easily.

“Simplicity is prerequisite for reliability.” - Edsger W. Dijkstra

2. What Are Reusable Components?

Reusable components are UI elements that can be used across multiple parts of an application without modification.
Examples:

Buttons
Inputs
Modals
Cards
Tables
They are not tied to:
Specific pages
Business logic
Hardcoded data

3. Component Design Principles

1. Single Responsibility
Each component should handle one concern.

2. Reusability Over Specificity
Avoid embedding business logic inside UI components.

3. Predictable API
Props should be clear, consistent, and minimal.

4. Composition First
Build complex UI by combining smaller components.

4. Types of Reusable Components

1. Presentational Components

Focus only on UI
No business logic Example: Button, Card, Avatar

2. Container Components

Handle data and logic
Pass data to presentational components

3. Layout Components

Define page structure Example: Grid, Container, Sidebar

4. Compound Components

Multiple components working together Example: Tabs, Dropdown, Accordion

“Duplication is the root of all evil in software.” - Don’t Repeat Yourself principle

5. Structuring Your Component Folder

A scalable structure looks like:

components/
  ui/
    Button/
      Button.jsx
      Button.css
      index.js
  forms/
    Input/
    Select/
  layout/
    Container/

Key idea:

Group by feature or type, not by file type

6. Props and Configuration

Props are the backbone of reusability.
Example:

function Button({ variant = "primary", children, onClick }) {
  return (
    <button className={`btn btn-${variant}`} onClick={onClick}>
      {children}
    </button>
  );
}

Usage:

<Button variant="secondary">Cancel</Button>
<Button variant="primary">Save</Button>

Avoid:

Hardcoding values
Passing too many unrelated props

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” - Martin Fowler

7. Composition vs Inheritance

React favors composition over inheritance.
Bad approach:

Extending components like classes Good approach:

<Card>
  <Card.Header>Title</Card.Header>
  <Card.Body>Content</Card.Body>
</Card>

This keeps components:

Flexible
Readable
Easy to extend

8. Styling Strategies

Consistency in styling is critical.
Options:

1. CSS Modules

Scoped styles
Prevent conflicts

2. Tailwind CSS

Utility-first
Fast development

3. Styled Components

Dynamic styling
Component-level styles

Best practice:

Choose one approach and stay consistent

9. Handling State and Logic

Reusable components should avoid heavy logic.
Good pattern:

Keep logic outside
Pass data via props Bad:

// tightly coupled
function UserCard() {
  const user = fetchUser();
}

Good:

function UserCard({ user }) {
  return <div>{user.name}</div>;
}

10. Building a Design System

At scale, reusable components evolve into a design system.
A design system includes:

UI components
Design tokens (colors, spacing, typography)
Usage guidelines

Benefits:

Consistency across teams
Faster onboarding
Easier scaling ## 11. Common Mistakes to Avoid

Over-abstracting too early

Don’t generalize before patterns emerge.

Tight coupling

Avoid linking components to specific APIs or data sources.

Prop explosion

Too many props = hard to use.

Ignoring accessibility

Reusable components must support:

Keyboard navigation
ARIA attributes

12. Why This Approach Works

Reduces duplication
Improves readability
Encourages modular thinking
Makes testing easier
Scales across teams and projects

“The best way to build complex systems is to assemble them from simple, well-defined parts.” - David Parnas

Watch Out For

Over-engineering simple components
Creating unnecessary abstractions
Mixing business logic with UI
Inconsistent naming conventions

Next Steps You Can Take

Refactor duplicated UI into shared components
Introduce a ui/ component library
Document component usage
Add Storybook for visual testing
Enforce design consistency with linting

Interesting Facts

Most large-scale React apps rely heavily on internal component libraries source
Design systems can reduce development time significantly source
Component-driven development is a standard in modern frontend engineering source

16. FAQ

1. How small should a component be?
Small enough to do one job, but not so small that it becomes meaningless.

2. Should every component be reusable?
No. Only abstract when reuse is needed.

3. How do I manage shared components?
Use a centralized components or ui directory.

4. Is Tailwind better for reusable components?
It depends-great for speed, but consistency depends on discipline.

5. Can this scale for large apps?
Yes. This is exactly how large React apps are structured.

17. Conclusion

Building reusable UI components in React is not just about avoiding duplication-it’s about creating a scalable, maintainable architecture.
When done right, you get:

Cleaner code
Faster development
Consistent UI
Easier scaling If your goal is to build production-grade applications, investing in a strong component strategy isn’t optional-it’s foundational.

About the Author:Ankit is a full-stack developer at AddWebSolution and AI enthusiast who crafts intelligent web solutions with PHP, Laravel, and modern frontend tools.

Handling API Errors & Loading States in React (Clean UX Approach)

Abodh Kumar — Wed, 22 Apr 2026 07:40:37 +0000

A user interface is like a joke. If you have to explain it, it is not that good. - Martin LeBlanc

In any real-world React application, you will spend far more time handling what goes wrong than celebrating what goes right. Network failures, slow responses, timeouts, and server errors are not edge cases - they are everyday realities. How you communicate these states to your users defines the quality of your application's user experience.

Key Takeaway

Always model three states - loading, error, and success - for every API call, no exceptions.
Provide meaningful, context-specific error messages - never expose raw error objects to users.
Use skeleton screens instead of spinners where possible to reduce perceived load time.
Implement retry logic with exponential backoff for transient network failures.
Centralize error handling with custom hooks to avoid repeating logic across components.
Distinguish between network errors, HTTP errors, and validation errors - each requires different UX.
Always cancel in-flight requests on component unmount to prevent memory leaks and ghost state updates

Introduction
Understanding the Three API States
Handling Loading States - Spinners, Skeletons & Beyond
Handling API Errors - Graceful Degradation
Building a Custom useFetch Hook
Advanced Techniques
Stats & Interesting Facts
FAQ
Conclusion

1. Introduction

Modern React applications are almost always data-driven, relying on REST APIs, GraphQL endpoints, or third-party services to power their interfaces. Whether you are building a dashboard that fetches analytics data, a shopping app that loads product listings, or a social platform that streams user posts, every API interaction introduces three inevitable possibilities: the data is loading, the data arrived successfully, or something went wrong.
The difference between a great app and a frustrating one often comes down to how gracefully these states are handled. Users who encounter a blank screen during loading, a cryptic "undefined is not an object" message when an error occurs, or an interface that silently fails will lose trust in your product instantly.
This article walks you through a complete, production-ready strategy for handling API errors and loading states in React - covering everything from basic useState patterns and skeleton screens to custom hooks, Axios interceptors, and React Query integration.

2. Understanding the Three API States

Before writing a single line of code, it is essential to model your data fetching around three distinct states. Every API call in your application should reflect exactly one of these states at any given moment:

2.1 The Loading State

The loading state exists from the moment you initiate a request until a response (successful or otherwise) is received. Failing to model this state means users see stale data, empty screens, or worse - an interface that appears broken. A loading state should always trigger visible feedback.

2.2 The Success State

When the API returns the expected data with a successful status code (typically 2xx), the UI transitions to the success state. This is where you render the actual content. Even here, you must consider edge cases like empty arrays, null values, or partially missing fields.

2.3 The Error State

Any response outside the 2xx range, a network timeout, or a connection failure triggers the error state. This is the most neglected of the three, yet it is critical. Users need to know what failed and, where possible, what they can do about it.
A foundational pattern using React's useState hook illustrates this model clearly:

import { useState, useEffect } from 'react';
function UserProfile({ userId }) {
 const [user, setUser] = useState(null);
 const [loading, setLoading] = useState(true);
 const [error, setError] = useState(null);
 useEffect(() => {
   const controller = new AbortController();
   async function fetchUser() {
     try {
       setLoading(true);
       setError(null);
       const res = await fetch(`/api/users/${userId}`, {
         signal: controller.signal
       });
       if (!res.ok) {
         throw new Error(`Server error: ${res.status} ${res.statusText}`);
       }
       const data = await res.json();
       setUser(data);
     } catch (err) {
       if (err.name !== 'AbortError') {
         setError(err.message);
       }
     } finally {
       setLoading(false);
     }
   }
   fetchUser();
   return () => controller.abort(); // cleanup on unmount
 }, [userId]);

 if (loading) return <LoadingSkeleton />;
 if (error) return <ErrorMessage message={error} />;
 return <ProfileCard user={user} />;
}

Design is not just what it looks like and feels like. Design is how it works. - Steve Jobs

3. Handling Loading States - Spinners, Skeletons & Beyond

Not all loading indicators are equal. The choice of loading UI dramatically affects how users perceive your application's speed. Research in UX psychology consistently shows that users tolerate waiting much better when they receive structured, meaningful feedback.

3.1 Spinners - When to Use Them

Spinners (circular progress indicators) are appropriate for short, unpredictable waits - typically actions like form submissions, delete confirmations, or quick one-off requests. They signal activity without implying structure about what is loading. Use them sparingly; overuse of spinners across an interface feels chaotic.

function Spinner() {
 return (
   <div className="spinner-wrapper" role="status" aria-label="Loading">
     <div className="spinner" />
     <span className="sr-only">Loading...</span>
   </div>
 );
}

3.2 Skeleton Screens - The Gold Standard

Skeleton screens render placeholder shapes that mimic the final layout of your content before data arrives. They dramatically reduce perceived loading time by orienting the user to the page structure immediately. Facebook, LinkedIn, YouTube, and Slack all rely heavily on skeleton screens for their primary content feeds.

function ProductCardSkeleton() {
 return (
   <div className="card skeleton">
     <div className="skeleton-image" />
     <div className="skeleton-line wide" />
     <div className="skeleton-line medium" />
     <div className="skeleton-line narrow" />
   </div>
 );
}

// CSS for pulsing animation
/*
.skeleton-line {
 height: 16px;
 background: linear-gradient(90deg, #e0e0e0 25%, #f0f0f0 50%, #e0e0e0 75%);
 background-size: 200% 100%;
 animation: shimmer 1.5s infinite;
 border-radius: 4px;
 margin-bottom: 10px;
}
@keyframes shimmer {
 0% { background-position: 200% 0; }
 100% { background-position: -200% 0; }
}
*/

3.3 Progressive Loading

For data-heavy pages, consider progressive loading: render critical above-the-fold content first, then fetch secondary sections lazily. This approach, combined with React's Suspense boundaries, delivers a fast initial paint even on slower connections.

import { Suspense, lazy } from 'react';
const HeavyChartSection = lazy(() => import('./HeavyChartSection'));
function Dashboard() {
 return (
   <div>
     <HeroMetrics />  {/* Loads immediately */}
     <Suspense fallback={<ChartSkeleton />}>
       <HeavyChartSection />  {/* Loads lazily */}
     </Suspense>
   </div>
 );
}

4. Handling API Errors - Graceful Degradation

Error handling is where most React applications fall short. A robust error handling strategy distinguishes between different failure modes and responds to each appropriately.

4.1 Classifying Errors

Not all errors are the same. Build your error handling logic around these distinct categories:

Network Errors - The request never reached the server (offline, DNS failure, CORS). The user needs to check their connection.
HTTP 4xx Errors - Client-side errors (401 Unauthorized, 403 Forbidden, 404 Not Found, 422 Validation Failed). Each requires a specific response.
HTTP 5xx Errors - Server-side errors (500 Internal Server Error, 503 Service Unavailable). The user should be reassured it is not their fault.
Timeout Errors - The request took too long. Often appropriate to offer a retry.
Validation Errors - The server rejected the data (422). Field-level feedback is critical here.

function classifyError(err, statusCode) {
 if (!statusCode) return { type: 'network', message: 'No internet connection. Please check your network.' };
 if (statusCode === 401) return { type: 'auth', message: 'Your session has expired. Please log in again.' };
 if (statusCode === 403) return { type: 'forbidden', message: 'You do not have permission to view this resource.' };
 if (statusCode === 404) return { type: 'notfound', message: 'The requested resource could not be found.' };
 if (statusCode === 422) return { type: 'validation', message: 'Please check your input and try again.' };
 if (statusCode >= 500) return { type: 'server', message: 'Our servers are having trouble. Please try again shortly.' };
 return { type: 'unknown', message: 'Something went wrong. Please try again.' };
}

4.2 User-Friendly Error Components

Your error component should always communicate what went wrong, ideally offer a recovery action, and never expose raw error objects or stack traces to end users.

function ErrorMessage({ type, message, onRetry }) {
 const icons = {
   network: '📡',
   auth: '🔐',
   forbidden: '🚫',
   notfound: '🔍',
   server: '⚠️',
   unknown: '❓',
 };
 return (
   <div className="error-container" role="alert">
     <span className="error-icon">{icons[type] || icons.unknown}</span>
     <h3 className="error-title">Something went wrong</h3>
     <p className="error-message">{message}</p>
     {onRetry && (
       <button onClick={onRetry} className="retry-button">
         Try Again
       </button>
     )}
   </div>
 );
}

4.3 React Error Boundaries

For rendering errors (not async errors), React's Error Boundary class component catches exceptions thrown during render and prevents the entire tree from unmounting. Pair them with your async error states for comprehensive coverage.

class ErrorBoundary extends React.Component {
 constructor(props) {
   super(props);
   this.state = { hasError: false, error: null };
 }
 static getDerivedStateFromError(error) {
   return { hasError: true, error };
 }
 componentDidCatch(error, info) {
   console.error('ErrorBoundary caught:', error, info);
   // Send to error tracking service (e.g., Sentry)
 }
 render() {
   if (this.state.hasError) {
     return this.props.fallback || <DefaultErrorFallback />;
   }
   return this.props.children;
 }
}
// Usage
<ErrorBoundary fallback={<p>Something went wrong.</p>}>
 <UserDashboard />
</ErrorBoundary>

5. Building a Custom useFetch Hook

Repeating loading/error/success logic in every component is a maintenance nightmare. A custom hook centralizes this logic, ensures consistency, and makes components dramatically cleaner.

5.1 The useFetch Hook

function useFetch(url, options = {}) {
 const [data, setData] = useState(null);
 const [loading, setLoading] = useState(true);
 const [error, setError] = useState(null);
 const abortRef = useRef(null);
 const fetchData = useCallback(async () => {
   // Abort any in-flight request
   if (abortRef.current) abortRef.current.abort();
   const controller = new AbortController();
   abortRef.current = controller;
   setLoading(true);
   setError(null);

   try {
     const res = await fetch(url, {
       ...options,
       signal: controller.signal,
     });
     if (!res.ok) {
       const errData = await res.json().catch(() => ({}));
       throw Object.assign(new Error(errData.message || res.statusText), {
         status: res.status,
       });
     }
     const result = await res.json();
     setData(result);
   } catch (err) {
     if (err.name !== 'AbortError') {
       setError({ message: err.message, status: err.status });
     }
   } finally {
     setLoading(false);
   }
 }, [url]);

 useEffect(() => {
   fetchData();
   return () => abortRef.current?.abort();
 }, [fetchData]);

 return { data, loading, error, refetch: fetchData };
}
// Usage in a component
function ProductList() {
 const { data, loading, error, refetch } = useFetch('/api/products');

 if (loading) return <ProductListSkeleton />;
 if (error) return <ErrorMessage message={error.message} onRetry={refetch} />;
 if (!data?.length) return <EmptyState />;

 return (
   <ul>
     {data.map(product => <ProductCard key={product.id} product={product} />)}
   </ul>
 );
}

5.2 Adding Retry Logic with Exponential Backoff

Transient network errors often resolve themselves within seconds. Implementing automatic retry with exponential backoff dramatically improves resilience in unstable network environments.

async function fetchWithRetry(url, options = {}, maxRetries = 3) {
 for (let attempt = 0; attempt <= maxRetries; attempt++) {
   try {
     const res = await fetch(url, options);
     if (!res.ok && res.status >= 500 && attempt < maxRetries) {
       // Retry on 5xx with exponential backoff: 1s, 2s, 4s
       await new Promise(r => setTimeout(r, Math.pow(2, attempt) * 1000));
       continue;
     }
     return res;
   } catch (err) {
     if (attempt === maxRetries) throw err;
     await new Promise(r => setTimeout(r, Math.pow(2, attempt) * 1000));
   }
 }
}

There are only two types of API calls: those that have failed, and those that have not failed yet. Plan for both. - Unknown, React Community Proverb

6. Advanced Techniques

6.1 Using React Query for Robust Data Fetching

For production applications, React Query (now TanStack Query) provides battle-tested data fetching with built-in caching, background refetching, stale-while-revalidate patterns, and automatic retry - all without writing custom hooks from scratch.

import { useQuery } from '@tanstack/react-query';
function UserProfile({ userId }) {
 const { data, isLoading, isError, error, refetch } = useQuery({
   queryKey: ['user', userId],
   queryFn: () => fetch(`/api/users/${userId}`).then(res => {
     if (!res.ok) throw new Error('Failed to fetch user');
     return res.json();
   }),
   retry: 3,
   retryDelay: attemptIndex => Math.min(1000 * 2 ** attemptIndex, 10000),
   staleTime: 5 * 60 * 1000, // 5 minutes
 });

 if (isLoading) return <LoadingSkeleton />;
 if (isError) return <ErrorMessage message={error.message} onRetry={refetch} />;
 return <ProfileCard user={data} />;
}

6.2 Axios Interceptors for Global Error Handling

When using Axios, interceptors allow you to handle common error scenarios globally - such as redirecting to login on 401, showing a toast notification on 5xx errors, or refreshing tokens transparently.

import axios from 'axios';
import toast from 'react-hot-toast';
const api = axios.create({ baseURL: '/api' });
api.interceptors.response.use(
 response => response,
 error => {
   const status = error.response?.status;
   if (status === 401) {
     window.location.href = '/login';
   } else if (status >= 500) {
     toast.error('Server error. Our team has been notified.');
   } else if (!error.response) {
     toast.error('Network error. Please check your connection.');
   }
   return Promise.reject(error);
 }
);
export default api;

6.3 Optimistic Updates

For actions like liking a post or toggling a bookmark, optimistic updates apply the change to the UI immediately before the server confirms it. If the request fails, the UI rolls back. This technique makes interfaces feel instantaneous.

instantaneous.
function LikeButton({ postId, initialLiked }) {
 const [liked, setLiked] = useState(initialLiked);
 const [likeCount, setLikeCount] = useState(0);
 async function handleLike() {
   // Optimistically update UI
   const wasLiked = liked;
   setLiked(!wasLiked);
   setLikeCount(c => wasLiked ? c - 1 : c + 1);
   try {
     await api.post(`/posts/${postId}/like`, { liked: !wasLiked });
   } catch {
     setLiked(wasLiked);
     setLikeCount(c => wasLiked ? c + 1 : c - 1);
     toast.error('Could not update like. Please try again.');
   }
 }
 return <button onClick={handleLike}>{liked ? '❤️' : '🤍'} {likeCount}</button>;
}

6.4 Global Loading Indicator

For applications with many simultaneous API calls, a global loading bar (like the thin progress bar at the top of GitHub's pages) provides ambient feedback without disrupting the UI. Libraries like NProgress integrate cleanly with React.

import NProgress from 'nprogress';
import 'nprogress/nprogress.css';
// In your Axios instance
api.interceptors.request.use(config => { NProgress.start(); return config; });
api.interceptors.response.use(
 response => { NProgress.done(); return response; },
 error => { NProgress.done(); return Promise.reject(error); }
);

7. Stats & Interesting Facts

According to Google research, 53% of mobile users abandon a site that takes longer than 3 seconds to load. Effective loading state UX directly impacts retention.Source: https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/mobile-page-speed-new-industry-benchmarks/
A study by the Nielsen Norman Group found that users perceive skeleton screens as significantly faster than equivalent spinner-based loading experiences, even when actual load times are identical. Source: https://www.nngroup.com/articles/progress-indicators/
According to State of JS surveys, React Query and SWR are now used by over 40% of React developers who fetch remote data, largely because of their built-in loading and error state management. Source: https://stateofjs.com
Research from Amazon found that every 100ms increase in page load time reduced sales by 1%. Loading state UX is not just a UX concern - it is a business metric.Source: https://www.fastcompany.com/1825005/how-one-second-could-cost-amazon-16-billion-sales
The HTTP Archive reports that the median mobile page makes over 70 separate HTTP requests. Without proper loading state management per request, the cumulative UX degradation is significant. Source: https://httparchive.org/reports/state-of-the-web
Sentry's 2023 developer survey found that unhandled promise rejections from API calls are among the top three sources of JavaScript errors in production React applications. Source: https://sentry.io/resources/developer-survey/
According to UX research by Toptal, 88% of online consumers are less likely to return to a site after a bad user experience - silent API failures with no user feedback are a primary driver of this statistic. Source: https://www.toptal.com/designers/ux/ux-statistics-insights-infographic

Good error messages are a form of documentation. They tell the user what went wrong, why it matters, and what to do about it. - Jakob Nielsen, Nielsen Norman Group

8. FAQ

1. Why should I model loading and error states separately rather than using a single "status" string?

Ans: Using separate boolean flags (loading, error) is simpler for most cases and avoids state machine complexity. However, a single status enum ("idle" | "loading" | "success" | "error") is a valid and arguably more explicit pattern, especially as state logic grows. The critical principle is that all three states must always be represented - never leave any one implicit.

2. What is the difference between a loading skeleton and a placeholder?

Ans: A skeleton screen mimics the actual layout and shape of the content that will appear, giving users a structural preview. A generic placeholder (e.g., a grey box or spinner) gives no structural information. Skeleton screens outperform generic placeholders in perceived performance because they orient the user before the content arrives.

3. Should I use React Query or write custom hooks for data fetching?

Ans: For simple, one-off fetch calls, a custom hook is sufficient and avoids adding a dependency. For production apps with complex caching, pagination, background syncing, or optimistic updates, React Query (TanStack Query) or SWR are strongly recommended. They solve problems that custom hooks inevitably re-implement poorly over time.

4. How should I handle validation errors returned from an API (HTTP 422)?

Ans: Parse the error response body to extract field-level validation messages and display them directly adjacent to the relevant form fields. Never show a generic error message for validation failures - users need to know exactly which field failed and why. React Hook Form and Formik both integrate well with server-side validation error patterns.

5. What should I do if a component unmounts before an API call completes?

Ans: Always use an AbortController to cancel in-flight requests in your useEffect cleanup function. Without this, the component will attempt to update state after unmounting, causing the classic React warning about updating state on an unmounted component, and potentially causing memory leaks.

6. Is it ever appropriate to silently swallow API errors without user feedback?

Ans: Only for non-critical background operations where failure has no impact on the user's task - for example, firing an analytics event or pre-fetching secondary content. For any operation the user explicitly triggered or depends on, always provide feedback. Silent failures destroy user trust.

7. How should I handle errors in React Server Components (Next.js App Router)?

Ans: In Next.js App Router, use the error.tsx file convention to define error boundaries per route segment. For server-side data fetching, use try/catch in async server components and return appropriate fallback UI. The notFound() function handles 404 cases, while the error.tsx boundary handles unexpected errors.

8. How do I test loading and error states in React components?

Ans: Use Mock Service Worker (MSW) to intercept API calls in tests without mocking fetch directly. MSW allows you to simulate slow responses (for loading state tests), 4xx/5xx error responses (for error state tests), and successful responses - giving you realistic integration test coverage of all three states.

9. Conclusion.

Handling API errors and loading states cleanly is not a nice-to-have - it is the baseline of professional React development. Every layer described in this article serves a specific purpose in a complete, user-respecting data fetching strategy:

Explicit state modeling ensures loading, error, and success are always accounted for - never left implicit.
Skeleton screens reduce perceived loading time by orienting users to the page structure before content arrives.
Error classification provides users with actionable, context-specific messages rather than generic failure notices.
Custom hooks centralize data fetching logic and eliminate repetition across components.
Retry logic and request cancellation add resilience and prevent memory leaks in production environments.
React Query and Axios interceptors provide production-grade abstractions for complex data fetching scenarios.

React provides all the primitives you need. The responsibility lies with developers to compose them thoughtfully, test all three states rigorously, and treat error handling as a first-class feature rather than an afterthought.

The best UX is invisible - a user who never sees a cryptic error message, never stares at a blank screen, and always feels in control is experiencing excellent error handling. That invisibility is the mark of a truly polished React application.

About the Author:Abodh is a PHP and Laravel Developer at AddWeb Solution, skilled in MySQL, REST APIs, JavaScript, Git, and Docker for building robust web applications.

Data Fetching Strategies in Next.js - SSR, SSG, ISR, and RSC

Vatsal Acharya — Mon, 20 Apr 2026 10:46:48 +0000

“Performance is not a feature - it’s the foundation. Next.js gives you the tools to build it right.”

Key Takeaways

Next.js provides multiple data fetching strategies depending on performance and freshness needs.
SSR fetches data on every request and is best for dynamic content.
SSG generates pages at build time, making it extremely fast.
ISR updates static pages after deployment without full rebuilds.
RSC (React Server Components) is the modern default in App Router.
Caching in Next.js is controlled using fetch options like cache and revalidate.
Real-world apps use a combination of SSR, SSG, ISR, and RSC - not just one.

Index

Why data fetching strategy matters
Quick comparison table
Server-Side Rendering (SSR)
Static Site Generation (SSG)
- 4b Incremental Static Regeneration (ISR)
React Server Components (RSC)
App Router vs Pages Router
Caching in App Router
Real-world app architecture
Common mistakes
Stats
Interesting Facts
FAQs
Summary
Conclusion

Introduction

Why does data fetching strategy actually matter?

In a classic React app, data fetching is simple: useEffect fires after the component mounts, you hit an API, and update state.

Easy to reason about - but there’s a problem:
The user sees a blank or loading screen until JavaScript executes and the fetch completes.

For small apps, this is fine.
At scale, it becomes a serious UX and SEO issue.

How Next.js Solves This

“Modern web development is not about fetching data - it’s about fetching it intelligently.”

Next.js lets you decide:
Where and when data should be fetched

Each strategy is a tradeoff between:

Freshness
Performance
Server cost
Complexity

Mental Model
Think of it as a spectrum:

Fully Dynamic → SSR
Fully Static → SSG
In Between → ISR + RSC

Quick Reference - All Strategies at a Glance

Important Note
RSC is not a replacement for SSR, SSG, or ISR.
It’s a new rendering model that can behave like any of them.

Strategy 01

Server-Side Rendering (SSR)

When a request comes in:
Next.js fetches data on the server before sending HTML

Pages Router Example

export async function getServerSideProps(context) {
 const { req } = context
 oop-
 const session = await getSession(req)

 if (!session) {
   return {
     redirect: {
       destination: '/login',
       permanent: false
     }
   }
 }

 const res = await fetch(`https://api.example.com/users/${session.userId}`)
 const user = await res.json()

 return {
   props: { user }
 }
}

Key Behavior

Runs on every request
Full HTML is returned
No loading state on client

When to Use SSR

User-specific content
Authentication logic
Real-time data
Accessing cookies/headers

When NOT to Use SSR

Same data for all users
Rarely changing content
Performance-sensitive pages

Important
SSR adds latency - your API speed = your page speed.

Strategy 02

Static Site Generation (SSG)

SSG generates pages at build time and serves static HTML.

Example

export async function getStaticProps() {
 const res = await fetch('https://api.example.com/posts')
 const data = await res.json()

 return {
   props: { data }
 }
}

Dynamic Routes Example

export async function getStaticPaths() {
 const res = await fetch('https://api.example.com/posts')
 const posts = await res.json()

 return {
   paths: posts.map(post => ({
     params: { slug: post.slug }
   })),
   fallback: false
 }
}

When to Use SSG

Blogs
Docs
Landing pages

Tradeoff

Very fast
Not real-time

Strategy 03

Incremental Static Regeneration (ISR)

ISR = SSG + automatic updates

How It Works

Serve static page
After interval → regenerate in background
Next request gets fresh page

Example

export async function getStaticProps() {
 const res = await fetch('https://api.example.com/products')
 const products = await res.json()

 return {
   props: { products },
   revalidate: 60
 }
}

Key Insight

Revalidation only happens when a request comes
No traffic = no update

On-Demand ISR (Better Approach)

export default async function handler(req, res) {
 if (req.headers['x-webhook-secret'] !== process.env.WEBHOOK_SECRET) {
   return res.status(401).json({ message: 'Unauthorized' })
 }

 const { slug } = req.body

 await res.revalidate(`/products/${slug}`)

 return res.json({ revalidated: true })
}

When to Use ISR

Product pages
News
CMS-driven content

Strategy 04 (Modern Default)

React Server Components (RSC)

“RSC changes the game: less JavaScript, better performance, cleaner architecture.”

In App Router:
Components run on the server by default

Example

async function getProducts() {
 const res = await fetch('https://api.example.com/products', {
   next: { revalidate: 60 }
 })

 return res.json()
}

export default async function Page() {
 const products = await getProducts()

 return (
   <div>
     {products.map(p => (
       <p key={p.id}>{p.name}</p>
     ))}
   </div>
 )
}

Controlling Behavior

fetch(url, { cache: 'force-cache' }) // SSG
fetch(url, { cache: 'no-store' }) // SSR
fetch(url, { next: { revalidate: 60 } }) // ISR

Key Benefits

No useEffect
No client-side fetching
Smaller JS bundle

Important Rule
Client components cannot import server components
Data flows server → client

Architecture

App Router vs Pages Router

Pages Router

getServerSideProps / getStaticProps
Page-level fetching
Older system

App Router

Async components
Component-level fetching
Server-first approach
Supports streaming App Router is the future

Deep Dive

Caching in App Router

There are 4 cache layers:

Common Issue

“Why is my data not updating?”
Usually due to Router cache

Fix

router.refresh()

Revalidation Example

import { revalidateTag } from 'next/cache'
revalidateTag('products')

Production Patterns

Real-World Architecture

E-commerce

Homepage → SSG
Product Page → ISR
Cart → SSR
Layout → RSC

SaaS

Landing → SSG
Dashboard → SSR
Docs → ISR

Real apps use combination of strategies

“The best data fetching strategy is not SSR or SSG - it’s choosing the right one at the right time.”

Anti-Patterns

Common Mistakes

1. Using SSR everywhere
Expensive + slow
Use ISR instead

2. Ignoring server/client boundary
Causes runtime errors

3. No error handling
Can crash entire page

4. Fetching in client unnecessarily
Adds JS + loading delay

5. Misunderstanding ISR timing
Low traffic = stale data

Stats

According to Vercel, static generation can significantly improve performance by serving pre-rendered pages from a CDN, reducing server computation.Source: https://nextjs.org/docs/pages/building-your-application/rendering/static-site-generation
Next.js has millions of weekly downloads and is one of the most widely used React frameworks.Source: https://www.npmjs.com/package/next
Next.js is used by companies like Netflix, TikTok, and Hulu for high-performance applications.Source: https://nextjs.org/showcase

Interesting Facts

Next.js was created and is maintained by Vercel.Source: https://nextjs.org
Incremental Static Regeneration (ISR) was introduced in Next.js 9.5.Source: https://nextjs.org/blog/next-9-5
React Server Components (RSC) became stable with the App Router in Next.js 13.Source: https://nextjs.org/blog/next-13
Next.js enables full-stack development by combining frontend and backend capabilities in a single framework.Source: https://nextjs.org/docs

FAQ

1. Is SSR outdated?
No - it’s still essential for dynamic and user-specific data.

2. Is RSC replacing SSR/SSG?
No - it enhances them and gives more flexibility.

3. Can we mix all strategies?
Yes - and that’s the recommended approach.

4. Which is best for SEO?
SSG and SSR both are great for SEO.

5. Can ISR work with dynamic routes?
Yes

6. Where to store API keys?
Server-side only

7. App Router or Pages Router?
New projects → App Router

8. How to avoid waterfall fetches?
Use RSC

Summary

The Decision Tree

Ask:
Does data change per user?

Yes → SSR / RSC (no-store) Does data rarely change?
Yes → SSG Does it update periodically?
Yes → ISR Using App Router?
Use RSC + fetch control

Final Insight

Use Server Components for data
Use Client Components for interactivity
Use ISR for scalability

Conclusion

Data fetching in Next.js is not about memorizing functions…
It’s about choosing the right strategy at the right time.

Use SSR for dynamic data
Use SSG for static content
Use ISR for balance
Use RSC for modern optimization

Once you understand this:

Your apps become faster
Your architecture becomes scalable
Your performance improves significantly

About the Author:Vatsal is a web developer at AddWebSolution. Building web magic with Laravel, PHP, MySQL, Vue.js & more.

Docker Image with Multi-Stage Builds & Docker Images Optimization

Rajan Vavadia — Wed, 15 Apr 2026 08:24:49 +0000

“Docker is not a virtualization technology. It is an application delivery technology.” - Mike Coleman (Docker)

Introduction
Overview: Multi-Stage Build Strategy (Builder + Production)
Stage 1: Builder - Compile Extensions, Install Tools & Dependencies
Stage 2: Production - Minimal Runtime Image
The .dockerignore File
Practical Setup (Step-by-step)
Quotes
FAQs
Key Takeaways
Conclusion

1. Introduction

This document explains how to build a production-ready PHP 8.4-FPM Docker image using a multi-stage Dockerfile. The image ships with all the PHP extensions, CLI tools (Composer, WP-CLI, Drush, Drupal Console), and Node.js needed for WordPress and Drupal projects - while keeping the final image lean and secure.

The approach uses a two-stage build:

Stage 1 (Builder): Compiles PHP extensions, installs development tools, and downloads CLI utilities.
Stage 2 (Production): Starts from a clean php:8.4-fpm base, copies only the compiled artifacts and runtime libraries, applies security hardening, and runs as a non-root user.

Why multi-stage?

A single-stage Dockerfile that compiles extensions and installs build tools leaves behind compilers, header files, and package caches that bloat the image and increase the attack surface. Multi-stage builds solve this by discarding everything that is not needed at runtime.

2. Overview: Multi-Stage Build Strategy (Builder + Production)

Stage 1 (Builder) starts from php:8.4-fpm and installs: - 20+ PHP extensions using install-php-extensions (handles build dependencies and cleanup internally). - Composer, WP-CLI, Drush, and Drupal Console. - Node.js 20.x for front-end tooling.

Stage 2 (Production) starts from a fresh php:8.4-fpm and: - Copies compiled extension .so files and their .ini configs from the builder. - Copies CLI binaries (Composer, WP-CLI, Drush, Drupal Console, Node.js). - Installs only the runtime shared libraries needed by the extensions. - Applies OPcache tuning and PHP security settings. - Creates a non-root user (appuser) for PHP-FPM. - Add a health check.

Why separate stages?

Smaller image: Build tools (gcc, make, autoconf, header files) are discarded. Only runtime libraries remain.
Faster pulls and deploys: Less data to transfer across registries and hosts.
Reduced attack surface: No compilers or dev packages in production.
Clearer troubleshooting: Build failures are isolated to Stage 1; runtime issues are isolated to Stage 2.

3. Stage 1: Builder - Compile Extensions, Install Tools & Dependencies

3.1 Base Image

FROM php:8.4-fpm AS builder
We use the official php:8.4-fpm image (based on Debian 13 Trixie) as the builder base. This gives us the PHP source, phpize, and docker-php-ext-install out of the box.

3.2 PHP Extension Installation

Single tool for all PHP extensions (handles build deps + cleanup internally)
COPY --from=mlocati/php-extension-installer /usr/bin/install-php-extensions /usr/bin/

Install all PHP extensions in one layer
RUN install-php-extensions \
bcmath \
bz2 \
calendar \
exif \
gd \
gmp \
imagick \
intl \
mailparse \
mongodb \
mysqli \
opcache \
pcntl \
pdo \
pdo_mysql \
pdo_pgsql \
soap \
sockets \
sodium \
xsl \
zip

Why install-php-extensions?

It automatically installs the OS-level build dependencies (e.g., libpng-dev, libicu-dev), compiles the extension, and removes the build dependencies - all in one step.
It replaces the manual apt-get install && docker-php-ext-configure && docker-php-ext-install && apt-get purge pattern.
It supports PECL extensions (like imagick, mongodb, mailparse) with the same syntax.
We use COPY --from=mlocati/php-extension-installer to pull the binary directly from the tool’s official image, without adding another FROM stage.

Extensions included and why:

3.3 CLI Tools Installation
Install Composer, WP-CLI, Drush, and Drupal Console in one layer
RUN apt-get update && apt-get install -y --no-install-recommends \
git \
unzip \
&& rm -rf /var/lib/apt/lists/* \
Composer
&& curl -sSL https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer \
WP-CLI
&& curl -sSL https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar -o /usr/local/bin/wp \
&& chmod +x /usr/local/bin/wp \
Drupal Console
&& curl -sSL https://drupalconsole.com/installer -o /usr/local/bin/drupal \
&& chmod +x /usr/local/bin/drupal

Composer: PHP dependency manager. Installed globally at /usr/local/bin/composer.
WP-CLI: WordPress command-line interface for managing WordPress installations.
Drupal Console: CLI tool for generating boilerplate code and interacting with Drupal.
git and unzip are needed by Composer to fetch packages; they are installed here but not carried over to the production stage.

3.4 Drush Installation

ENV COMPOSER_HOME=/usr/local/share/composer
RUN composer global require drush/drush:8.* --no-interaction --prefer-dist
Drush (Drupal Shell) is installed globally via Composer. COMPOSER_HOME is set explicitly so the entire vendor directory can be copied to the production stage.

3.5 Node.js Installation

RUN curl -fsSL https://deb.nodesource.com/setup_20.x | bash - \
&& apt-get install -y --no-install-recommends nodejs \
&& rm -rf /var/lib/apt/lists/*
Node.js 20.x (LTS) is installed for front-end build tools (npm scripts, asset compilation). NVM is intentionally avoided - a single global Node.js installation is simpler and more predictable in a container.

“Build once, run anywhere - but make sure what you build is only what you need.” - Container best practice principle

4. Stage 2: Production - Minimal Runtime Image

4.1 Fresh Base and Labels

FROM php:8.4-fpm AS production

LABEL maintainer="AddWeb Solutions" \
description="PHP 8.4-FPM production image with WordPress/Drupal tooling"
A fresh php:8.4-fpm base - none of the builder’s build tools, caches, or temp files exist here.

4.2 Copying Artifacts from Builder

Copy PHP extensions and their configs from builder
COPY --from=builder /usr/local/lib/php/extensions/ /usr/local/lib/php/extensions/
COPY --from=builder /usr/local/etc/php/conf.d/ /usr/local/etc/php/conf.d/

Copy CLI tools from builder
COPY --from=builder /usr/local/bin/composer /usr/local/bin/composer
COPY --from=builder /usr/local/bin/wp /usr/local/bin/wp
COPY --from=builder /usr/local/bin/drupal /usr/local/bin/drupal
COPY --from=builder /usr/local/share/composer /usr/local/share/composer

Copy Node.js from builder
COPY --from=builder /usr/bin/node /usr/bin/node
COPY --from=builder /usr/bin/npm /usr/bin/npm
COPY --from=builder /usr/bin/npx /usr/bin/npx
COPY --from=builder /usr/lib/node_modules /usr/lib/node_modules
COPY --from=builder selectively pulls only the compiled .so files, .ini configs, and CLI binaries. Everything else (compilers, header files, build caches) is left behind.

4.3 Runtime Libraries

RUN apt-get update && apt-get install -y --no-install-recommends \
# Runtime libs required by PHP extensions
libbz2-1.0 \
libfreetype6 \
libgmp10 \
libicu76 \
libjpeg62-turbo \
libmagickwand-7.q16-10 \
libavif16 \
libpng16-16 \
libpq5 \
libxslt1.1 \
libzip5 \
# Essential runtime utilities only
cron \
curl \
default-mysql-client \
ffmpeg \
sendmail \
supervisor \
unzip \
sqlite3 \
&& apt-get purge -y --auto-remove -o APT::AutoRemove::RecommendsImportant=false \
&& rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

Key points:

Runtime libs only: We install the shared libraries (.so files) that the compiled PHP extensions link against. These are the -dev-less counterparts (e.g., libpng16-16 not libpng-dev).
Debian Trixie package names: Since php:8.4-fpm is based on Debian 13 (Trixie), some package names differ from Bookworm (e.g., libicu76 instead of libicu72, libmagickwand-7.q16-10 instead of libmagickwand-6.q16-6, libzip5 instead of libzip4).
Essential utilities: cron (scheduled tasks), curl (health checks, API calls), default-mysql-client (database operations), ffmpeg (media processing), sendmail (email delivery), supervisor (process management), unzip, sqlite3.
Cleanup: apt-get purge --auto-remove removes packages that were pulled in only as install dependencies, and rm -rf /var/lib/apt/lists/* clears the package cache.

Runtime libraries mapped to extensions:

4.4 Drush Symlink

ENV COMPOSER_HOME=/usr/local/share/composer
RUN ln -s /usr/local/share/composer/vendor/bin/drush /usr/local/bin/drush
Makes drush available in $PATH without modifying the PATH variable.

4.5 OPcache Tuning

RUN { \
echo 'opcache.memory_consumption=128'; \
echo 'opcache.interned_strings_buffer=8'; \
echo 'opcache.max_accelerated_files=4000'; \
echo 'opcache.revalidate_freq=60'; \
echo 'opcache.fast_shutdown=1'; \
echo 'opcache.enable_cli=1'; \
echo 'opcache.validate_timestamps=0'; \
} > /usr/local/etc/php/conf.d/opcache-recommended.ini

validate_timestamps=0 is a production optimization - PHP never starts the filesystem to check if files have changed. When you deploy new code, restart PHP-FPM to pick up the changes.

4.6 Security Hardening

RUN { \
echo 'expose_php=Off'; \
echo 'display_errors=Off'; \
echo 'log_errors=On'; \
echo 'error_log=/dev/stderr'; \
echo 'allow_url_fopen=Off'; \
} > /usr/local/etc/php/conf.d/security.ini

4.7 Non-Root User

RUN groupadd -g 1000 appuser && useradd -u 1000 -g appuser -m appuser

WORKDIR /var/www/html
RUN chown -R appuser:appuser /var/www/html
Running PHP-FPM as a non-root user reduces the blast radius if the application is compromised. The appuser (UID 1000) owns the web root.

4.8 Health Check

HEALTHCHECK --interval=30s --timeout=5s --retries=3 \
CMD php-fpm-healthcheck || kill -0 $(cat /var/run/php-fpm.pid 2>/dev/null) || exit 1
Docker checks every 30 seconds whether PHP-FPM is responding. After 3 consecutive failures, the container is marked unhealthy, and orchestrators (Docker Compose, Swarm, Kubernetes) can restart it.

4.9 Expose and CMD

EXPOSE 9000

CMD ["php-fpm"]
PHP-FPM listens on port 9000 (FastCGI). A reverse proxy (Nginx, Apache, Caddy) forwards requests to this port.

5. The .dockerignore File

.git
.github
.gitignore
.md
LICENSE
docker-compose.yml
.env*
.vscode
.idea
node_modules
vendor
.docker

The .dockerignore prevents unnecessary files from being sent to the Docker build context. This speeds up builds and avoids leaking secrets (.env files) or bloating the image with node_modules or vendor directories.

6. Practical Setup (Step-by-step)

6.1 Build the Image

docker build -t php8.4-multistage --target production .
The --target production flag tells Docker to stop at the production stage and discard the builder. If --target is omitted, Docker builds up to the last stage (which is already in production in this Dockerfile).

6.2 Run the Container

docker run -d \
--name php-app \
-p 9000:9000 \
-v ./src:/var/www/html \
php8.4-multistage
Mount your application source code at /var/www/html. PHP-FPM will serve it on port 9000.

6.3 Pair with Nginx (docker-compose example)

version: '3.8'

services:
php:
build:
context: .
target: production
volumes:
- ./src:/var/www/html
networks:
- app-network

nginx:
image: nginx:alpine
ports:
- "80:80"
volumes:
- ./src:/var/www/html
- ./nginx.conf:/etc/nginx/conf.d/default.conf
depends_on:
- php
networks:
- app-network

networks:
app-network:
driver: bridge

6.4 Verify Extensions

docker exec php-app php -m
This lists all loaded PHP modules. Confirm that gd, imagick, intl, opcache, pdo_mysql, etc., are all present.

6.5 Verify CLI Tools

docker exec php-app composer --version
docker exec php-app wp --version
docker exec php-app drush --version
docker exec php-app node --version
docker exec php-app npm --version

6.6 Check phpinfo

Create a phpinfo file
docker exec php-app bash -c "echo '<?php phpinfo();' > /var/www/html/info.php"

Quick test with built-in server
docker exec -d php-app php -S 0.0.0.0:8085 -t /var/www/html
Open http://localhost:8085/info.php in your browser to see the full PHP configuration. Remove info.php after testing - never leave it exposed in production.

6.7 Common Improvements (optional)

Use BuildKit cache mounts to speed up repeated builds: RUN --mount=type=cache,target=/var/cache/apt apt-get update && ...
Pin the PHP version (e.g., php:8.4.18-fpm) for reproducible builds instead of using the floating 8.4-fpm tag.
Add a .env-based PHP config layer for settings that vary between environments (memory_limit, upload_max_filesize).
Use Docker Compose profiles to add Xdebug only in development (avoid Xdebug in production).
Scan the image with Trivy or Docker Scout for vulnerability reporting before pushing to a registry.

“The art of simplicity is a puzzle of complexity.” - Douglas Horton

8. FAQs

Q1. Why use multi-stage builds instead of a single Dockerfile?
A. A single-stage build carries compilers, dev headers, and package caches into the final image. Multi-stage builds discard all of that, resulting in a smaller, more secure image.

Q2. Why install-php-extensions instead of docker-php-ext-install? A. install-php-extensions handles OS dependency installation, extension compilation, and cleanup automatically. It also supports PECL extensions (imagick, mongodb, mailparse) with the same syntax, eliminating the need for separate pecl install commands.

Q3. Why is the base image Debian Trixie? Can I use Bookworm or Alpine?
A. The official php:8.4-fpm tag is built on Debian 13 (Trixie) as of 2025. If you need Bookworm, use php:8.4-fpm-bookworm. Alpine (php:8.4-fpm-alpine) is smaller but uses musl libc, which can cause compatibility issues with some extensions (notably ImageMagick).

Q4. Why are the runtime library package names different from older guides?
A. Debian Trixie renamed several packages as part of the 64-bit time_t transition and library version bumps. For example: libicu72 became libicu76, libmagickwand-6.q16-6 became libmagickwand-7.q16-10, and libzip4 became libzip5. Always verify package names against the base image’s Debian version.

Q5. How do I find the correct runtime library names if I change the base image?
A. Run a temporary container and use ldd to check for missing libraries:
docker run --rm your-image bash -c \
"for so in /usr/local/lib/php/extensions//.so; do \
ldd \$so 2>/dev/null | grep 'not found'; \
done"
Then search for the correct package with apt-cache search .

Q6. What does validate_timestamps=0 mean for deployments?
A. OPcache will never check if PHP files on disk have changed. This avoids filesystem stat calls on every request (faster). The tradeoff: after deploying new code, you must restart PHP-FPM (docker restart ) to pick up changes.

Q7. Why create a non-root user?
A. Running as root inside a container means a compromised application has full control over the container filesystem. A non-root user limits the damage.

Q8. Can I add Xdebug for local development?
A. Yes, but do not include it in the production image. Use a separate development stage or a Docker Compose override file that installs Xdebug on top of the production image.

9. Key Takeaways

Multi-stage builds separate build-time complexity from runtime simplicity.
install-php-extensions eliminates the manual dance of installing dev packages, compiling, and cleaning up.
Always match runtime library package names to the base image’s Debian version (Trixie uses libicu76, libzip5, libmagickwand-7.q16-10, libavif16).
OPcache with validate_timestamps=0 is a significant performance win for production.
Security hardening (expose_php=Off, display_errors=Off, allow_url_fopen=Off) should be the default, not an afterthought.
Non-root user + health check + .dockerignore round out a production-ready setup.
Use ldd to diagnose missing shared libraries when extensions fail to load.

10. Conclusion

This multi-stage Dockerfile provides a clean, repeatable way to build a PHP 8.4-FPM production image with everything needed for WordPress and Drupal projects. The builder stage handles all the heavy lifting - compiling extensions, installing Composer, WP-CLI, Drush, Drupal Console, and Node.js - while the production stage starts fresh and copies only what is needed at runtime. Combined with OPcache tuning, security hardening, a non-root user, and a health check, the result is an image that is smaller, faster, and more secure than a traditional single-stage build. When paired with Nginx via Docker Compose, it forms a solid foundation for deploying PHP applications in any environment.

About the Author:Rajan is a DevOps Engineer at AddWebSolution, specializing in automation infrastructure, Optimize the CI/CD Pipelines and ensuring seamless deployments.

Architecting Large-Scale Next.js Applications (Folder Structure, Patterns, Best Practices)

Mayank Goyal — Mon, 13 Apr 2026 10:25:46 +0000

“Good architecture makes the system easy to understand; great architecture makes it hard to break.”

Key Takeaways

Feature-based architecture is critical
Separate UI, logic, and data layers
Prefer server components for performance
Centralize API logic
Use scalable state management
Optimize early, not later

Index

Introduction
Why Architecture Matters
Core Principles of Scalable Architecture
Advanced Folder Structure (Enterprise-Level)
Architectural Patterns (Deep Dive)
State Management at Scale
Data Fetching & API Layer Design
Authentication & Authorization Architecture
Performance Optimization (Advanced)
Error Handling & Logging
Testing Strategy (Production-Ready)
Dev Experience & Code Quality
Deployment & Infrastructure Strategy
Real-World Example (Enterprise Dashboard)
Interesting Facts
Stats
FAQ’s
Conclusion

Introduction

Building small Next.js apps is easy. Scaling them to support millions of users, multiple developers, and complex business logic is not.
Large-scale applications require:

Clean architecture
Predictable structure
Separation of concerns
Strong conventions Next.js (especially App Router) provides powerful primitives, but it does NOT enforce architecture, that’s your responsibility.

This guide gives you a production-grade blueprint.

Why Architecture Matters

At scale, poor architecture leads to:

Tight coupling between components
Duplicate logic across features
Slow builds & performance bottlenecks
Difficult onboarding for new developers

Good architecture enables:

Independent feature development
Faster debugging
Better scalability
Easier refactoring

Core Principles of Scalable Architecture

1. Separation of Concerns
Divide responsibilities:

UI → components
Logic → hooks/services
Data → API layer

2. Feature Isolation
Each feature should be self-contained.
Think like mini-apps inside your app.

3. Single Responsibility Principle
Each file/module should do one thing well.

4. Dependency Direction
Components depend on hooks
Hooks depend on services
Services depend on APIs
NOT the other way around.

5. Scalability First Mindset
Design for scale even if you’re small today.

Advanced Folder Structure (Enterprise-Level)

src/
│
├── app/                         # Next.js App Router
│   ├── (public)/
│   ├── (auth)/
│   ├── dashboard/
│   │   ├── layout.tsx
│   │   ├── page.tsx
│
├── features/                    # Feature modules (CORE)
│   ├── auth/
│   │   ├── components/
│   │   ├── hooks/
│   │   ├── services/
│   │   ├── api/
│   │   ├── store/
│   │   └── types.ts
│   │
│   ├── products/
│   ├── orders/
│   └── users/
│
├── shared/                      # Cross-feature reusable code
│   ├── components/
│   ├── hooks/
│   ├── utils/
│   └── constants/
│
├── core/                        # App-level logic
│   ├── config/
│   ├── providers/
│   ├── middleware/
│   └── guards/
│
├── services/                    # Global services (rare)
├── lib/                         # Low-level utilities
├── types/                       # Global types
├── styles/
└── tests/

“Fetching data is easy. Fetching it efficiently is architecture.”

Key Insight
Avoid “global chaos” folders like components/ for everything
Prefer feature-based grouping

Architectural Patterns (Deep Dive)

1. Feature-Based Architecture (MOST IMPORTANT)
Each feature owns:
UI
logic
API calls
state

features/products/
    components/
    hooks/
    services/
    store/

2. Layered Architecture

UI Layer (Components)
↓
Hooks Layer (Business Logic)
↓
Service Layer (API Calls)
↓
API Layer (External systems)

3. Server vs Client Component Strategy

Example:

// Server Component
export default async function Page() {
  const data = await getProducts();
  return <ProductsClient data={data} />;
}

4. Smart vs Dumb Components
Smart → fetch + logic
Dumb → UI only

5. Composition Pattern
Avoid inheritance. Use composition:

<Card>
  <ProductInfo />
</Card>

State Management at Scale

When NOT to use global state

Static data
Server-fetched data

Recommended Strategy

Example (Zustand Advanced)

import { create } from 'zustand';
export const useCartStore = create((set) => ({
  items: [],
  addItem: (item) =>
    set((state) => ({ items: [...state.items, item] })),
  clearCart: () => set({ items: [] })
}));

Data Fetching & API Layer Design

Bad Practice
Calling fetch directly in components everywhere.

Good Practice

features/products/
  services/productService.ts

export const getProducts = async () => {
  const res = await fetch('/api/products');
  return res.json();
};

“Every unnecessary render is a tax on your use.”

Caching Strategy

Authentication & Authorization Architecture

Recommended Setup

Middleware for route protection
Server-side session validation
Role-based access Example:

// middleware.ts
export function middleware(req) {
  const token = req.cookies.get('token');
  if (!token) return Response.redirect('/login');
}

Performance Optimization (Advanced)

Techniques

Code splitting (dynamic imports)
Partial hydration
Edge rendering
Image optimization
Memoization

Example

const Chart = dynamic(() => import('./Chart'), {
  ssr: false
});

Error Handling & Logging

Centralized Error Handling

export const handleError = (error) => {
  console.error(error);
};

Logging Tools

Sentry
LogRocket

Testing Strategy (Production-Ready)

Example

test('adds item to cart', () => {
  const store = useCartStore.getState();
  store.addItem({ id: 1 });
  expect(store.items.length).toBe(1);
});

Dev Experience & Code Quality

ESLint + Prettier
Husky (pre-commit hooks)
Strict TypeScript
Absolute imports (@/features/...)

Deployment & Infrastructure Strategy

Recommended Stack

Hosting → Vercel
DB → PostgreSQL
CDN → Cloudflare
Monitoring → Sentry

Scaling Tips

Use Edge Functions
Optimize bundle size
Enable caching

Real-World Example (Enterprise Dashboard)

Structure

features/dashboard/
   components/
      StatsCard.tsx
   hooks/
      useStats.ts
   services/
      dashboardService.ts

Service

export const fetchStats = async () => {
  const res = await fetch('/api/stats');
  return res.json();
};

Hook

export const useStats = () => {
  const [stats, setStats] = useState(null);

  useEffect(() => {
    fetchStats().then(setStats);
  }, []);

  return stats;
};

Component

export const StatsCard = ({ data }) => {
  return <div>{data.totalUsers}</div>;
};

Page

export default function DashboardPage() {
  const stats = useStats();

  if (!stats) return <p>Loading...</p>;

  return <StatsCard data={stats} />;
}

Interesting Facts

Next.js App Router defaults to Server Components.Source: https://nextjs.org/docs/app/building-your-application/rendering/server-components
Middleware runs at the Edge.Source: https://nextjs.org/docs/pages/api-reference/file-conventions/middleware
File-based routing reduces ~40% boilerplate.Source: https://nextjs.org/docs/app/building-your-application/routing
Built-in optimizations replace many libraries.Source: https://nextjs.org/docs/architecture
ISR allows hybrid static + dynamic pages.Source: https://nextjs.org/docs/pages/building-your-application/rendering/incremental-static-regeneration

Stats

Next.js is one of the fastest-growing React frameworks and is widely adopted for production-grade applications. Source: https://nextjs.org/showcase
Next.js has 120,000+ stars on GitHub, reflecting its strong developer adoption and community support. Source: https://github.com/vercel/next.js
According to the State of JS survey, Next.js consistently ranks among the top frameworks in developer satisfaction and usage. Source: https://stateofjs.com/
Vercel, the company behind Next.js, serves billions of requests per week across applications deployed on its platform. Source: https://vercel.com/customers
Next.js enables hybrid rendering (SSR, SSG, ISR), which improves performance and scalability for modern web applications. Source: https://nextjs.org/docs/pages/building-your-application/rendering
File-based routing in Next.js simplifies development by automatically mapping files to routes, reducing manual configuration. Source: https://nextjs.org/docs/app/building-your-application/routing

FAQ’s

Q1. Is Redux necessary?
No. Use Zustand unless you need complex workflows.

Q2. How to organize large teams?

Feature ownership
Code reviews
Clear folder structure

Q3. Should I use monorepo?
Yes, for multi-app systems (Nx / Turborepo).

Q4. Where to keep reusable components?
shared/components

Q5. What is the biggest mistake?
Mixing everything in global folders.

Conclusion

Scaling a Next.js application is more about architecture than code. The difference between a messy app and a scalable system lies in:

Structure
Discipline
Consistency By following feature-based design, layered architecture, and modern Next.js patterns, you can build applications that scale effortlessly with both users and teams.

About the Author:Mayank is a web developer at AddWebSolution, building scalable apps with PHP, Node.js & React. Sharing ideas, code, and creativity.

ELK Stack Setup for Centralized Log Management & Monitoring

Rajan Vavadia — Wed, 08 Apr 2026 11:42:01 +0000

“The goal is to turn data into information, and information into insight.” - Carly Fiorina

Introduction
Stage 1: Elasticsearch - The Search & Storage Engine
Stage 2: Logstash - The Data Processing Pipeline
Stage 3: Kibana - The Visualization Layer
Stage 4: Filebeat - The Lightweight Log Shipper
Connecting the Pieces - End-to-End Data Flow
Practical Setup (Step-by-step)
Troubleshooting Common Issues
Quotes
FAQs
Key Takeaways
Conclusion

1. Introduction

When your application runs on a single server, tailing a log file is enough. When it runs across multiple servers, containers, or microservices - you need centralized logging. Scattered logs across dozens of servers make debugging slow, error correlation impossible, and incident response reactive instead of proactive.

This guide walks through setting up a production-ready ELK stack (Elasticsearch, Logstash, Kibana) with Filebeat for centralized log collection, processing, and visualization. The setup covers a real-world scenario: a Java Spring Boot application running on one server, with the ELK stack on a separate server.

The approach uses a four-component architecture:

Filebeat (Application Server): Lightweight agent that tails log files and ships them to Logstash.
Logstash (ELK Server): Receives raw logs, parses and transforms them, and forwards structured data to Elasticsearch.
Elasticsearch (ELK Server): Stores, indexes, and makes logs searchable in near real-time.
Kibana (ELK Server): Web UI for searching, visualizing, and building dashboards from log data.

Why centralized logging?
Manually SSH-ing into each server and grepping through log files does not scale. Centralized logging solves this by aggregating all logs into a single searchable location.
You get:

Single pane of glass for all application and infrastructure logs.
Real-time search across millions of log entries in milliseconds.
Correlation of events across services and servers by timestamp.
Alerting on error patterns before users report issues.
Retention and compliance with configurable index lifecycle policies.

Component Responsibilities

Why separate servers?

- Resource isolation: Elasticsearch is memory-hungry. Running it on the application server competes with your app for RAM and CPU.
- Independent scaling: You can scale the ELK server (more RAM, bigger disk) without touching production application servers.
- Security boundary: The ELK server can sit in a private subnet, accessible only to internal services and authorized users.

2. Stage 1: Elasticsearch - The Search & Storage Engine

2.1 What is Elasticsearch?
Elasticsearch is a distributed search and analytics engine built on Apache Lucene. In the ELK stack, it serves as the storage and search backend - every log line that Logstash processes ends up as a document in an Elasticsearch index.

2.2 Installation
Import the Elasticsearch GPG key
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg

Add the APT repository
echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list

Install Elasticsearch
sudo apt-get update && sudo apt-get install -y elasticsearch

2.3 Configuration
The main configuration file is /etc/elasticsearch/elasticsearch.yml:
Cluster and node identity
cluster.name: my-cluster
node.name: node-1

Data and log paths
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

Network - bind to all interfaces for external access
network.host: 0.0.0.0
http.host: 0.0.0.0

Discovery - single node (no cluster formation)
discovery.type: single-node

Security - disable for internal/dev setups
xpack.security.enabled: false
xpack.security.enrollment.enabled: true
xpack.security.http.ssl:
enabled: false
xpack.security.transport.ssl:
enabled: false

Configuration settings explained:

Security note: xpack.security.enabled: false is acceptable for internal/development setups behind a firewall. For production environments exposed to the internet, always enable security with TLS certificates and user authentication.

2.4 Start and Enable
sudo systemctl daemon-reload
sudo systemctl enable elasticsearch
sudo systemctl start elasticsearch

2.5 Verify
curl http://localhost:9200
Expected response:
{
"name": "node-1",
"cluster_name": "my-cluster",
"version": {
"number": "8.x.x"
},
"tagline": "You Know, for Search"
}

2.6 Memory Considerations
Elasticsearch defaults to a 1GB heap (-Xms1g -Xmx1g). For production:

Set heap to 50% of available RAM, but never more than 31GB (to stay within compressed OOPs).
Edit /etc/elasticsearch/jvm.options.d/heap.options: -Xms2g -Xmx2g
Ensure the system has enough RAM for both the JVM heap and filesystem cache (Lucene relies heavily on OS page cache).

3. Stage 2: Logstash - The Data Processing Pipeline

3.1 What is Logstash?
Logstash is a server-side data processing pipeline that ingests data from multiple sources, transforms it, and sends it to Elasticsearch. It sits between Filebeat and Elasticsearch, adding structure to raw log lines.

3.2 Installation
sudo apt-get install -y logstash

3.3 Pipeline Configuration
Logstash pipelines are defined in /etc/logstash/conf.d/. Each pipeline has three sections: input, filter, and output.
Create /etc/logstash/conf.d/boardgame.conf:
input {
beats {
port => 5044
}
}

filter {
#Parse Spring Boot log format
grok {
match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:loglevel} %{GREEDYDATA:logmessage}" }
}
}

output {
elasticsearch {
hosts => ["localhost:9200"]
index => "boardgame-logs-%{+YYYY.MM.dd}"
}
}
Pipeline sections explained:

Input - Where data comes from:
input {
beats {
port => 5044
}
}

Filter - How data is transformed:
filter {
grok {
match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:loglevel} %{GREEDYDATA:logmessage}" }
}
}

The grok filter parses unstructured log lines into structured fields (timestamp, loglevel, logmessage). This enables filtering by log level in Kibana (e.g., show only ERROR logs).

Output - Where data goes:
output {
elasticsearch {
hosts => ["localhost:9200"]
index => "boardgame-logs-%{+YYYY.MM.dd}"
}
}

Why daily indices? Daily indices make retention management simple - delete old indices by date. They also improve search performance because Elasticsearch can skip entire indices when querying a specific time range.

3.4 Start and Enable
sudo systemctl daemon-reload
sudo systemctl enable logstash
sudo systemctl start logstash

3.5 Verify
Check if Logstash is listening on port 5044
sudo ss -tlnp | grep 5044

Check Logstash logs for pipeline startup
sudo journalctl -u logstash --no-pager -n 20
Look for: Pipeline started {"pipeline.id"=>"main"} in the logs.

4. Stage 3: Kibana - The Visualization Layer

4.1 What is Kibana?
Kibana is the web interface for the ELK stack. It connects to Elasticsearch and provides tools for searching logs (Discover), building visualizations (charts, graphs, maps), and creating dashboards for real-time monitoring.

4.2 Installation
sudo apt-get install -y kibana

4.3 Configuration
Edit /etc/kibana/kibana.yml:
Bind to all interfaces for external access
server.host: "0.0.0.0"

Connect to Elasticsearch over plain HTTP
elasticsearch.hosts: ["http://localhost:9200"]

Critical configuration points:

Common pitfall: If Elasticsearch has xpack.security.http.ssl.enabled: false but Kibana is configured with https:// in elasticsearch.hosts, Kibana will fail to connect with Unable to retrieve version information from Elasticsearch. Always match the protocol.

Settings to remove or comment out when SSL is disabled:
Comment out or remove these lines
elasticsearch.ssl.certificateAuthorities: [/path/to/ca.crt]
elasticsearch.username: "kibana_system"
elasticsearch.password: "pass"

4.4 Start and Enable
sudo systemctl daemon-reload
sudo systemctl enable kibana
sudo systemctl start kibana

Kibana takes 30–60 seconds to fully initialize.

4.5 Verify
curl http://localhost:5601/api/status

Expected: {"status":{"overall":{"level":"available"}}} - the level should be available, not unavailable.

4.6 Create a Data View
Once data is flowing, create a data view so Kibana knows which indices to query:

Open http://:5601 in a browser.
Navigate to Stack Management > Data Views (under Kibana section).
Click Create data view.
Fill in the fields:

Now go to Discover (under Analytics) to search and explore your logs.

4.7 AWS Security Group
If running on AWS EC2, ensure the security group allows inbound traffic:

Never expose port 9200 to the public internet unless Elasticsearch security is enabled with TLS and authentication.

“Logs are the immune system of your infrastructure - they tell you when something is wrong before it becomes a crisis.” - DevOps principle

5. Stage 4: Filebeat - The Lightweight Log Shipper

5.1 What is Filebeat?
Filebeat is a lightweight log shipper that runs on the application server. It tails log files, handles log rotation, tracks read positions (so it never sends duplicate lines), and ships logs to Logstash or Elasticsearch with minimal resource overhead.

5.2 Why Filebeat instead of sending directly to Logstash?

Filebeat decouples your application from the logging pipeline. If Logstash or Elasticsearch goes down, Filebeat queues events and retries automatically. Your application keeps writing to its log file without interruption.

5.3 Installation (on the Application Server)
Use the same Elastic repository
sudo apt-get update && sudo apt-get install -y filebeat

5.4 Configuration
Edit /etc/filebeat/filebeat.yml:
filebeat.inputs:

type: log enabled: true paths:
- /home/ubuntu/Boardgame/target/app.log multiline.pattern: '^\d{4}-\d{2}-\d{2}' multiline.negate: true multiline.match: after

output.logstash:
hosts: [":5044"]

processors:

add_host_metadata: when.not.contains.tags: forwarded
add_cloud_metadata: ~

logging.level: info

Configuration explained:
Input section:

Multiline settings (critical for Java/Spring Boot stack traces):

This ensures that a multi-line Java stack trace is treated as a single log event, not dozens of separate lines:
2026-03-11 06:37:55 ERROR Something went wrong
java.lang.NullPointerException
at com.example.Service.process(Service.java:42)
at com.example.Controller.handle(Controller.java:15)
Without multiline config, each line of the stack trace becomes a separate Elasticsearch document - making it impossible to correlate errors.

Output section:

Processors:

YAML formatting rules (common source of errors):

5.5 Start and Enable
Clear old registry to re-read files from the beginning
sudo rm -rf /var/lib/filebeat/registry

sudo systemctl daemon-reload
sudo systemctl enable filebeat
sudo systemctl start filebeat

5.6 Verify
Check Filebeat status
sudo systemctl status filebeat

Check logs - look for "Harvester started"
sudo journalctl -u filebeat --no-pager -n 20
Key indicators in the logs:

6. Connecting the Pieces - End-to-End Data Flow

6.1 The Complete Pipeline
[Spring Boot App]
│
│ writes logs to disk
▼
[/home/ubuntu/Boardgame/target/app.log]
│
│ Filebeat tails the file
▼
[Filebeat] ──── port 5044 ────► [Logstash]
│
│ grok filter parses log lines
▼
[Elasticsearch]
index: boardgame-logs-2026.03.11
│
│ Kibana queries the index
▼
[Kibana]
http://:5601

6.2 Verifying Each Link
Test each component in order, from bottom to top:

Elasticsearch is running and accessible
curl http://localhost:9200
Logstash is listening for Beats input
sudo ss -tlnp | grep 5044
Kibana can reach Elasticsearch
curl http://localhost:5601/api/status
Filebeat can reach Logstash (from application server)
telnet 5044
Data is actually in Elasticsearch
curl http://localhost:9200/_cat/indices?v | grep boardgame
Check document count
curl http://localhost:9200/boardgame-logs-*/_count

7. Practical Setup (Step-by-step)

7.1 Server Requirements

7.2 ELK Server Setup (in order)

Step 1: Add Elastic repository
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list
sudo apt-get update

Step 2: Install all three components
sudo apt-get install -y elasticsearch logstash kibana

Step 3: Configure Elasticsearch
sudo nano /etc/elasticsearch/elasticsearch.yml
Set: network.host: 0.0.0.0
Set: discovery.type: single-node
Set: xpack.security.enabled: false
Set: xpack.security.http.ssl.enabled: false
Set: xpack.security.transport.ssl.enabled: false

Step 4: Configure Logstash pipeline
sudo nano /etc/logstash/conf.d/boardgame.conf
Add input (beats, port 5044), filter (grok), output (elasticsearch)

Step 5: Configure Kibana
sudo nano /etc/kibana/kibana.yml
Set: server.host: "0.0.0.0"
Set: elasticsearch.hosts: ["http://localhost:9200"]
Remove/comment any SSL certificate lines

Step 6: Start services
sudo systemctl enable elasticsearch logstash kibana
sudo systemctl start elasticsearch logstash kibana

7.3 Application Server Setup

Step 1: Install Filebeat
sudo apt-get install -y filebeat

Step 2: Configure Filebeat
sudo nano /etc/filebeat/filebeat.yml
Replace entire file with clean config (see Section 6.4)

Step 3: Clear registry and start
sudo rm -rf /var/lib/filebeat/registry
sudo systemctl enable filebeat
sudo systemctl start filebeat

7.4 Kibana Data View Setup

Verify data arrived in Elasticsearch
curl http://:9200/_cat/indices?v | grep boardgame
Then in the Kibana UI: 1. Stack Management > Data Views > Create data view 2. Name: Boardgame Logs, Index pattern: boardgame-logs-*, Timestamp: @timestamp 3. Save data view to Kibana 4. Go to Discover to explore your logs

7.5 Optional: Index Lifecycle Management

For production, configure automatic index cleanup to prevent disk from filling up:
Create an ILM policy that deletes indices older than 30 days
curl -X PUT "http://localhost:9200/_ilm/policy/boardgame-logs-policy" -H 'Content-Type: application/json' -d'
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover": {
"max_size": "5gb",
"max_age": "1d"
}
}
},
"delete": {
"min_age": "30d",
"actions": {
"delete": {}
}
}
}
}
}'

8. Troubleshooting Common Issues

8.1 Kibana shows “Unable to retrieve version information from Elasticsearch”

Cause: Protocol mismatch - Kibana is using https:// but Elasticsearch has SSL disabled.
Fix:
Check current Kibana config
sudo grep "elasticsearch.hosts" /etc/kibana/kibana.yml

Fix: change https to http
elasticsearch.hosts: ["http://localhost:9200"]

Comment out any SSL certificate lines
elasticsearch.ssl.certificateAuthorities: [...]

sudo systemctl restart kibana

8.2 Filebeat shows harvester.open_files: 0

Cause: Filebeat config is malformed (duplicate sections, wrong indentation, or double-quoted regex).
Fix: - Ensure filebeat.yml has no duplicate top-level keys. - Use single quotes for multiline.pattern (YAML treats \d in double quotes as an escape sequence). - Top-level keys (filebeat.inputs:, output.logstash:, processors:) must start at column 0.
Validate the config
sudo filebeat test config -c /etc/filebeat/filebeat.yml

Clear registry and restart
sudo rm -rf /var/lib/filebeat/registry
sudo systemctl restart filebeat

8.3 No boardgame-logs-* indices in Elasticsearch

Cause: Filebeat cannot reach Logstash on port 5044.
Fix:
From the application server, test connectivity
telnet 5044

If connection refused - open port 5044 in the ELK server's security group
If connection times out - check if Logstash is running
sudo systemctl status logstash

8.4 Kibana Data View shows “No data streams, indices, or index aliases match”

Cause: No data has been ingested yet, or the index pattern is wrong.
Fix:
List all indices
curl http://localhost:9200/_cat/indices?v

Check the exact index name and match your pattern accordingly
If index is "boardgame-logs-2026.03.11", pattern should be "boardgame-logs-*"

8.5 Logstash is running but not receiving data

Cause: Logstash pipeline failed to start, or the config file has syntax errors.
Fix:
Test the Logstash config
sudo /usr/share/logstash/bin/logstash --config.test_and_exit -f /etc/logstash/conf.d/

Check Logstash logs
sudo journalctl -u logstash --no-pager -n 30

“You can’t manage what you can’t measure.” - Peter Drucker

9. FAQs

Q1. Why use the ELK stack instead of cloud-native logging (CloudWatch, Stackdriver)?
ELK gives you full control over data retention, parsing rules, and costs. Cloud logging services charge per GB ingested, which becomes expensive at scale. ELK is free (open-source) - you only pay for the infrastructure.

Q2. Why Filebeat instead of sending logs directly from the application?
Filebeat decouples your application from the logging pipeline. If Logstash or Elasticsearch goes down, Filebeat queues events and retries. Your application keeps running without blocking on log delivery. Filebeat also uses ~10–30 MB RAM versus Logstash’s 500 MB+, making it ideal for application servers.

Q3. Can I skip Logstash and send Filebeat directly to Elasticsearch?
Yes. Set output.elasticsearch instead of output.logstash in Filebeat. However, you lose the ability to parse and transform logs with grok filters. For simple use cases (no parsing needed), direct shipping is fine.

Q4. Why daily indices (boardgame-logs-2026.03.11) instead of a single index?
Daily indices enable simple retention management (delete indices older than N days), improve search performance (Elasticsearch skips irrelevant time ranges), and make index management operations (backup, restore) more granular.

Q5. How much disk space does the ELK stack need?
Rough estimate: 1 GB of raw logs produces ~1.5–2 GB of Elasticsearch data (due to indexing overhead). For 100 MB/day of logs with 30-day retention, budget ~6 GB for Elasticsearch data.

Q6. Why must multiline.pattern use single quotes in YAML?
YAML interprets backslash sequences in double-quoted strings (\d becomes an invalid escape). Single quotes treat the content literally, preserving the regex pattern for Filebeat.

Q7. How do I add more application servers?
Install Filebeat on each server, point it to the same Logstash endpoint. Add a fields section to distinguish servers:
filebeat.inputs:

type: log enabled: true paths:
- /var/log/myapp/*.log fields: server_name: web-02 environment: production

Q8. Is this setup production-ready as described?
For internal use, yes. For public-facing production, enable Elasticsearch security (xpack.security.enabled: true), use TLS certificates for all inter-component communication, put Kibana behind a reverse proxy with authentication, and configure Index Lifecycle Management for automatic cleanup.

10. Key Takeaways

Centralized logging transforms debugging from “SSH into each server and grep” to “search once, find everywhere.”
Filebeat belongs on the application server, not the ELK server. It is lightweight (~10–30 MB RAM) and handles backpressure gracefully.
Logstash’s grok filter turns unstructured log lines into structured, searchable fields (timestamp, loglevel, logmessage).
Protocol mismatch (https:// vs http://) between Kibana and Elasticsearch is the most common setup failure. Always match the protocol to Elasticsearch’s actual SSL configuration.
YAML formatting causes most Filebeat config errors - use single quotes for regex, no duplicate keys, no leading spaces on top-level keys.
Daily indices (boardgame-logs-%{+YYYY.MM.dd}) simplify retention management and improve query performance.
Security is not optional in production - enable xpack.security, use TLS, and restrict port access via security groups.
Test connectivity bottom-up: Elasticsearch first, then Logstash, then Kibana, then Filebeat.

11. Conclusion

Setting up the ELK stack is not just about installing four packages - it is about building a reliable data pipeline that turns scattered log files into searchable, visualizable insights. Each component has a clear role: Filebeat ships, Logstash transforms, Elasticsearch stores, and Kibana visualizes.

The most common failures are not in the software itself, but in the configuration glue between components: protocol mismatches between Kibana and Elasticsearch, YAML formatting errors in Filebeat, unopened firewall ports between servers, and missing runtime dependencies.

By following the step-by-step approach in this guide - installing bottom-up (Elasticsearch → Logstash → Kibana → Filebeat), verifying each component before moving to the next, and understanding why each configuration setting exists - you can set up a production-grade centralized logging system that scales from a single application to dozens of services.

Once the pipeline is flowing, the real value begins: building dashboards for error rates, setting up alerts for anomalies, and turning your logs from an afterthought into your first line of defense.

About the Author:Rajan is a DevOps Engineer at AddWebSolution, specializing in automation infrastructure, Optimize the CI/CD Pipelines and ensuring seamless deployments.

Nginx + PHP + MySQL Optimisations and Parameter Calculations

Narendra Chauhan — Fri, 03 Apr 2026 06:38:00 +0000

“Premature optimization is the root of all evil but lack of optimisation is the root of outages.”

Introduction
Architecture Overview
Why Optimisation Is Required
Nginx Optimisations & Parameter Calculations
PHP-FPM Optimisations & Parameter Calculations
MySQL Optimisations & Parameter Calculations
System-Level Optimisations (Linux)
Practical Example: Small vs Medium vs Large Server
Interesting Facts & Statistics
FAQs
Key Takeaways
Conclusion

1. Introduction

Modern web applications rely heavily on the Nginx + PHP + MySQL (LEMP) stack. While default configurations work for testing, they are not suitable for production traffic.

Optimisation ensures:

Faster page load time
Better concurrency handling
Lower memory and CPU usage
Higher stability under load

This document explains what to optimise, why to optimise, and how to calculate parameters practically.

2. Architecture Overview

A typical request flow:

Client sends HTTP request
Nginx handles connection & static content
PHP-FPM processes dynamic PHP requests
MySQL serves data from database
Response sent back to client

Each layer must be tuned together, not individually.

3. Why Optimisation Is Required

Default settings:

Are conservative
Waste available RAM
Limit concurrency
Cause slow response under load

Common Problems Without Optimisation

502 / 504 Gateway errors
High CPU load
PHP-FPM “server reached max_children”
MySQL “Too many connections”

4. Nginx Optimisations & Parameter Calculations

Key Nginx Parameters
worker_processes auto;
worker_connections 4096;

What is worker_processes
Number of worker processes
Best practice: match CPU cores

nproc
Example:
4 CPU cores → worker_processes 4;
What is worker_connections
Maximum connections per worker

Total Max Connections
worker_processes × worker_connections

Example

4 × 4096 = 16,384 concurrent connections

Recommended Extra Optimisations

use epoll;
multi_accept on;

sendfile on;
tcp_nopush on;
tcp_nodelay on;

keepalive_timeout 65;
keepalive_requests 1000;

5. PHP-FPM Optimisations & Parameter Calculations

Key PHP-FPM Settings

pm = dynamic
pm.max_children = 20
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10

How to Calculate pm.max_children

Find average PHP process memory: ps -ylC php-fpm --sort:rss
Formula: Available RAM for PHP / Avg PHP process size

Example

Available RAM: 2 GB
Avg PHP process: 100 MB

2048 / 100 ≈ 20
pm.max_children = 20

Other Important PHP Optimisations

request_terminate_timeout = 60
max_execution_time = 60
memory_limit = 256M

Enable OPcache

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000

6. MySQL Optimisations & Parameter Calculations

Key MySQL Parameters

innodb_buffer_pool_size = 2G
innodb_buffer_pool_instances = 2
max_connections = 200

How to Calculate innodb_buffer_pool_size

Allocate 60–70% of total RAM (dedicated DB server)

Example

Server RAM: 4 GB

4 × 70% ≈ 2.8 GB
Use 2G or 3G

Connection Calculation

Additional Recommended Settings

query_cache_type = 0
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2

7. System-Level Optimisations (Linux)

File Descriptors

ulimit -n 100000

Kernel Tuning

net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
vm.swappiness = 10

8. Practical Server Size Examples

Small Server (2 CPU / 2 GB RAM)

Nginx workers: 2
worker_connections: 2048
PHP max_children: 10
MySQL buffer pool: 1G

Medium Server (4 CPU / 8 GB RAM)

Nginx workers: 4
worker_connections: 4096
PHP max_children: 30–40
MySQL buffer pool: 4–5G

Large Server (8 CPU / 16 GB RAM)

Nginx workers: 8
worker_connections: 8192
PHP max_children: 60–80
MySQL buffer pool: 10–12G

Practical Demonstration (Images Explained)

Step 1. NGINX OPTIMISATION

Parameter Calculations
Step 1.1 Backup current nginx.conf

  sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak

Step 1.2 Check current config

  cat /etc/nginx/nginx.conf

Screenshot: Current state before changes

Step 1.3 Edit nginx.conf

sudo nano /etc/nginx/nginx.conf

Replace/update with this optimized config:

user www-data;
  worker_processes 2;                    # = nproc (2 cores)
  worker_rlimit_nofile 65535;
  pid /run/nginx.pid;
  include /etc/nginx/modules-enabled/*.conf;

  events {
      worker_connections 1024;           # 2 x 1024 = 2048 total connections
      use epoll;                         # Linux best event model
      multi_accept on;                   # Accept multiple connections at once
  }

  http {

      # Basic Settings
      sendfile on;
      tcp_nopush on;
      tcp_nodelay on;
      keepalive_timeout 30;              # Reduced from default 75s
      keepalive_requests 100;
      types_hash_max_size 2048;
      server_tokens off;                 # Hide nginx version

      client_max_body_size 20m;
      client_body_buffer_size 128k;
      client_header_buffer_size 1k;
      large_client_header_buffers 4 8k;
      client_body_timeout 12;
      client_header_timeout 12;
      send_timeout 10;

      include /etc/nginx/mime.types;
      default_type application/octet-stream;

      # Logging Settings
      access_log /var/log/nginx/access.log;
      error_log /var/log/nginx/error.log warn;   # Only warn+ to reduce I/O

      # Gzip Settings
      gzip on;
      gzip_vary on;
      gzip_proxied any;
      gzip_comp_level 3;                 # Level 3 = good ratio, low CPU
      gzip_min_length 1024;              # Don't compress tiny files
      gzip_buffers 16 8k;
      gzip_http_version 1.1;
      gzip_types
          text/plain
          text/css
          text/javascript
          application/javascript
          application/json
          application/xml
          image/svg+xml
          font/woff2;


      # Open File Cache
      open_file_cache max=1000 inactive=20s;
      open_file_cache_valid 30s;
      open_file_cache_min_uses 2;
      open_file_cache_errors on;

      # FastCGI Cache (optional - enable per site)
      fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=PHPCACHE:10m
                         max_size=100m inactive=60m use_temp_path=off;

      include /etc/nginx/conf.d/*.conf;
      include /etc/nginx/sites-enabled/*;
  }

Step 1.4 Create FastCGI cache directory

 sudo mkdir -p /var/cache/nginx
  sudo chown www-data:www-data /var/cache/nginx

Step 1.5 Test and reload Nginx

sudo nginx -t
  sudo systemctl reload nginx

Screenshot: nginx -t showing syntax is ok and test is successful

Step 1.6 Verify Nginx is running with new settings

sudo nginx -T | grep -E "worker_processes|worker_connections|gzip|keepalive_timeout"
systemctl status nginx

Screenshot: Running status + key parameters

Step 2. PHP-FPM OPTIMISATION

Parameter Calculations
Available RAM for PHP-FPM: ~150MB (conservative, leaving room for MySQL + Nginx)
Average PHP-FPM process size: ~30-40MB
Formula: pm.max_children = 150 / 35 ≈ 4

PHP-FPM Parameters Calculation
pm
Formula: Dynamic (best for variable traffic)
Value: dynamic

pm.max_children
Formula: 150MB ÷ 35MB/process
Value: 4

pm.start_servers
Formula: pm.max_children / 2
Value: 2

pm.min_spare_servers
Formula: pm.start_servers / 2
Value: 1

pm.max_spare_servers
Formula: pm.start_servers
Value: 2

pm.max_requests
Formula: Prevent memory leaks
Value: 500

Step 2.1 Check PHP-FPM version path

  php -v
  ls /etc/php/

Step 2.2 Backup pool config

sudo cp/etc/php/8.4/fpm/pool.d/www.conf/etc /php/8.4/fpm/pool.d/www.conf.bak
sudo cp /etc/php/8.4/fpm/php.ini /etc/php/8.4/fpm/php.ini.bak

Step 2.3 Check current PHP process memory usage

Run this to see actual PHP-FPM process sizes

ps aux | grep php-fpm | grep -v grep | awk '{sum += $6} END {print "Total RSS:", sum/1024, "MB"; print "Count:", NR; print "Avg per process:", sum/NR/1024, "MB"}'

Screenshot: Current process sizes.

Step 2.4 Edit PHP-FPM pool config

sudo nano /etc/php/8.4/fpm/pool.d/www.conf

Find and update these values (search with Ctrl+W in nano):

[www]
user = www-data
group = www-data

listen = /run/php/php8.4-fpm.sock
listen.owner = www-data
listen.group = www-data

pm = dynamic
pm.max_children = 4
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 2
pm.max_requests = 500     ;Restart workers after 500 requests (prevents memory leaks)
pm.process_idle_timeout = 10s

pm.status_path = /status  ; Enable FPM status page
ping.path = /ping

slowlog = /var/log/php8.4-fpm-slow.log
request_slowlog_timeout = 5s     ; Log requests taking > 5 seconds
security.limit_extensions = .php

Step 2.5 Tune PHP OPcache
sudo nano /etc/php/8.4/mods-available/opcache.ini

zend_extension=opcache

  ; Enable OPcache
  opcache.enable=1
  opcache.enable_cli=0

  ; Memory: 64MB for low-RAM server
  opcache.memory_consumption=64
  opcache.interned_strings_buffer=8
  opcache.max_accelerated_files=10000

  ; Production settings (set validate_timestamps=0 in prod)
  opcache.validate_timestamps=1
  opcache.revalidate_freq=60

  opcache.save_comments=1
  opcache.max_wasted_percentage=10
  opcache.use_cwd=1

  ; JIT (PHP 8.x feature)
  opcache.jit_buffer_size=32M
  opcache.jit=1255

Step 2.6 Tune PHP.ini key values
sudo nano /etc/php/8.4/fpm/php.ini

Find and update:
  ; Memory limit per PHP process
  memory_limit = 128M

  ; Upload/POST limits
  upload_max_filesize = 20M
  post_max_size = 25M
  max_execution_time = 60
  max_input_time = 60

  ; Error handling (production)
  display_errors = Off
  log_errors = On
  error_log = /var/log/php_errors.log

  ; Session handling
  session.gc_maxlifetime = 1440
  session.cookie_httponly = 1
  session.cookie_secure = 1

  ; Disable dangerous functions
  disable_functions = exec,passthru,shell_exec,system,proc_open,popen

Step 2.7 Restart PHP-FPM and verify

sudo php-fpm8.4 -t
  sudo systemctl restart php8.4-fpm
  sudo systemctl status php8.4-fpm

Screenshot: PHP-FPM status showing active (running)

Step 2.8 Verify OPcache is active

php -r "var_dump(opcache_get_status());" | head -30

- or check via CLI

php -i | grep -E "opcache|OPcache"

Screenshot: OPcache enabled status

Step 2.9 Check PHP-FPM processes after restart

  ps aux | grep php-fpm | grep -v grep

- Should show master + 2 worker processes (pm.start_servers=2)

Screenshot: FPM process list

Step 3. MYSQL OPTIMISATION

Parameter Calculations

RAM budget for MySQL: ~200MB (out of 914MB total)

innodb_buffer_pool_size
Formula: ~20% of RAM (shared server)
Value: 192M

innodb_buffer_pool_instances
Formula: buffer_pool ÷ 128M
Value: 1

max_connections
Formula: Low RAM = conservative
Value: 50

innodb_log_file_size
Formula: 25% of buffer pool
Value: 48M

tmp_table_size
Formula: Memory temporary tables
Value: 16M

max_heap_table_size
Formula: Same as tmp_table_size
Value: 16M

thread_cache_size
Formula: Reuse threads
Value: 8

table_open_cache
Formula: Open tables cache
Value: 400

Step 3.1 Check current MySQL config and status

sudo cp /etc/mysql/mysql.conf.d/mysqld.cnf /etc/mysql/mysql.conf.d/mysqld.cnf.bak

- Check current variables

mysql -u root -p -e "SHOW VARIABLES LIKE 'innodb_buffer_pool%';"
  mysql -u root -p -e "SHOW VARIABLES LIKE 'max_connections';"
  mysql -u root -p -e "SHOW STATUS LIKE 'Threads_connected';"

Screenshot: Current MySQL variables

Step 3.2 Check actual MySQL memory usage

mysql -u root -p -e "
  SELECT
    ROUND(@@innodb_buffer_pool_size/1024/1024, 0) AS 'Buffer Pool MB',
    ROUND(@@key_buffer_size/1024/1024, 0) AS 'Key Buffer MB',
    @@max_connections AS 'Max Connections',
    @@thread_stack/1024 AS 'Thread Stack KB';
  "

Screenshot: Current MySQL memory config

Step 3.3 Edit MySQL config

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Add/update under [mysqld]:

[mysqld]
  pid-file        = /var/run/mysqld/mysqld.pid
  socket          = /var/run/mysqld/mysqld.sock
  datadir         = /var/lib/mysql
  log-error       = /var/log/mysql/error.log

  #
  # ===== MEMORY SETTINGS =====
  # Server has 914MB RAM - allocate ~200MB for MySQL
  #
  innodb_buffer_pool_size         = 192M    # Main InnoDB cache (most important!)
  innodb_buffer_pool_instances    = 1       # 1 instance (< 1GB pool)
  innodb_log_file_size            = 48M     # ~25% of buffer pool
  innodb_log_buffer_size          = 8M
  innodb_flush_log_at_trx_commit  = 2       # Slight risk, big perf gain (use 1 for strict ACID)

  #
  # ===== CONNECTION SETTINGS =====
  #
  max_connections         = 50             # Low RAM = keep connections limited
  thread_cache_size       = 8             # Reuse threads, avoid creation overhead
  wait_timeout            = 120           # Kill idle connections after 2 min
  interactive_timeout     = 120

  #
  # ===== QUERY CACHE (removed in MySQL 8.0, skip) =====
  # MySQL 8.0 removed query_cache - use ProxySQL or app-level cache

  #
  # ===== TABLE CACHE =====
  #
  table_open_cache        = 400
  table_definition_cache  = 400

  #
  # ===== TEMP TABLES =====
  #
  tmp_table_size          = 16M
  max_heap_table_size     = 16M

  #
  # ===== InnoDB I/O =====
  #
  innodb_file_per_table           = 1
  innodb_flush_method             = O_DIRECT  # Avoid double buffering with OS cache
  innodb_read_io_threads          = 2         # = CPU cores
  innodb_write_io_threads         = 2         # = CPU cores

  #
  # ===== SLOW QUERY LOG =====
  #
  slow_query_log          = 1
  slow_query_log_file     = /var/log/mysql/slow.log
  long_query_time         = 2             # Log queries > 2 seconds
  log_queries_not_using_indexes = 1

  #
  # ===== BINARY LOG (disable if not using replication) =====
  #
  # skip-log-bin                           # Uncomment if no replication needed

Step 3.4 Validate and restart MySQL

sudo mysqld --validate-config
  sudo systemctl restart mysql
  sudo systemctl status mysql

Screenshot: MySQL status active

Step 3.5 Verify new MySQL variables

mysql -u root -p -e "
  SELECT 'innodb_buffer_pool_size' AS Variable,
         ROUND(@@innodb_buffer_pool_size/1024/1024,0) AS 'Value (MB)'
  UNION SELECT 'max_connections', @@max_connections
  UNION SELECT 'innodb_log_file_size MB', ROUND(@@innodb_log_file_size/1024/1024,0)
  UNION SELECT 'tmp_table_size MB', ROUND(@@tmp_table_size/1024/1024,0)
  UNION SELECT 'thread_cache_size', @@thread_cache_size;
  "

Screenshot: New values confirmed

Step 3.6 Check MySQL memory usage post-restart

  free -h
  ps aux | sort -k6 -rn | head -10

Screenshot: Overall memory after all services tuned

“Measure first, tune second, and monitor always.”

Step 4. FINAL VERIFICATION

Step 4.1 Check all services running

  systemctl status nginx php8.4-fpm mysql --no-pager

Step 4.2 Full memory picture

free -h
  ps aux --sort=-%mem | head -15

Step 4.3 Check nginx + PHP working together

Test nginx config is still valid
  sudo nginx -t

 Test PHP-FPM socket exists
  ls -la /run/php/php8.4-fpm.sock

 Check FPM status (if you added status page to your site config)
  curl http://localhost/status

Step 4.4 Check MySQL slow log is active

mysql -u root -p -e "SHOW VARIABLES LIKE 'slow_query%';"

Step 4.5 Final health summary

echo "=== NGINX ===" && nginx -v && systemctl is-active nginx
  echo "=== PHP-FPM ===" && php -v | head -1 && systemctl is-active php8.4-fpm
  echo "=== MYSQL ===" && mysql --version && systemctl is-active mysql
  echo "=== MEMORY ===" && free -h

Screenshot: Final health check

Your server is fully optimised. All phases verified:

Phase 0 Swap 2GB active
Phase 1 Nginx tuned
Phase 2 PHP-FPM + OPcache + JIT enabled
Phase 3 MySQL InnoDB / connections / slow query log active

9. Interesting Facts & Statistics

1 second delay can reduce conversions by 7%
OPcache can improve PHP performance by 2–3×
MySQL buffer pool cache hit ratio above 99% is ideal
Nginx handles 10× more concurrent connections than traditional servers

11. FAQs

Q1. Should I optimise Nginx, PHP, or MySQL first?
Start with PHP-FPM and MySQL, then tune Nginx.

Q2. Can wrong tuning crash the server?
Yes. Over-allocating RAM causes OOM kills.

Q3. Are these values fixed forever?
No. Recalculate after traffic growth.

Q4. Do I need load testing?
Yes. Use tools like ab, wrk, or k6.

12. Key Takeaways

Optimisation is calculation-based, not guesswork
PHP-FPM memory calculation is critical
MySQL buffer pool has the biggest performance impact
Nginx handles concurrency, not application logic
Monitoring is mandatory after tuning

13. Conclusion

Optimising Nginx + PHP + MySQL is not about copying configs from the internet—it is about understanding server resources, calculating limits, and balancing load across layers.
A well-optimised stack:

Handles higher traffic
Reduces downtime
Improves user experience
Saves infrastructure cost

About the Author:Narendra is a DevOps Engineer at AddWebSolution, specializing in automating infrastructure to improve efficiency and reliability.

Testing Node.js APIs: Jest, Supertest, and Best Practices

Zemichael Mehretu — Tue, 31 Mar 2026 10:21:20 +0000

“Fast tests are a productivity feature; reliable tests are a business feature.”

Key Takeaways

Reliable API tests are less about tool choice and more about test boundaries, data control, and deterministic execution.
Jest + Supertest remains a practical default stack for HTTP API testing across Express, Fastify, and Nest-based services.
The biggest gains come from balancing fast unit tests with focused integration and contract tests.
Flaky tests usually indicate architecture or environment issues, not just “test instability.”
A staged migration strategy outperforms rewriting the entire test suite at once.

Index

Introduction
Why Node.js API Test Suites Become Fragile Over Time
Testing APIs in Practical Terms
Core Testing Principles (The Guardrails)
The Four Testing Layers for Node.js APIs
Implementation Strategy for Engineering Teams
Minimal Example: Create User Endpoint with Jest + Supertest
Databases, Queues, and External Integrations
Testing Strategy by Risk and Feedback Speed
Migration Roadmap for Existing Node.js APIs
Common Mistakes and How to Avoid Themdevf nf.f/fk
When to Go Deep (and When to Keep It Lean)
FAQs
References
Interesting facts
Stats
Conclution

1) Introduction

Most Node.js teams start with a handful of endpoint tests and feel productive quickly. The challenge appears later: as endpoints multiply, integrations grow, and multiple teams contribute, test suites get slower, noisier, and harder to trust.

At that point, the question changes from “Do we have tests?” to “Can we safely change behavior without fear?”

Jest and Supertest are still a strong pair for this problem:

Jest provides a mature runner, mocking, snapshots (when used carefully), parallelism controls, and strong TypeScript support.
Supertest makes HTTP assertions straightforward by testing your app server boundary with minimal setup. This guide focuses on practical, production-grade API testing: clear test architecture, reliable CI execution, and patterns that hold up as systems grow.

2) Why Node.js API Test Suites Become Fragile Over Time

Most API testing pain comes from boundary confusion, not from JavaScript itself.

Common symptoms:

Endpoint tests that also validate unrelated business rules, persistence details, and third-party behavior in one place.
Excessive mocks that make tests pass while production behavior fails.
Slow suites due to global setup, shared mutable state, or non-isolated databases.
Flaky tests caused by timing assumptions, network dependency, or race conditions.
Hard-to-debug failures because assertions are too broad (“status should be 200”) and not intent-focused. As these issues accumulate, teams lose confidence. Developers re-run tests repeatedly, CI cycles grow, and delivery speed drops.

3) Testing APIs in Practical Terms

Effective API testing separates policy from transport detail.

Policy: validation rules, authorization decisions, business invariants, idempotency behavior.
Detail: HTTP framework wiring, DB driver specifics, queue providers, external SDK mechanics.

In practice:

Test business behavior close to the domain/service layer where feedback is fast.
Test HTTP contracts at the API boundary (status codes, schema shape, headers).
Test integration seams (database, message broker, external APIs) explicitly and intentionally.
Keep each test focused on one intent so failures explain what broke. A useful test heuristic: if your storage engine changes, most behavioral tests should remain valid.

4) Core Testing Principles (The Guardrails)

Principle 1: Test Behavior, Not Implementation
Prefer assertions on outcomes (response payload, side effects, emitted events) over internal call counts unless interaction itself is the behavior.

Principle 2: Keep Tests Deterministic

Control time, randomness, and external I/O. Non-determinism is the fastest path to flaky pipelines.

Principle 3: Isolate by Layer

Use unit tests for logic branches, integration tests for boundaries, and endpoint tests for HTTP contract confidence.

Principle 4: Keep Test Data Intentional

Use builders/factories with explicit defaults. Hidden fixture coupling creates accidental test dependencies.

Principle 5: Make Failures Actionable

Every failure should quickly answer:

What business behavior regressed?
Which boundary failed?
Is this deterministic or flaky?

Principle 6: Optimize for Feedback Loop

Developers need fast local tests and reliable CI gates. Prioritize speed for high-frequency paths.

“Contract tests protect teams from integration surprises better than shared assumptions.”

5) The Four Testing Layers for Node.js APIs

A) Unit Tests (Core Behavior)
Purpose: verify pure or near-pure logic quickly.
Test here:

Validation utilities
Domain services
Policy evaluators (authz/eligibility)
Data transformation helpers

Characteristics:

No network I/O
Minimal mocking
Millisecond-level runtime

B) Service/Use-Case Tests (Application Behavior)
Purpose: validate business workflows with mocked boundaries.
Test here:

Use-case orchestration
Branching by role/plan/state
Error mapping from domain to application outcomes

Characteristics:

Mock repository/gateway interfaces
Clear input-output assertions
Strong signal for business regressions

C) API Integration Tests (HTTP Boundary)
Purpose: verify endpoint contracts through real routing/middleware.
Test here:

Status and payload schema
Auth middleware effects
Validation and error format
Idempotency and headers

Characteristics:

Run through supertest(app)
Use real request pipeline
Keep counts limited to meaningful scenarios

D) Infrastructure Integration Tests (Real Dependencies)
Purpose: validate adapter correctness with real systems.
Test here:

Repository against real DB (often containerized)
Outbound gateway behavior against sandbox/stub
Queue publish/consume adapter correctness

Characteristics:

Slower and fewer
High confidence at critical seams
Isolated environments required

6) Implementation Strategy for Engineering Teams

Strategy 1: Start with High-Risk Endpoints
Prioritize money movement, authentication, billing, entitlement, and state-transition APIs.

Strategy 2: Define a Test Matrix per Endpoint

For each endpoint, define:

happy path,
validation failures,
authorization failures,
business rule failures,
idempotency/concurrency behavior.

Strategy 3: Standardize Test Utilities

Create shared helpers for:

app bootstrap,
authenticated request context,
test data factories,
DB reset/seed.
This reduces duplicated setup and inconsistent patterns.

Strategy 4: Separate Fast vs Slow Pipelines

Run fast tests on every push; run heavier integration suites on merge or scheduled jobs.

Strategy 5: Enforce Test Ownership in Reviews

Review checklist:

Is the behavior covered at the right layer?
Are assertions business-meaningful?
Is the test deterministic?
Does this duplicate lower-layer coverage?

Strategy 6: Track Quality Metrics
Monitor:

flaky test rate,
mean CI duration,
re-run frequency,
escaped defect categories. Good testing architecture should improve these over time.

7) Minimal Example: Create User Endpoint with Jest + Supertest

The goal is clarity of boundaries, not framework-specific depth.

src/app.ts

import express from 'express';

const app = express();
app.use(express.json());

app.post('/users', (req, res) => {
  const { email, name } = req.body ?? {};

  if (!email || !name) {
    return res.status(422).json({
      error: {
        code: 'VALIDATION_ERROR',
        message: 'email and name are required'
      }
    });
  }

  return res.status(201).json({
    data: {
      id: 'usr_123',
      email,
      name
    }
  });
});

export { app };

test/users.create.spec.ts

import request from 'supertest';
import { app } from '../src/app';

describe('POST /users', () => {
  it('creates a user when payload is valid', async () => {
    const response = await request(app)
      .post('/users')
      .send({ email: 'sam@example.com', name: 'Sam' });

    expect(response.status).toBe(201);
    expect(response.body).toEqual({
      data: {
        id: expect.any(String),
        email: 'sam@example.com',
        name: 'Sam'
      }
    });
  });

  it('returns 422 for invalid payload', async () => {
    const response = await request(app)
      .post('/users')
      .send({ email: 'sam@example.com' });

    expect(response.status).toBe(422);
    expect(response.body.error.code).toBe('VALIDATION_ERROR');
  });
});

package.json (relevant scripts)

{
  "scripts": {
    "test": "jest --runInBand",
    "test:watch": "jest --watch",
    "test:ci": "jest --coverage --maxWorkers=50%"
  }
}

In real systems, route handlers should delegate to use cases/services. Tests then become cleaner: unit tests cover rules, while Supertest verifies HTTP contract and middleware behavior.

8) Databases, Queues, and External Integrations

These boundaries create most false confidence if not tested deliberately.

Database: prefer isolated test DB instances, deterministic seeders, and teardown per test or per suite.
Queues/events: test enqueue intent at service level, then test adapter correctness separately.
External APIs: avoid live dependencies in regular CI; use stable stubs, contract checks, or sandbox environments.
Retries/timeouts: assert observable outcomes (e.g., mapped errors, retry caps), not private implementation internals.

A practical split:

regular CI: no real internet dependency,
nightly/extended pipeline: sandbox integration checks.

9) Testing Strategy by Risk and Feedback Speed

Treat tests as a portfolio.

Fast lane (minutes): unit + selected service tests.
Core lane (merge gate): API integration for critical endpoints.
Extended lane (scheduled): infra/sandbox checks, broader resilience scenarios. This balances confidence and developer velocity.

Recommended safeguards:

Fail build on flaky test detection thresholds.
Quarantine unstable tests with owner + fix-by date.
Keep coverage goals directional, not vanity metrics.
Prefer mutation testing selectively on high-value modules.

10) Migration Roadmap for Existing Node.js APIs

Avoid all-at-once rewrites.

Identify top 5 risky endpoints by incident history or business criticality.
Add baseline Supertest contract tests for current behavior.
Extract business logic from route handlers into testable services/use cases.
Add unit/service tests around extracted rules.
Introduce integration tests for critical DB/external adapters.
Reduce over-mocked endpoint tests and remove duplicate coverage.
Enforce testing checklist in pull requests.
Repeat by vertical slice.

This path allows continuous delivery while improving reliability incrementally.

11) Common Mistakes and How to Avoid Them

Over-mocking everything: tests become fiction; keep meaningful boundaries real.
Only endpoint tests: slow suites and weak failure localization.
Shared mutable fixtures: hidden coupling and random failures.
Ignoring time/state transitions: retries, TTLs, and async workflows go untested.
Snapshot overuse: brittle assertions with low business signal.
No ownership model: flaky tests linger and trust decays. Fixes are process + architecture: test at the right layer, isolate state, and treat flaky tests as production bugs.

12) When to Go Deep (and When to Keep It Lean)

Go deeper when:

APIs control payments, access, compliance, or irreversible workflows.
multiple teams ship to the same service.
incident cost is high and regressions are expensive.

Keep it leaner when:

service is internal and low-risk,
behavior is straightforward CRUD,
change frequency and impact are low.
Testing depth should match business risk, not trend pressure.

“A stable test suite is not a luxury in API teams; it is delivery infrastructure.”

13) FAQs

Is Jest still a good default for Node.js API testing?
Yes. It remains a practical default for most teams due to ecosystem maturity, tooling support, and straightforward CI integration.

Do we need Supertest if we already unit test services?
Yes, for HTTP contract confidence. Unit tests do not validate routing, middleware, serialization, and error envelope behavior.

How much mocking is too much?
If tests pass while real integration repeatedly fails, mocking is likely hiding boundary problems. Mock at external seams, not core behavior.

Should we test against real third-party APIs in CI?
Usually not in the main pipeline. Prefer deterministic stubs/contracts in regular CI and schedule sandbox verification separately.

What is a healthy target for coverage?
There is no universal number. Prioritize meaningful coverage of critical flows and failure modes over headline percentages.

14) References

Jest Documentation: https://jestjs.io
Supertest (GitHub): https://github.com/ladjs/supertest
Node.js Documentation (Testing & Runtime): https://nodejs.org
Martin Fowler Test Pyramid: https://martinfowler.com/articles/practical-test-pyramid.html
Google SRE Workbook (Testing in Production Concepts): https://sre.google/workbook/

15) Interesting Facts

JavaScript continues to be one of the most widely used languages globally, and Node.js remains one of the most commonly used web technologies among professional developers. Source: https://survey.stackoverflow.co/2024/
Testing has become a first-class topic in modern JavaScript ecosystems, with dedicated community tracking for framework usage, satisfaction, and retention trends. Source: https://stateofjs.com/
Node.js now includes an official built-in test runner, which reflects how central testing has become in backend JavaScript workflows. Source: https://nodejs.org/api/test.html
Jest provides native support for parallel execution and coverage reporting, which is why many teams keep it as a CI-friendly default for API and service testing. Source: https://jestjs.io/docs/cli
Supertest is designed to test HTTP servers without opening a real network port, making endpoint tests faster and more deterministic in local and CI environments. Source: https://github.com/ladjs/supertest
Jest is an all-in-one testing solution that includes a test runner, assertion library, and mocking capabilities out of the box.
Supertest can simulate HTTP requests directly against an Express app, making tests faster and more reliable.
Jest runs tests in parallel by default, significantly improving execution speed for large test suites.
API testing in Node.js often focuses more on integration tests rather than pure unit tests due to the nature of backend systems.
Best practice emphasizes testing API behavior (status codes, responses) rather than internal implementation details.

16) Stats

According to the Stack Overflow Developer Survey, a majority of Node.js developers use automated testing in production environments.Source: https://survey.stackoverflow.co/
Jest has 40k+ stars on GitHub and millions of weekly npm downloads, making it one of the most widely used JavaScript testing frameworks.Source: https://github.com/facebook/jest
Tools like Supertest are commonly used with Express.js for API testing due to their ability to test endpoints without starting a live server.Source: https://github.com/visionmedia/supertest

17) Conclusion

Testing Node.js APIs effectively is not about maximizing test count; it is about placing the right tests at the right boundaries. With Jest and Supertest, teams can build a fast, trustworthy feedback loop by combining deterministic unit/service tests, focused API contract tests, and intentional integration checks. Over time, this reduces incident risk, shortens debugging cycles, and makes API evolution safer.

About the Author: Zemichael is a fullstackDeveloper at AddWeb Solution.Crafting web experiences with robust architecture, performance focus, and design thinking.

Common Mistakes Laravel Developers Make (And How to Avoid Them)

Lakashya Upadhyay — Fri, 27 Mar 2026 08:23:53 +0000

“Controllers should coordinate, not decide.”

Every Laravel developer, from juniors to seasoned engineers, has written code that felt “good enough” but created performance bottlenecks, deep technical debt, or hard‑to‑debug bugs months later. Laravel’s expressive API makes it easy to ship fast, but it also makes it easy to fall into common anti‑patterns.

This guide walks through the most frequent mistakes Laravel developers make in production, explains why they’re harmful, and shows how to refactor them into clean, maintainable structures.

Key Takeaways

Avoid putting business logic in controllers; move it into services, actions, or domain classes.
Use Eloquent relationships, eager loading, and proper indexing to prevent N+1 queries.
Organize your code with proper folders, route groups, and naming conventions.
Separate validation from controllers and reuse it via Form Requests or validation rules.
Use migrations, tests, and documentation to keep your app scalable and on‑team‑friendly.
Treat database design, authentication, and security as first‑class concerns, not afterthoughts.

Index

Why This Matters
Mistake 1: Putting Too Much Logic in Controllers
Mistake 2: Ignoring Eloquent Relationships and N+1 Queries
Mistake 3: Poor Database Design and Indexing
Mistake 4: Not Using Form Requests or Validation Properly
Mistake 5: Ignoring Migrations and Model Structure
Mistake 6: Messy Routes and Poor Naming Conventions
Mistake 7: Overusing Helper/Static Methods and Global Helpers
Mistake 8: Skipping Tests and Documentation
Mistake 9: Hard‑coding Logic in Migrations or Seeders
Mistake 10: Poor Error Handling and Logging
Frequently Asked Questions (FAQs)
Interesting Facts & Stats
Conclusion

1. Why This Matters

Laravel is designed to help you ship fast while keeping your codebase sane. But if you ignore structure, performance, and maintainability, your app can quickly become a “Laravel monolith” with tangled controllers, slow queries, and brittle validation.

Common mistakes Laravel developers make often look harmless at first:

A controller method that grows from 10 to 100 lines.
A route file that crosses 500 lines.
A model that eagerly loads every relation on every query. These small decisions compound over time, leading to slower performance, harder debugging, and more expensive refactoring later.

This guide helps you avoid the most common pitfalls and build Laravel apps that are:

Readable to other developers
Testable with clear separation of concerns
Scalable as the user base and feature set grow

2. Mistake 1: Putting Too Much Logic in Controllers

Controllers are meant to handle HTTP concerns:

Accepting requests
Running validation
Returning responses
When you put business logic directly in controllers, you end up with:
Fat controllers anyone is afraid to touch
Duplicated logic across multiple controller methods
Hard‑to‑test code that depends on the HTTP request
Example of the mistake:

class SubscriptionController extends Controller
{
    public function upgrade(Request $request)
    {
        $user = Auth::user();

        if ($user->isPremium()) {
            return back()->withErrors('You are already premium.');
        }

        $price = $request->input('plan') === 'annual'
            ? 1000 : 200;

        $gateway = new StripeGateway();
        $gateway->charge($user, $price);

        $user->role = 'premium';
        $user->premium_until = now()->addYear();
        $user->save();

        event(new UserUpgraded($user));

        return redirect('/dashboard');
    }
}

How to fix it:

Move charge and subscription logic into a SubscriptionService or SubscriptionAction.
Keep the controller action thin and focused on the request/response pipeline.

class SubscriptionController extends Controller
{
    public function upgrade(Request $request, UpgradeSubscriptionAction $action)
    {
        $result = $action->execute(
            user: Auth::user(),
            plan: $request->input('plan'),
        );

        if ($result->failed()) {
            return back()->withErrors($result->message);
        }

        return redirect('/dashboard');
    }
}

Benefits:

Business logic is reusable across APIs, commands, and jobs.
Easier to unit test the subscription logic without touching HTTP.
Cleaner diffs and easier on‑boarding for new team members.

3. Mistake 2: Ignoring Eloquent Relationships and N+1 Queries

“Eloquent is powerful, but misuse kills performance.”

Many Laravel developers fetch data manually instead of using Eloquent relationships. This leads to:

N+1 queries (one query per related record)
Slow page loads
Database bottlenecks

Example of the mistake:

$posts = Post::all();

foreach ($posts as $post) {
    echo $post->user->name; // Each access triggers a separate query
}

How to fix it:

Define relationships in your models (User belongsToMany Posts, etc.).
Use with() to eager load related data.

$posts = Post::with('user')->get();

foreach ($posts as $post) {
    echo $post->user->name; // No extra query
}

Additional tips:

Use select() to limit columns when you don’t need the full model.
Avoid all() on large tables; paginate instead with paginate().
Use tools like laravel-debugbar or clockwork to detect N+1 queries early.

4. Mistake 3: Poor Database Design and Indexing

“Bad database design will always be your bottleneck.”

Many Laravel apps start with poorly normalized tables, missing foreign keys, or no indexes on frequently queried columns. This leads to:

Slow queries
Complex joins and filters in PHP instead of SQL
Inconsistent or denormalized data

Common anti‑patterns:

Storing JSON in a single column instead of proper relationships
Using integers for IDs but not defining foreign‑key constraints
Not indexing columns used in where, order, or join clauses

How to fix it:

Use Laravel migrations to define tables, indexes, and foreign keys.
Normalize your data where it makes sense (e.g., users → posts → comments).

Index frequently filtered columns:

$table->index('status');
$table->foreignId('user_id')->constrained();

Benefits:

Faster queries as datasets grow
Easier to maintain data consistency
Cleaner, more predictable Eloquent relationships

5. Mistake 4: Not Using Form Requests or Validation Properly

“Validation should be reusable, not copy‑pasted.”

Laravel’s validation is powerful, but it’s often embedded directly in controllers as inline arrays or repeated in multiple methods.

Example of the mistake:

class UserController extends Controller
{
    public function update(Request $request)
    {
        $request->validate([
            'name' => 'required',
            'email' => 'required|email',
            'age' => 'nullable|integer|min:18',
        ]);

        // ...
    }

    public function store(Request $request)
    {
        $request->validate([
            'name' => 'required',
            'email' => 'required|email',
            'age' => 'nullable|integer|min:18',
        ]);

        // ...
    }
}

How to fix it:

Create Form Request classes:

php artisan make:request UserStoreRequest
php artisan make:request UserUpdateRequest

class UserStoreRequest extends FormRequest
{
    public function rules()
    {
        return [
            'name' => 'required',
            'email' => 'required|unique:users,email',
            'age' => 'nullable|integer|min:18',
        ];
    }
}

Then inject the form request into your controller:

public function store(UserStoreRequest $request)
{
    $validated = $request->validated();

    // ...
}

Benefits:

Validation rules are reusable and centralized
You can add custom validation logic or authorization inside the form request
Controllers stay lean and focused

6. Mistake 5: Ignoring Migrations and Model Structure

“They removed the model directory after the first migration.”

Migrations are Laravel’s way to version‑control your database. Ignoring them or using them incorrectly leads to:

Divergent schemas across environments
Manual SQL changes in production
Broken deployments
Common mistakes:
Not using down() methods in migrations
Writing business logic inside migration files (e.g., looping through users and updating them)
Skipping foreign keys or using unsigned() on integer foreign keys
How to fix it:
Always define proper foreign keys:

$table->foreignId('user_id')->constrained();

Use rollback‑safe migrations with clear up() and down() methods.
Avoid complex business logic in migrations; move it to seeders or jobs.

Best practice:

Treat migrations as “immutable” after they’re pushed to production.
Use Schema::table() for alterations, not Schema::dropIfExists() for simple changes.

7. Mistake 6: Messy Routes and Poor Naming Conventions

“Routes are the contract of your app.”

Laravel’s routing system is powerful, but it’s easy to end up with a monolithic routes/web.php file and inconsistently named routes.

Common issues:

Mixing API and web routes in one file
Not using route groups (prefix, middleware, namespace)
Using inconsistent route names like userShow, showUser, show_user

How to fix it:

Split routes into:
- routes/web.php (HTML pages)
- routes/api.php (REST or JSON endpoints)
Use route groups to apply middleware and prefixes:

Route::middleware('auth')->prefix('admin')->group(function () {
    Route::get('users', [UserController::class, 'index'])->name('admin.users.index');
    Route::post('users', [UserController::class, 'store'])->name('admin.users.store');
});

Follow consistent naming conventions (e.g.,

resource_route_name.action, snake_case):

Route::name('users.')->group(function () {
    Route::get('/users', [UserController::class, 'index'])->name('index');
    Route::get('/users/{user}', [UserController::class, 'show'])->name('show');
});

Benefits:

Routes are easier to scan and maintain
Route names are predictable for other developers
Auth and middleware configuration is centralized

8. Mistake 7: Overusing Helper/Static Methods and Global Helpers

“Helper methods are helpers, not your business logic.”

Many Laravel apps accumulate global helper functions in app/Helpers or config/helpers.php. This leads to:

Hidden dependencies and hard‑to‑trace behavior
Testing nightmare (no dependency injection)
Spaghetti‑style code scattered across functions

How to fix it:

Use services, actions, or managers instead of global helpers.
Use dependency injection where possible. For example, instead of:

// app/Helpers/general.php
function calculateDiscount($price, $user)
{
    return $price * 0.9;
}

Use a service:

class DiscountService
{
    public function calculate($price, User $user)
    {
        return $price * 0.9;
    }
}

Inject it into your controller or action:

public function checkout(Request $request, DiscountService $discount)
{
    $price = $request->input('price');
    $discounted = $discount->calculate($price, $user);

    // ...
}

Benefits:

Clear dependencies and easier testing
Reusable across services, jobs, and controllers
Easier to refactor or replace logic

9. Mistake 8: Skipping Tests and Documentation

“Tests are your safety net.”

Skipping tests leads to:

Fear of refactoring
More bugs in production
Longer on‑boarding for new developers

How to fix it:

Write feature tests for critical user flows.
Write unit tests for business logic and services. Use Laravel’s built‑in testing helpers:

public function test_user_can_upgrade_subscription()
{
    $user = User::factory()->create();

    $response = $this
        ->actingAs($user)
        ->post(route('subscriptions.upgrade'), [
            'plan' => 'annual',
        ]);

    $response->assertRedirect('/dashboard');
    $this->assertTrue($user->fresh()->isPremium());
}

Best practices:

Use expectsDatabaseTransactions() for database‑intensive tests.
Keep your tests fast and focused.
Add high‑level documentation for architecture, routes, and key classes.

10. Mistake 9: Hard‑coding Logic in Migrations or Seeders

“Migrations are not meant to run business logic.”

People sometimes write loops, call services, or send notifications inside migrations or seeders. This is dangerous because:

Migrations are meant to be repeatable and safe to roll back
Running business logic here can break future deployments

How to fix it:

Use migrations only for:
- Schema changes
- Simple data seeding (if needed)
Move business logic into:
- Artisan commands
- Jobs
- Seeders with proper rollback support

Example:

php artisan make:command MigrateOldUserSubscriptions

Then run it explicitly instead of hiding it in a migration.

Benefits:

Migrations stay predictable and safe
Business logic can be retried or rolled back cleanly

11. Mistake 10: Poor Error Handling and Logging

“Exceptions are information, not noise.”

Ignoring error handling and logging in Laravel apps leads to:

Silent failures
Difficult debugging in production
Unpredictable behavior after exceptions

How to fix it:

Use try/catch blocks where appropriate.
Use Log::error(), Log::info(), or report() to log errors.
Configure app/Exceptions/Handler.php to:
- Report critical errors to services like Sentry, Bugsnag, or LogRocket
- Transform exceptions into user‑friendly messages

Example:

public function report(Throwable $exception)
{
    if ($exception instanceof CustomException) {
        // Log or notify specific teams
        Log::channel('slack')->error($exception->getMessage());
    }

    parent::report($exception);
}

Benefits:

Easier debugging and faster incident response
Better visibility into production issues

12. Frequently Asked Questions (FAQs)

Q. Should I always move logic from controllers to services?
A. Yes, if it’s reusable business logic. Keep controllers focused on HTTP concerns and use services, actions, or domain classes for the rest.

Q. Is it okay to keep small apps without tests?
A. For small prototypes, maybe. But even tiny apps benefit from a basic test suite once they go to production.

Q. Can I mix web and API routes in one file?
A. Technically yes, but it’s cleaner to separate them into web.php and api.php with proper prefixing and middleware.

Q. Are migrations really necessary for small changes?
A. Yes, especially after going live. Migrations help keep your team and environment in sync.

Q. How do I know if my app has N+1 queries?
A. Use tools like laravel-debugbar or clockwork to analyse queries or enable Laravel’s built‑in query logging in development.

13. Interesting Facts & Stats

Well-structured Laravel apps with services, form requests, and proper Eloquent usage can reduce controller code by 40-60% in larger projects. Source: https://laravel.com/docs/eloquent-resources
Teams that consistently use migrations and tests spend 25-35% less time debugging in production compared to teams that don’t. Source: https://martinfowler.com/articles/practical-test-pyramid.html
Avoiding N+1 queries often reduces page load time by 2-10x for list-style pages with relationships.Source: https://laravel.com/docs/eloquent-relationships#eager-loading
Laravel’s Form Request system and built-in validation rules have become industry standards for clean, maintainable validation logic in web frameworks.Source: https://laravel.com/docs/validation

14. Conclusion

Laravel is a powerful framework that encourages fast development, but it also amplifies the impact of bad habits. Common mistakes like fat controllers, poor database design, and ignoring migrations can slow your app and your team over time.

By consistently:

Moving business logic out of controllers
Using Eloquent properly and avoiding N+1 queries
Organizing routes, migrations, and helpers
Writing tests and proper logging

You turn Laravel’s “easy to start” advantage into a long‑term maintenance win.

Clean, maintainable Laravel code is not about syntax alone; it’s about structure, separation of concerns, and respecting the framework’s conventions. Stick to these patterns, and you’ll avoid most of the common pitfalls Laravel developers face in production.

About the Author: Lakashya is a full‑stack Laravel developer at AddWeb Solution specializing in scalable, real‑time applications with PHP and modern frontends.

References

Laravel Documentation. (2025). Best Practices. https://laravel.com/docs/12.x
Laravel.io. (2026). Common Laravel Mistakes I See in Production. https://laravel.io/articles/common-laravel-mistakes-i-see-in-production-and-how-to-avoid-them
Laravel Daily. (2025). Laravel: 9 Typical Mistakes Juniors Make. https://laraveldaily.com/post/laravel-typical-mistakes-juniors-make

Practical Techniques for Optimizing React Performance in Production: A Developer’s Guide

Mayank Goyal — Thu, 26 Mar 2026 10:34:57 +0000

"Premature optimization is the root of all evil." - Donald Knuth

Introduction

As modern web applications grow in complexity, maintaining high performance becomes increasingly important. React is known for its efficient rendering and component-based architecture, but poorly optimized applications can still suffer from issues such as slow rendering, unnecessary re-renders, large bundle sizes, and delayed user interactions.

Optimizing React applications in production environments requires a combination of architectural decisions, efficient state management, and performance monitoring.

This guide explores practical techniques developers can use to optimize React performance in production, helping applications remain fast, scalable, and responsive even as they grow.

Key Takeaways

Avoid unnecessary component re-renders using React.memo, useMemo, and useCallback.
Use code splitting and lazy loading to reduce initial bundle size.
Implement list virtualization when rendering large datasets.
Optimize state management to prevent unnecessary updates.
Use debouncing and throttling for expensive operations like search or scroll events.
Regularly monitor performance using React DevTools and browser profiling tools.

Index

Understanding React Performance Optimization
Detailed Comparison of Optimization Techniques
Implementation Overview
When to Use Each Optimization Strategy
Developer Recommendations
Code Examples
FAQ
Interesting Facts
Conclusion

1. Understanding React Performance Optimization

1.1 Preventing Unnecessary Re-Renders
React re-renders components whenever their state or props change. While React's Virtual DOM minimizes DOM updates, unnecessary re-renders can still affect performance.

Key Techniques

React.memo
Prevents functional components from re-rendering when props have not changed.

useMemo
Caches the result of expensive computations.

useCallback
Prevents functions from being recreated on every render.

Best For

Components that render frequently
Expensive calculations inside components
Preventing unnecessary child component updates

1.2 Code Splitting and Lazy Loading
Large JavaScript bundles increase page load time and negatively impact performance.
Code splitting allows loading only the code required for the current view.
React provides built-in support through:

React.lazy
Suspense

Benefits

Faster initial page load
Reduced bundle size
Improved performance on slower networks

Best For

Large applications
Route-based components
Feature-heavy dashboards

1.3 Virtualizing Large Lists
Rendering thousands of DOM elements simultaneously can slow down the browser.
List virtualization renders only the items visible in the viewport.
Popular libraries include:

react-window
react-virtualized

Best For

Large tables
Infinite scrolling lists
Analytics dashboards

2. Detailed Comparison

2.1 Rendering Optimization

2.2 Bundle Optimization

2.3 Event Optimization

3. Implementation Overview

3.1 Memoizing Components
Flow:

Component receives props
React compares previous and new props
If props are unchanged, rendering is skipped

Pros

Reduces unnecessary rendering
Improves UI responsiveness
Useful in component-heavy applications

3.2 Code Splitting in React
Flow:

User visits application
Initial bundle loads
Additional components load on demand
Suspense displays fallback UI

Pros

Faster application startup
Reduced network usage
Better scalability for large apps

3.3 Virtualizing Lists
Flow:

Large dataset fetched
Only visible rows rendered
Rows dynamically mounted/unmounted during scroll

Pros

Reduces DOM nodes
Smooth scrolling
Improves memory usage

4. When to Use Each Optimization Technique

Use Memoization If

Components render frequently
Parent components trigger unnecessary updates
Expensive calculations occur during rendering

Use Code Splitting If

Your bundle size is large
Your app has multiple pages
You want faster initial load time

Use Virtualization If

Rendering thousands of items
Working with large datasets
Building analytics dashboards or tables

5. Developer Recommendation

For most production React applications, the following performance practices provide the biggest impact:

Memoize components when necessary
Implement route-based code splitting
Use virtualization for large lists
Debounce expensive API requests
Continuously monitor performance using profiling tools

Optimizing too early can introduce unnecessary complexity, so focus first on identifying performance bottlenecks before applying optimizations.

6. Code Examples

6.1 Preventing Re-renders with React.memo

import React from "react";

const UserCard = React.memo(({ name }) => {
  console.log("Rendering UserCard");

  return <div>{name}</div>;
});

export default UserCard;

6.2 Using useMemo for Expensive Calculations

import { useMemo } from "react";

function ExpensiveComponent({ items }) {

  const sortedItems = useMemo(() => {
    return items.sort((a, b) => a.price - b.price);
  }, [items]);

  return (
    <ul>
      {sortedItems.map(item => (
        <li key={item.id}>{item.name}</li>
      ))}
    </ul>
  );
}

6.3 Lazy Loading Components

import React, { Suspense } from "react";

const Dashboard = React.lazy(() => import("./Dashboard"));

function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <Dashboard />
    </Suspense>
  );
}

6.4 Debouncing API Calls

import debounce from "lodash/debounce";

const searchUsers = debounce(async (query) => {
  const response = await fetch(`/api/users?q=${query}`);
  return response.json();
}, 300);

7. FAQ

1. What causes poor React performance?
Common causes include:

Unnecessary re-renders
Large bundle sizes
Rendering large lists
Heavy computations during rendering

2. Should every component use React.memo?
No. Memoization adds comparison overhead. Use it only when performance issues exist.

3. What tool helps identify slow components?
React DevTools Profiler helps identify slow rendering components.

4. Is lazy loading good for SEO?
It can be, but server-side rendering (SSR) may be required for SEO-critical pages.

5. What is the biggest performance win in React apps?
Reducing bundle size and unnecessary re-renders typically provides the largest improvements.

8. Interesting Facts

React’s Virtual DOM reduces direct DOM manipulation by updating only the elements that changed.Source:https://react.dev/learn/render-and-commit
The React Profiler tool allows developers to measure rendering performance and detect unnecessary updates.Source:https://react.dev/reference/react/Profiler
Libraries like react-window can reduce thousands of DOM nodes to just a few dozen visible elements.Source:https://github.com/bvaughn/react-window

"Programs must be written for people to read, and only incidentally for machines to execute." – Harold Abelson

9. Conclusion

Optimizing React performance in production requires thoughtful architecture and strategic use of optimization techniques. While React already provides efficient rendering through the Virtual DOM, developers must still manage component updates, bundle sizes, and expensive computations carefully.

By applying techniques such as memoization, code splitting, virtualization, and event optimization, developers can significantly improve application responsiveness and scalability.
The key is to identify real performance bottlenecks first and apply targeted optimizations, ensuring the application remains both maintainable and performant.

About the Author: Mayank is a web developer at AddWebSolution, building scalable apps with PHP, Node.js & React. Sharing ideas, code, and creativity.

Secure File Uploads in Laravel: Validation, Storage & Basic Virus Protection

Abodh Kumar — Fri, 20 Mar 2026 07:54:18 +0000

Security is not a product, but a process.- Bruce Schneier, Security Technologist

File uploads are a common requirement in modern web applications - whether it's profile pictures, documents, invoices, or media files. However, insecure file uploads can expose your application to serious threats such as malware injection, remote code execution, and data breaches.

Key Takeaway

Validate both file extension (mimes) and content-based MIME type (mimetypes) - never trust one alone.
Always generate a random UUID-based filename - never persist client-supplied filenames to disk.
Store files outside the public directory on a private disk; serve through authenticated controllers.
Use temporary signed URLs for file downloads to prevent unauthorized access and link sharing.
Integrate ClamAV or another AV engine; fail closed if the scanner is unavailable.
Strip EXIF metadata from images to protect user privacy and prevent location data leaks.

Introduction
Understanding File Upload Risks
Laravel File Validation - A Deep Dive
Secure Storage Strategies
Basic Virus Protection with ClamAV
Advanced Security Techniques
Stats & Interesting Facts
FAQ
Conclusion

1. Introduction

document managers to medical portals and e-commerce platforms. Yet despite their ubiquity, secure file handling remains one of the most misunderstood areas of web development.

Laravel, PHP's premier web framework, equips developers with an elegant and expressive set of tools for handling file uploads. However, leveraging those tools securely requires a deliberate, layered approach: validating the incoming file, storing it safely, and scanning it for malicious content before it ever reaches your users or your system.

This article walks you through a complete, production-ready strategy for secure file uploads in Laravel - covering everything from MIME type validation and file size limits to randomized storage paths and ClamAV antivirus integration.

2. Understanding File Upload Risks

Before writing a single line of code, it is essential to understand why file uploads are dangerous. Attackers routinely exploit careless upload implementations to compromise servers and steal data. The most common attack vectors include:

2.1 Malicious File Execution
An attacker uploads a PHP file disguised as an image (e.g., evil.php.jpg). If the server is misconfigured or the MIME type is not properly validated, the file may be executed as a script, granting the attacker remote code execution (RCE).

2.2 Denial of Service via Large Uploads
Without file size restrictions, an attacker can upload multi-gigabyte files to exhaust disk space or memory, effectively taking down the server.

2.3 Path Traversal Attacks
If user-supplied filenames are stored directly, an attacker might submit a filename like ../../etc/passwd to write or overwrite sensitive files on the server.

2.4 Virus & Malware Distribution
Even with correct validation, a seemingly valid PDF or DOCX file might contain embedded malware. If your application serves these files to other users, you inadvertently become a malware distribution vector.

2.5 Metadata & Privacy Leaks
Uploaded images may contain EXIF metadata including GPS coordinates, device information, or personally identifiable information - a significant privacy risk if files are served publicly without stripping metadata.

3. Laravel File Validation - A Deep Dive

Laravel's validation system is remarkably expressive. The file() and image() validation rules, combined with additional constraints, let you define exactly what constitutes an acceptable upload.

3.1 Basic Validation Setup
Start with a dedicated Form Request class to keep your controller lean:

    php artisan make:request SecureFileUploadRequest

In your SecureFileUploadRequest class:

<?php

namespace App\Http\Requests;
use Illuminate\Foundation\Http\FormRequest;
class SecureFileUploadRequest extends FormRequest
{
   public function authorize(): bool
   {
       return auth()->check();
   }

   public function rules(): array
   {
       return [
           'document' => [
               'required',
               'file',
               'mimes:pdf,docx,xlsx,png,jpg,jpeg',
               'mimetypes:application/pdf,image/png,image/jpeg,
                          application/vnd.openxmlformats-officedocument
                          .wordprocessingml.document',
               'max:10240',  
               'min:1', 
           ],
       ];
   }
   public function messages(): array
   {
       return [
           'document.mimes'    => 'Only PDF, DOCX, XLSX, PNG, and JPG                   files are allowed.',
           'document.max'      => 'File size must not exceed 10 MB.',
           'document.mimetypes'=> 'The file type does not match the expected MIME type.',
       ];
   }
}

3.2 Understanding mimes vs. mimetypes
This is a common source of confusion. The mimes rule validates using the file extension, while mimetypes validates the actual MIME type detected by PHP's Fileinfo extension. Using both together is a stronger approach:

mimes:pdf,png - Laravel maps the extension to an expected MIME type and checks it.
mimetypes:application/pdf - Directly checks the MIME type detected from file content.
Using both ensures neither the extension nor the MIME type is spoofed independently.

3.3 Validating Dimensions for Images
For image uploads specifically, Laravel allows you to enforce dimension constraints:

'avatar' => [
   'required',
   'image',
   'mimes:jpeg,png,webp',
   'max:2048',
   'dimensions:min_width=100,min_height=100,max_width=3000,max_height=3000',
],

4. Secure Storage Strategies

Validating a file is only half the battle. Where and how you store it is equally critical to your application's security posture.

4.1 Never Store in the Public Directory
A common beginner mistake is storing uploads directly in public/uploads. This makes files web-accessible by default, which is dangerous. Use the storage/app/private directory instead:

use Illuminate\Support\Facades\Storage;
use Illuminate\Support\Str;

public function store(SecureFileUploadRequest $request)
{
   $file = $request->file('document');

   $filename = Str::uuid() . '.' . $file->getClientOriginalExtension();

   $path = $file->storeAs(
       'uploads/' . auth()->id(),
       $filename,
       'private' 
   );

   Document::create([
       'user_id'        => auth()->id(),
       'original_name'  => $file->getClientOriginalName(),
       'stored_path'    => $path,
       'mime_type'      => $file->getMimeType(),
       'file_size'      => $file->getSize(),
   ]);
   return response()->json(['message' => 'File uploaded successfully.']);
}

4.2 Configuring a Private Disk
In config/filesystems.php, define a private disk that lives outside the public web root:

'disks' => [
   'private' => [
       'driver'     => 'local',
       'root'       => storage_path('app/private'),
       'visibility' => 'private',
   ],
   's3_private' => [
       'driver'     => 's3',
       'key'        => env('AWS_ACCESS_KEY_ID'),
       'secret'     => env('AWS_SECRET_ACCESS_KEY'),
       'region'     => env('AWS_DEFAULT_REGION'),
       'bucket'     => env('AWS_BUCKET'),
       'visibility' => 'private',
   ],
],

Never trust user input when handling uploaded files. Always validate file types, sizes, and storage locations on the server side.- Stephen Rees-Carter

4.3 Serving Files Securely via Signed URLs
Since files are not publicly accessible, you need a controller endpoint to serve them. Use signed URLs to prevent unauthorized access:

use Illuminate\Support\Facades\URL;
$signedUrl = URL::temporarySignedRoute(
   'file.download',
   now()->addMinutes(30),
   ['document' => $document->id]
);
Route::get('/files/{document}', function (Document $document) {
   abort_unless(
       request()->hasValidSignature() &&
       $document->user_id === auth()->id(),
       403
   );
   return Storage::disk('private')->download($document->stored_path);
})->name('file.download')->middleware(['auth', 'signed']);

5. Basic Virus Protection with ClamAV

Even perfectly validated files can harbor malicious payloads. A PDF can contain JavaScript exploits; a DOCX can embed macros. Integrating an antivirus scanner is the professional-grade answer.

5.1 Installing ClamAV
On Ubuntu/Debian servers:

sudo apt-get update
sudo apt-get install -y clamav clamav-daemon
sudo freshclam   # Update virus definitions
sudo systemctl enable clamav-daemon
sudo systemctl start clamav-daemon

5.2 Using the Laravel ClamAV Package
The most popular Laravel integration is via the laravel-clamav package:

composer require clamav/clamav

Or use a custom wrapper with the PHP socket connection:

composer require sunspikes/clamav-validator

5.3 Building a ClamAV Service
Here is a clean, reusable ClamAV service class:

<?php

namespace App\Services;

use Illuminate\Http\UploadedFile;
use Illuminate\Support\Facades\Log;

class VirusScanService
{
   protected string $clamdHost;
   protected int $clamdPort;

   public function __construct()
   {
       $this->clamdHost = config('services.clamav.host', '127.0.0.1');
       $this->clamdPort = config('services.clamav.port', 3310);
   }

   public function scan(UploadedFile $file): bool
   {
       $socket = @fsockopen(
           $this->clamdHost,
           $this->clamdPort,
           $errno,
           $errstr,
           5
       );

       if (!$socket) {
           Log::error('ClamAV unavailable', ['error' => $errstr]);
           // Fail closed: reject upload if scanner unavailable
           return false;
       }

       $fileContent = file_get_contents($file->getRealPath());
       $length = strlen($fileContent);

       fwrite($socket, "nINSTREAM\n");
       fwrite($socket, pack('N', $length) . $fileContent);
       fwrite($socket, pack('N', 0));

       $response = trim(fgets($socket));
       fclose($socket);
       // 'stream: OK' means clean; anything else is infected
       return str_contains($response, 'OK');
   }
}

5.4 Integrating the Scanner in Your Controller

<?php
use App\Services\VirusScanService;

public function store(SecureFileUploadRequest $request, VirusScanService $scanner)
{
   $file = $request->file('document');
   if (!$scanner->scan($file)) {
       return response()->json([
           'message' => 'File rejected: security scan failed.'
       ], 422);
   }
}

Allowing unrestricted file uploads can lead to remote code execution if attackers manage to upload executable scripts to the server.- OWASP Security Guidelines

6. Advanced Security Techniques

6.1 Strip EXIF Metadata from Images
Use the intervention/image package to remove sensitive metadata from uploaded images before storage:

composer require intervention/image

use Intervention\Image\Facades\Image;

$image = Image::make($file->getRealPath());
// Strip all EXIF data by re-encoding
$cleanImage = $image->encode('jpg', 85);
Storage::disk('private')->put($path, $cleanImage);

6.2 Implement Rate Limiting on Upload Endpoints

// In routes/api.php
Route::middleware(['auth', 'throttle:10,1'])  // 10 uploads per minute
    ->post('/upload', [FileController::class, 'store']);

6.3 Queue Virus Scans for Large Files
For large files, run the virus scan asynchronously to avoid request timeouts:

// Create a job

php artisan make:job ScanUploadedFile

// Dispatch after initial upload
ScanUploadedFile::dispatch($document->id)->onQueue('scans');

6.4 Content Security Headers
Even with secure storage, add these HTTP headers when serving files to prevent browsers from executing served content:

return response()->download($path)->withHeaders([
   'X-Content-Type-Options' => 'nosniff',
   'Content-Disposition'    => 'attachment; filename="' . $filename . '"',
   'X-Frame-Options'        => 'DENY',
]);

7.Stats & Interesting Facts

According to the Veracode State of Software Security Report, file upload vulnerabilities are responsible for a significant portion of web application security flaws, with around 12% of critical vulnerabilities related to improper file handling.Source: https://www.veracode.com/resources/reports/state-of-software-security-report
The OWASP Top 10 highlights insecure file upload mechanisms as a common cause of Remote Code Execution (RCE) attacks when applications fail to properly validate file types and storage paths. Source: https://owasp.org/www-project-top-ten/
Research shows that attackers often bypass validation by disguising malicious scripts as image or PDF files, such as renaming a .php file to .jpg or .png.Source: https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload
Malware scanning systems like ClamAV can detect up to 98% of known malware signatures, making antivirus scanning a useful additional layer for file upload security.Source: https://www.clamav.net/documents/clamav-user-manual
According to security studies, allowing unrestricted file sizes can lead to Denial-of-Service (DoS) attacks, where attackers intentionally upload large files to exhaust server disk space.Source: https://owasp.org/www-community/attacks/Denial_of_Service
According to cybersecurity research, over 90% of successful web attacks exploit known vulnerabilities that could have been prevented through proper validation and secure configuration practices.Source: https://www.verizon.com/business/resources/reports/dbir/
According to the SANS Institute, improper file upload validation is one of the most common ways attackers upload web shells, which can allow them to execute commands on the server and gain full control of the application.Source: https://www.sans.org/white-papers/

8. FAQ

1. Why is file upload security important in Laravel?
Ans: File upload security is important because attackers can upload malicious files such as scripts or malware. If the application does not properly validate and store files, it may lead to serious vulnerabilities like Remote Code Execution (RCE), data theft, or server compromise.

2. How can Laravel validate uploaded files?
Ans: Laravel provides built-in validation rules such as mimes, mimetypes, max, and file. These rules help ensure that only allowed file types and sizes are uploaded, reducing the risk of malicious files entering the system.

3. Where should uploaded files be stored in Laravel?
Ans: Uploaded files should ideally be stored in the storage directory instead of the public directory. Laravel’s Storage system helps manage files securely and prevents direct execution of uploaded files on the server.

4. How can I limit the file size in Laravel uploads?
Ans: You can limit file size using the max validation rule in Laravel. For example:
'file' => 'required|mimes:jpg,png,pdf|max:2048'
This restricts uploads to specific file types and a maximum size of 2MB.

5. Can Laravel scan uploaded files for viruses?
Ans: Laravel does not include built-in antivirus scanning, but you can integrate tools like ClamAV or third-party security services to scan uploaded files before storing or processing them.

6. What are some best practices for secure file uploads?
Ans: Best practices include validating file types, restricting file sizes, renaming uploaded files, storing them outside the public directory, scanning for malware, and setting proper file permissions.

7. How can attackers bypass file upload validation?
Ans: Attackers may rename malicious files to appear as safe formats (e.g., .php to .jpg) or manipulate MIME types. This is why multiple validation layers and secure storage practices are important.

8. Does Laravel provide protection against malicious file execution?
Ans: Laravel helps reduce risk through validation and secure storage systems, but developers must still implement proper validation, file renaming, and server configuration to fully protect against malicious file execution.

9. Conclusion

Secure file uploads are not a feature - they are a discipline. Every layer described in this article serves a specific purpose in a defense-in-depth strategy:

Validation catches malformed or unexpected files before they enter your system.
Secure storage ensures that even if validation is bypassed, files cannot be executed.
Virus scanning adds a safety net against sophisticated threats that evade other checks.
Rate limiting, signed URLs, and HTTP security headers complete the picture.

Laravel provides all the building blocks you need. The responsibility lies with developers to connect them thoughtfully, test them rigorously, and stay current with evolving attack patterns.

Security is never a one-time setup. Regularly update ClamAV virus definitions, review your validation rules when you add new file types, and audit your storage access logs. A breach avoided is invisible - and that invisibility is the mark of excellent security engineering.

About the Author: Abodh is a PHP and Laravel Developer at AddWeb Solution, skilled in MySQL, REST APIs, JavaScript, Git, and Docker for building robust web applications.

DEV Community: AddWeb Solution Pvt Ltd

Managing Environment Variables in React Properly

Key Takeaways

Index

1. Why This Matters

2. Mistake 1: Using the Wrong Environment Variable Prefix

3. Mistake 2: Treating Client-Side Env Vars Like Secrets

4. Mistake 3: Mixing process.env and import.meta.env

5. Mistake 4: Hardcoding URLs Instead of Using Config

6. Mistake 5: Not Using .env.local Properly

7. Mistake 6: Forgetting to Restart the Dev Server

8. Mistake 7: Keeping Too Many Environment Files Without a Clear Rule

9. Mistake 8: Not Validating Required Variables

10. Mistake 9: Committing Sensitive .env Files to Git

11. Mistake 10: Poor Naming and Documentation

12. Frequently Asked Questions (FAQs)

13. Interesting Facts & Stats

14. Conclusion

Building Reusable UI Components in React (Clean & Scalable Approach)

Why Reusable Components Matter

What Makes a Component Truly Reusable?

Key Takeaways

Index

1. Introduction

2. What Are Reusable Components?

3. Component Design Principles

4. Types of Reusable Components

5. Structuring Your Component Folder

6. Props and Configuration

7. Composition vs Inheritance

8. Styling Strategies

9. Handling State and Logic

10. Building a Design System

12. Why This Approach Works

16. FAQ

17. Conclusion

Handling API Errors & Loading States in React (Clean UX Approach)

Key Takeaway

Table of Contents

1. Introduction

2. Understanding the Three API States

3. Handling Loading States - Spinners, Skeletons & Beyond

4. Handling API Errors - Graceful Degradation

5. Building a Custom useFetch Hook

6. Advanced Techniques

7. Stats & Interesting Facts

8. FAQ

9. Conclusion.

Data Fetching Strategies in Next.js - SSR, SSG, ISR, and RSC

Key Takeaways

Index

Introduction

Quick Reference - All Strategies at a Glance

Strategy 01

Strategy 02

Strategy 03

Strategy 04 (Modern Default)

Architecture

Deep Dive

Production Patterns

Anti-Patterns

Stats

Interesting Facts

FAQ

Summary

Final Insight

Conclusion

Docker Image with Multi-Stage Builds & Docker Images Optimization

Table of Contents

1. Introduction

2. Overview: Multi-Stage Build Strategy (Builder + Production)

3. Stage 1: Builder - Compile Extensions, Install Tools & Dependencies

4. Stage 2: Production - Minimal Runtime Image

5. The .dockerignore File

6. Practical Setup (Step-by-step)

8. FAQs

9. Key Takeaways

10. Conclusion

Architecting Large-Scale Next.js Applications (Folder Structure, Patterns, Best Practices)

Key Takeaways