DEV Community: Lakashya Upadhyay

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

Building Real-time Notifications with Laravel Broadcasting and React

Lakashya Upadhyay — Mon, 02 Mar 2026 08:40:43 +0000

"Your users don't want to refresh to know what just happened."

Real-time notifications keep your users in sync with what's happening in your app the moment it happens. Whether it's a new club event, a gallery image, or a direct message, Laravel Broadcasting combined with React (or Firebase push) gives you a clean, scalable way to deliver these updates instantly.

This guide walks you through building real-time notifications in Laravel, wiring them to a React frontend (and optionally Firebase), and structuring everything in a way that fits enterprise-grade apps

Key Takeaways

Use Laravel Broadcasting for server-side event streaming over WebSockets
Use Laravel Echo in React to subscribe to channels and listen for events
Use private channels for per-user notifications and proper authorizationUse Laravel notifications when you want a unified API (database, broadcast, mail, etc.)
Use Firebase Cloud Messaging for OS-level push notifications on web/mobile
Real-time notifications improve UX, engagement, and responsiveness of your Laravel apps

Index

Why Real-time Notifications Matter
How Laravel Broadcasting Works
Broadcasting vs Firebase Notifications
Setting Up Broadcasting in Laravel
Creating a Broadcastable Notification/Event
Wiring React with Laravel Echo
Implementing User-specific (Private) Notifications
Using Firebase for Push Notifications
Common Mistakes to Avoid
FAQs
Interesting Facts & Stats
Conclusion

1. Why Real-time Notifications Matter

Real-time notifications ensure your app pushes updates to users the moment something important occurs, instead of waiting for manual refreshes or cron-based checks
This is critical for:

- Engagement: Users stay hooked when they see new events, bookings, or messages instantly
- Productivity: Admins can react faster to changes like new registrations or approvals
- UX: Your app feels modern and responsive, like chat apps or live dashboards
- Scalability: WebSockets reduce polling overhead and server load for frequent updates

Today, Laravel's built-in broadcasting API, combined with WebSockets or Pusher-style drivers, makes building these real-time experiences straightforward

2. How Laravel Broadcasting Works (The Basics)

“A real-time notification system is the heartbeat of a responsive web application.”- Technical Lead

Laravel Broadcasting lets you "broadcast" server-side events over WebSockets (or Pusher-like services) so your frontend can listen in real time.

Core pieces:

Broadcast events: PHP classes (often implementing ShouldBroadcast) that describe what to send to the front end
Channels: Named streams (public, private, or presence) your front end subscribes to
Broadcasters: Drivers like pusher, ably, redis + laravel-websockets, etc., that handle WebSocket delivery
Laravel Echo: JavaScript client that connects to your broadcaster and listens to events in the browser/React app
Example event outline:
Backend: Broadcast an event (e.g., NewNotificationCreated) on channel notifications or App.Models.User.{id}
Frontend: Echo.channel('notifications').listen('NewNotificationCreated', callback)
Laravel reconstructs the payload into JSON and sends it over the WebSocket connection automatically.

3. Broadcasting vs Firebase Notifications

Both Broadcasting and Firebase deliver real-time messages, but they solve slightly different problems.

Table 1: Comparison of Laravel Broadcasting and Firebase FCM
A solid architecture often uses both: broadcasting for in-app real-time UI and FCM for OS-level push when the user is not actively on the page.

4. Setting Up Broadcasting in Laravel

Laravel ships with broadcasting out of the box; you just pick a driver and configure it.
Steps:

Configure broadcast driver in .env:
- BROADCAST_DRIVER=pusher (or ably, redis, etc.)
Configure your broadcaster in config/broadcasting.php (keys, cluster, host, etc.)
Enable the BroadcastServiceProvider if not already enabled (for channels.php)
Define channels in routes/channels.php:
- Public channel: Broadcast::channel('notifications', fn () => true);
- Private channel: Broadcast::channel('App.Models.User.{id}', fn ($user, id)=>(int)user->id === (int)$id);

