DEV Community: Prajapati Paresh

Demystifying Next.js Caching Strategies ⚡

Prajapati Paresh — Sat, 01 Aug 2026 04:42:53 +0000

The Complexity of the App Router

When Vercel introduced the Next.js App Router, it brought unprecedented power through React Server Components. However, it also introduced one of the most misunderstood and complex systems in modern frontend development: The Next.js Caching Architecture.

Many developers migrating from older React or Next.js Pages Router applications suddenly found their data acting unpredictably. A user would update their profile picture, navigate back to the dashboard, and the old picture would still be there. No matter how many times they refreshed the page, the data seemed permanently stuck. This happens because Next.js now caches almost everything by default to guarantee the absolute fastest page load speeds possible.

At Smart Tech Devs, we build enterprise-grade frontends that require real-time accuracy without sacrificing Core Web Vitals. To achieve this, you must understand the four distinct layers of the Next.js cache and, more importantly, how to forcefully invalidate them.

The Four Layers of Caching

Next.js operates a multi-tiered caching strategy that spans both the server and the client browser.

1. Request Memoization (Server-Side, Per Request)

React automatically extends the native fetch API. If you call the exact same fetch endpoint multiple times during a single render pass (e.g., fetching the current user in the Header, the Sidebar, and the Main Content), Next.js will only execute the network request once. Subsequent calls return the memoized result. This cache only lasts for the lifecycle of that specific page render.

2. The Data Cache (Server-Side, Persistent)

Unlike Request Memoization, the Data Cache persists across incoming requests and deployments. When you fetch data, Next.js stores the result on the server. If another user visits the site an hour later, they get the cached data instantly without hitting your database.

To control this, you configure the fetch options:


// ❌ Fetches fresh data every single time (Bypasses Data Cache)
const data = await fetch('https://api.example.com/stats', { cache: 'no-store' });

// ✅ Caches indefinitely until manually revalidated (Default behavior)
const data = await fetch('https://api.example.com/stats', { cache: 'force-cache' });

// ⏱️ Time-based Revalidation (Caches for 60 seconds)
const data = await fetch('https://api.example.com/stats', { next: { revalidate: 60 } });

3. Full Route Cache (Server-Side, Persistent)

Next.js doesn't just cache raw data; it caches the actual rendered HTML and Server Component payloads. At build time, Next.js renders your pages into static files. If your page does not use dynamic functions (like reading cookies, headers, or URL search params), it will be served from the Full Route Cache, providing instantaneous load times.

4. The Router Cache (Client-Side)

This is the layer that confuses most developers. Next.js stores a client-side memory cache in the user's browser. As the user navigates between pages using the <Link> component, Next.js caches the Server Component payload. If the user navigates back to a previously visited page, Next.js serves it instantly from browser memory without ever pinging the server.

Architecting Cache Invalidation (On-Demand Revalidation)

Caching is easy; invalidation is hard. In an enterprise application, when a user submits a form to update their profile, you need to instantly bust the Data Cache and the Full Route Cache so the UI reflects the new state.

We handle this using Next.js Server Actions and the revalidatePath or revalidateTag functions.

Step 1: Tagging Your Fetch Requests

When fetching data that might change frequently, we assign it a custom cache tag.


// app/dashboard/page.tsx
export default async function Dashboard() {
  // We tag this specific fetch request with 'user-profile'
  const res = await fetch('https://api.example.com/profile', {
    next: { tags: ['user-profile'] }
  });
  const user = await res.json();

  return <div>Welcome back, {user.name}</div>;
}

Step 2: Busting the Cache via Server Action

When the user updates their profile, we execute a Server Action. Inside this action, we mutate the database and then explicitly tell Next.js to purge any cached data associated with our tag.


// app/actions/profileActions.ts
'use server';

import { revalidateTag } from 'next/cache';
import db from '@/lib/database';

export async function updateName(formData: FormData) {
  const newName = formData.get('name');

  // 1. Mutate the actual database
  await db.user.update({ name: newName });

  // 2. Purge the Data Cache and Full Route Cache across the entire app
  // for any fetch request tagged with 'user-profile'
  revalidateTag('user-profile');

  return { success: true };
}

The Engineering ROI

Mastering the Next.js caching architecture transforms your frontend from a sluggish application into an enterprise-grade powerhouse. By leveraging the Data Cache and Full Route Cache, you drastically reduce the load on your backend databases, saving massive amounts of compute costs. By understanding the Client Router Cache, you provide users with SPA-like instant navigation. Most importantly, by correctly implementing On-Demand Revalidation via tags, you guarantee that your users never see stale data, achieving the perfect balance between blazing-fast performance and absolute data integrity.

Scaling Laravel: Mastering CQRS Architecture 🏗️

Prajapati Paresh — Sat, 01 Aug 2026 04:38:36 +0000

The Bottleneck of Traditional CRUD

When you build a standard Laravel application, you typically follow the CRUD (Create, Read, Update, Delete) paradigm. You have a single User model and a single UserController. This controller handles writing data (creating a user) and reading data (fetching a list of users). Under the hood, both the read and write operations interact with the exact same MySQL or PostgreSQL database table.

For most applications, this is perfectly fine. However, in high-traffic enterprise systems, the workload is rarely symmetrical. In a reporting dashboard or an e-commerce platform, your application might execute 1,000 "Read" queries for every 1 "Write" query. If you use the exact same database and the exact same Eloquent models for both, your heavy write operations (which lock rows and require transaction integrity) will start blocking your lightning-fast read operations, bringing your application to a crawl.

At Smart Tech Devs, when we architect platforms that demand massive scalability, we implement CQRS (Command Query Responsibility Segregation). CQRS is an architectural pattern that strictly separates the operation that mutates data (the Command) from the operation that reads data (the Query).

The Philosophy of CQRS

By separating Commands and Queries, we can optimize them independently.

Commands (Writes): These handle complex business validation, domain logic, and transactional integrity. They do not return data (other than a success acknowledgment).
Queries (Reads): These bypass complex domain logic entirely. They just fetch data as fast as possible, often from highly optimized, denormalized read-replicas or caching layers like Redis.

