README

This package helps detect N+1 query problems in Laravel applications, especially in Blade views.

Installation

composer require kirkill823/laravel-nplusone-detector

Laravel auto-discovers the package service provider in most cases, so no manual registration is required.

Publish the config

php artisan vendor:publish --tag=nplusone-config

This creates config/nplusone.php.

Basic configuration

// config/nplusone.php
return [
    'enabled' => env('NPLUSONE_ENABLED', env('APP_ENV') === 'local'),
    'strategy' => env('NPLUSONE_STRATEGY', 'log'), // log, exception, both
    'threshold' => env('NPLUSONE_THRESHOLD', 3),
    'block_blade_queries' => env('NPLUSONE_BLOCK_BLADE_QUERIES', true),
];

You can also configure it through your .env file:

NPLUSONE_ENABLED=true
NPLUSONE_STRATEGY=log
NPLUSONE_THRESHOLD=3
NPLUSONE_BLOCK_BLADE_QUERIES=true

Available modes

log — writes warnings to the Laravel log only.
exception — throws an NPlusOneException and returns HTTP 500.
both — logs the warning and throws the exception.

Important

This detector is intended mainly for local development and testing. In production, it is best to keep it disabled or use a very strict configuration.

Example

@foreach($users as $user)
    {{ $user->posts->count() }}
@endforeach

If this pattern triggers repeated queries inside a loop, the package will detect them and report the file and line where the query was triggered.

Have you ever had a Blade page take several seconds to render without knowing why? By the time you suspect N+1, you have already checked everything from a clogged cache to a slow internet connection.

I once ran into this problem too. I realized it was N+1, but before I could confirm it, I had to rule out several other possible issues, which took time. This package helps you eliminate the N+1 issue early and quickly.

It is also possible to track queries coming specifically from Blade and block them to encourage a stronger "all data should be prepared in the controller" approach.

Why do you need another N+1 detector?

Laravel's built-in preventLazyLoading is useful, but it works on an all-or-nothing basis: either it does nothing, or it crashes the application. My package offers two modes: "soft" (logging only) and "strict" (returning a 500 error).

It groups queries by their origin in the code, making it much easier to find the source of the problem in large projects.

kirkill823 / laravel-nplusone-detector

Maintainers

Package info

Statistics

Security