If you use Laravel WebSockets or a self-hosted server, you configure a pusher-compatible app ID/key/secret pointing to your WebSocket host and port.

5. Creating a Broadcastable Notification/Event

There are two main ways to broadcast from Laravel: events and notifications.
Events approach:
Generate an event:
php artisan make:event ClubEventCreated
Example:

class ClubEventCreated implements ShouldBroadcast
{
    public $clubEvent;

    public function __construct($clubEvent)
    {
        $this->clubEvent = $clubEvent;
    }

    public function broadcastOn(): array
    {
        return [
            new Channel('club-events'), // Public
            new PrivateChannel('App.Models.User.' . $this->clubEvent->user_id), // User-specific
        ];
    }

    public function broadcastWith(): array
    {
        return [
            'message' => 'New club event: ' . $this->clubEvent->name,
            'event' => $this->clubEvent,
        ];
    }
}

Dispatch: event(new ClubEventCreated($eventModel));

Notifications approach:

Use Laravel's Notification system and add broadcast to via().
Laravel automatically broadcasts a notification to a channel App.Models.User.{id}.
Example:

class NewClubEventNotification extends Notification implements ShouldBroadcast
{
    public $clubEvent;

    public function __construct($clubEvent)
    {
        $this->clubEvent = $clubEvent;
    }

    public function via($notifiable): array
    {
        return ['database', 'broadcast'];
    }

    public function toBroadcast($notifiable): BroadcastMessage
    {
        return new BroadcastMessage([
            'message' => 'New club event created!',
            'event_id' => $this->clubEvent->id,
        ]);
    }
}

Send: $user->notify(new NewClubEventNotification($clubEvent));
This gives you database + real-time delivery with almost no extra wiring.

6. Wiring React with Laravel Echo

“Users shouldn’t refresh to see updates,real-time notifications should do the talking.” - Frontend Specialist

On the frontend, you use Laravel Echo plus a connector like pusher-js to subscribe to channels and listen for events in React.
Key steps:

Install libraries in your React app (e.g., laravel-echo and pusher-js)
Create a shared Echo instance (for example in a separate echo.js or service file)
Configure with broadcaster: 'pusher', key, wsHost, wsPort, forceTLS, etc.
In a React component, subscribe to channels and attach listeners in useEffect, cleaning up on unmount Example pattern:

import { useEffect } from 'react';
import Echo from 'laravel-echo'; // Your Echo instance

const NotificationsComponent = ({ userId }) => {
  useEffect(() => {
    // Public channel
    Echo.channel('club-events')
      .listen('ClubEventCreated', (e) => {
        console.log('New event:', e.message);
        // Update UI state
      });

    // Private per-user notifications
    Echo.private(`App.Models.User.${userId}`)
      .notification((notification) => {
        console.log('Personal notification:', notification.message);
        // Show toast or update badge
      });

    return () => {
      Echo.leaveChannel('club-events');
      Echo.leaveChannel(`App.Models.User.${userId}`);
    };
  }, [userId]);

  return <div>Your notifications here</div>;
};

This pattern keeps your React code clean and focused on updating state when events arrive.

7. Implementing User-specific (Private) Notifications

For real-world apps, you rarely show the same notification to everyone; you want user-specific or role-specific notifications.
Laravel makes this easy:

Use private channels like App.Models.User.{id} for per-user streams
Write a channel authorization callback in routes/channels.php to ensure only the owner can subscribe
Use Laravel Notifications with broadcast channel, which automatically targets App.Models.User.{id}

Example channels.php:

Broadcast::channel('App.Models.User.{id}', function ($user, $id) {
    return (int) $user->id === (int) $id;
});

On the React side:

Subscribe to Echo.private(App.Models.User.${userId}) once the user is authenticated
Use the .notification(...) helper to receive any broadcast notification
Update a notifications list, counter badge, or toast component when data arrives This maps perfectly to scenarios like "show a red dot on the bell icon when there is a new club event for this user".

8. Using Firebase for Push Notifications

Broadcasting covers in-app real-time, but sometimes you want OS-level push notifications via Firebase Cloud Messaging (FCM).
Common flow:

Configure a Firebase project and enable FCM
Include the Firebase JS SDK in your web app and request notification permission from the user
Retrieve and store the user's FCM token in your Laravel users table
From Laravel, send push notifications using FCM HTTP APIs or a package (e.g., via a notification channel)

class ClubEventPushNotification extends Notification
{
    public function via($notifiable): array
    {
        return ['fcm']; // Assuming a package like laravel-fcm
    }

    public function toFcm($notifiable)
    {
        return FcmMessage::create('New Club Event')
            ->withBody('Check out the new event!')
            ->withData(['event_id' => $this->event->id]);
    }
}

Usage examples:

When a new gallery image is uploaded, broadcast via Laravel for users currently on the site and send an FCM push for users in the background
When a booking is about to expire, trigger queued notifications that hit FCM and update in-app badges via broadcasting at the same time Combining FCM with Laravel Broadcasting gives you a full real-time story: in-tab updates plus system-level pushes.

9. Common Mistakes to Avoid

Mixing up event and notification names in Echo listeners (they must match the class name or notification structure)
Forgetting to start or configure your WebSocket server (like laravel-websockets or echo server)
Using public channels for sensitive data instead of private channels with authorization callbacks
Not cleaning up Echo subscriptions in React components, causing memory leaks or duplicate listeners
Ignoring token lifecycle for FCM (tokens change and need to be refreshed and updated on the backend)
Avoiding these issues will save you hours of debugging and strange "it works sometimes" bugs.

10. FAQs

Q. Do I need Pusher to use Laravel Broadcasting?
No. Laravel supports multiple broadcasters, including self-hosted Laravel WebSockets and Redis-based setups that emulate Pusher's protocol.

Q. When should I use events vs notifications for broadcasting?
Use broadcastable events when you just need a fire-and-forget message; use notifications when you also want database/email/SMS plus real-time broadcasting under a single API.

Q. How do I secure user-specific notifications?
Use private channels (App.Models.User.{id}) with proper channel authorization and Echo.private on the frontend.

Q. Can I use React, Vue, or plain JS with Laravel Echo?
Yes. Echo is framework-agnostic and can be used in React, Vue, Next.js, or even vanilla JavaScript, as long as you instantiate it correctly in your client-side code.

Q. Is Firebase required for real-time notifications?
No. WebSockets via Broadcasting and Echo are enough for in-app real-time updates. Firebase is only needed if you want OS-level push notifications outside of the active browser tab or app.

11. Interesting Facts & Stats

Laravel's broadcasting system is built to integrate directly with its event and notification APIs, so you can reuse the same infrastructure for in-app events, queues, and real-time updates.
Articles and tutorials on WebSockets and real-time Laravel apps highlight significant reductions in server load when replacing long polling with proper WebSocket broadcasting.
Guides on Laravel + Next.js and Laravel + WebSockets show that real-time notification architectures scale well when you offload to WebSockets servers and use broadcasting events efficiently.
Documentation for Laravel notifications emphasizes how broadcasting and the notification system together simplify multi-channel delivery (database, mail, Slack, broadcast) with minimal code.
Firebase FCM is widely used as a backend for mobile and web push notifications, and it integrates well with Laravel as long as you manage tokens and server keys securely.

12. Conclusion

Real-time notifications transform your Laravel app from "request-response only" to a live, interactive experience.

By combining Laravel Broadcasting, Echo, and a React frontend (plus optional Firebase), you can deliver user-specific updates instantly, keep your UI always fresh, and still maintain a clean, testable backend architecture.

References