Phase 1: Structuring the Command Stack

Let's architect an order processing system. When a user places an order, it's a complex write operation involving inventory checks, payment processing, and state changes. We encapsulate this entirely within a Command object and a Command Handler.


namespace App\CQRS\Commands;

// 1. The Command: A simple Data Transfer Object (DTO)
class PlaceOrderCommand
{
    public function __construct(
        public readonly string $userId,
        public readonly array $items,
        public readonly string $paymentToken
    ) {}
}

Next, we build the Handler. This class executes the business logic. Notice that it does not return the created Order object; it simply executes the mutation.


namespace App\CQRS\Handlers;

use App\CQRS\Commands\PlaceOrderCommand;
use App\Models\Order;
use Illuminate\Support\Facades\DB;

class PlaceOrderHandler
{
    public function handle(PlaceOrderCommand $command): void
    {
        DB::transaction(function () use ($command) {
            // 1. Validate inventory (Domain Logic)
            // 2. Process Payment via Stripe
            
            // 3. Persist to the "Write" Database
            $order = Order::create([
                'user_id' => $command->userId,
                'status' => 'processing',
                'total' => calculateTotal($command->items)
            ]);

            // 4. Fire an event to sync the Read Database later
            OrderPlaced::dispatch($order);
        });
    }
}

Phase 2: Structuring the Query Stack

Now, let's look at the read side. If a user wants to view their order history, we don't need the heavy domain logic, and we don't even necessarily need Eloquent's object hydration overhead. We just need raw speed. We create a Query object to define the request, and a Query Handler to fetch it.


namespace App\CQRS\Queries;

class GetUserOrdersQuery
{
    public function __construct(public readonly string $userId) {}
}


namespace App\CQRS\Handlers;

use App\CQRS\Queries\GetUserOrdersQuery;
use Illuminate\Support\Facades\DB;

class GetUserOrdersHandler
{
    public function handle(GetUserOrdersQuery $query): array
    {
        // 1. We bypass Eloquent entirely for maximum read speed.
        // 2. We query from the optimized "Read" database connection.
        return DB::connection('mysql_read')
            ->table('user_order_views')
            ->where('user_id', $query->userId)
            ->orderBy('created_at', 'desc')
            ->get()
            ->toArray();
    }
}

Phase 3: Physical Database Segregation

The true power of CQRS is unlocked when you physically separate your databases. In Laravel, you can configure primary/replica connections in your config/database.php file. You write data to the Primary database, and read data from the Replicas.


'mysql' => [
    'read' => [
        'host' => ['192.168.1.2', '192.168.1.3'], // Read Replicas
    ],
    'write' => [
        'host' => ['192.168.1.1'], // Primary Master
    ],
    'driver' => 'mysql',
    'database' => env('DB_DATABASE'),
    'username' => env('DB_USERNAME'),
    'password' => env('DB_PASSWORD'),
    // ...
],

When an order is created (Command), it goes to the write database. Our previously dispatched OrderPlaced event triggers an asynchronous background worker. This worker updates a highly denormalized user_order_views table on the read replicas. This is called Eventual Consistency. The read database might be milliseconds behind the write database, but in exchange, we can handle tens of thousands of concurrent reads without locking the primary tables.

The Engineering ROI

Adopting CQRS in Laravel is not for simple blogs or internal tools; it introduces undeniable architectural complexity. However, for enterprise systems dealing with high-throughput reporting, massive user concurrency, or complex domain rules, it is a game-changer. By decoupling your reads from your writes, you can scale your database infrastructure asymmetrically—spinning up ten cheap read-replica servers while maintaining just one powerful primary write server. Furthermore, your codebase becomes highly organized; developers optimizing a complex reporting query will never accidentally break the core payment processing logic, as the two concerns are physically and logically separated.

Kill the API Layer: Next.js Server Actions ⚡

Prajapati Paresh — Fri, 31 Jul 2026 04:54:18 +0000

Liquid syntax error: Variable '{{% raw %}' was not properly terminated with regexp: /\}\}/

Architecting SaaS: Multi-Tenancy in Laravel 🏢

Prajapati Paresh — Fri, 31 Jul 2026 04:52:06 +0000

The SaaS Scaling Dilemma

When you transition from building internal company tools to building a Software-as-a-Service (SaaS) platform, the fundamental architecture of your database must evolve. In a standard application, every user accesses the same overarching dataset. However, in a B2B Enterprise SaaS application, you are onboarding entire organizations. Organization A (Tenant A) must never, under any circumstances, see the data belonging to Organization B (Tenant B). A data leak across tenant boundaries is the fastest way to destroy a SaaS company's reputation.

This architectural challenge is known as Multi-Tenancy. There are generally two ways to solve this: a Multi-Database approach (where every tenant gets a physically separate database) or a Single-Database approach (where all tenants share tables, but rows are strictly filtered by a `tenant_id`). While the Multi-Database approach offers ultimate isolation, it creates an infrastructure nightmare when you need to run migrations across 5,000 separate databases.

At Smart Tech Devs, for the vast majority of our enterprise SaaS builds, we utilize a Single-Database Multi-Tenancy Architecture. By leveraging Laravel's powerful Global Scopes and Middleware, we can create a system where data isolation is enforced automatically at the ORM layer, preventing developers from ever accidentally writing a query that leaks data.

Understanding the Architecture

The goal of our architecture is invisibility. The developer writing a controller should not have to remember to append ->where('tenant_id', currentTenantId()) to every single database query. If we rely on human memory, someone will eventually forget, and a catastrophic data breach will occur.

Instead, we intercept the request at the perimeter, identify the tenant from the URL or headers, and then instruct Laravel's Eloquent ORM to automatically append this filter to all queries globally.

Step 1: Identifying the Tenant (Middleware)

First, we need to know who is making the request. In a modern SaaS, this is often done via subdomains (e.g., companyA.smarttechdevs.in) or via an API header. For this example, we will intercept the request using a custom Middleware, identify the Tenant, and bind it to Laravel's Service Container so it can be accessed anywhere.


namespace App\Http\Middleware;

use Closure;
use App\Models\Tenant;
use Illuminate\Http\Request;
use Symfony\Component\HttpFoundation\Response;

class IdentifyTenant
{
    public function handle(Request $request, Closure $next): Response
    {
        // Example: Identifying tenant by a custom HTTP Header
        $tenantId = $request->header('X-Tenant-ID');

        if (! $tenantId) {
            return response()->json(['error' => 'Tenant identification missing.'], 400);
        }

        $tenant = Tenant::findOrFail($tenantId);

        // Bind the active tenant into the Service Container
        app()->instance('currentTenant', $tenant);

        return $next($request);
    }
}

Step 2: Enforcing Isolation (Global Scopes)

Now that the application knows who the tenant is, we must force Eloquent to respect this boundary. We achieve this using a Global Scope. A Global Scope allows us to add constraints to all queries for a given model automatically.


namespace App\Models\Scopes;

use Illuminate\Database\Eloquent\Builder;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Scope;

class TenantScope implements Scope
{
    public function apply(Builder $builder, Model $model)
    {
        // If we are in the console (e.g., running migrations) or if no tenant is set, 
        // we might want to skip this, but in production web requests, enforce it strictly.
        if (app()->has('currentTenant')) {
            $tenant = app('currentTenant');
            $builder->where($model->getTable() . '.tenant_id', $tenant->id);
        }
    }
}

Step 3: Creating a Reusable Trait

To easily apply this scope and ensure that newly created records automatically receive the correct tenant_id, we create a Trait that we can attach to any model that belongs to a tenant (like Invoice, Employee, or Project).


namespace App\Traits;

use App\Models\Scopes\TenantScope;

trait BelongsToTenant
{
    protected static function bootBelongsToTenant()
    {
        // 1. Automatically apply the Global Scope to all read queries
        static::addGlobalScope(new TenantScope);

        // 2. Automatically inject the tenant_id on creation (Write queries)
        static::creating(function ($model) {
            if (app()->has('currentTenant')) {
                $model->tenant_id = app('currentTenant')->id;
            }
        });
    }
}

Now, our models remain incredibly clean. We simply add the trait:


namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use App\Traits\BelongsToTenant;

class Invoice extends Model
{
    use BelongsToTenant;
    
    protected $fillable = ['amount', 'due_date', 'status']; // No need to make tenant_id fillable!
}

Step 4: The Developer Experience

With this architecture in place, the developer experience becomes flawless and secure. Inside a controller, if a developer writes:

$invoices = Invoice::all();

Laravel will automatically execute the following SQL query behind the scenes:

SELECT * FROM invoices WHERE tenant_id = 5;

Similarly, when creating a record:

Invoice::create(['amount' => 500, 'status' => 'unpaid']);

The system will automatically insert 5 into the tenant_id column without the developer ever needing to specify it.

Advanced Considerations: The Queue Worker Trap

The most common pitfall in Single-Database Multi-Tenancy occurs with Background Jobs. When you dispatch an event to a Redis Queue, the HTTP Request dies. When the Queue Worker picks up the job, there is no HTTP Header, no URL subdomain, and therefore, no Tenant in the Service Container! If your job tries to query an Invoice, it will fail or query the wrong data.

To solve this, your Job classes must explicitly serialize the tenant_id when they are dispatched. When the job is processed by the worker, the first line of the handle() method must manually re-bind the Tenant back into the Service Container before executing any Eloquent queries. This ensures that the global scopes continue to function securely even in asynchronous, background-processed environments.

The Engineering ROI

By implementing Multi-Tenancy at the architectural level rather than the application logic level, you completely eliminate an entire class of security vulnerabilities. Your codebase remains DRY (Don't Repeat Yourself), your controllers remain thin, and your engineering team can build features rapidly without the constant anxiety of accidentally exposing sensitive enterprise data across organizational boundaries.

Enterprise State Management: React & Zustand 🐻

Prajapati Paresh — Thu, 30 Jul 2026 05:26:15 +0000

The Collapse of React Context

State management is the most heavily debated topic in the React ecosystem. For years, Redux was the undisputed king, but its massive boilerplate and steep learning curve led many teams to seek alternatives. When React introduced the Context API, many developers assumed it was the ultimate state management replacement. Unfortunately, in enterprise applications, using Context for rapidly changing state leads to two massive architectural failures: Provider Hell and Unnecessary Re-renders.

Because Context forces you to wrap your application in layers of <Provider> tags, your component tree becomes deeply nested and unreadable. Worse, whenever a single value inside a Context object updates, every single component consuming that Context is forced to re-render, even if it only cares about a completely unrelated piece of data within that same Context.

At Smart Tech Devs, we architect high-performance React and Next.js applications by abandoning heavy Redux boilerplates and avoiding Context API pitfalls. Instead, we use Zustand. Zustand is a minimalist, unopinionated, and blazingly fast state management library that operates outside of the React component tree, eliminating Provider Hell entirely.

The Philosophy of Zustand

Unlike Context, Zustand relies on an atomic, subscription-based model. Your state lives in a centralized store outside of React's render cycle. Components subscribe only to the exact slices of state they need using "Selectors." If a property updates, only the components explicitly subscribed to that specific property will re-render.

Step 1: Architecting the Store (The Slices Pattern)

In a large application, putting all your state into one massive file is an anti-pattern. Zustand allows us to architect our state using the "Slices" pattern, where we divide our store logically by domain (e.g., Auth, Cart, UI) and merge them together.


// store/useStore.ts
import { create } from 'zustand';

// Define the shape of our User slice
interface AuthSlice {
  user: { id: string; name: string } | null;
  login: (userData: { id: string; name: string }) => void;
  logout: () => void;
}

// Define the shape of our Cart slice
interface CartSlice {
  items: Array<{ id: string; price: number }>;
  addItem: (item: { id: string; price: number }) => void;
  clearCart: () => void;
}

// Combine the types
type StoreState = AuthSlice & CartSlice;

// Create the unified store using the set function
export const useStore = create()((set) => ({
  // Auth Slice Implementation
  user: null,
  login: (userData) => set(() => ({ user: userData })),
  logout: () => set(() => ({ user: null })),

  // Cart Slice Implementation
  items: [],
  addItem: (item) => set((state) => ({ items: [...state.items, item] })),
  clearCart: () => set(() => ({ items: [] })),
}));

Step 2: Preventing Re-renders with Selectors

The true power of Zustand is revealed when we consume the state. Because there are no <Provider> wrappers, we can import the hook anywhere. However, we must use Selectors to ensure strict render boundaries.

If a component only needs the login function, it should not re-render when an item is added to the cart.


// components/LoginButton.tsx
import { useStore } from '@/store/useStore';

export default function LoginButton() {
  // ✅ CORRECT: Selecting only the specific function.
  // This component will NEVER re-render when cart items change.
  const login = useStore((state) => state.login);

  return (
     login({ id: '1', name: 'John Doe' })}
      className="bg-blue-600 text-white px-4 py-2 rounded"
    >
      Sign In
    
  );
}