[1] Laravel Documentation. (2025). Broadcasting. https://laravel.com/docs/12.x/broadcasting
[2] Rumpel, C. (2020). Laravel Real-Time Notifications. Retrieved from https://christoph-rumpel.com/2020/11/laravel-real-time-notifications
[3] Laravel Documentation. (2025). Notifications. https://laravel.com/docs/12.x/notifications
[4] Laravel-Docs. (2024). Event Broadcasting. Retrieved from https://laravel-docs.readthedocs.io/en/latest/broadcasting/
[5] Dev.to. (2025). Implementing Real-time Notifications Using Laravel WebSockets. Retrieved from https://dev.to/prateekshaweb/implementing-real-time-notifications-using-laravel-websockets-and-nextjs-a-complete-guide-1a2l
[6] iFlair. (2025). Real-Time Push Notifications in Laravel with Firebase. https://www.iflair.com/real-time-push-notifications-in-laravel-with-firebase/
[7] Pusher. (2024). Build Online Presence into Your Laravel App. Retrieved from https://pusher.com/tutorials/online-presence-laravel/

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

Laravel Event Sourcing: From Aggregates to Projectors

Lakashya Upadhyay — Tue, 27 Jan 2026 13:08:33 +0000

“Your app’s history is as important as its current state.”- Every Enterprise Developer Ever

Event sourcing is a powerful architectural pattern that treats every change in your application as an event. If you’re building complex systems where audit trails, historical data, and state changes are critical, Laravel event sourcing is a game-changer.

This guide walks you through mastering Laravel event sourcing, from setting up aggregates and projectors to building scalable, auditable applications.

Key Takeaways

Use aggregates for business logic and state management
Use projectors for read models and reporting
Use reactors for side effects
Version events and plan for migration
Ensure events are immutable and idempotent
Event sourcing makes your Laravel apps auditable, scalable, and maintainable.

Index

Why Laravel Event Sourcing Matters
How Laravel Event Sourcing Works
Aggregates vs Projectors
Setting Up Event Sourcing in Laravel
Creating Aggregates
Building Projectors
Handling Events and Event Queries
Using Reactors
Event Versioning and Migration
Common Mistakes to Avoid
FAQs
Interesting Facts & Stats
Conclusion

1. Why Laravel Event Sourcing Matters

Event sourcing ensures every action in your application is recorded as an immutable event. This makes it possible to:

Reconstruct any state at any point in time
Audit and debug changes easily
Build powerful reporting and analytics
Scale read and write operations independently Without event sourcing, complex applications often lose historical context and become hard to maintain. Laravel, with packages like Spatie’s laravel-event-sourcing, makes it easy to adopt this pattern.

2. How Laravel Event Sourcing Works (The Basics)

Event sourcing in Laravel revolves around:

Events: Represent changes (e.g., UserCreated, OrderPlaced)
Aggregates: Entities that record and replay events
Projectors: Classes that update read models based on events
Reactors: Classes that trigger side effects (e.g., sending emails) Example:

$user->create(['name' => 'John'])->recordThat(new UserCreated(['name' => 'John']));

Each event is stored, and the aggregate’s state is rebuilt by replaying events.

3. Aggregates vs Projectors

Aggregates:

Hold business logic and state
Record and replay events to rebuild state
Ensure consistency Projectors:
Listen to events and update read models (e.g., database tables)
Enable fast queries and reporting
Decouple read and write logic

4. Setting Up Event Sourcing in Laravel

Install the Spatie package:

composer require spatie/laravel-event-sourcing

Publish the configuration:

php artisan vendor:publish --provider="Spatie\EventSourcing\EventSourcingServiceProvider"

Create your event store migration:

php artisan make:migration create_stored_events_table

Configure your event store model and repository as needed.

5. Creating Aggregates

Generate an aggregate:

php artisan make:aggregate UserAggregate

Example:

class UserAggregate extends AggregateRoot
{
    public function createUser(array $attributes)
    {
        $this->recordThat(new UserCreated($attributes));
        return $this;
    }
}

Aggregates handle business logic and record events.

6. Building Projectors

Generate a projector:

php artisan make:projector UserProjector

Example:

class UserProjector extends Projector
{
    public function onUserCreated(UserCreated $event)
    {
        User::create($event->attributes);
    }
}

Projectors update read models for fast queries.

7. Handling Events and Event Queries

Events are stored in the event store. To query events:

$events = StoredEvent::where('aggregate_uuid', $uuid)->get();

Replay events to rebuild state:

$aggregate = UserAggregate::retrieve($uuid);