Compare this to the React Context approach, where accessing useContext(StoreContext) would force LoginButton to re-render every time the cart total updated. Zustand solves this natively.

Step 3: Enterprise Middleware (Persistence)

Enterprise applications require state persistence across page reloads (e.g., keeping the user's cart intact). With Redux, this requires complex configuration with redux-persist. In Zustand, it is achieved instantly via built-in middleware.


// store/useStore.ts (Refactored with Persist Middleware)
import { create } from 'zustand';
import { persist } from 'zustand/middleware';

export const useStore = create()(
  persist(
    (set) => ({
      user: null,
      login: (userData) => set(() => ({ user: userData })),
      // ... rest of state
    }),
    {
      name: 'smart-tech-storage', // Key name in localStorage
      partialize: (state) => ({ user: state.user }), // Only persist the user slice!
    }
  )
);

The Engineering ROI

By adopting Zustand and the Slices pattern, you immediately eradicate React Provider Hell, flattening your component tree and vastly improving developer experience. Because state logic is decoupled from React's render lifecycle, you can even access and mutate your store from outside of React components (like inside standard utility functions or Axios interceptors). Furthermore, by strictly utilizing selectors, you guarantee optimal rendering performance, ensuring your frontend remains incredibly fast even as the state object grows to encompass thousands of properties.

Event-Driven Laravel Architecture 📡

Prajapati Paresh — Thu, 30 Jul 2026 05:22:30 +0000

The Perils of Synchronous Coupling

As your Laravel application grows from a simple monolith into a complex enterprise platform, the way your internal domains communicate becomes the most critical factor in system stability. In a traditional, synchronously coupled architecture, a single user action triggers a massive chain of procedural events. For example, when a user registers, your controller might create the database record, assign a default role, call an external API to subscribe them to a mailing list, and finally send a welcome email.

The problem with this synchronous approach is fragility. If the third-party mailing list API is down and times out, the entire registration request fails. The user receives a 500 Internal Server Error, their account creation is rolled back, and you lose a customer—all because a non-critical marketing integration was temporarily unavailable.

At Smart Tech Devs, we prevent these cascading failures by implementing an Event-Driven Architecture (EDA). Instead of domains explicitly calling each other's methods, they simply announce that something happened (an Event). Other domains can listen for that announcement and react asynchronously (Listeners). This completely decouples your application's core logic from its side effects.

Understanding the Publish-Subscribe (Pub/Sub) Model

Event-Driven Architecture relies heavily on the Pub/Sub pattern. In Laravel, this is seamlessly managed through the internal Event Dispatcher and Queue system. The "Publisher" (your core domain) dispatches an event. The "Subscribers" (your listeners) intercept that event and process their logic in the background using a message broker like Redis or RabbitMQ.

Step 1: Defining the Domain Event

An Event should be a simple data container. It should not contain business logic. Its only purpose is to describe something that has already happened in the past tense (e.g., UserRegistered, OrderShipped, PaymentFailed). We use the SerializesModels trait so that Eloquent models are gracefully serialized and deserialized when passed through the queue.


namespace App\Events;

use App\Models\User;
use Illuminate\Broadcasting\InteractsWithSockets;
use Illuminate\Foundation\Events\Dispatchable;
use Illuminate\Queue\SerializesModels;

class UserRegistered
{
    use Dispatchable, InteractsWithSockets, SerializesModels;

    public User $user;

    /**
     * Create a new event instance.
     */
    public function __construct(User $user)
    {
        $this->user = $user;
    }
}

Step 2: Dispatching the Event

Now, we refactor our controller or domain action. Instead of explicitly calling external services, we persist the core database transaction and immediately fire the event. The response is returned to the user in milliseconds, entirely unconcerned with what happens next.


namespace App\Http\Controllers;

use App\Models\User;
use App\Events\UserRegistered;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Hash;
use Illuminate\Support\Facades\DB;

class RegisterUserController extends Controller
{
    public function store(Request $request)
    {
        $validated = $request->validate([
            'name' => 'required|string|max:255',
            'email' => 'required|email|unique:users',
            'password' => 'required|min:8',
        ]);

        $user = DB::transaction(function () use ($validated) {
            return User::create([
                'name' => $validated['name'],
                'email' => $validated['email'],
                'password' => Hash::make($validated['password']),
            ]);
        });

        // Announce that the user has registered
        UserRegistered::dispatch($user);

        return response()->json(['message' => 'Registration successful!'], 201);
    }
}

Step 3: Creating Asynchronous Listeners

Next, we create the independent listeners. By implementing the ShouldQueue interface, we instruct Laravel to push these listeners onto our Redis queue worker rather than executing them synchronously during the HTTP request lifecycle. We can have multiple listeners reacting to the same single event.


namespace App\Listeners;

use App\Events\UserRegistered;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Support\Facades\Mail;
use App\Mail\WelcomeEmail;

class SendWelcomeEmail implements ShouldQueue
{
    use InteractsWithQueue;

    // Retry the job up to 3 times if it fails
    public $tries = 3;

    public function handle(UserRegistered $event)
    {
        // This runs in the background via a Queue Worker
        Mail::to($event->user->email)->send(new WelcomeEmail($event->user));
    }
}

We can create a completely separate listener for the mailing list integration without touching the email listener or the controller.


namespace App\Listeners;

use App\Events\UserRegistered;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Support\Facades\Http;
use Illuminate\Support\Facades\Log;

class SubscribeToMailingList implements ShouldQueue
{
    public function handle(UserRegistered $event)
    {
        $response = Http::timeout(5)->post('https://api.mailchimp.com/3.0/lists/sub', [
            'email_address' => $event->user->email,
            'status' => 'subscribed',
        ]);

        if ($response->failed()) {
            Log::warning("Failed to subscribe user {$event->user->id} to mailing list.");
            // We can choose to fail the job or let it pass gracefully
        }
    }
}

Handling Idempotency and Race Conditions in Listeners

When operating in a distributed queue environment, you must assume that "at-least-once" delivery could result in a listener being executed twice due to network timeouts. Therefore, your listeners must be idempotent. Before executing a heavy mutation in a listener, always check if the action has already been performed. For example, if a listener grants a signup bonus, check if the bonus record already exists for that user before inserting it.

The Engineering ROI

Transitioning to an Event-Driven Architecture fundamentally shifts your application from a fragile monolith to a resilient, self-healing system. HTTP response times plummet because heavy processing is shifted to background workers. When external APIs experience downtime, your core application remains fully functional, and failed queued jobs can simply be retried automatically once the external service recovers. This separation of concerns allows autonomous teams to build new features (like a new analytics listener) simply by subscribing to existing events, without ever risking regression bugs in the core system.

Shattering the Frontend Monolith: Micro-Frontends in Next.js 🧩

Prajapati Paresh — Wed, 29 Jul 2026 04:12:25 +0000

The Evolution of Frontend Complexity

Over the past decade, software engineering has largely embraced the microservices architecture on the backend. We split massive backend monoliths into smaller, independently deployable services based on business domains. However, while the backend evolved, the frontend was left behind. We created a new beast: The Frontend Monolith.

In massive enterprise web applications, it is common to find dozens of development teams pushing code to a single, gigantic React or Next.js repository. This creates severe bottlenecks. Build times skyrocket to 30+ minutes. A critical bug introduced by the "Checkout" team blocks the deployment of a crucial feature built by the "Marketing" team. Codebase navigation becomes a nightmare, and upgrading a core dependency like React or a UI library requires a massive, coordinated effort across the entire organization.

At Smart Tech Devs, when scaling web platforms for enterprise teams, we implement a Micro-Frontend Architecture. Just like backend microservices, micro-frontends allow independent teams to build, test, and deploy separate pieces of the user interface autonomously, assembling them seamlessly in the user's browser.

The Magic of Webpack Module Federation

Historically, implementing micro-frontends was clunky. Developers relied on iframes (which caused massive accessibility and styling issues) or complex build-time compositions via NPM packages (which still required the main host app to redeploy every time a package updated).

Everything changed with the release of Webpack 5 and a feature called Module Federation. Module Federation allows a JavaScript application to dynamically load code from another application at runtime. The host application doesn't need to know about the remote code at build time; it simply fetches it over the network when the user navigates to the page.

Architecting the Solution

To implement this in Next.js, we require two distinct types of applications:

The Host (Shell) Application: The main container that handles global routing, authentication state, and the overall layout (headers, footers).
The Remote Applications: Independent Next.js apps that expose specific components or pages (e.g., a standalone E-commerce Checkout app).

Step 1: Configuring the Remote Application

Let's say we have an independent application built by the Checkout team. They want to expose their CartWidget component so the Host application can display it in the global navbar. We utilize the @module-federation/nextjs-mf plugin in the remote application's next.config.js.


// Remote App (Checkout Team) - next.config.js
const NextFederationPlugin = require('@module-federation/nextjs-mf');

module.exports = {
  webpack(config, options) {
    config.plugins.push(
      new NextFederationPlugin({
        name: 'checkoutApp',
        filename: 'static/chunks/remoteEntry.js',
        exposes: {
          // Exposing the CartWidget component to the world
          './CartWidget': './components/CartWidget.tsx',
        },
        shared: {
          // Ensure React is shared as a singleton to prevent hooks crashing
          react: { singleton: true, eager: false, requiredVersion: false },
          'react-dom': { singleton: true, eager: false, requiredVersion: false },
        },
      })
    );
    return config;
  },
};

Step 2: Configuring the Host Application

Now, we configure the main Host application to consume the remote code. We tell the Host where to find the remoteEntry.js file generated by the Checkout app.


// Host App (Shell) - next.config.js
const NextFederationPlugin = require('@module-federation/nextjs-mf');

module.exports = {
  webpack(config, options) {
    config.plugins.push(
      new NextFederationPlugin({
        name: 'hostApp',
        remotes: {
          // Defining the remote URL (dynamically assigned in production via env vars)
          checkoutApp: `checkoutApp@http://localhost:3001/_next/static/chunks/remoteEntry.js`,
        },
        shared: {
          react: { singleton: true, eager: false, requiredVersion: false },
          'react-dom': { singleton: true, eager: false, requiredVersion: false },
        },
      })
    );
    return config;
  },
};

Step 3: Dynamic Runtime Integration

With the configuration in place, we can now render the remote component inside our Host application. Because this component is fetched over the network at runtime, we must use Next.js dynamic imports wrapped in a React Suspense boundary to handle the loading state gracefully.


// Host App - components/Navbar.tsx
import dynamic from 'next/dynamic';
import { Suspense } from 'react';

// Dynamically import the remote component
const RemoteCartWidget = dynamic(
  () => import('checkoutApp/CartWidget'),
  { ssr: false } // Best practice to render remote MF components client-side initially
);

export default function GlobalNavbar() {
  return (
    <nav className="flex justify-between items-center p-4 bg-gray-900 text-white">
      <div className="logo">Smart Tech Devs</div>
      
      {/* Render the remote component, showing a fallback while it downloads */}
      <Suspense fallback={<div className="animate-pulse w-8 h-8 bg-gray-700 rounded"></div>}>
        <RemoteCartWidget />
      </Suspense>
    </nav>
  );
}

Handling Global State and Styling

The greatest challenge in Micro-Frontends is managing shared state (like a logged-in User object) and CSS conflicts. To manage state, the Host application usually holds the primary React Context Provider (or Zustand store). Because we defined React as a "singleton" in the Webpack configuration, the remote components will seamlessly hook into the Host's context. For styling, it is highly recommended to use scoped CSS solutions like CSS Modules, Tailwind CSS, or styled-components to ensure a class name in the "Checkout" app doesn't accidentally override the design of a button in the "Host" app.

The Engineering ROI

Micro-frontends fundamentally transform how large engineering departments operate. The "Checkout" team can now merge a PR, trigger their own isolated CI/CD pipeline, and deploy their app to production in 2 minutes. The moment their deployment finishes, the new CartWidget is instantly reflected on the main Host application without the Host ever needing to redeploy. You achieve true team autonomy, vastly reduced build times, and the ability to scale your frontend infrastructure to infinity.

Taming the Laravel Monolith: A Deep Dive into DDD 🏗️

Prajapati Paresh — Wed, 29 Jul 2026 04:10:22 +0000

The Crisis of the MVC Monolith

When you first start building a Laravel application, the standard Model-View-Controller (MVC) architecture feels like magic. You place your models in the app/Models directory, your controllers in app/Http/Controllers, and your business logic organically spreads between the two. However, as your enterprise application scales over months or years, this default structure begins to break down. You suddenly find yourself staring at an app/Models folder containing 150 unrelated files, ranging from User and Invoice to ShippingLabel and TaxCalculation.

The core problem with the standard MVC folder structure is that it groups files by their technical type rather than their business purpose. A developer tasked with fixing a bug in the "Invoicing" system has to jump between the Models folder, the Controllers folder, the Events folder, and the Listeners folder, slowly piecing together how the system works. This cognitive overload leads to tightly coupled code, where changing a user's profile accidentally breaks the billing system.

At Smart Tech Devs, when we architect large-scale enterprise platforms, we abandon the standard MVC folder structure. Instead, we embrace Domain-Driven Design (DDD). DDD is a software engineering approach that aligns your codebase directly with the business domains it serves, making your code modular, scalable, and infinitely easier to maintain.

Understanding the Core Concepts of DDD

Before writing any code, it is crucial to understand the terminology and philosophy behind Domain-Driven Design. DDD is not just a folder structure; it is a way of thinking about your business.

1. Bounded Contexts

In a large application, the same word can mean different things depending on the context. For example, to the "Shipping" department, a Customer is just a name and a physical address. To the "Billing" department, a Customer is a credit card token and a tax ID. In DDD, we define strict "Bounded Contexts." Instead of one massive User model that knows about shipping, billing, and marketing, we isolate these concepts into separate domains.

2. Ubiquitous Language

Your code should read like a business conversation. If the business stakeholders say, "When a customer upgrades their subscription, we generate a prorated invoice," your code should explicitly contain classes like UpgradeSubscriptionAction and GenerateProratedInvoice, rather than a generic UserController@update method.

Restructuring Laravel for DDD

To implement DDD, we typically create a new src/ directory at the root of the Laravel project and update the composer.json file to autoload it. We divide this directory into distinct business Domains (e.g., Invoicing, Identity, Inventory).


// 📂 Example Folder Structure
src/
  ├── Domain/
  │   ├── Invoicing/
  │   │   ├── Models/
  │   │   ├── DataTransferObjects/
  │   │   ├── ValueObjects/
  │   │   ├── Actions/
  │   │   └── Events/
  │   └── Identity/
  ├── App/
  │   ├── Http/
  │   │   ├── Controllers/
  │   └── Console/

Step-by-Step Implementation

Step 1: Leveraging Value Objects

In standard Laravel, we often represent money as an integer or a float on a model. This leads to logic duplication when formatting or calculating totals. In DDD, we use Value Objects—immutable classes that represent a descriptive aspect of the domain with no conceptual identity.


namespace Domain\Invoicing\ValueObjects;

use InvalidArgumentException;

class Money
{
    private int $amountInCents;
    private string $currency;

    public function __construct(int $amountInCents, string $currency = 'USD')
    {
        if ($amountInCents < 0) {
            throw new InvalidArgumentException("Amount cannot be negative.");
        }

        $this->amountInCents = $amountInCents;
        $this->currency = $currency;
    }

    public function add(Money $other): self
    {
        if ($this->currency !== $other->currency) {
            throw new InvalidArgumentException("Currency mismatch.");
        }

        return new self($this->amountInCents + $other->amountInCents, $this->currency);
    }

    public function getFormatted(): string
    {
        return number_format($this->amountInCents / 100, 2) . ' ' . $this->currency;
    }
}

Step 2: Securing Boundaries with Data Transfer Objects (DTOs)

Controllers should not pass raw HTTP Request arrays into your business logic. This creates a brittle dependency on the HTTP layer. Instead, we map the request data into strongly typed Data Transfer Objects (DTOs) before passing it to the domain layer.


namespace Domain\Invoicing\DataTransferObjects;

class CreateInvoiceDTO
{
    public function __construct(
        public readonly int $customerId,
        public readonly array $lineItems,
        public readonly string $dueDate
    ) {}

    public static function fromRequest(Request $request): self
    {
        return new self(
            $request->validated('customer_id'),
            $request->validated('items'),
            $request->validated('due_date')
        );
    }
}

Step 3: Encapsulating Business Logic in Actions

With our data validated and wrapped in a DTO, we execute the actual business logic using an Action class (sometimes called an Application Service or Command). Actions have a single responsibility: execute a specific business use case.


namespace Domain\Invoicing\Actions;

use Domain\Invoicing\Models\Invoice;
use Domain\Invoicing\DataTransferObjects\CreateInvoiceDTO;
use Illuminate\Support\Facades\DB;

class CreateInvoiceAction
{
    public function execute(CreateInvoiceDTO $dto): Invoice
    {
        return DB::transaction(function () use ($dto) {
            $invoice = Invoice::create([
                'customer_id' => $dto->customerId,
                'due_date' => $dto->dueDate,
                'status' => 'draft',
            ]);

            foreach ($dto->lineItems as $item) {
                $invoice->items()->create($item);
            }

            // Fire domain event
            InvoiceCreated::dispatch($invoice);

            return $invoice;
        });
    }
}

Step 4: Thinning Out the Controller

Because the complex logic is encapsulated in the Domain layer, our Application layer (the Controller) becomes incredibly thin. Its only job is to receive the HTTP request, instantiate the DTO, call the Action, and return an HTTP response. If we ever want to trigger this exact same logic from an Artisan CLI command, we simply call the Action without touching the Controller.


namespace App\Http\Controllers\Invoicing;

use App\Http\Controllers\Controller;
use Illuminate\Http\JsonResponse;
use Domain\Invoicing\Actions\CreateInvoiceAction;
use Domain\Invoicing\DataTransferObjects\CreateInvoiceDTO;
use Illuminate\Http\Request;

class InvoiceController extends Controller
{
    public function store(Request $request, CreateInvoiceAction $action): JsonResponse
    {
        $dto = CreateInvoiceDTO::fromRequest($request);
        
        $invoice = $action->execute($dto);

        return response()->json([
            'message' => 'Invoice generated successfully',
            'invoice_id' => $invoice->id
        ], 201);
    }
}

The Long-Term Engineering ROI

Migrating a Laravel application to a Domain-Driven Design architecture introduces undeniable upfront complexity. You are writing more files, defining more strict boundaries, and investing more time in architectural planning. However, for an application expected to live for years and be maintained by dozens of developers, this investment pays massive dividends.

By organizing code by business domain, new developers can onboard significantly faster. If they are tasked with fixing a billing bug, they know exactly where the Invoicing domain lives. Furthermore, DDD sets the perfect foundation for future transitions into microservices. Because your domains are already decoupled, splitting the Invoicing folder into its own standalone microservice later down the road becomes a matter of infrastructure, not a massive code rewrite.

Stop the Blank Screen: Next.js Streaming & Suspense ⏳

Prajapati Paresh — Tue, 28 Jul 2026 04:20:02 +0000

The All-or-Nothing Rendering Trap

In traditional Server-Side Rendering (SSR), the server must wait to fetch all the data for a page before it can generate the HTML and send it to the client. If your dashboard has a lightning-fast user profile widget but relies on a slow analytics query that takes 3 seconds, the user stares at a blank screen for 3 seconds. The slow component bottlenecks the fast ones.

At Smart Tech Devs, we build fluid, non-blocking user interfaces by leveraging React Suspense and Streaming in the Next.js App Router. This allows us to send parts of the UI to the browser immediately while the slower data fetches finish in the background.

Architecting Progressive UIs

Streaming breaks down the page's HTML into smaller chunks. Next.js instantly delivers the static layout and wraps the slow dynamic components in a fallback state until their data resolves.

Step 1: Isolating the Data Fetch

First, we create a Server Component that handles its own asynchronous data fetching. We intentionally do not await this data at the top-level page layout.


// components/RevenueChart.tsx
import db from '@/lib/database';

export default async function RevenueChart() {
  // Simulate a slow database query (e.g., 3 seconds)
  const revenueData = await db.analytics.getHeavyRevenueMetrics();

  return (
    <div className="p-4 border rounded-xl">
      <h3>Q3 Revenue</h3>
      {/* Chart rendering logic using revenueData */}
    </div>
  );
}

Step 2: Wrapping with Suspense

In our main page component, we import the heavy component and wrap it in a <Suspense> boundary. We provide a lightweight skeleton as a fallback.


// app/dashboard/page.tsx
import { Suspense } from 'react';
import RevenueChart from '@/components/RevenueChart';
import UserProfile from '@/components/UserProfile'; // Fast component
import ChartSkeleton from '@/components/Skeletons/ChartSkeleton';

export default function DashboardPage() {
  return (
    <main className="grid grid-cols-2 gap-6">
      {/* This renders instantly */}
      <UserProfile /> 
      
      {/* Next.js sends the skeleton immediately, then streams the chart in later */}
      <Suspense fallback={<ChartSkeleton />}>
        <RevenueChart />
      </Suspense>
    </main>
  );
}

The Engineering ROI

By implementing Streaming and Suspense, you drastically reduce your Time To First Byte (TTFB) and First Contentful Paint (FCP). Users instantly perceive your application as lightning-fast, and slow backend queries no longer paralyze the entire frontend experience.

Separate Reads from Writes: CQRS in Laravel 🔀

Prajapati Paresh — Tue, 28 Jul 2026 04:17:51 +0000

The "God Controller" Bottleneck

As enterprise applications grow, controllers often become bloated monoliths. A single endpoint might handle complex validation, fire off external API calls, mutate multiple database tables, and then run a heavy, multi-join SQL query just to return the updated UI state. This tightly couples your read logic with your write logic, making both incredibly difficult to scale or optimize independently.

At Smart Tech Devs, we break this bottleneck by implementing CQRS (Command Query Responsibility Segregation). This architectural pattern mandates that the methods used to mutate data (Commands) must be strictly separated from the methods used to fetch data (Queries).

Deconstructing CQRS in Laravel

By separating these concerns, we can route write operations to a primary database while routing read operations to specialized, lightning-fast read replicas or cached projections.

Step 1: The Command (Writes)

A Command represents an intent to change system state. We encapsulate this inside a dedicated Job or Action class. It does not return data; it only performs the mutation.


namespace App\Commands;

use App\Models\Order;
use Illuminate\Support\Facades\DB;

class PlaceOrderCommand
{
    public function __construct(
        public int $userId,
        public array $cartItems
    ) {}

    public function execute(): void
    {
        DB::transaction(function () {
            $order = Order::create(['user_id' => $this->userId]);
            $order->items()->createMany($this->cartItems);
            
            // Dispatch event for projection builders or other domains
            OrderPlaced::dispatch($order);
        });
    }
}

Step 2: The Query (Reads)

A Query represents a request for data. Because it has no side effects, it can bypass the heavy ORM and use raw SQL or query builder for maximum performance, reading directly from a specialized Read Model.


namespace App\Queries;

use Illuminate\Support\Facades\DB;

class GetUserOrderSummaryQuery
{
    public function __construct(public int $userId) {}

    public function fetch(): array
    {
        // Bypassing Eloquent for raw read speed
        return DB::table('order_summary_projections')
            ->where('user_id', $this->userId)
            ->orderByDesc('last_order_date')
            ->get()
            ->toArray();
    }
}

The Engineering ROI

By adopting CQRS, your codebase becomes highly modular and testable. You gain the ability to scale your read and write databases independently, drastically improve endpoint performance, and pave a clear pathway toward Event Sourcing and advanced microservices architectures.

Stop Writing API Routes: Next.js Server Actions

Prajapati Paresh — Mon, 27 Jul 2026 04:44:25 +0000

The Client-to-API Friction

In traditional React Single Page Applications (SPAs), submitting a simple form requires an exhausting amount of boilerplate. You have to build a dedicated backend API route, write a client-side fetch request, manage loading states, handle cross-origin resource sharing (CORS), and manually sync the UI with the newly mutated data.

At Smart Tech Devs, we accelerate our frontend development velocity by adopting Server Actions in the Next.js App Router. This architecture allows us to execute secure backend code directly from client-side interactions, entirely eliminating the need for intermediary API endpoints.

The Server Actions Paradigm

Server Actions are asynchronous functions that run exclusively on the server. They can be called directly from React components—even Client Components—blurring the line between the frontend and backend.

Step 1: Defining the Server Action

We create a dedicated file for our actions and use the "use server" directive. Inside this function, we can securely interact with our database, as this code will never be shipped to the browser.


'use server';

import db from '@/lib/database';
import { revalidatePath } from 'next/cache';

export async function createProject(formData: FormData) {
  const title = formData.get('title') as string;
  
  if (!title) throw new Error('Title is required');

  // Securely mutate the database directly
  await db.project.create({
    data: { title }
  });

  // Purge the cache so the UI updates instantly
  revalidatePath('/dashboard');
}

Step 2: Client Integration

You can wire this Server Action directly into a standard HTML form's action attribute. Because it leverages native web APIs, the form can even submit before the JavaScript bundle has fully loaded (Progressive Enhancement).


import { createProject } from '@/actions/projectActions';
import { SubmitButton } from '@/components/SubmitButton';

export default function NewProjectForm() {
  return (
    <form action={createProject} className="flex flex-col gap-4">
      <input 
        type="text" 
        name="title" 
        placeholder="Enter project name..." 
        className="border p-2"
        required
      />
      
      {/* A custom button using useFormStatus() for loading states */}
      <SubmitButton /> 
    </form>
  );
}

The Engineering ROI

By adopting Server Actions, you drastically reduce codebase complexity. You eliminate the need for dozens of boilerplate API routes, achieve end-to-end type safety automatically, natively handle loading and error states, and ensure your forms work seamlessly even on slow networks. It is the fastest way to mutate data in modern React.

Process 10k Tasks Safely: Job Batching in Laravel 🚂

Prajapati Paresh — Mon, 27 Jul 2026 04:42:25 +0000

The Long-Running Request Problem

Imagine your application needs to generate end-of-month financial reports for 10,000 users. If you try to process this synchronously in an HTTP controller, the server will time out, leaving the user staring at a broken page and half of the reports ungenerated. Even if you push them to a standard queue, tracking when the entire job of 10,000 reports is finished is notoriously difficult.

At Smart Tech Devs, we handle massive, resource-intensive workflows using Laravel Job Batching. This allows us to group thousands of asynchronous jobs together, process them in parallel, and execute callbacks when the entire batch is complete.

Harnessing Job Batching

Instead of dispatching jobs blindly into the void, batching gives you a tracking ID. This allows your frontend to show a real-time progress bar to the user.

Step 1: Dispatching the Batch

We use the Bus::batch() facade to array our jobs and define what happens when the batch succeeds, fails, or finishes completely.


use App\Jobs\GenerateMonthlyReport;
use Illuminate\Support\Facades\Bus;
use Throwable;

$users = User::active()->pluck('id');
$jobs = $users->map(fn($id) => new GenerateMonthlyReport($id))->toArray();

$batch = Bus::batch($jobs)->then(function (Batch $batch) {
    // All jobs completed successfully
    Notification::route('mail', 'admin@smarttechdevs.in')
        ->notify(new ReportsCompletedNotification());
})->catch(function (Batch $batch, Throwable $e) {
    // First batch job failure detected
    Log::error('Batch processing failed: ' . $e->getMessage());
})->finally(function (Batch $batch) {
    // Executed when the batch has finished (regardless of success/failure)
})->name('Monthly Financial Reports')->dispatch();

// Return the batch ID to the frontend to poll for progress
return response()->json(['batch_id' => $batch->id]);

Step 2: Processing the Individual Job

Inside the individual job class, we use the Batchable trait. If a specific user's report fails, we can mark the job as failed, which triggers the batch's catch callback.


namespace App\Jobs;

use Illuminate\Bus\Batchable;
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;

class GenerateMonthlyReport implements ShouldQueue
{
    use Batchable, Queueable;

    public function __construct(public int $userId) {}

    public function handle()
    {
        if ($this->batch()->cancelled()) {
            // Determine if the batch has been cancelled...
            return;
        }

        // Heavy processing logic here...
    }
}

The Engineering ROI

By implementing Job Batching, you transform fragile, timeout-prone endpoints into robust, highly scalable background processes. You gain the ability to process tasks in parallel across multiple queue workers, handle partial failures gracefully, and provide users with transparent, real-time progress tracking.