This allows you to reconstruct any state from events.

8. Using Reactors

Reactors trigger side effects (e.g., sending notifications):

class UserReactor extends Reactor
{
    public function onUserCreated(UserCreated $event)
    {
        Mail::to($event->attributes['email'])->send(new WelcomeEmail());}}

Reactors keep business logic and side effects separate.

9. Event Versioning and Migration

When events change, version them:

class UserCreatedV2 extends UserCreated
{
    // new structure
}

Migrate old events to new versions to maintain compatibility.

10. Common Mistakes to Avoid

Not versioning events
Storing mutable state in events
Overloading aggregates with too much logic
Ignoring idempotency in event handling
Not planning for event store growth

11. FAQs

Q. When should I use event sourcing?
When you need audit trails, historical data, or complex state changes.

Q. Can I mix event sourcing with traditional models?
Yes, use event sourcing for critical parts and traditional models elsewhere.

Q. How do I handle event store growth?
Use database partitioning, archiving, and optimization.

Q. What if an event is missing?
Replay events to rebuild state or fix the event stream.

Q. Can I use event sourcing for small apps?
Only if you need the benefits; otherwise, it adds complexity.

12. Interesting Facts

- Laravel’s event sourcing concepts
This covers why event sourcing works well for audit trails and fits Laravel/CQRS architectures.https://laravel-news.com/event-sourcing-in-laravel Laravel News
- MoldStud article noting debugging and audit trail benefits
Discusses how using event sourcing helps trace state changes and can cut debugging time by replaying events. https://moldstud.com/articles/p-managing-data-consistency-in-laravel-microservices-best-practices-and-strategies MoldStud
- Spatie Laravel Event Sourcing documentation
Explains how event sourcing in Laravel supports auditability and reporting needs.https://spatie.be/docs/laravel-event-sourcing/v7/introduction Spatie
- Event sourcing & CQRS patterns overview (general context)
Shows broader adoption of these patterns and why they’re used in event-driven architectures.https://medium.com/techartifact-technology-learning/event-driven-architecture-with-cqrs-event-sourcing-bdded2f3c595

13. Conclusion

Event sourcing is a powerful pattern for building robust, auditable, and scalable Laravel applications. By using aggregates, projectors, and reactors, you can decouple business logic, reporting, and side effects. Whether you’re building a CRM, banking app, or e-commerce platform, event sourcing ensures your system is maintainable and future-proof.

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

MySQL Index Optimization for Complex Laravel Queries

Lakashya Upadhyay — Fri, 07 Nov 2025 10:02:33 +0000

A developer's Guide for optimization. It will be very helpful if you’re going to create a DB from Scratch.

"Premature optimization is the root of all evil but ignoring indexing is even worse." -Donald Kunth

Key Takeaways

Analyze first, then optimize. Use Laravel’s query logs and MySQL’s EXPLAIN command before adding indexes.
Choose selective columns. Index fields often used in WHERE, JOIN, and ORDER BY clauses.
Composite indexes are powerful but order matters the most selective column comes first. Avoid over indexing. Too many indexes slow down writes and take up unnecessary storage.
Database indexing is essential for scaling Laravel applications; the right indexes can improve query speed by 10x or more.
Index maintenance is ongoing. As your data grows, periodically review and adjust indexes.

Index

Why Your Laravel App is Slow
What Are Indexes Really?
Finding and Fixing Slow Queries
Creating the Right Indexes
Fixing Common Laravel Performance Issues
Real World Examples
Quick Wins You Can Implement Today
Monitoring and Measuring Query Performance
What Not to Do
Key Takeaways
FAQs
Conclusion

Why Your Laravel App is Slow (And How to Fix It)

After building dozens of Laravel applications, I've seen the same performance issues over and over. Your app works fine with 100 users, but crashes with 10,000. This is due to Poor database indexing.

Let me share what I've learned from optimizing.

The Basics You Need to Know

1. What Are Indexes Really?
Just think of indexes like a phone book. Without indexing, you'd flip through every page to find "Lakashya Upadhyay." With an index, you jump straight to the S section. That's exactly what database indexes do for your queries

This query without an index scans EVERY row

SELECT * FROM users WHERE email = 'lakashya@addwebsoution.in'; 

-- With an index on email, it finds the row instantly 
CREATE INDEX idx_users_email ON users(email);

2. The Performance Results will be:

Faster reads, slower writes. Every index you add:

Speeds up SELECT queries
Slows down INSERT/UPDATE operations
Takes extra storage space See,You have to Choose wisely if the table is mostly used for fetch the Data Then Indexing will be the best option

"Good indexes make queries fly; bad ones make servers cry."

Finding Your Slow Queries

1. Laravel Query Log

// Add this to your controller temporarily
DB::enableQueryLog();

// Run your slow page
$users = User::with('posts')->where('status', 'active')->get();

// See what's really happening
dd(DB::getQueryLog());

2. The EXPLAIN Command

EXPLAIN SELECT u.name, COUNT(p.id) as post_count 
FROM users u 
LEFT JOIN posts p ON u.id = p.user_id 
WHERE u.status = 'active' 
GROUP BY u.id

Look for:

type: ALL (table scan - bad)
type: index or type: ref (good)
High rows count (needs optimization) This is a basic Example of how a query looks good but if we are talking about large data sets then a small indexes can make the filtering and query fast a lot that we can notice it with human eyes as well

Creating the Right Indexes

1. Laravel Migrations Made Simple

Schema::table('users', function (Blueprint $table) {
    // Single column - for WHERE clauses
    $table->index('email');

    // Composite index - column order matters!
    $table->index(['status', 'created_at']);

    // Foreign keys (Laravel creates these automatically)
    $table->foreign('company_id')->references('id')->on('companies');});

2. The Golden Rules of Composite Indexes

Order matters! Put the most selective column first:

// Good: status has few values, created_at has many
$table->index(['status', 'created_at']);

// Bad: created_at first makes the index less effective
$table->index(['created_at', 'status']);

Fixing Common Laravel Performance Issues

1. The N+1 Query

// This executes 101 queries (1 + 100)
$users = User::all(); // 1 query
foreach ($users as $user) {
    echo $user->posts->count(); // 100 queries
}

// This executes 1 query
$users = User::withCount('posts')->get();
foreach ($users as $user) {
    echo $user->posts_count; // Uses preloaded data
}

2. Inefficient WHERE Clauses

// Bad - can't use indexes
User::whereRaw('YEAR(created_at) = 2024')->get();

// Good - uses index on created_at
User::whereBetween('created_at', ['2024-01-01', '2024-12-31'])->get();

3. Missing Relationship Indexes

Schema::create('posts', function (Blueprint $table) {
    $table->id();
    $table->foreignId('user_id')->constrained(); // Auto-indexed
    $table->string('title');
    $table->text('content');
    $table->string('status');
    $table->timestamps();

    // Add this for common queries
    $table->index(['user_id', 'status']);
    $table->inindex(['status', 'created_at']);
});
$table->index(['user_id', 'status']);
 $table->index(['status', 'created_at']);
});

Real-World Example

1. E-commerce Product Search

// The query
Product::where('category_id', 5)
       ->where('status', 'active')
       ->where('price', '<=', 100)
       ->orderBy('created_at', 'desc')
       ->get();

// The index
Schema::table('products', function (Blueprint $table) {
    $table->index(['category_id', 'status', 'price']);
    $table->index(['status', 'created_at']); // For ordering});

2. User Dashboard with Posts

// Common query pattern
$user = User::with(['posts' => function($query) {
    $query->where('status', 'published')
          ->orderBy('created_at', 'desc')
          ->limit(10);
}])->find(1);

// Required indexes
Schema::table('posts', function (Blueprint $table) {
    $table->index(['user_id', 'status', 'created_at']);
});

3. Quick Wins You Can Implement Today

1. Add Indexes for Common Filters

// If you filter by status everywhere
$table->index('status');

// If you sort by created_at often
$table->index('created_at');

// If you do both together
$table->index(['status', 'created_at']);

2. Use Database Transactions for Bulk Operations

DB::transaction(function () {
    foreach ($data as $item) {
        User::create($item); }});

Monitoring Your Success

1. Simple Query Time Logging

// In AppServiceProvider::boot()
DB::listen(function ($query) {
    if ($query->time > 1000) { // Over 1 second
        Log::warning('Slow query', [
            'sql' => $query->sql,
            'time' => $query->time . 'ms'
        ]);
    }
});

What NOT to Do

1. Don't Over-Index

// Bad - too many indexes
$table->index('name');
$table->index('email');
$table->index(['name', 'email']);
$table->index(['email', 'name']); // Redundant!

// Good - strategic indexing
$table->unique('email');
$table->index(['name', 'email']); // Covers both columns

2. Don't Index Low-Selectivity Columns

// Bad - gender has only 2-3 values
$table->index('gender');

// Good - email is unique per row
$table->index('email');

Doing Column Indexing is good approach but make sure use indexing for the field which don't have multiple values just like above example of gender field.Use Indexing for fields which don’t contain common values in it

“Fast apps don’t happen by accident; they happen by design and indexing is part of that design."

The Bottom Line

Measure first - Use query logs and EXPLAIN
Index strategically - Focus on WHERE, JOIN, and ORDER BY columns
Watch the order - Most selective column first in composite indexes
Monitor continuously - Set up slow query alerts
Test everything - Indexes can sometimes hurt performance

Quick Reference

1. Most Common Indexes You Need

// Users table
$table->unique('email');
$table->index('status');
$table->index(['status', 'created_at']);

// Posts table
$table->index(['user_id', 'status']);
$table->index(['status', 'created_at']);
$table->index('slug');

// Orders table
$table->index(['user_id', 'status']);
$table->index(['status', 'created_at']);
$table->index('order_number');

2. Essential Laravel Query Optimizations

// Eager loading
User::with('posts', 'comments')->get();

// Select specific columns
User::select('id', 'name', 'email')->get();
// Use exists() for boolean checks
$hasActivePosts = Post::where('user_id', $id)->where('status', 'active')->exists();

// Chunk large datasets
User::chunk(1000, function($users) {
    // Process users});

Start with these basics, measure your improvements, and slowly and gradually we will achieve an environment where the system gets well optimized and easy to manage.

FAQs

Q. What’s the best way to find slow queries in Laravel?
Use DB::enableQueryLog() during development or set up a listener
in AppServiceProvider to log queries taking more than 1000ms.

Q. Should I index every column used in WHERE clauses?
No. Only index columns with high selectivity (many unique values). Avoid
indexing low-selectivity columns like gender or status with few distinct values.

Q. How do I test if an index is helping?
Use the EXPLAIN command in MySQL and compare query execution times
before and after creating the index.

Q. Can too many indexes hurt performance?
Yes. Each index must be updated during INSERT and UPDATE operations, which
can slow write-heavy tables.

Q. Do Laravel migrations automatically create indexes for foreign keys?
Yes. When you use $table->foreignId()->constrained(),
Laravel automatically indexes that column.

Interesting Facts & Stats

Database performance accounts for nearly 70% of backend bottlenecks in web applications. Source: Percona Performance Blog
Proper indexing can reduce query time by up to 95%. Source: MySQL Performance Blog
The N+1 query problem is responsible for up to 80% of unnecessary queries in unoptimized Laravel apps. Source: Laravel News

Conclusion

Optimizing your Laravel application starts with understanding your database queries. Proper MySQL indexing is not just a technical detail it’s the foundation for a fast, scalable, and maintainable application. By strategically adding indexes to high-selectivity columns, using composite indexes wisely, and monitoring query performance, you can achieve massive improvements in read efficiency without compromising write operations.
Combine this with Laravel-specific best practices like eager loading, query chunking, and avoiding N+1 queries, and you’ll create an environment where your application can handle growth smoothly. Remember: measure first, index smartly, and monitor continuously performance doesn’t happen by accident; it happens by design.

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